Using stdin/out in a windows application bugs only when compiled to 64bit.

[realhet]

On Thursday, 7 June 2018 at 19:42:05 UTC, Steven Schveighoffer 
wrote:
> Are you just compiling the 32-bit dmd version with default 
> flags?
Yes, no flags at all and it defaults to a 32bit target. I can use 
the console and able to make windows, and able to setup an opengl 
window too.
The console (stdin/stdout/SetConsoleAttribute) stuff crashes only 
when I compile to 64bit with DMD or to 32/64 with LDC.

> If so, it's likely an issue with MSVC runtime library not being 
> properly set up. DMD 32 bit by default uses DMC runtime.
I just tried to put up msvcrt2017 runtime but doesnt solved the 
issue.

> To verify, use the switch -m32mscoff to do 32-bit result but 
> link against MSVC library.
Compiling this way is impossible: It can't link even basic stuff 
like GetDC().

>> I know this isn't really an answer, but it at least narrows it
> down. Been a while since I did windows development, but it 
> sounds like you are trying to print to or read from a console 
> that isn't open. A windows program that has gui-only flag 
> doesn't by default allocate a console. Most likely dmc just 
> does it for you.

To be honest I don't use gui-only flag as I don't even know about 
where to put it :D (.def file maybe, but I don't). I use 
core.Runtime.initialize only. That is enough in 32bit but not in 
64bit.

My goal is to have a fully functional exe that contains every 
necessary things inside it. So far this is given when I use DMD 
and compile to win32.
The error I'm getting is not a 'friendly' exception. It is a 
privileged instruction crash.
And it caused only by adding the -m64 option, not changing 
anything else. The linking is done by DMD itself also. (If I link 
with msvcenv.bat && MSLink.exe, it produces also the same fail.)