On 9/26/2011 3:38 PM, Steven Schveighoffer wrote:
On Mon, 26 Sep 2011 18:10:05 -0400, Mehrdad <[email protected]>
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!
