Standalone .exe?

Hello:

I’m presently developing in RS2011r4.2 in Windows … When I upgraded to RS2012r2.1 a while back, I was no longer able to build a standalone .exe file–is this correct? Instead, a “Libs” folder appeared containing:

msvcp100.dll
msvcr100.dll
RBGUIFramework.dll

So, I switched back to RS2011r4.2; however, would like to move forward. The standalone .exe file feature is important for easy portability for my application. Is there any info on this change? (I haven’t been able to locate any …) And, is this a switchable setting/feature now available in Xojo 2013rX?

Thanks!

[quote=63235:@Christopher Morgan]Hello:

I’m presently developing in RS2011r4.2 in Windows … When I upgraded to RS2012r2.1 a while back, I was no longer able to build a standalone .exe file–is this correct? Instead, a “Libs” folder appeared containing:

msvcp100.dll
msvcr100.dll
RBGUIFramework.dll

So, I switched back to RS2011r4.2; however, would like to move forward. The standalone .exe file feature is important for easy portability for my application. Is there any info on this change? (I haven’t been able to locate any …) And, is this a switchable setting/feature now available in Xojo 2013rX?

Thanks![/quote]

Single file executables were removed for technical reasons and are not coming back.

Thanks, and makes sense. Any good tools out there to make a standalone .exe?

I think it was Aaron Ballman that wrote an extremely information article on why that had to happen - I couldn’t find the link offhand.

As time goes on, it’s starting to become fairly smart to hang on to multiple versions of REAL/Xojo, as REAL/Xojo tends to shed compatibility as time goes on instead of retaining it. I hang onto RB2007r4 for the .exe standalone reason, and RS2011r3 to handle PPC for Mac. Now that Xojo r4 went SnowLeopard forward, I keep a Xojo r3 around to compile for Leopard. That’s just so far.

There are issues with the .exe standalones even if you can build them with an old REAL, but with light things I’ve never seen issues. For certain things it’s nicely worth it to build small bootstrap apps that are standlone, so you don’t have to carry around dependencies.

Joe, wasn’t there talk of, once the LLVM compiler comes online, with making standalone .exe’s could come back?

Visual Studio makes standalone .exe’s.

But remember, this often is an illusion. Technically, there is no such thing as a standalone executable, since all apps rely on the operating system to run them. We call certain apps “standalone” if we know that the dependencies are guaranteed to exist, and the only entity that can guarantee this is the operating system itself. For example, many times with VS the .exe rely on C++ runtimes that are guaranteed to be within the OS and no one is supposed to fiddle with those.

All, thanks for your replies … The dependencies don’t worry me as much as the ease of distributing one program file–just makes distribution and installation simple!

May 9, 2008 Important Win32 application packaging changes - Ramblings

November 26, 2008
http://web.archive.org/web/20081222224320/http://ramblings.aaronballman.com/2008/11/touchy_subject.html

Plus one of the great examples of the problem
http://web.archive.org/web/20081223140612/http://forums.realsoftware.com/viewtopic.php?f=5&t=21215

It was mentioned a long, long time ago as a possibility. It has since been ruled out as it would mean that we wouldn’t get error reports from crashes in our DLLs (amongst other reasons).

On Windows you can try EnigmaVirtualBox. I used for many years with no problem at all, is amazing!, is FREE.

There is also http://www.molebox.com

Geoff’s comments in <https://xojo.com/issue/5767> (ranked 122 right now) suggest that it might be still be an option? If it’s definitely not possible, might be good to update that item.

How all those fit with code-signing your app?

I found no mention of codesign whatsoever on their web site. But I suspect it should be possible to simply code sign the packaged executable, since what Windows tests is the .exe itself.

I hope so. Was thinking the possibility of some inconsistency due to some deeper checking loading packed resources, DLLs for example.

I do not believe Windows checks more than the executable. Unlike a Mac bundle, a Windows executable is a flat file.

At any rate, it should be easy to test what happens with signing a packed exe.

I figured you would have to treat it like an installer. You sign your application, build your installer then you sign the installer.

What a shame; single file EXEs were a big draw for me on RealBASIC.

If you read the links I posted you can see why they had to go away.
The issues are covered in the links https://forum.xojo.com/conversation/post/63250

Yep yep. I understand it had to happen, and is unavoidable, but it’s still a shame! I have found workarounds though, so no worries!