Xojo 2022 - Single File EXE - 64 bit Application Packers

Targets Windows
1

About 5 years ago I was investigating ways to create a single-file EXE for 64 bit Xojo apps on Windows. It was an interesting rabbit hole: Xojo 2017 - Single File EXE - 64 bit Application Packers
In the end, I decided that 32 bit support was still relevant, and the app packers were a lot of trouble, so decided not to pursue it. I just delivered a 32 bit app for my windows customers. (Note: 32 bit windows apps generally work fine on 64 bit windows OSs).

Now, in 2022, I think I’m finally ready to give up supporting older and 32 bit OSs (Windows 7, 8, 8.1 and 32 bit versions of Windows 10) and move to the 64 bit future for Windows 10 and 11 (which is 64 bit only).

I still have a problem, which is that due to my specific needs, I really prefer a single-file-EXE for 64 bits.

So it’s time to revisit the question: in 2022, how do Xojo’s 64 bit windows apps, and the 64 bit Windows application packers, work together?

2

My goal: a 64 bit single-file-exe built in Xojo that can run a web page - sort of a Electron-like version of Xojo, where most of the UI/UX is happening in HTML/Javascript/CSS rather than within Xojo.

I’m done with the IE11 (native) HTMLViewer renderer and I really want to support the modern Edge (WebView2) rendere which is built on WebKit/Chromium and is (generally) built in to Windows 10 and 11.

First tests:

App:

  • a simple app which opens 2 windows, one using HTMLViewer (native) and one using MBS Plugins (22.2) Edge/WebView2 renderer

Packer:

  • Enigma Protector x64 (paid version with lots of features) - note there is also Enigma Virtual Box (freeware version)

Results:

  • mixed.
  • the Xojo native HTMLviewer works fine
  • the MBS Plugin WebView2 control does not work
    It appears that virtualized files work with Xojo, but not with MBS? I’ll try to work with @Christian_Schmitz on this.

Screenshot:

image
image1920×1270 221 KB

Here is the same app with 2 windows running before being Packed: both windows work fine!

image
image1734×978 204 KB

3

Check your file URL. It has a lot of slashes and maybe a few too much?

4

The File URL is correct - when the App is not protected it works fine in WebView2 (see second screenshot). It’s only after the app has been protected / packed by Enigma that it fails.

However, using File URLs is not what I actually want to do, so I just tested a real URL (https://…) and it works fine even after the app has been packed, so that may be good enough for now…

5

I discovered another trick which helps.

  • Normally, for a 64 bit EXE, Xojo puts some DLLs inside a folder named “MyApp Libs” (where “MyApp” is the actual name of the built application.
  • If the user renames the EXE, however, the EXE can no longer find the DLLs. This is true both before the app has been boxed as well as afterwards.
  • Solution: include a post-build script which renames the “MyApp Libs” to simply “Libs” - this makes the EXE resistant being renamed - it will still find the DLLs
  • Here is the post-build script (I’m building on Mac for Windows, but similar technique would work if you are building on Windows)
' Post-build-script
' 64 bit DLLs must exist in 'MyApp Libs' folder but after packing, the name of 'MyApp' may be different
' we solve this by renaming the folder to 'Libs' which is also allowed

dim appName as string = PropertyValue("App.WindowsAppName")
appName = appName.left(appName.len - 4) ' remove .exe from filename

dim cmd as string = "cd " + chr(34) + "$PROJECT_PATH/Builds - " + appName + "/Windows 64 bit/" + appName + chr(34) + " ;  mv '" + appName + " Libs' Libs"

dim result as string = DoShellCommand(cmd)
  • I’ve tested this with Xojo DLLs as well as MBS Plugin DLLs and it works with both.
2 Likes
6

The same trick appears to be necessary, and also works, for data in the Resources folder:

' Post-build-script
' 64 bit Resources must exist in 'MyApp Resources' folder but after packing, the name of 'MyApp' may be different
' we solve this by renaming the folder to 'Resources' which is also allowed

dim appName as string = PropertyValue("App.WindowsAppName")
appName = appName.left(appName.len - 4) ' remove .exe from filename

dim cmd as string = "cd " + chr(34) + "$PROJECT_PATH/Builds - " + appName + "/Windows 64 bit/" + appName + chr(34) + " ;  mv '" + appName + " Resources' Resources"

dim result as string = DoShellCommand(cmd)
7

I thought that a couple years ago, but to this day I still get a surprising number of 32-bit users, even up to Windows 10.

1 Like
8

but to this day I still get a surprising number of 32-bit users, even up to Windows 10.

Just checked: My main app recorded over 100 new registration from 32bit Windows installations in the last 9 months.
No reason to give up that revenue… :slight_smile:

9

You both make good points. My usual method of operations is to sell the newest app only but give a free license to the prior version of the app along with the purchase.