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

[Dmitry Olshansky]

On 27.09.2011 2:33, Jonathan M Davis wrote:
> 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.
>

It's not that easy. I mean to gain this level of compatibility we'd have 
to do both: switch to MS runtime and use COFF object format. Linking 
together two C runtimes is *ehm* tricky.

But most importantly newer versions of VC++ use newer runtimes, I'm not 
sure how compatible they are, but judging by my previous experience - 
you still has to keep things separated like in DLLs and never mix 
allocation/FILE* stuff between them.


> - Jonathan M Davis


-- 
Dmitry Olshansky