No dependency or external DLLs?

I am looking into making a lightweight single application in xojo, can someone please guide me into how I can have just a single file contain all the DLL files needed.
Thanks in advanced.

for Windows?
Use Real Studio 2008 R1 to build it.

http://www.molebox.com turns your Xojo Windows app, sub-folders and DLLs into a single .exe.

I thought that the Xojo folks had thoroughly researched putting everything into an .exe and found that it led to problems. Is the Molebox solution different somehow?

That’s a good question. I did some tests the other day with a complex app, and some things worked fine. Some things (such as showing a HTMLViewer that used ActiveX plugins) did not work. I’m not sure what to make of it.

In addition to molebox there are some other similar ones, such as http://boxedapp.com/ and http://enigmaprotector.com/en/aboutvb.html

Also, note that RB 2011 R3 was the last version to make single-file EXEs (if your code is pure RealBasic code and declares - e.g. you did not use any internal or external plugins).

I even recall reading that Microsoft specifically told them not to do it anymore.

We have
It was recommended to us by MS engineers to do what we do now
Security issues was a reason to move to separate dll’s
Plus the way MS patches or loads “shims” for various applications
With the old scheme we’d get crashes like
http://forums.realsoftware.com/viewtopic.php?f=5&t=21215&p=112681&hilit=c+runtime+initialized#p112681

MoleBox creates a single .exe application that creates an ‘on the fly’ virtual drive and then runs your Xojo app from within this virtual drive. You can access your files within this drive, but cannot access these virtual files from outside the virtual drive.

There may be caveats in the use of MoleBox and Xojo but we haven’t found them — except maybe that if you need access to files from multiple Xojo apps you may need to copy it outside the MoleBox .exe first or accessing a file via ShowURL e.g. downloading a PDF as a WebFile.

Norman, does that sound like it would address the problems the MS engineers were talking about or not? Isn’t this similar to what Xojo did before? (I seem to remember something about the old single-file exe’s loading the DLLs into memory.)

I might be wrong, but it’s the other way around. The MS way requires that the system-level calls take precedence, but making it all a static bundle forces the local dlls always.

I might be misunderstanding. I always thought that the problem was this, though.

Not to steal Normans spotlight but the old “single file” binary of 2008 used static libraries which are slightly different that dynamic link libraries (dlls)… They contain the “same” code in essence but can be directly bound together and require no external influence. The problem with static libraries is they require every plugin to be built using the same version of the c runtime library (causes all kinds of side-by-side assembly problems otherwise and instant crashes). Dlls allow any c runtime library version to be used, where static libraries do not.

You could recreate mole simply by binding your files together in a xojo-written packer that creates a ramdrive (a virtual disk space that exists in memory only) at startup, extracts the contents to the ram-drive, and launches the main application exe. This is how a number of my installers are made for Windows. When the program is closed, the ram-drive is destroyed and no files remain.

Very interesting - what API are you using for this?

There are a number of command-line ramdisk options. Add to your Xojo project (drop it in your window) at startup see if the ramdisk command-line file exists, if not write it to file. Send the command via shell to make the appropriately sized ramdisk (to fit your software and libs folder plus any additional resources you added), extract your zipped app to the ramdisk, create a folderitem and point it at your app exe, then use folderitem.launch to start it. Since 100mb app will take about 6…7 seconds to extract to the ramdisk (remember ramdisk has better performance than a solid state drive. … Thus faster extraction in memory vs. to disk), I usually add my splash screen to the single file bound project instead of the extracted exe… to be displayed while the extraction is taking place.

I use Thomas temples zip classes by the way…

Matthew, thanks. I have an installer that I built a while back which does it the “old school” way : upon launch, unzips the EXE and DLLs folder to a new folder in %TMP% and then launches the EXE.

Do you have any opinion on which is more or less likely to trigger antivirus warnings?

  • RAMDISK way requires (in some cases) one DLL to be copied to the C: drive, then the rest of the files are run from RAMDisk
  • TMP Folder way requires many DLLs to be copied

[quote=90179:@Michael Diehr]Matthew, thanks. I have an installer that I built a while back which does it the “old school” way : upon launch, unzips the EXE and DLLs folder to a new folder in %TMP% and then launches the EXE.

Do you have any opinion on which is more or less likely to trigger antivirus warnings?

  • RAMDISK way requires (in some cases) one DLL to be copied to the C: drive, then the rest of the files are run from RAMDisk
  • TMP Folder way requires many DLLs to be copied[/quote]
    And those options will flag your app as a security risk on everything since Windows XP SP3 unless the user completely disables UAC and they aren’t running real time virus protection. Been there, suffered through that.

Trust us. A real installer that properly places your required files is the best (and only MS approved) solution.

Tim

[quote=90198:@Tim Jones]And those options will flag your app as a security risk on everything since Windows XP SP3 unless the user completely disables UAC and they aren’t running real time virus protection. Been there, suffered through that.
Trust us. A real installer that properly places your required files is the best (and only MS approved) solution.
Tim[/quote]

Tim - can you explain? When you say “real installer” what do you mean?

On windows, there are literally dozens of different installers of a wide variety (from MSIs to InnoSetup to … ) and my experience has been that as long as the installer file (whatever flavor) has a proper code signature, that OS will let it run.

It will be allowed to run, but the user will be warned and you’ll get false positives from many realtime virus/malware tools.

All of the installers that “install” your app are what I mean by “real installers”.

What the request for a single Windows binary almost always translates to is that the developer just wants a single file that they can drop onto a user’s system and have it run with no further effort. Depending on the installer tool that you use, creating an installer for a RS/Xojo app can be quite a task. I still keep an old copy of Windows Installer Tool (circa WIndows NT 4) on a Windows XP box so that I don’t have to learn another programming language. Back at Archive in the early 90’s, we had two guys who did nothing but code the installer scripts for our driver packages.

OK, I think we are in agreement. What’s not entirely clear is how this happens: I believe that antivirus software makers, as well as microsoft, keep lists of “known safe” and “known dangerous” and “unknown” applications - so what happens is that if you write your own installer, it is going to fall into the “unknown” category. “Real” installers are not magically different, but rather they’ve just been around enough that they are recognized as “safe” by various scanners.