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

Steven Schveighoffer schveiguy at yahoo.com
Mon Sep 26 15:38:49 PDT 2011


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


More information about the Digitalmars-d mailing list