Required to link windows header modules (?)

[Sean Kelly]

Walter Bright wrote:
> Sean Kelly wrote:
>> phobos.lib(date)
>>  Error 42: Symbol Undefined 
>> __init_3std1c7windows7windows21TIME_ZONE_INFORMATION
>>
>> phobos.lib(file)
>>  Error 42: Symbol Undefined 
>> __init_3std1c7windows7windows16WIN32_FIND_DATAW
>> phobos.lib(file)
>>  Error 42: Symbol Undefined 
>> __init_3std1c7windows7windows15WIN32_FIND_DATA
>> phobos.lib(gcx)
>>  Error 42: Symbol Undefined __init_3std1c7windows7windows7CONTEXT
>> phobos.lib(syserror)
>>  Error 42: Symbol Undefined _MAKELANGID at 8
> 
> Ok, these are the static initializers for the struct, and a function for 
> MAKELANGID. My next question is what's the issue with linking with 
> windows.obj?

Linking with the windows module present in Phobos isn't a big deal.  But 
the Windows header project Don has been working on is quite expansive, 
and simply importing windows.d ends up pulling in a substantial chunk of 
the windows modules.  This slows compilation noticeably and increases 
binary size significantly--simply importing Don's windows.d in my test 
app made the executable size increase from ~90K to over 150K.  This 
appears to be related at least in part to what appears to be a fixed 
minimum for importing a module using DMD of approximately 500 bytes, 
which I assume is the ModuleInfo data and similar things.

What I find confusing, however, is that I don't appear to need to link 
in the standard C modules I've defined in order to use the structs 
defined there.  I performed a quick test using struct tm and no 
dependency problems came up simply by compiling the test app itself and 
linking against a library without std.c.time in it.  Assuming I didn't 
mess up the test somehow, can you explain the difference between this 
situation and the Windows one?  If it's simply a matter of having the 
static initializers available, I'm fine with building everything, but 
the inconsistency doesn't seem to make sense.


Sean