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 …
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.
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’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 …
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
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?
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
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