Cannot Compile Embedded files in sub-folders of @lib$

[circe]

When compiling with a compiler directive: REM!Embed @lib$+"filedlg.bbc" works OK, but if it references a sub-folder: REM!Embed @lib$+"custom/filedlg.bbc", it will appear to be OK, but on clicking TEST, an error message
"Couldn't copy C:\Program Files (X86)BBC BASIC for SDL2\lib\custom/filedlg.bbc" appears and the compile fails.

The compiler directive uses Forward-solidus (/), but sone Reverse-Solidus (\) appear in the Error Message, which are not part of the compiler directive.

The files referenced DO exist.

[Richard Russell]

When compiling with a compiler directive: REM!Embed @lib$+"filedlg.bbc" works OK, but if it references a sub-folder: REM!Embed @lib$+"custom/filedlg.bbc", it will appear to be OK, but on clicking TEST, an error message
"Couldn't copy C:\Program Files (X86)BBC BASIC for SDL2\lib\custom/filedlg.bbc" appears and the compile fails.

@lib$ does not have any sub-directories (and you are not expected to create your own)! If I change @lib$ to @dir$ I cannot reproduce the error. Try making the same change:

Code: Select all

      REM!Embed @dir$+"custom/filedlg.bbc"

The compiler directive uses Forward-solidus (/), but sone Reverse-Solidus (\) appear in the Error Message, which are not part of the compiler directive.

No, they are the same. You can see that if you PRINT the compiler directive, as follows:

Code: Select all

      REM!Embed @lib$+"custom/filedlg.bbc"
      PRINT @lib$+"custom/filedlg.bbc"

You will see that the use of forward-slash (/) and backslash (\) is identical in the error message and in the compiler directive. As the two are equivalent in Windows (apart from in the shell), it doesn't matter which is used.

[circe]

Yes, but it seems logical that a Custom version of a file legitimately in @lib$ should be in a sub-folder of @lib$.
My other (personal) objection to using @dir$ is that if you use separate folders for projects, the custom folder has to be copies to each project folder . Having such files in a Fixed location is advantageous.
Enabling sub-folders of @lib$ avoids having custom files in @lib$.

[Richard Russell]

Yes, but it seems logical that a Custom version of a file legitimately in @lib$ should be in a sub-folder of @lib$.

I'm happy to record that as a feature request, but I wouldn't want to offer much hope that it will be implemented any time soon.

Something to bear in mind is that if you install BBCSDL 'conventionally' on a Windows machine the libraries are stored in a protected folder (under C:\Program Files (x86)\) which is not writable by an ordinary user. So if you want to copy custom libraries there (whether in a sub-directory or not) you would have to do so 'as administrator' which is potentially a security risk.

Similarly @lib$ is a location shared by all users of that machine and therefore I would argue that a custom library, which is almost by definition specific to a particular user, ought not to go there but should rather go somewhere user-specific, which @dir$ should be. I know it's uncommon for a 'home' Windows PC to have multiple users but that's how Windows is designed and 'properly engineered' applications should follow suit.

My other (personal) objection to using @dir$ is that if you use separate folders for projects, the custom folder has to be copies to each project folder . Having such files in a Fixed location is advantageous.

One solution to that is to use links. You could put your custom library in one place, common to all projects, and then add a link (in each project which uses the library) to that common location. That offers the best of all worlds, only those projects which use the custom library have access to it, but there's only one copy to maintain.

File and directory links are a powerful feature of most modern Operating Systems, and are not used as much as they could usefully be in my opinion.

[circe]

Brilliant
Thanks Richard.

[circe]

Unfortunately, this does have the disadvantage, that being linked from @dir$, whenever the compiled program is run, the linked folder is dumped out . This may mean that Intellectual Property is made freely available . This would not be true of a sub-folder or linked folder of @lib$, but this is not possible (see subject).

[Richard Russell]

Unfortunately, this does have the disadvantage, that being linked from @dir$, whenever the compiled program is run, the linked folder is dumped out

Although embedded files in @lib$ are slightly harder to find than those in @dir$ neither location is in any way 'secure' and shouldn't be used to store files that you want to keep secret. Indeed whilst files in @dir$ are in principle readable only by the current logged-in user files in @lib$ are readable by anybody!

Also bear in mind that embedded files in MacOS, Linux, Android and iOS 'application bundles' (whether in @lib$ or @dir$) are even easier to find and copy than they are in the case of a Windows executable. Typically you simply have to 'open' the bundle file (e.g. the .dmg file in the case of MacOS) and there they are.

This may mean that Intellectual Property is made freely available.

"Freely available" is something of an exaggeration. Reverse-engineering a BBC BASIC program embedded in an executable is not a trivial task, whether in @lib$ or @dir$. I tried doing that once with a program written by David Williams, I didn't get very far.

[circe]

But if the data is in a linked file under @dir$ it is presented on a plate (or in a folder) and does not require any reverse engineering. Also, the end user may not want the data, but he/she gets it without the option, which can lead to complaints.

[Richard Russell]

But if the data is in a linked file under @dir$ it is presented on a plate (or in a folder) and does not require any reverse engineering

You're now talking about something different. Yes a data file of some sort requires no reverse engineering, but that would properly be stored under @dir$ anyway, so the issue under discussion in this thread (sub-directories of @lib$) isn't relevant.

What you were previously talking about wasn't a data file it was a custom library. A custom library is a BBC BASIC program, which does require reverse engineering to reveal its 'secrets' and therefore putting it in @dir$ rather than @lib$ doesn't result in a significant weakening of security.

Also, the end user may not want the data, but he/she gets it without the option, which can lead to complaints.

Most non-trivial programs need resources, which may for example be graphics images, music, code modules, sound effects, icons, 3D models etc. It's these resource files which belong under @dir$, whether the user 'wants' them or not. In fact the whole concept of the user 'wanting' files which are a necessary part of an application is a bit daft, in my opinion.

Take for example David Williams's Forces of Darkness application. It has a total of 484 resource files: 41 data files, 263 graphics images, 91 code sub-modules and 89 music & sound-effects files. Do you think the 'user' would complain if a custom library was added?

The bottom line is that resource files go into @dir$ (or subdirectories thereof) and libraries go into @lib$. If you have one or more custom libraries put those in @dir$ along with the other resources, just as (non-library) code sub-modules are.

I'm locking this discussion now.