
On Fri, Apr 7, 2017 at 3:51 PM, Akos Marton
wrote: *me.exe: RegOpenKey: invalid argument (The system cannot find the file specified.)*
That would be fine, however the key does exists. When same code, same system, but the .exe built to be x64 it runs like a charm.
My guess is that the FFI call has an incorrect type somewhere and therefore passes garbage. My fear is that, even if digging into the code of win32 package, underlying details seems to be hidden how certain values are read out. - at least for me. Can it be that ghc forces its evaluation during compilation and renders something hard-coded into the binary? - this is how it feels, I am
On 04/07/2017 05:09 PM, Brandon Allbery wrote: trying to show it, so far w/o success.
Another thing which convoluted in the issue...
The function, *getSystemInfo :: IO SYSTEM_INFO, *can read out the underlying architecture. When compiled on x86 and run on x64 it would tell me: "I am running on x86". That's failure.
You can blame Windows for that one: if you run an x86 binary on x86_64, it launches the WoW subsystem emulating an x86 processor, so you will get the emulated processor reported back. There may be a different API to get the actual host --- but given that WoW exists to minimize incompatibilities for x86 software, it is likely well hidden if it exists at all.
I do not know that, but it feels like I should use something which can be called via /system/ and hence on can rely on the local window api and not on the system I compile.