www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Linking COFF and OMF

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
I just took a stab at linking together different object formats with 
UniLink.
Well, it just works(tm).  So I may suggest to anyone having to link with 
precompiled COFF static libs on windows to try it out.

For starters I just replaced most of my kernel32.lib, shell32.lib etc 
with Microsoft SDK  latest COFF import lib variants and
then built and linked winsamp.d from the DMD examples dir. Of course, 
that broke optlink linkage.
Then I tried it with static libs, so I produced simplistic static lib 
with MinGW gcc:

#include <stdio.h>
int AddInt(int i1, int i2)
{
     return i1 + i2;
}
void PrintInt(int a)
{
     printf("%d\n",a);
}

and linked with this module:

import std.stdio;
extern(C) int AddInt(int a,int b);
extern(C) int PrintInt(int a);
void main(){
     assert(AddInt(3,5) == 8);
     PrintInt(42);
     writeln("Works?");
}

All passed as expected. (It took renaming lib from *.a to *.lib but 
that's it!)
I guess it linked printf with DMC's printf in snn.lib though,
so there might be some problems with foreign RTLs when one goes too far.


P.S. I know I sound like a freaking promoter ;)

-- 
Dmitry Olshansky
Feb 20 2011
next sibling parent reply Trass3r <un known.com> writes:
 I guess it linked printf with DMC's printf in snn.lib though,
 so there might be some problems with foreign RTLs when one goes too far.


Can we replace snn with the other RTL?
Feb 20 2011
parent reply Don <nospam nospam.com> writes:
Trass3r wrote:

 I guess it linked printf with DMC's printf in snn.lib though,
 so there might be some problems with foreign RTLs when one goes too far.


 
 Can we replace snn with the other RTL?


In 2.052 several of the most complicated dependencies on snn.lib (those 
relating to exception handling) were removed. I don't know how many more 
DMC-specific ones there are, but using another snn.lib might be possible 
now.
Feb 20 2011
parent reply Trass3r <un known.com> writes:
 In 2.052 several of the most complicated dependencies on snn.lib (those 
 relating to exception handling) were removed. I don't know how many more 
 DMC-specific ones there are, but using another snn.lib might be possible 
 now.


Compiled a hello world with empty snn.lib:


OPTLINK (R) for Win32  Release 8.00.8
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
helloworld.obj(helloworld) 
 Error 42: Symbol Undefined __acrtused_con
C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) 
 Error 42: Symbol Undefined ___alloca
C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) 
 Error 42: Symbol Undefined __except_list
helloworld.obj(helloworld) 
 Error 42: Symbol Undefined _fprintf
C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) 
 Error 42: Symbol Undefined _wcslen
C:\dmd\windows\bin\..\lib\phobos.lib(deh) 
 Error 42: Symbol Undefined __tls_array
C:\dmd\windows\bin\..\lib\phobos.lib(deh) 
 Error 42: Symbol Undefined __tls_index
C:\dmd\windows\bin\..\lib\phobos.lib(gc) 
 Error 42: Symbol Undefined _memcpy
C:\dmd\windows\bin\..\lib\phobos.lib(gc) 
 Error 42: Symbol Undefined _malloc
C:\dmd\windows\bin\..\lib\phobos.lib(memory) 
 Error 42: Symbol Undefined __xi_a
C:\dmd\windows\bin\..\lib\phobos.lib(memory) 
 Error 42: Symbol Undefined __end
C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
 Error 42: Symbol Undefined _calloc
C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
 Error 42: Symbol Undefined _free
C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
 Error 42: Symbol Undefined _memset
C:\dmd\windows\bin\..\lib\phobos.lib(object_) 
 Error 42: Symbol Undefined _strlen
C:\dmd\windows\bin\..\lib\phobos.lib(thread) 
 Error 42: Symbol Undefined __beginthreadex
C:\dmd\windows\bin\..\lib\phobos.lib(thread) 
 Error 42: Symbol Undefined __tlsend
C:\dmd\windows\bin\..\lib\phobos.lib(thread) 
 Error 42: Symbol Undefined __tlsstart
C:\dmd\windows\bin\..\lib\phobos.lib(object_) 
 Error 42: Symbol Undefined _memcmp
C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
 Error 42: Symbol Undefined _memmove
C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
 Error 42: Symbol Undefined _realloc
C:\dmd\windows\bin\..\lib\phobos.lib(regexp) 
 Error 42: Symbol Undefined _printf
C:\dmd\windows\bin\..\lib\phobos.lib(regexp) 
 Error 42: Symbol Undefined _memchr
C:\dmd\windows\bin\..\lib\phobos.lib(datetime) 
 Error 42: Symbol Undefined _localtime
C:\dmd\windows\bin\..\lib\phobos.lib(datetime) 
 Error 42: Symbol Undefined _tzset
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined __iob
C:\dmd\windows\bin\..\lib\phobos.lib(monitor) 
 Error 42: Symbol Undefined __assert
C:\dmd\windows\bin\..\lib\phobos.lib(lifetime) 
 Error 42: Symbol Undefined __LDIV 
C:\dmd\windows\bin\..\lib\phobos.lib(outbuffer) 
 Error 42: Symbol Undefined __vsnprintf
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined _fclose
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined _tmpfile
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined _ftell
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined _fseek
C:\dmd\windows\bin\..\lib\phobos.lib(exception) 
 Error 42: Symbol Undefined _strerror
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined _setmode
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined ___fhnd_info
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined _fread
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined _fopen
C:\dmd\windows\bin\..\lib\phobos.lib(conv) 
 Error 42: Symbol Undefined __ULDIV 
C:\dmd\windows\bin\..\lib\phobos.lib(format) 
 Error 42: Symbol Undefined ___pfloatfmt
C:\dmd\windows\bin\..\lib\phobos.lib(errno) 
 Error 42: Symbol Undefined _errno
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined ___fp_unlock
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined __fgetc_nlock
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined __fgetwc_nlock
C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
 Error 42: Symbol Undefined ___fp_lock
C:\dmd\windows\bin\..\lib\phobos.lib(ti_cfloat) 
 Error 42: Symbol Undefined __Ccmp
Feb 21 2011
parent reply Don <nospam nospam.com> writes:
Trass3r wrote:

 In 2.052 several of the most complicated dependencies on snn.lib (those 
 relating to exception handling) were removed. I don't know how many more 
 DMC-specific ones there are, but using another snn.lib might be possible 
 now.


 
 Compiled a hello world with empty snn.lib:


That's pretty good. Almost all of those things are standard C.
LDIV and UDIV could easily be eliminated.
__except_list is a null asm label (it is FS:[0]).

So the main problematic ones are:
_xi_a , __acrtused_con, the __fp functions, and _Ccmp



 
 
 OPTLINK (R) for Win32  Release 8.00.8
 Copyright (C) Digital Mars 1989-2010  All rights reserved.
 http://www.digitalmars.com/ctg/optlink.html
 helloworld.obj(helloworld) 
  Error 42: Symbol Undefined __acrtused_con
 C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) 
  Error 42: Symbol Undefined ___alloca
 C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) 
  Error 42: Symbol Undefined __except_list
 helloworld.obj(helloworld) 
  Error 42: Symbol Undefined _fprintf
 C:\dmd\windows\bin\..\lib\phobos.lib(dmain2) 
  Error 42: Symbol Undefined _wcslen
 C:\dmd\windows\bin\..\lib\phobos.lib(deh) 
  Error 42: Symbol Undefined __tls_array
 C:\dmd\windows\bin\..\lib\phobos.lib(deh) 
  Error 42: Symbol Undefined __tls_index
 C:\dmd\windows\bin\..\lib\phobos.lib(gc) 
  Error 42: Symbol Undefined _memcpy
 C:\dmd\windows\bin\..\lib\phobos.lib(gc) 
  Error 42: Symbol Undefined _malloc
 C:\dmd\windows\bin\..\lib\phobos.lib(memory) 
  Error 42: Symbol Undefined __xi_a
 C:\dmd\windows\bin\..\lib\phobos.lib(memory) 
  Error 42: Symbol Undefined __end
 C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
  Error 42: Symbol Undefined _calloc
 C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
  Error 42: Symbol Undefined _free
 C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
  Error 42: Symbol Undefined _memset
 C:\dmd\windows\bin\..\lib\phobos.lib(object_) 
  Error 42: Symbol Undefined _strlen
 C:\dmd\windows\bin\..\lib\phobos.lib(thread) 
  Error 42: Symbol Undefined __beginthreadex
 C:\dmd\windows\bin\..\lib\phobos.lib(thread) 
  Error 42: Symbol Undefined __tlsend
 C:\dmd\windows\bin\..\lib\phobos.lib(thread) 
  Error 42: Symbol Undefined __tlsstart
 C:\dmd\windows\bin\..\lib\phobos.lib(object_) 
  Error 42: Symbol Undefined _memcmp
 C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
  Error 42: Symbol Undefined _memmove
 C:\dmd\windows\bin\..\lib\phobos.lib(gcx) 
  Error 42: Symbol Undefined _realloc
 C:\dmd\windows\bin\..\lib\phobos.lib(regexp) 
  Error 42: Symbol Undefined _printf
 C:\dmd\windows\bin\..\lib\phobos.lib(regexp) 
  Error 42: Symbol Undefined _memchr
 C:\dmd\windows\bin\..\lib\phobos.lib(datetime) 
  Error 42: Symbol Undefined _localtime
 C:\dmd\windows\bin\..\lib\phobos.lib(datetime) 
  Error 42: Symbol Undefined _tzset
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined __iob
 C:\dmd\windows\bin\..\lib\phobos.lib(monitor) 
  Error 42: Symbol Undefined __assert
 C:\dmd\windows\bin\..\lib\phobos.lib(lifetime) 
  Error 42: Symbol Undefined __LDIV 
 C:\dmd\windows\bin\..\lib\phobos.lib(outbuffer) 
  Error 42: Symbol Undefined __vsnprintf
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined _fclose
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined _tmpfile
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined _ftell
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined _fseek
 C:\dmd\windows\bin\..\lib\phobos.lib(exception) 
  Error 42: Symbol Undefined _strerror
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined _setmode
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined ___fhnd_info
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined _fread
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined _fopen
 C:\dmd\windows\bin\..\lib\phobos.lib(conv) 
  Error 42: Symbol Undefined __ULDIV 
 C:\dmd\windows\bin\..\lib\phobos.lib(format) 
  Error 42: Symbol Undefined ___pfloatfmt
 C:\dmd\windows\bin\..\lib\phobos.lib(errno) 
  Error 42: Symbol Undefined _errno
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined ___fp_unlock
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined __fgetc_nlock
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined __fgetwc_nlock
 C:\dmd\windows\bin\..\lib\phobos.lib(stdio) 
  Error 42: Symbol Undefined ___fp_lock
 C:\dmd\windows\bin\..\lib\phobos.lib(ti_cfloat) 
  Error 42: Symbol Undefined __Ccmp
Feb 21 2011
next sibling parent Trass3r <un known.com> writes:
Don Wrote:

 That's pretty good. Almost all of those things are standard C.
 LDIV and UDIV could easily be eliminated.
 __except_list is a null asm label (it is FS:[0]).
 
 So the main problematic ones are:
 _xi_a , __acrtused_con, the __fp functions, and _Ccmp


Yep, they need to be taken care of anyway to support 64Bit on Windoze, some of
them are even written in asm.


Member ..\core32\cinit.asm Offset 0x700
  __argc
  _errno
  __argv
  __xi_a

Member llmath.asm Offset 0x7E540
  __LCMP 
  __LDIV 
  __LMUL 
  __ULDIV 


Member ..\win32\constart.c Offset 0x5B280
  BSS
  __acrtused_con
Feb 21 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 That's pretty good. Almost all of those things are standard C.
 LDIV and UDIV could easily be eliminated.
 __except_list is a null asm label (it is FS:[0]).

 So the main problematic ones are:
 _xi_a , __acrtused_con, the __fp functions, and _Ccmp


So how to tackle that?
Feb 21 2011
parent reply %u <wfunction hotmail.com> writes:
 That's pretty good. Almost all of those things are standard C.
 LDIV and UDIV could easily be eliminated.
 __except_list is a null asm label (it is FS:[0]).

 So the main problematic ones are:
 _xi_a , __acrtused_con, the __fp functions, and _Ccmp





 So how to tackle that?


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.
I couldn't figure out how to solve it; I'm not sure if it was the
root cause, but I think it interfered with thread-static data,
and/or the garbage collector.

What does _xi_a even do? Is it anything more than just a marker
inside the executable?
Feb 21 2011
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
%u wrote:

 What does _xi_a even do? Is it anything more than just a marker
 inside the executable?


have you seen this page: http://wiki.osdev.org/C_PlusPlus#Visual_C.2B.2B ?
I think dmc is pretty much in line with it. You can also find these 
sections in the map files generated when compiling a D file with dmd.
Feb 22 2011
parent %u <wfunction hotmail.com> writes:
 What does _xi_a even do? Is it anything more than just a marker
 inside the executable?



 have you seen this page:


http://wiki.osdev.org/C_PlusPlus#Visual_C.2B.2B ?

 I think dmc is pretty much in line with it. You can also find these


sections in the map files generated when compiling a D file with dmd.

:O no, I hadn't! That's great information; thanks!
Feb 22 2011
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 22.02.2011 05:54, schrieb %u:

  That's pretty good. Almost all of those things are standard C.
  LDIV and UDIV could easily be eliminated.
  __except_list is a null asm label (it is FS:[0]).

  So the main problematic ones are:
  _xi_a , __acrtused_con, the __fp functions, and _Ccmp





  So how to tackle that?


 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.
 I couldn't figure out how to solve it; I'm not sure if it was the
 root cause, but I think it interfered with thread-static data,
 and/or the garbage collector.

 What does _xi_a even do? Is it anything more than just a marker
 inside the executable?


i don't if the source of snn.lib is available - is it?

but the new ida freeware version 5 
(http://www.hex-rays.com/idapro/idadownfreeware.htm) is very nice for 
the lib-analysis
(core32\cinit.asm)
Feb 23 2011
next sibling parent Trass3r <un known.com> writes:
dennis luehring Wrote:

 i don't if the source of snn.lib is available - is it?


Don't think so, that's dmc land.
Feb 23 2011
prev sibling next sibling parent Adam Ruppe <destructionator gmail.com> writes:
dennis luehring wrote:

 i don't if the source of snn.lib is available - is it?


The complete source to DMC and it's libraries are available
in the purchased development kit.
Feb 23 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/23/11, dennis luehring <dl.soluz gmx.net> wrote:

 but the new ida freeware version 5


I did not know v5 went freeware. Fantastic, thanks.
Feb 23 2011
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 22.02.2011 05:54, schrieb %u:

  That's pretty good. Almost all of those things are standard C.
  LDIV and UDIV could easily be eliminated.
  __except_list is a null asm label (it is FS:[0]).

  So the main problematic ones are:
  _xi_a , __acrtused_con, the __fp functions, and _Ccmp





  So how to tackle that?


 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.
 I couldn't figure out how to solve it; I'm not sure if it was the
 root cause, but I think it interfered with thread-static data,
 and/or the garbage collector.

 What does _xi_a even do? Is it anything more than just a marker
 inside the executable?


some light in the darkness...

http://www.nynaeve.net/?p=44
Feb 23 2011
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 22.02.2011 7:54, %u wrote:

 That's pretty good. Almost all of those things are standard C.
 LDIV and UDIV could easily be eliminated.
 __except_list is a null asm label (it is FS:[0]).

 So the main problematic ones are:
 _xi_a , __acrtused_con, the __fp functions, and _Ccmp


 So how to tackle that?


 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.
 I couldn't figure out how to solve it; I'm not sure if it was the
 root cause, but I think it interfered with thread-static data,
 and/or the garbage collector.

 What does _xi_a even do? Is it anything more than just a marker
 inside the executable?


Inspired by your works, I wasted best part of two hours and managed the 
following:
replaced snn.lib with dummy one, for now I placed _acrt_used symbol 
there which happens to be weird 32bit integer, in fact.
rebuild C part of druntime with MS C compiler into druntime_c.lib 
(that's MS COFF lib all right)
rebuild the D part of druntime -> druntime.lib (that's OMF objects, they 
can't sit together)
phobos actually builds as usual though now it lacks parts that were in 
druntime_c.lib

then I linked simple program with MSVCRT lib and got
Error: No entry point

simple.d being:
import core.stdc.stdio;
void main(){
     printf("Holly crap!\n");
}

Some google-fu later I forcibly dragged mainCRTstartup symbol in, that's 
where is C runtime entry point for MSVCRT.
I went like this:
ulink  simple.obj -i_mainCRTStartup druntime_c.lib phobos.lib

Error: Unresolved external '__tlsend' referenced from 
'C:\ulink\phobos.lib|thread.d'
Error: Unresolved external '__tlsstart' referenced from 
'C:\ulink\phobos.lib|thread.d'
Error: Unresolved external '__LDIV ' referenced from 
'C:\ulink\phobos.lib|thread.d'
Error: Unresolved external '__xi_a' referenced from 
'C:\ulink\phobos.lib|memory.d'
Error: Unresolved external '___alloca' referenced from 
'C:\ulink\phobos.lib|dmain2.d'

that's where I stopped, technically it might still be attainable.
What I gather is that windows DMD itself emits direct references on 
__LDIV, __alloca and friends found in snn.
Maybe we can get out by writing simple thunk lib to replace snn.lib that 
maps these to MS runtime analogs if any.
 From druntime source I get an idea that __tlsstart, __tlsend are 
markers emitted by DMC dealing with them
and TLS in general would be trickier ;)

-- 
Dmitry Olshansky
Feb 23 2011
next sibling parent Trass3r <un known.com> writes:
Dmitry Olshansky Wrote:

 that's where I stopped, technically it might still be attainable.
 What I gather is that windows DMD itself emits direct references on 
 __LDIV, __alloca and friends found in snn.
 Maybe we can get out by writing simple thunk lib to replace snn.lib that 
 maps these to MS runtime analogs if any.
  From druntime source I get an idea that __tlsstart, __tlsend are 
 markers emitted by DMC dealing with them
 and TLS in general would be trickier ;)


Nice work so far :)
Shouldn't something like alloca be available in VCRT as well?
Feb 23 2011
prev sibling parent reply %u <wfunction hotmail.com> writes:
So I continued my quest to remove the SNN.lib dependency (and instead depend on
MSVCRT.dll), and ran into a Heisenbug that I think might relate to TLS.
Basically, the bug shows up only if Visual Studio isn't attached to the program,
and it only happens when the program is exiting. (!)

Would anyone be willing to help me figure this out? I feel like I'm SOOOO close
and yet so far! :(

I didn't attach the files, but I could definitely write up a set of detailed
instructions saying what I did. Is anyone interested? It seems to me like if we
can only fix this one error, we should be done with porting druntime to SNN.lib,
and then we can focus on porting higher-level things like std.stdio (which
should be much more straightforward).

Anyone interested?
Feb 28 2011
parent reply Trass3r <un known.com> writes:
What's the error?
Mar 01 2011
parent %u <wfunction hotmail.com> writes:
 what's the error?


I get an access violation at (or sometimes around) the statement

    ModuleInfo* m = _moduleinfo_tlsdtors[i];

inside _moduleTlsDtor() in object_.d.

My entire code for the main file is below (although there's obviously more to
the process, like the .obj files,
a few other changes, etc.):

------------------------------------------------------------
import core.stdc.wchar_ : wprintf;
import core.runtime : Runtime;

pragma(lib, "msvcrt.lib");
pragma(startaddress, mainCRTStartup);
extern (C)
{
    //Is this right? What does it even do?
    static __gshared uint _acrtused_con = 0x00009876;
    int main(int argc, char** argv); //in dmain2.d
}

//Just to avoid bringing in Phobos here... unsafe though
void writefln(S...)(in wchar[] format, S args)
{ wprintf(format.ptr, args); wprintf("\n"); }

extern (Windows) int mainCRTStartup()
{
	Runtime.initialize();
	scope(exit) Runtime.terminate(); // << ERROR here
	return main(0, null);
}

int main(string[] args)
{
	writefln("%u", args.length);
	return 0;
}
-------------------------------------------------------------

If I comment out the line with the error, it runs fine *inside* the Visual
Studio debugger, but crashes outside
(at a similar place)... can't figure it out, and I think you might need to
actually try it to see what I mean.

Any ideas?
Mar 01 2011
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 21.02.2011 15:26, schrieb Don:

 Trass3r wrote:

  In 2.052 several of the most complicated dependencies on snn.lib (those
  relating to exception handling) were removed. I don't know how many more
  DMC-specific ones there are, but using another snn.lib might be possible
  now.


  Compiled a hello world with empty snn.lib:


 That's pretty good. Almost all of those things are standard C.
 LDIV and UDIV could easily be eliminated.
 __except_list is a null asm label (it is FS:[0]).


question out of curiosity - would it be a good idea
(or technical solveable) to replace the snn.lib complete with D code?
Feb 23 2011
parent reply Trass3r <un known.com> writes:
dennis luehring Wrote:

 question out of curiosity - would it be a good idea
 (or technical solveable) to replace the snn.lib complete with D code?


Doesn't make sense since you'd have to introduce the D runtime into C runtime
code (remember that dmc also uses that runtime for compiling C code)
Furthermore I expect it wouldn't technically work cause the D runtime itself
requires a C runtime.
Feb 23 2011
parent dennis luehring <dl.soluz gmx.net> writes:
Am 23.02.2011 12:56, schrieb Trass3r:

 dennis luehring Wrote:

  question out of curiosity - would it be a good idea
  (or technical solveable) to replace the snn.lib complete with D code?


 Doesn't make sense since you'd have to introduce the D runtime into C runtime
code (remember that dmc also uses that runtime for compiling C code)
 Furthermore I expect it wouldn't technically work cause the D runtime itself
requires a C runtime.



introduce the D runtime into C runtime code


why? (except you want to use the existing C runtime code)


I expect it wouldn't technically
work cause the D runtime itself requires a C runtime.


ok maybe a bootstrap is needed - dmd/phobos links with snn.lib produced 
by dmc, and another compile/link run for dmd and phobos - with an D 
version of snn.lib

i don't the big technical difficulty here - any special case? something 
that can't be done with D?

do the WinApi needs some form of C-Runtime initalisation on 
Application-side? (i don't think so) - and the excecption-stuff is 
win-api based not c-runtime, or?
Feb 23 2011
prev sibling parent reply Trass3r <un known.com> writes:
 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
Feb 22 2011
parent reply %u <wfunction hotmail.com> writes:
 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. :)
Feb 22 2011
parent Trass3r <un known.com> writes:
Sounds like a lot of fun ;)
I'm also sick of dmd's policy to mess everything up on Windows by completely
depending on dmc and its friends while Linux users have a proper linker, libc
and object format.
I mean wouldn't it be the easiest way to use COFF + MinGW's ld and libc since
it's very similar to what is used on Linux?
Feb 22 2011