Same code, system, but different arch using Win32 for reading registry.
Having a binary compiled on either x86 or x64 system (same
installation, utilizing stack) in order to preserve compatibility
against x64 systems. Actually, not to have 2 separate executable
for each, that would be the overall goal. However it surprises me
when running the x86 .exe utilizing Win32-22.214.171.124 package with
ghc-8.0.2, reading out a registry key fails on x64 system with the
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.
A couple of question, which some of them eventually will not
make sense, but still:
- Can it be ghc code optimization issue?
- but this is a runtime check in IO, if so, how?
- Yes, I could use a built-in windows system command and parse
the input of that; unless absolutely necessary I would not
introduce another dependency (system package). Would love to solve
it with the currently utilized weapons.
- the issue just puzzles me... I would know the answer if
- Is it more library (Win32), ghc, binary I generate, issue?
What library can I use to detect a system's architecture which
works in this scenario?
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.
Most importantly: what is the obvious I am missing?