More graceful error message on older Windows versions?

Targets Windows
1

Hi all,

Been getting a few support emails from people running older versions of Windows (XP/Vista) that are no longer supported (nor SHOULD they be) trying out my latest programs written in Xojo.

The error message you get when trying to run my app on unsupported Windows versions is:

“The ordinal 344 could not be located in the dynamic link library COMCTL32.dll”

That message is not very user friendly and is yielding more support emails than a simpler one would. Anyone have any zany ideas to display a more user-friendly “this application requires windows 7 or newer” message?

This app is not distributed with an installer, or I’d do it there. I’m hoping for a non-installer-based solution.

3

Maybe a wrapper built with an older version of Xojo that checks the OS version and FolderItem.Launch your actual app (built with the latest Xojo) if it’s Windows 7 or newer, and deletes the OS displays your message if it’s XP or Vista.

4

You should really consider an installer. That is what users expect, as well as the system. A program copied to a folder does not benefit from the system uninstall, for instance.

6

This would technically solve the problem, but has the overhead of shipping two xojo frameworks, which will increase the package size significantly. I’ve been considering a solution using a Vbscript compiler which has a very small footprint.

7

My program is literally called CommandsScrewInstallers so this is not an option, haha.

8

It looks like your choices are ship two Xojo frameworks, use an installer, or use a different tool.

9

Is there anything in your software that requires a newer version of Xojo to build? Maybe you could just build with an older version and deliver two versions?

10

Create a launcher using vbscript, and decide whether to launch your app or display a message.

example code:

[code]Set dtmConvertedDate = CreateObject(“WbemScripting.SWbemDateTime”)
strComputer = “.”
Set objWMIService = GetObject(“winmgmts:{impersonationLevel=impersonate}!\” & strComputer & “\root\cimv2”)
Set oss = objWMIService.ExecQuery (“Select * from Win32_OperatingSystem”)

For Each os in oss
msgbox "Version: " & os.Version
Next[/code]

tools like VBedit can ‘compile’ this as an exe file.

11

You can share the framework between the 2 apps. Rename one of the Libs folders to just plain “Libs” and put both executables in the same folder.

App1.exe
App2.exe
./Libs

12

[quote=333571:@Tim Hare]You can share the framework between the 2 apps. Rename one of the Libs folders to just plain “Libs” and put both executables in the same folder.

App1.exe
App2.exe
./Libs[/quote]
Not if they are built using different versions of Xojo

13

Oh, duh! Where’s my brain today?

14

well it IS 5 o’clock somewhere :stuck_out_tongue:
Beer time !

15

Did you leave it on the kitchen counter next to Emiles head?

16

Thanks for the replies everyone. Seems to me like there’s room for a more versatile solution to this issue. Frankly I’m surprised there aren’t more people asking this question. Perhaps because most people are using installers.

However I think I’m going to work on something to solve this (and a few other quirks of distributing xojo apps on Windows) for my next project.

17

If you’re distributing using a version that does NOT generate a single file exe then an installer makes sense since you can include the various MS redistributables and they can be installed if and only if required (ie Windows 7 may require them and Windows 8+ shouldn’t if they are fully up to date)
And should users remove your app they get the right bits removed

Thats a lot harder to do with a manual distribution of something like a zip file etc

And it would inform users right at the point they try to install that these old systems are not compatible/supported by your application

18

@Norman Palardy Agreed, but there are some times when you don’t want to install an application. For example, I have several utilities that are designed to be run once, they perform some function (usually tweaking a system setting in my case), and then are to be discarded. But I certainly concede that for most applications you’ll want an installer.

19

I have a couple of utilities like there here
But I wouldn’t throw them away as once I tweak the setting they make it easy to “untweak” the setting as well so I can revert to “normal” settings

But this isn’t my software so … :slight_smile:

Just a note that IF you chose to include the MS CRT redistributables they will end up as a pile of DLL’s (I think there’s 43 of them or something like that) next to the compiled exe so the presentation is, in some opinions, messy. There’s no way round that IF you do chose include them.
Of course the installer avoids this as they can be installed system wide - and will get security updates
Again this only affects systems that dont already have them from other means
But you wont know that when you create your app so …

20

I like the idea of maybe compiling with an older version of Xojo as a solution for Windows XP. It might not work to have multiple versions for some people but it could work for me.

I just hit this issue today. I had an old PowerBASIC program that needed a new com-library to work with some SFTP changes on a cloud server I use. I don’t do any new PowerBASIC development so I decided to use Xojo and the ChilKat library I already have licensed rather than pay for an upgrade for something I am not using. I re-wrote the program in Xojo.

BUT … This is for a multi-location client and I found one of their machines is an XP machine. It took me a few minutes to realize the problem based on the “The ordinal 344 …” message.

QUESTION - What was the last version of Xojo that could compile for XP?

Then I will need to figure out if the ChilKat library will work with that old version of Xojo.

–OR–

I could just say that feature does not work until you upgrade to at least Windows 7.

21

You can find this information on the depreciations page at https://developer.xojo.com