Hey,
I wanted to write a quick update about Neko for Windows, Haxe 4, and where we stand.
TLDR: New versions of Lime and OpenFL are up on Haxelib – get them
Haxe 4 RC4 changed the default architecture of Neko in the release from 32-bit to 64-bit, which caused a lot more trouble than I expected.
First, the “openfl” and “lime” command shortcuts were Neko-based, but incompatible with the 64-bit version it seems. We converted them to C++ compiled versions that are much bigger for now but work consistently for both.
The second issue is that Neko looks for a matching native library (such as “lime.ndll”) on Windows and picks the first one it finds and does not keep looking if it is the wrong architecture. I had (wrongly) thought that we could add both paths and call it a day. It worked – until users with the 32-bit version reported that their version was broken 
There’s an is64 call supported by Neko but it had a bug on Windows where it always returned false even on 64-bit builds, finally, we came up with an approach where we force an NDLL load and try/catch to fallback and correct the library path if it does not work. Not clean, not nice, but both 32- and 64-bit Neko users can now access the command-line tools 
The last problem is in our openfl test neko user-builds… what NDLL architecture should we copy? Linux and macOS builds match the system architecture but that would not have worked because Windows users will have a different version of Neko depending on their Haxe version or user preference. As an effort to have things working out of the box, the Windows tools will run haxe -version at build-time to look for Haxe 4 and assume 64-bit if it is Haxe 4. I can’t say I like this but I can’t think of a better approach.
Lime 7.6.3 and OpenFL 8.9.5 are now live with these fixes in place.
Long-term I think we are going to look closely at HashLink, Node.js, C++ or another alternative