Not a valid win32 application on windows xp

Yes, that worked - Updating OpenFL and the app now runs.

However, I’m back to where I started: lime test neko says “Not a valid win32 application” and lime test windows compiles, runs, and the app crashes, as before …

Tried with -Dlegacy as well …

It may be more hardware restrictions based on using an unsupported operating system. Try opening the file in compatibility mode.

Right click the application -> Properties -> Compatibility -> Run this program in compatibility mode for “Windows XP”

Other issues may include an old graphics driver which does not support the latest version of OpenGL, or just simply does not support OpenGL entirely (although rare).

For a more technical reason why it cannot read the file from MSDN:

Clickonce bootstrapper engine (setup.exe) that was shipped with Visual Studio 2012 is NOT compatible with any OS below Windows Vista.  So, the above error message is expected and by design. The reason for this behavior is because the bootstrapper is compiled using the VC compiler and the Dev11 VC compiler does not support Windows XP.   


So the workaround is to install all the prerequisites manually and launch the ClickOnce application directly from deployment manifest file (.application). Another workaround would be to create a sample ClickOnce application using Visual Studio 2010 OR Visual Studio 2008 with the same name as mentioned in Visual Studio 2012 and publish it. From the published location take the setup.exe bootstrapper and replace the existing setup.exe bootstrapper created using Visual Studio 2012.

Now this is found here, but that is regarding a ClickOnce application, but may also apply here. If you have VC 11 installed on your computer, that may also be likely to be causing the error. Either uninstall it, or download the latest version of your Visual Studio service pack from MSDN, as that will include support for Windows XP.

Haxe, as far as I am concerned, will compile your application using the latest and most up-to-date version of the C++ redistributable through HXCPP installed on your computer. It is likely that the version of the C++ compiler Haxe is using is one not supported on Windows XP.

1 Like

Now you are set up to build from the source, try using the oldest version of Visual Studio you have, like 2008 or 2010, I recall these working on Windows XP, either it is in how the full project is built, or perhaps there is a method call somewhere which is expecting a newer version. An older compiler should probably catch that, though.

There might also be something with the ReplaceVistaIcon.exe tool we use that corrupts it for Windows XP support, I don’t think that’s the case, but it’s worth mentioning

I always did the compilation on WinXP with VS2010 Express.

I missed that haxe 3.2 is officially released, so I updated Haxe, hxcpp (and Lime with OpenFl of course) and the problem has gone!

I’m in Windows XP already so the only options that come up are “Windows 95, Windows NT, WIndows 2000”…

I have Visual Studio 2010 …

Interestingly the Neko generated .exe (which gives the Not a valid win32 application error) does not have a proper icon when viewed in explorer …

Still not working …

If ya’ll don’t mind, I’m going to close this issue down (If I can … ?) - My old laptop is just too slow to use anyway, so going to retire trying. Thanks for the help, peeps… But I’ll stick to Windows 7 from now on …

I think problem in the hxcpp. Do you run haxelib update hxcpp ? Also on Haxe forum exists the similar topic .

That the point. Current solution:

<assets path="assets" exclude="openfl.svg" />

Ico generated from openfl.svg file and is need to exclude that file to avoid “not valid win32 application”.

Oh, interesting, so without an icon, it works on Windows XP, but with the icon, it fails. I wonder if it is upset with the Vista PNG icons, or is upset with all of the PNG icons, or the icon embed in general

I’m also having “Not a valid win32 application” on my win xp sp3. using latest haxelib for openfl, lime, hxcpp when compiling for neko.

I have tried recompiling lime using vs2010 express, remove the icon from project.xml. Still same result

Is windows xp still supported?

We used to build on Windows XP exclusively to ensure compatibility, but had to update the build machine when we moved to automated builds

I would not mind to have Windows XP compatiblity, I do not know if this is a build flag, or a matter of building with a different Visual Studio version. How many people are still using XP?

Personally I’ve decided to stop supporting it. I just had an old laptop I wanted to use … But it seems too antiquated now to be useful to me.

think I give up too, and switch to win7, still no luck though :frowning:

Have you tried openfl test neko --window-hardware=false in Windows 7, if it wasn’t working normally?

thanks, that actually works

just got the chance to try again… :smiley:

Okay, good! So that actually means it is working for Windows XP, but the issue is with OpenGL 2 framebuffer support, we need to add something to check and enable software mode automatically when this is the case, or perhaps look at using ANGLE by default (which implements the OpenGL features over DirectX, which should be supported even by old cards)

Hey guys, I just found my Windows XP CD, I’m installing in a VM, so (hopefully) I’ll be able to test and confirm how we’re doing on Windows XP support. Regarding the OpenGL 2 framebuffer issue, current versions use Cairo for bitmapData.draw instead of a framebuffer, so it might work now if that was the only issue :smile:

Here we go!

I am using XP too :smile:

And I remember I saw a topic where someone said he used MinGW compiler for Windows builds. It would be cool if this would still be possible with OpenFL 3…

I have done more testing, and have found that compiled to the Windows C++ target, I can get Lime to work, so long as I do not attempt to paint a CairoImageSurface.

I am working in a VM, so I am not able to use OpenGL rendering at this point. On the software path, I found that I had to change the “SimpleImage” sample of Lime to render Cairo every frame, not just once. I also had to comment the image draw. Without, it works fine, and I can use other fill commands, but images cause it crash.

If someone wants to look into that, it works fine elsewhere, and I can’t find anything online about Cairo having trouble in this area, only on Windows XP.

I wonder with Windows 10 if we can look at XP dropping off, in general, but I understand that some people don’t have a choice (or prefer an older OS version for a VM)

So this is better than I suspected, and worse? I suspected it was an instant crash, due to a bad build, but now it seems that’s not the case here, but on the other hand, I’m not sure of an immediate solution :confused:

Just received the same complain from one of the clients about game not working in Windows XP.
As I can understand, that should help, right?

–window-hardware=false

Or is it better to drop Windows XP support, how about Windows 10 then?