>> 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. :)
