Re: A nice way to step into 2012

[Long Chang]

Lambda very cool!

I hope we can add shared lib support for linux & freebsd in 2012.


On 27 December 2011 12:25, Andrei Alexandrescu
 wrote:
> https://github.com/D-Programming-Language/dmd/commit/675898721c04d0bf155a85abf986eae99c37c0dc
>
> Andrei

Re: D1 to be discontinued on December 31, 2012

[Long Chang]

I use dwt and tango for some project recent.

Before dwt2 and minid and other cool project is ready for d2, I will
still need  D1.

On 13 December 2011 21:52, Don  wrote:
> On 10.12.2011 22:19, Andrei Alexandrescu wrote:
>>
>> In order to increase focus and unity in the language, we are
>> discontinuing support for D1 on December 31, 2012. That's more than one
>> year away, which gives enough time to D1 users to migrate libraries and
>> applications to D2.
>
>
> I thought we had moved away from these kinds of unilateral decisions.
> I strongly oppose this decision. In particlar, I find the lack of community
> consulatation deplorable.

Re: Shared lib support for Linux

[Long Chang]

It's been five months since I last ask for dynamic lib support of
linux ,   I want to know when this can be achieved .

A rough schedule time will be very help,  thank in advance .

On 22 March 2011 11:31, Long Chang  wrote:
>
> Hello ,
>
> The DMD will support shared lib for linux in future,  But I wan't to
> know when this can be completed .
>
> I am try use GDC build libgdruntime.a with -fPIC,  and catch some
> error I can't fix it .
>
> for example:
> ../../../../libphobos/rt/arraybyte.d
> ../../../../libphobos/rt/arraybyte.d: In function
> ‘_arraySliceExpAddSliceAssign_g’:
> ../../../../libphobos/rt/arraybyte.d:220: error: PIC register ‘ebx’
> clobbered in ‘asm’
>
> If Druntime team can help GDC team fix this issue will be great .
>
>
> Kind Regards / Long Chang

Re: CURL review request

[Long Chang]

http://gool.googlecode.com/files/libcurl_7.21.7.zip
this libcurl static lib is build by dmc , with openssl support .

On 16 August 2011 19:48, Jonas Drewsen  wrote:

> Hi all,
>
>   This is a review request for the curl wrapper. Please read the "known
> issues" in the top of the source file and if possible suggest a solution.
>
> We also need somebody for running the review process. Anyone?
>
> Code:
>
> https://github.com/jcd/phobos/**blob/curl-wrapper/etc/curl.d
> Docs:
>
> http://freeze.steamwinter.com/**D/web/phobos/etc_curl.html
>
> Demolish!
>
> /Jonas
>

Re: D2 & Web-Framework

[Long Chang]

I create one , fastcgi & template is done , but I need dynamic link lib of
posix support , http://d.puremagic.com/issues/show_bug.cgi?id=6014 also
block the jade template engine .

https://github.com/sleets/oak

Re: a 'Shared libraries for Linux' question

[Long Chang]

The shared lib support for Linux is very important for me .  I ask
people is there a schedule or plan once, but not get any responded .

I hope the somebody can tell us some information about this .

On Tue, Mar 29, 2011 at 11:53 AM, David Wang  wrote:
> Dear,
>
> We would like to know that whats the details of D2's next milstone ("Shared
> libraries for Linux") ?
>
> Will be shared with GTK+ 3.0 ? or other libraries ?
>
> As I know, GTK+ 3.0 has formally released (now its version is GTK+ 3.0.4),
> and it introduced a "GObject Introspection" which can widely enlarge the
> programming languages' bundling using (I think could includes D Language).
>
> "GObject Introspection" implements calling GObject easily and fluently. It
> means that every Language just need to build a 'GObject Introspection'
> bundle, then the Language can easily and fluently call every API of GTK+ 3.0
> through this bundle.
> GTK+ 3.0 is a very very good GUI level libraries, and it was written in C.
>
>
> Best regards.
> David.
>



-- 
.

Re: Shared lib support for Linux

[Long Chang]

I install libc_pic ,  and got this error :

gcc -shared -o dmd_xtpl.so dmd_xtpl.o -fPIC -m64
-L/home/opt/usr/local/lib64 -lgdruntime
-lc_pic/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/libc_pic.a(init-first.os):
In function `_init':
(.text+0x20): multiple definition of `_init'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crti.o:(.init+0x0):
first defined here
/usr/bin/ld: dmd_xtpl.so: version node not found for symbol
pthread_cond_destroy@@GLIBC_2.3.2
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status


On Tue, Mar 22, 2011 at 8:57 PM, Iain Buclaw  wrote:
> == Quote from Long Chang (changl...@jkys.info)'s article
>> Hello ,
>> The DMD will support shared lib for linux in future,  But I wan't to
>> know when this can be completed .
>> I am try use GDC build libgdruntime.a with -fPIC,  and catch some
>> error I can't fix it .
>> for example:
>> ../../../../libphobos/rt/arraybyte.d
>> ../../../../libphobos/rt/arraybyte.d: In function
>> ‘_arraySliceExpAddSliceAssign_g’:
>> ../../../../libphobos/rt/arraybyte.d:220: error: PIC register ‘ebx
>> ’
>> clobbered in ‘asm’
>> If Druntime team can help GDC team fix this issue will be great .
>> Kind Regards / Long Chang
>
> Ignoring any bugs in Druntime and DMD regarding PIC code generation; GDC puts 
> all
> used registers in any given asm statement in the clobbered list. Without 
> this, GCC
> will not know of their usage, and so assumes the register(s) are free, 
> therefore
> it may decide to use them for storing other data.
>
> Regards
>
>



-- 
.

Re: Shared lib support for Linux

[Long Chang]

On Tue, Mar 22, 2011 at 8:57 PM, Iain Buclaw  wrote:
> == Quote from Long Chang (changl...@jkys.info)'s article
>> Hello ,
>> The DMD will support shared lib for linux in future,  But I wan't to
>> know when this can be completed .
>> I am try use GDC build libgdruntime.a with -fPIC,  and catch some
>> error I can't fix it .
>> for example:
>> ../../../../libphobos/rt/arraybyte.d
>> ../../../../libphobos/rt/arraybyte.d: In function
>> ‘_arraySliceExpAddSliceAssign_g’:
>> ../../../../libphobos/rt/arraybyte.d:220: error: PIC register ‘ebx
>> ’
>> clobbered in ‘asm’
>> If Druntime team can help GDC team fix this issue will be great .
>> Kind Regards / Long Chang
>
> Ignoring any bugs in Druntime and DMD regarding PIC code generation; GDC puts 
> all
> used registers in any given asm statement in the clobbered list. Without 
> this, GCC
> will not know of their usage, and so assumes the register(s) are free, 
> therefore
> it may decide to use them for storing other data.
>
> Regards
>
>

I delete all error asm code line,  it building success .

But when I build my project, got this error :

gcc -shared -o dmd_xtpl.so dmd_xtpl.o -L/home/opt/usr/local/lib64/
-lgphobos2 -lgdruntime -fPIC
/usr/bin/ld: /home/opt/usr/local/lib64//libgphobos2.a(errno_.o):
relocation R_X86_64_PC32 against undefined symbol
`__errno_location@@GLIBC_2.2.5' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

Re: Shared lib support for Linux

[Long Chang]

On Tue, Mar 22, 2011 at 8:57 PM, Iain Buclaw  wrote:
> == Quote from Long Chang (changl...@jkys.info)'s article
>> Hello ,
>> The DMD will support shared lib for linux in future,  But I wan't to
>> know when this can be completed .
>> I am try use GDC build libgdruntime.a with -fPIC,  and catch some
>> error I can't fix it .
>> for example:
>> ../../../../libphobos/rt/arraybyte.d
>> ../../../../libphobos/rt/arraybyte.d: In function
>> ‘_arraySliceExpAddSliceAssign_g’:
>> ../../../../libphobos/rt/arraybyte.d:220: error: PIC register ‘ebx
>> ’
>> clobbered in ‘asm’
>> If Druntime team can help GDC team fix this issue will be great .
>> Kind Regards / Long Chang
>
> Ignoring any bugs in Druntime and DMD regarding PIC code generation; GDC puts 
> all
> used registers in any given asm statement in the clobbered list. Without 
> this, GCC
> will not know of their usage, and so assumes the register(s) are free, 
> therefore
> it may decide to use them for storing other data.
>
> Regards
>
>

The GDC default build script report this error and stop building,  I
don't know to to ignore it.

If the next GDC  can release  with shared lib support will be great news .

Shared lib support for Linux

[Long Chang]

Hello ,

The DMD will support shared lib for linux in future,  But I wan't to
know when this can be completed .

I am try use GDC build libgdruntime.a with -fPIC,  and catch some
error I can't fix it .

for example:
../../../../libphobos/rt/arraybyte.d
../../../../libphobos/rt/arraybyte.d: In function
‘_arraySliceExpAddSliceAssign_g’:
../../../../libphobos/rt/arraybyte.d:220: error: PIC register ‘ebx’
clobbered in ‘asm’

If Druntime team can help GDC team fix this issue will be great .


Kind Regards / Long Chang

Re: Moving to D

[Long Chang]

2011/1/6 Walter Bright 

> bearophile wrote:
>
>> Adrian Mercieca:
>>
>>  How does D square up, performance-wise, to C and C++ ? Has anyone got any
>>> benchmark figures?
>>>
>>
>> DMD has an old back-end, it doesn't use SSE (or AVX) registers yet (64 bit
>> version will use 8 or more SSE registers), and sometimes it's slower for
>> integer programs too.
>>
>
> The benchmarks you posted where it was supposedly slower in integer math
> turned out to be mistaken.
>
>
>  I've seen DMD programs slow down if you nest two
>> foreach inside each other. There is a collection of different slow
>> microbenchmarks.
>>
>> But LDC1 is able to run D1 code that looks like C about equally fast as C
>> or
>> sometimes a bit faster.
>>
>> DMD2 uses thread local memory on default that in theory slows code down a
>> bit
>> if you use global data, but I have never seen a benchmark that shows this
>> slowdown clearly (an there is __gshared too, but sometimes it seems a
>> placebo).
>>
>> If you use higher level constructs your program will often go slower.
>>
>
> Rubbish. The higher level constructs are "lowered" into the equivalent low
> level constructs.
>
>
>
>  Often one of the most important things for speed is memory management, D
>> encourages to heap allocate a lot (class instances are usually on the
>> heap),
>> and this is very bad for performance,
>>
>
> That is not necessarily true. Using the gc can often result in higher
> performance than explicit allocation, for various subtle reasons. And saying
> it is "very bad" is just wrong.
>
>
>
>  also because the built-in GC doesn't
>> have an Eden generation managed as a stack. So if you want more
>> performance
>> you must program like in Pascal/Ada, stack-allocating a lot, or using
>> memory
>> pools, etc. It's a lot a matter of self-discipline while you program.
>>
>
> This is quite wrong.
>

I using D for 3 years . I am not in newsgroup because my English is very
pool .
D is excellent , I try it with Libevent,  Libev,  pcre, sqlite,  c-ares,
dwt, and a lot other amazing Lib. It work great with C-lib .   I enjoy it so
much .
My work is a web developer, I also try use D in web field ,  It not result
well .

Adam D. Ruppe post some interesting cod in here , And I find a lot people
try in web field. for example: (mango, https://github.com/temiy/daedalus,
Sendero  ... )   , But in the end I had to say, most D project is dying .

D like a beautiful girl friends,  You play with her can have a lot of fun.
But she is be scared to make promisee ,   you can't count your life on it.
she is not a good potential marriage .  her life is still in mess, and day
after day she is more smart but not become more mature.so if you want do
some serious work ,  You'd better choose another language.  if you just wan
fun , D is a good  companion .

Re: DMD Backend Long-term

[Long Chang]

In windows if you want use some lib that is not provide dynamic dll support,
you need compile it with dmc. In this case your need deal a lot problem with
lack of c head file . if there is a vc++ version backend will be big help
for a lot of people who is not familiarity with c/c++ .



2010/6/22 Eldar Insafutdinov 

> == Quote from dsimcha (dsim...@yahoo.com)'s article
> > What is the long-term plan for the current DMD backend?  I've noticed the
> > first steps towards 64-bit support were just checked in today (excitement
> to
> > the extreme).  However, the backend is under such a restrictive license
> (which
> > I understand Walter is not free to change) that it has a "bus factor" of
> 1.
> > If Walter were to stop maintaining it, noone else would be able to, if I
> > understand the licensing issues correctly.
> > Is there a chance of these licensing issues being cleared up so that the
> > backend can be released under a more permissive license?  If not, while I
> > understand Walter's decision to use a backend he was familiar with in the
> > beginning, it seems like we should abandon such a heavily encumbered
> backend
> > now that it needs serious work.
>
> Hi
>
> I agree with what Sean says. Even more, DMD backend is good for development
> process, because it is very fast as opposed to more popular ones like llvm
> or gcc.
> What really worries me is what is going to happen on Windows. We have the
> burden
> which is old file format and optlink. There are still big problems with the
> linker, it has random problems on big projects, building them with debug
> info is
> even more problematic. As far as I understood that linker is being
> rewritten to C,
> but the process is very slow. It may take years to complete the port, and
> then to
> make it 64bit capable, isn't it? All existing problems would be propagated
> further. I would suggest(again and again) to add a new Windows backend
> targeting
> MinGW or MSVC toolchain. It should not necessarily replace the existing
> one, but
> people would at least have freedom and there wouldn't be situation that you
> are
> stuck in development when linker fails. Also those toolchain support 64bit,
> so it
> is another advantage. For those who still wants digital mars toolchain -
> there
> will be an old one. Remembering that it took Walter about 6 weeks to
> implement
> MacOS backend, that doesn't seem too bad. In the end, Windows is the most
> popular
> OS despite our personal preferences, and it's worth spending some time for
> it.
>
> Cheers
>

Re: Marketing of D - article topic ideas?

[Long Chang]

how to generate a header file in the source files dir? when i wan't get a
big project like dwtx headers, i like push all source file to dmd and generate
header file, but there is a lot source file have same name, and i only get
one header file in dmd run dir or Hd dir。
This is very inconvenient for such a large projects,  Is there any way to
avoid this problem?

2010/6/4 Walter Bright 

> D is an extremely powerful language, but when I read complaints and sighs
> about other languages, few seem to know that these problems are solved with
> D. Essentially, we have a marketing problem.
>
> One great way to address it is by writing articles about various aspects of
> D and how they solve problems, like
> http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/
>  which was well received on reddit.
>
> Anyone have good ideas on topics for D articles? And anyone want to stand
> up and write an article?
>
> They don't have to be comprehensive articles (though of course those are
> better), even blog entries will do.
>

Re: File size problem

[Long Chang]

xfbuild reduce the file size to 14M, cost memory to 20M.
compressed  size is 1M.

Re: File size problem

[Long Chang]

2009/12/13 torhu :
> On 12.12.2009 1:11, Long Chang wrote:
>>
>> I build dwt-win&  dwtx with dmd 1.053&  tango trunk on win32 . the
>> execute file size is huge.
>>
>> I build  dwt-samples\jface.text\Simple.d, the execute file size is
>> 24051kb, the file has 21733kb binary value is 0xff&  0x00,  after
>> upx compress the file size is 1034kb.
>
> Please try the advice posted here, and see if it helps:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=2254#c10
>

thank you for he tip.

the file size is still big with xfbuild or bud,  build dwtx.jface.text
will gen a float exe file.
the exe file can be compress  to 5% size.  when it run cost 29M memroy
even i already use upx compress  it .
I think there is some issue inside dmd or optlink.
the dwt is great lib, but had not get enough attention from Walter.
if we make a Product Level DWT  lib,  Will attract a lot of
programmers even without a IDE.

File size problem

[Long Chang]

I build dwt-win & dwtx with dmd 1.053 & tango trunk on win32 .
 the execute file size is huge.

I build  dwt-samples\jface.text\Simple.d, the execute file size is
24051kb, the file has 21733kb binary value is 0xff & 0x00,  after upx
compress the file size is 1034kb.

 I want to know is the optlink bring this issue ?
 The new version of optlink will fix it?
 About how long the new optlink be useful?

Re: Can we have this Syntactic sugar.

[Long Chang]

2009/11/24 Long Chang :
>
>
> enum CompileTimeOption{
>
>     ANCHORED ，
>     AUTO_CALLOUT ,
>     CASELESS ,
>     ENDONLY  ,
>     DOTALL  ,
>     EXTENDED ,
>     EXTRA   ,
>     FIRSTLINE ,
>     MULTILINE  ,
>     NO_AUTO_CAPTURE  ,
>     UNGREEDY ,
>     UTF8 ,
>     NO_UTF8_CHECK  ,
>     DUPNAMES  ,
>     NEWLINE_CR   ,
>     NEWLINE_LF   ,
>     NEWLINE_CRLF   ,
>     NEWLINE_ANY   ,
> }
>
> public class RegExp
> {
>     enum {
>         X, Y, Z
>     }
>     this(char[] pattern, int options = 0){}
>     static RegExp opCall(char[] pattern, int option2){}
> }
>
> void main(){
>     RegExp reg1    = new RegExp("^A.+", CompileTimeOption.UTF8 |
> CompileTimeOption.MULTILINE | CompileTimeOption.DOTALL );
>     // Syntactic sugar.
>     RegExp reg2    = new RegExp("^A.+",
>             CompileTimeOption.( UTF8 | MULTILINE | DOTALL )
>         );
>     const MyRegExpOption    = CompileTimeOption.( UTF8 | MULTILINE | DOTALL
> );
>     RegExp reg3    = RegExp( "^A.+",  .(X+Y*Z) );
>
>     int X    = 33;
>
>     RegExp reg4    = RegExp( "^A.+",  .( X+ .X /* the outer X */  ) );
>
> }
>

Int Y = 3;
const MyRegExpOption= CompileTimeOption.( UTF8 | MULTILINE |
DOTALL  +  RegExp.(X +Y + CompileTimeOption.DOTALL   +  outer.Y  )
);

I think there should not be any ambiguity， and it should work in ctfe .

It is not With(Object){}, It 's a part of a Expressions，can be Nested。

Re: Can we have this Syntactic sugar.

[Long Chang]

2009/11/24 Steven Schveighoffer :
> On Tue, 24 Nov 2009 10:26:08 -0500, Nick Sabalausky  wrote:
>
>> "Long Chang"  wrote in message
>> news:mailman.499.1259061212.20261.digitalmar...@puremagic.com...
>>>
>>> class RegExp
>>> {
>>>   enum Option{
>>>       X, Y, Z
>>>   }
>>>   int options;
>>>   this(int options = 0){ this.options = options; }
>>> }
>>>
>>> void main(){
>>>      auto reg  = new RegExp("^A.",   .Option(  X |Y|Z ) );
>>>      assert( RegExp .Option.X | RegExp .Option.Y| RegExp .Option.Z   ==
>>> reg.options );
>>> }
>>>
>>
>> That's a very good idea, I like that a lot.
>
> The .Option is already taken, it means "look in the global scope".
>
> However, doing RegExp.Option(X|Y|Z) would be cool.
>
> -Steve
>
It 's not "look in the global scope";
we can write this way:

RegExp.Option.(X|Y|Z)

there is a DOT befor (

Re: is this a dmd bug ?

[Long Chang]

 this.outer also. work on d1.
 thank you guys.

Re: is this a dmd bug ?

[Long Chang]

I use the d1 & tango trunk & dwt-win.
there is a new dispose method for Object, and Dwt-win already have a dispose
width Event argument.

I try it with outer,  the error is :


x.d(17): Error: undefined identifier outer
x.d(17): Error: undefined identifier outer
x.d(17): Error: no property 'toString' for type 'int'
x.d(17): Error: function expected before (), not 1 of type int

Re: is this a dmd bug ?

[Long Chang]

how about this case:


public interface Listener {
void handleEvent (int);
}

class Test{
this(){
Listener listener= new class() Listener {
public void handleEvent(int evt) {
toString(evt);
}
};
}

void toString(int evt){

}
}

void main(){

}

---
x.d(17): Error: function object.Object.toString () does not match parameter
types (int)
x.d(17): Error: expected 0 arguments, not 1 for non-variadic function type
char[]()

is this a dmd bug ?

[Long Chang]

public interface Listener {
void handleEvent (int);
}

void main(){
void print(int evt){

}
Listener listener= new class() Listener {
public void handleEvent(int evt) {
.print(evt);
}
};
}

---
x.d(20): Error: undefined identifier module x.print
x.d(20): Error: function expected before (), not module x.print of type void

Re: Can we have this Syntactic sugar.

[Long Chang]

class RegExp
{
enum Option{
X, Y, Z
}
int options;
this(int options = 0){ this.options = options; }
}

void main(){
   auto reg  = new RegExp("^A.",   .Option(  X |Y|Z ) );
   assert( RegExp .Option.X | RegExp .Option.Y| RegExp .Option.Z   ==
reg.options );
}

Can we have this Syntactic sugar.

[Long Chang]

enum CompileTimeOption{

ANCHORED ，
AUTO_CALLOUT ,
CASELESS ,
ENDONLY  ,
DOTALL  ,
EXTENDED ,
EXTRA   ,
FIRSTLINE ,
MULTILINE  ,
NO_AUTO_CAPTURE  ,
UNGREEDY ,
UTF8 ,
NO_UTF8_CHECK  ,
DUPNAMES  ,
NEWLINE_CR   ,
NEWLINE_LF   ,
NEWLINE_CRLF   ,
NEWLINE_ANY   ,
}

public class RegExp
{
enum {
X, Y, Z
}
this(char[] pattern, int options = 0){}
static RegExp opCall(char[] pattern, int option2){}
}

void main(){
RegExp reg1= new RegExp("^A.+", CompileTimeOption.UTF8 |
CompileTimeOption.MULTILINE | CompileTimeOption.DOTALL );
// Syntactic sugar.
RegExp reg2= new RegExp("^A.+",
CompileTimeOption.( UTF8 | MULTILINE | DOTALL )
);
const MyRegExpOption= CompileTimeOption.( UTF8 | MULTILINE | DOTALL
);
RegExp reg3= RegExp( "^A.+",  .(X+Y*Z) );

int X= 33;

RegExp reg4= RegExp( "^A.+",  .( X+ .X /* the outer X */  ) );

}

Re: Should we make DMD1.051 the recommended stable version?

[Long Chang]

2009/11/18 Don 

> If anyone has a reason that they have to use 1.030 instead of 1.051, now
> would be a great time to say why.
>

dmd 1.030 build small execute file size on windows.


I use bud build the dwt.lib. then use "dmd -L+dwt.lib" build the execute
file. it is much fast then other ways.

the problem is , execute file size  is become very big since dmd 1.41 .
I try dwt-win and dwt Shawn Liu ,  the  execute file size  is both grow big.

I try dmd 1.035 to dmd 1.041, the  execute file size  is similar,  build
Snippet38 the size is 850kb.

I try dmd 1.041 to dmd1052,  the file size is 1.7M。

my os is Window XP.

I use " bud all.d -clean -full -allobj -ofdwt -release -O -I../ -lib " to
build dwt.lib.


I use " dmd1040 Snippet38.d  -IE:\dmd\gui\dwt1
-L+advapi32_dwt.lib+gdi32_dwt.lib+comctl32_dwt.lib+comdlg32.lib+imm32_dwt.lib+kernel32_dwt.lib+msimg32_dwt.lib+ole32_dwt.lib+oleacc_dwt.lib+oleaut32_dwt.lib+olepro32_dwt.lib+shell32_dwt.lib+user32_dwt.lib+usp10_dwt.lib+version_dwt.lib+uuid.lib+dwt.lib
-L/SUBSYSTEM:windows:4 " to build Snippet38 .

I spent a lot of time on this issue,  and post some mail to newsgroup.
may be because my poor english, no body reply.

Re: Should we make DMD1.051 the recommended stable version?

[Long Chang]

2009/11/18 Don 

If anyone has a reason that they have to use 1.030 instead of 1.051, now
> would be a great time to say why.
>

dmd 1.030 build small execute file size on windows.


I use bud build the dwt.lib. then use "dmd -L+dwt.lib" build the execute
file. it is much fast then other ways.

the problem is , execute file size  is become very big since dmd 1.41 .
I try dwt-win and dwt Shawn Liu ,  the  execute file size  is both grow big.

I try dmd 1.035 to dmd 1.041, the  execute file size  is similar,  build
Snippet38 the size is 850kb.

I try dmd 1.041 to dmd1052,  the file size is 1.7M。

my os is Window XP.

I use " bud all.d -clean -full -allobj -ofdwt -release -O -I../ -lib " to
build dwt.lib.


I use " dmd1040 Snippet38.d  -IE:\dmd\gui\dwt1
-L+advapi32_dwt.lib+gdi32_dwt.lib+comctl32_dwt.lib+comdlg32.lib+imm32_dwt.lib+kernel32_dwt.lib+msimg32_dwt.lib+ole32_dwt.lib+oleacc_dwt.lib+oleaut32_dwt.lib+olepro32_dwt.lib+shell32_dwt.lib+user32_dwt.lib+usp10_dwt.lib+version_dwt.lib+uuid.lib+dwt.lib
-L/SUBSYSTEM:windows:4 " to build Snippet38 .

I spent a lot of time on this issue,  and post some mail to newsgroup.
may be because my poor english, no body reply.