[quote=181377:@Alain Bailleul]Didn’t know that So technically it wouldn’t be a big problem for Xojo to point every exe to a relative path where the dlls are (with a setting in the IDE). Our current structure look like this:
Theoretically, with such a parameter, it could become this, which would be a huge impovement for us:
SYSTEM\0001\0001.EXE -> points to …\Libs\
SYSTEM\0002\0002.EXE -> points to …\Libs\
…
SYSTEM\0050\0050.EXE -> points to …\Libs\
SYSTEM\Libs\x.dll[/quote]
To my understanding you would need to do something like:
You can remove the libs folder entirely if the apps are all created with the same version of xojo/rs, and when running the installer, install the libs to system32. I have quite a few products that work in this way so that the user doesn’t have 2GB of application material when only 80MB is actually required
Would it be just as easy to use a manifest editor and change the invoker of the primary exe? This way if the application is installed with admin privileges, it will always run with admin privileges bypassing UAC.
A lot of magic can be achieved with the “dark arts” of manifest editing. This is how console/gui applications two-in-one applications work after the advent of .NET.
ALternatively, you can make the installer install the application creating a scheduled task and invoking:
schtasks /run /TN “{Name of task}”
from the commandline. This will permanently elevate the application privileges silently. The application will start bypassing UAC, with the highest elevated privileges
Aha! If that works, maybe adding my libs folder (c:\OneTwo\SYSTEM\Libs\) location to the PATH variable could also work. Or creating a “Xojo Framework Setup” that includes all Xojo Dlls. The user of my apps have to install this only once. (Same way as installing “the .NET framework”). Good tips @Matthew Combatti
Installing them into system is probably not the bets place to put them as if some other installer overwrites the versions your installer puts there, say from and older or newer version of Xojo, then you have DLL hell.
Next to the exe is the safest to avoid this problem.
We have over 100 exes in the same folder (all compiled by the same IDE version, of course) and we put the .dll files in that same folder so they all share them.
Using Themida with its XBundler add-on I was able to pack all my stuff from the Resources folder together with the XojoGUIFramework32.dll. This has two advantages: The massive Framework dll shrinks in size by about 60% (excluding the size of the Resources folder) and my Resources Folder is empty (the Folder is still needed, though). Unfortunately packing the main executable is not supported due to Xojo internal quirks.
The disadvantage: cost.
Perhaps other exe bundler tools might be able to do similar things, has anybody tried some on the framework dll?
[quote=203234:@Thomas Zobl]Using Themida with its XBundler add-on I was able to pack all my stuff from the Resources folder together with the XojoGUIFramework32.dll. This has two advantages: The massive Framework dll shrinks in size by about 60% (excluding the size of the Resources folder) and my Resources Folder is empty (the Folder is still needed, though). Unfortunately packing the main executable is not supported due to Xojo internal quirks.
[/quote]
Its more correct to say Themida doesn’t support the things that Xojo apps do which are ALL supported OS API’s
They might be unusual but there’s nothing illegal/unsupported etc
A packager that properly supports the required OS APIs would NOT have any issues
Few, if any, do
[quote=181348:@Joost Rongen]Going back to the beginning of this conversation… would it be a good option to store all the graphics and language stuff in a SQLite database sitting next to the EXE ?
Does anybody have the experience with encrypted SQLite databases ?[/quote]
To give you short answer: Yes! I am using encrypted sqlite files as license files for years in both Mac and Windows. They work per user in I am placing them on initial start or via drag & drop of license files in the Users’ Appdata folder (where every windows programm should place its user-based data).
And yes couple of years ago I’ve made a bunch of programs for a customer who needed on-the-fly language switching. Check this sample on my webpage: http://www.jakobssystems.net/projekte/multi-language/ it’s in german but the video shows the big picture. All Texts and different languages were stored in a database.
@Tomas Jakobs : nice webpage too.
Language data in a database that belongs to the program EXE, my idea. I did that long ago and had success with it because I provided a tool to the translaters to enter their translations. In fact it was an unlimited number of languages.
I was thinking of adding the same to my Xojo template, but so far no request for it and a lack of time of course.
Because of the open resource-folder we have, I was looking for a good packer tool. Using that sometimes now, but none are 100% satisfying, so my plan is still to have a sort of resource-database rather than a resource directory.
So technically it wouldn’t be a big problem for Xojo to point every exe to a relative path where the dlls are (with a setting in the IDE). Our current structure look like this: