Xojo 2017 - Single File EXE - 64 bit Application Packers

I tested with both and have a license for BoxedApp, but gave up since I ran into issues which deduced me from the actual work.

I just did a very simple “Hello World” style test using Xojo 2017R3 for a x64 bit windows build. I packed it using BoxedApp Packer 2017.31.0.0 and it worked. This was on Windows 10 x64.

Joost, what kinds of issues were you seeing?

More testing with BoxedApp Packer 2017.31.0.0:

I’m testing with a more complicated app which includes the use of HTMLViewer. This results in a x64 app build that looks like this:

  MyApp.exe
  msvcp120.dll
  msvcp140.dll
  msvcr120.dll
  vccorlib140.dll
  vcruntime140.dll
  XojoGUIFramework64.dll
  MyApp Libs/
     Browser Pluginx64.dll

Now, when using BoxedApp Packer, it’s not working: when I launch the packed exe I’m getting the following error:

  Runtime Error.   
  Common\\plugin.cpp: 990
  Failure Condition: pluginEntryTable.GetEntry...
  Can't find plugin method _HTMLViewerPlugin.LoadURL

Although the packed app finds the other DLLs (Xojo GUIFramework and all the msvcp DLLs, ) it looks like the packed exe is not finding the Browser Pluginx64.dll.

I’ve tried a bunch of variations for packing the app:

  • moving Browser Pluginx64.dll next to the EXE
  • keeping the plugin inside the correct folder “MyApp Libs”
  • various combinations of the folder and plugin using the BoxedApp options Type=External vs. Type=Embedded
  • putting the Browser Pluginx64.dll in the virtual System64 folder
    etc.

I’m a little confused by the Xojo documentation which says:

http://developer.xojo.com/64-bit-guidelines

However, as shown above, the Browser Pluginx64.dll is definitely put inside a “MyApp Libs” folder when using 2017R3. Is this a compiler bug or a documentation issue?

Well Michael, I don’t need to explain much, since you’ve described it already above.

[quote=367771:@Michael Diehr]I’m a little confused by the Xojo documentation which says:

http://developer.xojo.com/64-bit-guidelines

However, as shown above, the Browser Pluginx64.dll is definitely put inside a “MyApp Libs” folder when using 2017R3. Is this a compiler bug or a documentation issue?[/quote]
Maybe the browser plugin is not considered a framework DLL?

I’ve submitted two cases:
<https://xojo.com/issue/51020> A bug report noting that the x64 builds puts the BrowserPluginX64.DLL in a weird location.
<https://xojo.com/issue/51021> A Feature request to fix the issue with BoxedApp on x64 bit apps.

+1

Good luck

Raised with BoxedApp?

Yes, I emailed BoxedApp today

Norman just closed both feedback reports as “not a bug”. I can understand closing 51021 if Xojo doesn’t want to deal with third party packers (although this behavior from Xojo Inc is decidedly customer-unfriendly - supporting third party tools is the sign of a healthy company).

However, closing 51020 makes no sense: Please re-open this.

It is clearly a bug, as the behavior is not functioning as per the documentation and is a regression as compared to established behavior.

  1. The documentation claims that the “MyApp Libs” folder isn’t used in x64 builds. And yet it is.

If this is just a documentation bug, then that’s fine, but this means the next issues are therefore bugs:

In prior versions of Xojo with 32-bit Win32 builds, plugins could be put in one of three locations:
2A. In the “MyApps Libs” folder (the default location)
2B. In a folder named simply “Libs” (an alternate, but allowed location)
2C. Right next to the EXE (an alternate, but allowed location)

This is no longer working in x64 builds. The only allowed location seems to be 2A.

From http://developer.xojo.com/64-bit-guidelines:

[quote]Build Files
For 64-bit builds, the compiler places framework DLLs next to the executable and not into the “MyApplication Libs” (or just “Libs”) folder like it did for 32-bit builds.[/quote]
All other DLLs will be placed in “MyApplication Libs”, just “framework DLLs” will be next to the executable.

Ok, looks like I’m both right, and wrong. Part of the confusion is that I’m updating a project from an older version of Xojo, and it looks like the DLLs location behavior has changed over the years:

Under Xojo 2014 R2.1, with a 32 bit build, both framework and plugins DLLs can be in one of 3 locations:

  • a folder named “MyApp Libs”
  • a folder named “Libs”
  • in the same folder with the EXE file.

Under Xojo 2017 R3, with a 32 bit build, framework DLLs can be in one of 3 locations:

  • a folder named “MyApp Libs”
  • a folder named “Libs”
  • in the same folder with the EXE file.
    But Plugin DLLs can only be in one of two locations:
  • a folder named “MyApp Libs”
  • a folder named “Libs”
  • (Putting Plugins DLLs in the same folder with the EXE file no longer works.)

Under Xojo 2017R3 with a x64 build, the rules are even tighter:

  • Framework DLLs must be in the same folder as the EXE
    Plugin DLLs can only be in one of two locations:
  • a folder named “MyApp Libs”
  • a folder named “Libs”
  • (Putting Plugins DLLs in the same folder with the EXE file does not work.)

So to restate the issue at hand:

  • Why did the allowed locations for Plugin DLLs change between Xojo 2014 and 2017?
  • Was this an intentional change or perhaps a bug?
  • Does the change have anything to do with the issues we are seeing with BoxedApp Packer?

Since my original Feedback report was both confusing and wrong, I’ve submitted a new one with better info <https://xojo.com/issue/51040>

Update - I’m finding that the BoxedApp packer actually does work with the HTMLViewer / Browser Pluginx64.dll on Windows 7x64. But it’s not working on a preview release of Windows 10 x64. I’ll report back when I have more details.

To recap,

Using Xojo 2017R3 with a 64 bit build, then packing the app using BoxedApp Packer 2017.31.0.0, I’m finding the app works fine on many systems but does not launch on others.

When it fails, it shows this error suggesting it can’t find Browser Pluginx64.dll :

The Packed app works on:

  • Windows 7x64 (with all updates) under Parallels 13.2.0.
  • Windows 10x64 (1703 build 15063.608) under BootCamp
  • Windows 10x64 (1703 build 15063.608) under VMWare Fusion 10.1.0 (using the same BootCamp partition)
  • Windows 10x64 (1709 build 16299.192) under BootCamp
  • Windows 10x64 (1709 build 16299.192) under VMWare Fusion 10.1.0 (using the same BootCamp partition)
  • Windows 10x64 (1703 build 15063.850) under BootCamp

The Packed app does not work on:

  • Windows 10x64 Windows Insider Preview build (1709 Build 17063.1000) running under VMWare Fusion 10.1.0
  • Windows 10x64 Windows Insider Preview build (1709 Build 17074.1000) running under VMWare Fusion 10.1.0

So it’s not clear what the problem is - it could be an issue in Windows, in BoxedApp, or even possibly in Xojo.

@Michael Diehr - as said earlier in this thread, I knocked off with BoxedApp since all kind of issues kept me away from developing a business application , which is more important I guess.
Seeing you going the same direction.

[quote=369647:@Michael Diehr]The Packed app does not work on:

Windows 10x64 Windows Insider Preview build (1709 Build 17063.1000) running under VMWare Fusion 10.1.0
Windows 10x64 Windows Insider Preview build (1709 Build 17074.1000) running under VMWare Fusion 10.1.0[/quote]
You wouldn’t happen to have filed bug reports with Microsoft would you? You are running betas of the OS.

I have not done so yet but it’s a good idea.

I am in contact with the BoxedApp folks - they have a debug log option in their apps so they have more information than I do. If they can’t/won’t then I will try to report this myself.

[quote=369749:@Joost Rongen]@Michael Diehr - as said earlier in this thread, I knocked off with BoxedApp since all kind of issues kept me away from developing a business application , which is more important I guess.
Seeing you going the same direction.[/quote]

So far, I’m only seeing a problem on 1 machine (which is running Betas of Windows 10) - the other 9 I’ve tested on work fine. I’m not sure if this is a big or little problem so far.