On Monday, September 26, 2011 14:53 Steven Schveighoffer wrote: > On Mon, 26 Sep 2011 17:35:20 -0400, Mehrdad <[email protected]> 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@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
