On 04/07/2017 05:09 PM, Brandon Allbery wrote:

On Fri, Apr 7, 2017 at 3:51 PM, Akos Marton <makos999@gmail.com> 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 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.