[quote=183833:@Michael Diehr]Old versions of REALbasic made single file EXEs, which are sometimes useful or necessary. More recent ones could still do this as long as you avoided plugins. The newest one can’t.
Suppose you still need on occasion a super-lightweight single-file EXE for a specific task.
Any suggestions on how to get it done?
Use an old version of REALbasic
Use the latest Xojo with an application packer
(Please, for the purposes of this discussion assume that the need for a single-file EXE is absolute, so suggestions such as “InnoSetup” aren’t viable).[/quote]
Packers seem to have issues with the most recent Xojo. I tried enigma which simply does not work at all, Molebox seems not to like much the very latest Xojo. Maybe there are things I should know, but when something does not work right away, it does not look good for stability.
I still keep an older version of Real Basic handy if a single file EXE is needed. We tend to underestimate the excellent stability of Real Basic and unless you absolutely need features specific to Xojo, it gets the job done very nicely.
Visual C++ is probably nice if you dig it. Visual Basic only if you absolutely need features RB does not have, IMHO.
The Windows REAL2007r3 is I think the last to do single-file EXE’s. That’s what I keep around.
Of course the usual warnings about possible instabilities (which is why REAL stopped doing it) but we all know in regular practice any issues were rare. Probably bigger apps (with more irons in the fire) ran into problems. But I use the single file .EXE for extremely simple things, usually in conjunction with a bigger non-single app.
Digression about REAL crashing? Well, REAL never crashes on me. (Although the Windows one does way more than the Mac, so I just compile Windows on the Mac. I use the Windows IDE as rarely as possible.)
I meant the executables. Actually, in 11 years or so of RB I had much less issues of executable stability under Windows than Visual Basic. For Mac the system itself as well as the hardware base went through motions that, IMHO, were pretty well managed by the company.
And, no, I am definitely not a nostalgic of RB. I switched over Xojo since 2013R1
Hm - indeed - Visual Basic as Xojo itself makes single-file EXE, but those are not independent. If you want quick results and small independent EXE, then I can suggest PureBasic. Just seek it with Google.
And off course - for example with WinRar you can make single executable file that silently unpacks all needed files and starts the main one.
[quote=183897:@llarKruustik]Hm - indeed - Visual Basic as Xojo itself makes single-file EXE, but those are not independent. If you want quick results and small independent EXE, then I can suggest PureBasic. Just seek it with Google.
And off course - for example with WinRar you can make single executable file that silently unpacks all needed files and starts the main one.[/quote]
The main interest of RB2007 is that it does not need a rewrite of the code. Or a minimal one, when PureBasic is another language.
Yep - I know that, but as there were Visual C++ and Basic in asker list, I thought that adding one more different - and much easier - to list, is not a crime.
And last, not least, to my previous reply as I studied it little bit more - with WinRar you can even change selfexecutable file icon. So I think it is easiest way to write program in Xojo, then pack it with WinRar or with another packer to silent selfexecutable file with autostart and here we have one executable as wished. And what is more important - with Visual Basic this is not doable because there may be possibility that some depedency files needs a registration in Windows system where they will be copied first time.
I feel like an ancient one to say this, but back in the day Real Basic could generate a standalone executable file, but the Compiler Gods needed to consult with the MS God & found that this plan could leave us poor developers with an unstable product. So after consulting with the MS God the Compiler Gods fixed the BUG.
So if you Young’uns would prefer to live with the bug then go for it, but don’t bitch here when it all goes wrong for you.
Oh and by the way I’m calling you Young’uns because you obviously don’t remember DLL HELL - I do and never want to go there again!
It’s surpricing that Older’ly like you did not understand that sometimes is certainly better give for dumb users (and world is full of them) one file and tell them that execute this for quick results, instead of explaining how and where to copy punch of files or how to install them. I think that Michael question and wish for one-file-executable is justified.
But yes - DLL HELL is awful thing and therefore I mentioned in my earlier post that with Visual Basic executable my suggested way about packing all files to one selfexecutable file may not work in every Windows computer, but Xojo result will work fine. Proved.
I don’t know what is worse : having cohorts of DLL files spread across the universe that regularly end up missing, or a single Libs folder. The Resources folder is another, somewhat more modern thing. Before Mac OS X became Unix, there was no Resources folder either. Resources were tucked inside the executable.
The world produces an amazing amount of better idiots. Yet, the typical Windows user usually just uses an installer and never bothers looking at what is in his application folder.
The only place where the Libs and Resources folders are truly getting in the way is for Console, where the immense majority of programs come as a single exe.
The old single file format (and I paraphrase here) used to load code and resources internally on the fly instead of using external DLLs. So DLL hell was avoided.
But the ‘trouble’ (and I never encountered this myself) was apparently due to Windows/Virus checkers thinking this was virus-like behaviour.
I seem to recall the RB team saying it could cause instability too. Again, never encountered that myself.
The virus false positives was one issue but the main issue is that Microsoft issued compatibility shims for different hardware platforms and having the DLLs packed into the EXE then loaded to memory using their own loader bypassed those shims. So the only way to track down those bugs when they happened is if you had the exact same machine and even then you couldn’t fix it.
Checking my notes, I believe that 2011R3 was the last version to make a single file EXE - but only in the case that you avoid using certain features (e.g. BevelButton which was implemented as in internal plugin, as well as any other plugins). I would assume that this would be “safer” than using one of the earlier versions which did the “plugins-in-memory” magic, but as others have mentioned there were lots of folks safely using those versions without problems as well.