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

[Mehrdad]

On 9/26/2011 3:38 PM, Steven Schveighoffer wrote:
> On Mon, 26 Sep 2011 18:10:05 -0400, Mehrdad <wfunction at hotmail.com> 
> wrote:
>
>> On 9/26/2011 2:53 PM, Steven Schveighoffer wrote:
>>> 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.
>> Wait, why does it have to output COFF? Can't you just use an OMF 
>> version of msvcrt.lib, like we're doing for all the other Windows 
>> libraries?
>> I'm confused as to how this is an issue.
>
> I don't know, maybe there's another reason.
>
>>
>>> 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 :)
>> Well, sort of. It's not so much Visual C++'s runtime, but it's 
>> Microsoft's C runtime that's packaged with Windows (which Microsoft 
>> ironically doesn't want you to use, but which compilers like GCC use 
>> anyway... and it turns out better than anything bundled with Visual 
>> Studio). You don't actually need Visual Studio to use it (in fact, 
>> it's not even included) -- the Windows Driver Kit has the bundled 
>> stuff required.
>
> It's the same thing.  MSVCRT.dll is included with every windows.  Just 
> the version may be different from the runtime bundled with Visual 
> Studio.  That's why you can install the visual studio redistributable 
> package.
>
> The lib file (which contains the linking information) is not included 
> (with Windows).  Neither is the statically linked version.
>
> But make no mistake, it's the Visual C++ runtime 
> (MicroSoftVisualCRunTime).
>
>>
>> In all honesty I don't see a single thing about it that I would call 
>> "better". Do you have any examples of things that snn.lib does 
>> 'better' than msvcrt.lib?
>
> I think it may conform to the standard better.  But I don't think any 
> C runtime is better than what we could make in D :)
>
>> The only incompatibility (which isn't "better" or "worse"... it's 
>> just an incompatibility) I can see is exception handling, but that's 
>> obviously an exception that can be left in snn.lib. Almost all the 
>> rest of the runtime, though, can be easily removed and redirected to 
>> msvcrt.dll... and I don't think there'd be any problems. (Are there?)
>
> I don't know.  For certain, there are some pieces of phobos written 
> specifically knowing the internals of Digital Mars' runtime (like 
> std.stdio).
>
>>> I think the best path is weaning ourselves off of C dependencies.  
>>> Starting with FILE *, which has a lot of limitations.  It's part of 
>>> the reason I'm working on reworking std.stdio.
>>> For example, with my version of std.stdio, you would never have this 
>>> problem, because it deals with the HANDLE directly instead of 
>>> through DMC's file descriptor layer.
>> 100% agree, but we weren't talking about D in the first place. :) 
>> This is all regarding what's /already/ taking place in snn.lib 
>> /before/ D runs, which is obviously unrelated to what's going on in 
>> std.stdio.
>>
>> I'm really curious to know what specific problems are keeping us from 
>> doing the switch (i.e. what snn.lib does better than msvcrt.dll). :)
>
> I'm not really qualified to answer that.  It seems like the right move 
> to me, so there must be good reasons compiler-wise.
>
> -Steve

I hope this isn't too huge of a request (Walter?), but would it be 
possible to PLEASE release an object or library file which would be 
helpful for implementing the use of msvcrt.lib?

Right now, most crucial thing I need is an object file which defines 
this symbol correctly (since it seems to be providing an anchor for the 
rest runtime and the GC):

phobos.lib(memory) Error 42: Symbol Undefined __xi_a

Having something that also implements the following would also be 
awesome, but I can't tell if it's as crucial as the above until I have 
the above and try it out first:

Test.obj(Test) Error 42: Symbol Undefined __except_list
phobos.lib(deh) Error 42: Symbol Undefined __tls_array
phobos.lib(deh) Error 42: Symbol Undefined __tls_index
phobos.lib(thread) Error 42: Symbol Undefined __tlsend
phobos.lib(thread) Error 42: Symbol Undefined __tlsstart
phobos.lib(memory) Error 42: Symbol Undefined __end

If I could _only_ have these, then I could very well try to see if I can 
integrate the C runtime with msvcrt.dll, which I think many people would 
appreciate.

I'm pretty sure that the definition of __xi_a itself must be incredibly 
small (maybe 2 lines of code total?) so I hope it's not too much trouble 
to release something about it... I have no idea how to define it myself. 
If a working definition was released then it'd be pretty awesome.

Thank you!