With release 2015r2 the releasenotes claim that EXE builds should be smaller.
But, to my horror I see what happens: graphics are not compiled in anymore but placed as pure *.jpg in a resource directory next to the EXE-file. The build has a pointer to the graphics file, which can easily be replaced by the end-user. Splashscreen, logo etc. According to me this is undesirable.
For now I prefer building with 2015r1 rather than 2015r2. Why ? Why doesn’t the R&D team provide an option when they decide to change the approach ?
Does anybody see a simple workaround to avoid a resource directory ?
A related question: is the folder name hard-coded to “Resources” or can it be changed, for example to “My App Resources” - this would be necessary if we need to have multiple Xojo apps residing in the same parent folder, e.g. living in the %win32% folder.
I just thought of another problem: if the resources are in a separate folder, they can’t be part of the authenticode / signcode code signature : this seems to pose something of a security risk.
I like the smaller DLL’s and .EXE’s, but the separate Resource folder thing should be a selectable option for those who require security or signature things, or don’t want their graphics or sounds changed.
We had several bug reports about resource compilation and runtime memory usage, which was anywhere from 2x-4x what it should have been on Windows compared to a platform like OS X that used separate resources. That’s because we had to generate the executable image as a whole there, including all general resources. We didn’t want Windows at a disadvantage any more and wanted to resolve the memory problems, so we made the shift. Microsoft also does not recommend large general resources in the executable itself.
We’ve shipped our own product with external resources for a while before we made the shift generally and haven’t had a problem. If you have particular reason to be concerned about a resource changing- you could do a quick MD5/SHA1 check, store them in a SQLite file, or any number of things. That advice is the same whether resources are inside an executable or not. Most resources don’t warrant that level of concern, though.
Thanks, Travis - can you comment on the search path? I know with the “Libs” folder there are a few options. How are Resources located?
Right now they are in a single Resources folder. If you have the need to install multiple apps in the same path, and those app’s resource names would conflict with each other (which in combination is fairly rare, but not impossible)- track/favorite this Feedback: <https://xojo.com/issue/38871>
Thanks - I would also direct folks to the old FR which is to have better error trapping for missing Libraries : <https://xojo.com/issue/14520>
Would this also resolve issues with writeable files giving errors sometimes if they were in the same folder right in the .EXE path? If they’re in the Resources folder, they should work correctly if I need to write to a text file, right?
If I understand what you’re asking, that’s a wholly separate question. You should never expect to be able write to an installed directory inside of Program Files- those should be treated as read-only. You should use your own folder inside of something like SpecialFolder.ApplicationData to read/write any changing data.
Heh, yep. I was trying to avoid the whole awkward AppData setup. Thanks.
Of course this is the way to avoid files from being changed and check existence of the resources, but it seems that this approach change came as a surprise, at least to me.
When output (build) is not expected to be the same as it was in prior release, more attention should be given to it in the release notes.
@Travis Hill : yes I think finally it’s better not to compile unlimited resources into the EXE, even no language related data etc. , but for now it would be very nice to have compile option to stay compatible which the prior approach.
A ha, about the release notes: we get a second chance since r2.1 is coming next Monday.
This change is certainly in the included r2 release notes (37660). It isn’t something we can (or should) give as an option, as we are now unified across platforms and follow platform guidelines. It not only addressed several other cases (compile memory usage, runtime memory usage, image size/translation to BMP)- but it is important for our other planned features going forward.
Thanks for your in dept reply Travis.
I didn’t know images were converted to .BMP; i’m glad that isn’t happening anymore.
BTW once one accesses a resource that has dragged into the IDE, is it loaded into memory? If so is there anyway to free the memory used or does it stay in memory until one quits?
When one loads pictures from a file with code, you have control over how long to stays in memory. (which is what I usually do- I use a CopyFiles build step to put them in the Resource folder)
If a resource dragged into the IDE stays in memory after being accessed, it would be good to have an UnloadResource type method. In that case the need to use CopyFiles Build steps would be rarer and handling resources would be more user friendly, particularly for beginners I think.
- Karen
I have a suggestion for the security aspect. Create a list of every file that you read from the resources directory with a hash of each one. If something changes, you’ll know.
This is just insane, from inconvenience and from security. To have to sit and hash your “embedded” images is the result of someone’s really stupid idea. ( Even if that is MS, who are notorious for doing stupid things with software ).
You don’t have to hash them, I was only suggesting it as a way to tell if they’ve been changed. Fwiw, even embedded in your app, they could be changed with a resource editor, and they’re not all that hard to come by.
If you’re really worried about resources like a splash screen being changed, you could still embed it in your app as a base64 string, or just make sure that the text is made of labels instead of burned into the splash screen image itself.
You could go one step further and save the hashes to a file and then Create an RSA signature of that file. Then you can be sure that the images AND the hash file haven’t been tampered with.