Imports in DWT

[John Reimer]

bobef wrote:

> Frank Benoit Wrote:
> 
>> bobef schrieb:
>> 
>> BTW, did it work with bud?
> 
> Tango is fixed. Bud works flawlessly. Here is what I did. Much shorter
> than the installation guide :)
> 
> bud all.d -clean -lib -full -allobj -O -release -inline
> 
> ...takes some time.. rename all.lib to dwt.lib, put the import libraries
> in dmd/lib, remove duplicates from dm/lib (they are older)
> 
> dmd myfle.d dwt.lib kernel32.lib gdi32.lib ole32.lib advapi32.lib shell32.
> lib user32.lib msimg32.lib gdiplus.lib comctl32.lib comdlg32.lib
> oleaut32.lib olepro32.lib usp10.lib oleacc.lib
> 
> ... compiles kind of slow and the exe is 1.8mb for hello world but it is
> loading pretty fast, so I guess it is OK.


That's great to know. 

I'm surprised, though, that you have to add all the implibs to the command
line.  DWT.d declares a version(build) section with the necessary
pragma(link, ...) directives for these libraries.  Does this not work with
bud?  I guess the dsss pragma must be incompatible with bud's.

1.8 mb is about average, I think.  I can't remember what the dsss size is,
but I know that if you do a dsss build (creating a dwt library) and dsss
install and then build the sample project, you get a smaller executable
than if you used dsss directly to build all necessary dwt modules at once.

I'm thinking, though, that there is a lot of redundant information in this
dwt port still.  I'm hoping we can shrink the size more.  We can get rid of
the const declarations for one and use enum constants instead.  

Another thing that makes dwt somewhat bloated is it's intrinsic platform
detection.  It has many code sections to test whether it is on win98, NT,
XP, Vista, and Win CE, and then does platform specific calls in those
sections.  This is unfortunate bloat (wish these didn't use different API
calls)... but it seems to add flexibility. Frank and I have already removed
many of the Win CE code sections merely by making the "if" sections
into "static if", but this does not solve many other situations that deal
with Vista and earlier versions.  I guess those may as well be left in as a
bonus because it makes the executables runnable across windows versions.

Some of the code has not been D'ized either, so there's much room for
improvement there too.  But for now, porting is still the priority. :)

-JJR