Imports in DWT

[bobef]

John Reimer Wrote:

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

I use bud only to build dwt.lib (6.6mb) and then use plain dmd to build the program, that's why I add all the libs. But maybe this pragma-s should remain not only for version(build), but for DMD also. It is pragma(lib,...) I think though.

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

Why don't you add versions? Like -version(xp) or something. At least I don't care for win98. I am not sure if this is a common case though.

> 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
> 
>