Linking COFF and OMF

[%u]

>> I'm really glad that this issue is being looked into. I've literally wasted days (if not a few weeks) getting
another to work instead of SNN.lib, and I think that the ultimate culprit that prevented things from working was
_xi_a.

> What steps did you take?

> btw, I opened http://d.puremagic.com/issues/show_bug.cgi?id=5639 for this

Well, since I hate executables that reference numerous Kernel32 functions in lieu of using MSVCRT's pre-prepared
environments (*especially* if they're ANSI functions), I got to work, figuring out what was causing it. Some of the
functions turned out to be from Phobos, which I modified to work with MSVCRT (e.g. I changed std.stdio to use
_fileno, etc.); many of them, though, were from SNN.lib. After lots of work unpacking each and every object file from
snn, I found out that cinit.obj was a major cause of the bloat, so I created another library file and added
everything necessary _except_ cinit.obj.

Well, I'm not sure if it should've been a surprise: cinit.obj was also necessary. Why? Because of just a few fields,
especially _xi_a.

I tried disassembling things; I tried looking at Microsoft's CRT; I tried looking everywhere on the web, but with no
luck... I couldn't figure out what the heck _xi_a was for. (I _think_) I looked in the garbage collector, and found
out that apparently it was just a marker for part of the executable. I tried making my own object file with the
symbol (with random bytes taken from the assembly, hoping to get it working), but obviously it didn't work... I got
access violations. I fixed a few of them by taking out the 'version' condition in dmain2.d, so that these lines would
also compile on Windows:
void _d_criticalInit()
{
    version (Posix)
    {
        _STI_monitor_staticctor();
        _STI_critical_init();
    }
}

but this was only a partial fix for druntime, and it didn't fix everything. I got random access violations in
different places (especially from stdio's module). I even posted a thread here a few months ago about making our own
runtime instead of SNN.lib (I can't find the link at the moment), but didn't get any real response... and I
eventually gave up; it didn't seem worth the effort.


My ultimate goals were:
1. To migrate to msvcrt.dll, and try to remove the ~100-200 KB bloat that the C runtime from SNN.lib added to
everything.
2. To migrate _everything_ to NTDLL.dll (this was very ambitious, I admit), which would be the ultimate low-level
portion of the Windows NT user-mode API. Why? Because given that D is a systems programming language, it should be
able to be used to make NT-native programs, that solely depend on NTDLL.dll. (An example of such a program is
CheckDisk, which runs without the Win32 subsystem.) Currently, D is a "systems programming language" in name only;
it's not actually possible to do any low-level programming in it unless we can remove the SNN.lib dependency
entirely.


So that's the adventure I've gone through... I've also tried doing various other things in the meanwhile (e.g. I
wrote my own boot loader + nanokernel using D, but ran into trouble when I tried to get the garbage collector to
work, because of so many issues with SNN.lib and also with thread-local storage.) These took many weeks of
[ultimately fruitless] effort, so now I'm happy that someone else also mentioned the topic; hopefully it'll be
possible to remove the SNN.lib dependency.

That's my story. :)