I have a project where to support older systems we have to include the runtime DLLs. This project also is best delivered as a portable app, an installer is just not part of the vision. So, the runtime dlls can be a bit cumbersome.
I came up with a way to tuck them inside a folder and then use a relative link to point to the real executable. This worked well for quite a long time. Microsoft issued an update for Windows that broke this very procedure though - relative links can no longer come from outside sources.
To maintain the tucked away DLLs packaging, I came up with a workaround in RealStudio 2011r3 that does essentially the exact same thing. This is the entirety of the Xojo code for the launcher app. It worked well for a few months, but now this app is being flagged by Windows Defender as malware. Somewhere along the way it now matches a known-false positive trigger, so recompiling doesn’t really help. Compiling with RealStudio 2012r2.1 ends up with extra libs.
I am looking into options for how to maintain this relative link / launcher packaging and am running out of simple ideas. I’m wondering if any Windows experts here have any clever ideas. My ideas so far include writing a .bat file that does essentially the same thing, and writing the launcher in a different tool. Each has a drawback. I know that app packers don’t play friendly with Xojo on Windows, so unless someone has a recommendation for one that does work with Xojo this is off the table.
Are there any tricks to tucking away the runtime DLLs?
I do something similar as what you mentioned for the Windows portable versions of my apps. I use a different compiler that creates a tiny program that basically just executes my main program. This program sits in my apps main directory and the real program and all .dll’s, etc get tucked away in a sub-folder called ‘App’. The trick is that the loader program and the main app cannot be called the same name (even when in different folders) or it will most likely be flagged as malware as you have experienced. I just add portable to the end of the program name for the loader program. For example, the main folder will have a folder called ‘App’ and a program called ‘LAN_SpeedTestPortable.exe’. The LAN_SpeedTestPortable app will execute LAN_SpeedTest.exe within the ‘App’ folder. I think that all you have to do is alter the RealStudio’s loader’s name, and it should work again for you the way that it used to. Also, your loader app will just look inside the ‘App’ sub-folder without caring about where the program is located on the customer’s computer. If you were to try to build a loader script using a .bat file, I believe that you would always have to know the full path to the sub-folder.
Just WHY?
Because DLLs look ugly?
Just put all the files in a folder and a shortcut on the desktop/Start Menu, as any other app.
Using a SFX rar seit it up to decompress on a path and launch the EXE with the option of NOT overwrite files
Just set the attibutes of the DLLs as Hidden system files
Etc. No need to use obsolete packaging
Because there are lots of users that won’t buy the program unless it’s a portable app - especially with utility programs. They like to run the portable app from USB Flash Drives, etc. Yes, you could supply the portable app the way that it is straight from Xojo’s building process, but when the program is buried among the .dlls and Window’s runtime .dlls, it’s confusing to the user and not very professional. Most power users have their Window’s settings set to show hidden folders, so hiding the .dlls does not work most of the time. Doing it as described above is a much cleaner way of doing it.
Unsure how you get the app onto the portable device unless you ship an installer.
Zip file?
If you have a Launcher app, and an App folder
Launcher.exe
App Folder
Real.exe
DLLs
Resources Folder
Stuff
Then as above, you could make Launcher.exe kick off Real.exe
Launcher.exe doesnt have to be fancy.
A VBS script would do it.
I use a VBS editor which compiles to an EXE in deference to Forum rules, I won’t name it here, but google VBS compiler and there are 4 decent hits on the first page.
Well, we can always make a launcher with Visual Studio.
But may a .bag file work, too?
This I did not know about! Thanks, I will have to give that a try.
@Ivan - It’s simply the way this software package is used by the customer. I have to tuck away my BUT WHY sometimes.
@Jeff - Thanks. The launcher exactly what I’m trying to sort out 
@Christian - Thanks, I may be in touch.
@Julian - What a handy link that didn’t come up in my searching! Thank you.
I’ve used the WinBatch+Compiler product to write this sort of simple launcher or glue programs in the past (that was with .Net programs, which have a similar issue of many, many assembly .dll files). We also wanted a clean portable app that could be easily understood by a user and installed from a ZIP file without much fuss.
If you don’t want to spend any money then this is not the ideal solution but Smart Packer is sold here on the Xojo Third Party tools page.
https://www.smartpacker.nl
This packages Windows EXE’s and DLL’s into a single executable and even a virtual file system if needed.