DMD 2.055 Crashing on Windows 7 x64 (So is my D program)

[Jonathan M Davis]

On Monday, September 26, 2011 14:53 Steven Schveighoffer wrote:
> On Mon, 26 Sep 2011 17:35:20 -0400, Mehrdad <wfunction at hotmail.com> wrote:
> > On 9/26/2011 2:30 PM, Mehrdad wrote:
> >> On 9/26/2011 1:51 PM, Steven Schveighoffer wrote:
> >>> AHA!
> >>> 
> >>> Yes, there is a bug in snn.lib regarding pipes. And I fixed it,
> >>> waiting for Walter to incorporate it :) I needed it for the new
> >>> std.process.
> >>> 
> >>> What it comes down to is, DMC's FILE * implementation does not expect
> >>> some of the quirks of pipe HANDLEs. For instance, if you open a FILE
> >>> * around a pipe handle, it still tries to do a seek on that handle,
> >>> and crashes. Also, when the write end of a pipe is closed, reading
> >>> from the read end results in EPIPE from ReadFile, but this is
> >>> translated to EBADF by the runtime. Therefore, FILE * sets an error
> >>> instead of EOF.
> >>> 
> >>> Is the email address you have for this message correct? If so, I can
> >>> send you a new version of snn.lib to try linking your code against (if
> >>> you are willing to go through these steps), to see if it fixes your
> >>> problem.
> >>> 
> >>> Using the command line dmd to build should be sufficient (I think).
> >>> 
> >>> -Steve
> >> 
> >> Thanks for the email.
> >> 
> >> It seems like it still crashes from SciTE, though. :(
> >> When I try debugging, I see it's doing so inside _close() which is
> >> /immediately/ above kernel32.dll!@BaseThreadInitThunk at 12() -- in other
> >> words, it seems to be called directly from the entrypoint of the
> >> program, assuming it hasn't undergone optimizations. The error is:
> >> 0xC0000008: An invalid handle was specified.
> >> 
> >> Is there any other place in which this can happen?
> > 
> > Also, now that we're on the topic... this might or might not sound
> > silly, but why not just use msvcrt.dll (if not the whole library, at
> > least the I/O functions)? It's not like it introduces a new dependency
> > (it's already in every version of Windows) and it's also proven to work.
> > Not to mention that it reduces code size as well...
> 
> I think the reason Walter always gives is that dmd would then have to
> output COFF objects, whereas it currently outputs OMF. OPTLINK also does
> not accept COFF objects.
> 
> I think a lot of people would very much welcome this change, but it's
> somewhat of an underwhelming change. Instead of using DMC's runtime for C
> functions, you are using VC++'s runtime. But who cares? I want D's
> runtime to be better :)

The gain in switching to COFF would be _huge_, because then D code would be 
properly interoperable with most of the C code on Windows - and in particular 
C code compiled with Microsoft's compiler. The only thing saving the current 
situation from being a complete disaster is that you can still use dlls.

- Jonathan M Davis