• yidabu <yidabu.nospam gmail.com> Mar 02 2008
• davidl <davidl 126.com> Mar 02 2008
• yidabu <yidabu.nospam gmail.com> Mar 02 2008
• John Reimer <terminal.node gmail.com> Mar 02 2008
• "Kris" <foo bar.com> Mar 02 2008
• John Reimer <terminal.node gmail.com> Mar 03 2008

larger executable building with DWT-WIN
    
A helloworld.exe build with DWT-WIN (-release), the executable size is 1.93 MB :
    
import dwt.widgets.Display;
import dwt.widgets.Shell;

void main ()
{
	Display display = new Display;
	Shell shell = new Shell(display);

	shell.setText = "Hello DWT World";
	shell.open;

	while (!shell.isDisposed)
		if (!display.readAndDispatch)
			display.sleep;

	display.dispose;
}



build with DFL (-release), the exectuable size is 284 KB :
    
import dfl.all;

int main()
{
	Form myForm;
	
	myForm = new Form;
	myForm.text = "Hello world";
	
	Application.run(myForm);
	
	return 0;
}

Anybody now What's cause this,  How larger executable size building with
DWT-WIN ?



-- 
yidabu <yidabu.nospam gmail.com>
SciTE4D Text Editor for D Programming Language:
http://scite4d.chinese-blog.org/

DWin library for D language, Windows COM support with Tango:
http://dwin.chinese-blog.org

在 Mon, 03 Mar 2008 08:04:45 +0800，yidabu <yidabu.nospam gmail.com> 写道:

 import dwt.widgets.Display;
 import dwt.widgets.Shell;
 void main ()
 {
 	Display display = new Display;
 	Shell shell = new Shell(display);
 	shell.setText = "Hello DWT World";
 	shell.open;
 	while (!shell.isDisposed)
 		if (!display.readAndDispatch)
 			display.sleep;
 	display.dispose;
 }



how's your dwt-win built?
do you build dwt-win with -release?

-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

build dwt.lib with -release, 
then build helloworld.exe with DSSS, executable size is 2.45 MB
DSSS may increase the size, but failed build with DMD e.g. :

dmd helloworld.d -release -inline -O -L/SUBSYSTEM:windows:5


5+tango-user-dmd.lib+dwt.lib+dfl.lib+dwin.lib+ydb.lib+pcre.lib+user32.lib+kernel
32.lib;
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

D:\d\dmd\bin\..\tango\lib\dwt.lib(Accessible)
 Error 42: Symbol Undefined _LresultFromObject 12
D:\d\dmd\bin\..\tango\lib\dwt.lib(Accessible)
 Error 42: Symbol Undefined _SysAllocString 4
D:\d\dmd\bin\..\tango\lib\dwt.lib(Accessible)
 Error 42: Symbol Undefined _SysStringByteLen 4
D:\d\dmd\bin\..\tango\lib\dwt.lib(COM)
 Error 42: Symbol Undefined _SysFreeString 4
D:\d\dmd\bin\..\tango\lib\dwt.lib(GC)
 Error 42: Symbol Undefined _AlphaBlend 44
D:\d\dmd\bin\..\tango\lib\dwt.lib(GC)
 Error 42: Symbol Undefined _TransparentBlt 44
D:\d\dmd\bin\..\tango\lib\dwt.lib(GC)
 Error 42: Symbol Undefined _GradientFill 24
D:\d\dmd\bin\..\tango\lib\dwt.lib(Accessible)
 Error 42: Symbol Undefined _CreateStdAccessibleObject 16
D:\d\dmd\bin\..\tango\lib\dwt.lib(Device)
 Error 42: Symbol Undefined _ScriptGetProperties 8
D:\d\dmd\bin\..\tango\lib\dwt.lib(OleClientSite)
 Error 42: Symbol Undefined _VariantClear 4
D:\d\dmd\bin\..\tango\lib\dwt.lib(OleClientSite)
 Error 42: Symbol Undefined _OleCreatePropertyFrame 44
D:\d\dmd\bin\..\tango\lib\dwt.lib(Variant)
 Error 42: Symbol Undefined _VariantChangeType 16
D:\d\dmd\bin\..\tango\lib\dwt.lib(Variant)
 Error 42: Symbol Undefined _VariantInit 4
--- errorlevel 13























On Mon, 03 Mar 2008 10:41:47 +0800
davidl <davidl 126.com> wrote:

 �� Mon, 03 Mar 2008 08:04:45 +0800��yidabu <yidabu.nospam gmail.com> �:
 
 import dwt.widgets.Display;
 import dwt.widgets.Shell;
 void main ()
 {
 	Display display = new Display;
 	Shell shell = new Shell(display);
 	shell.setText = "Hello DWT World";
 	shell.open;
 	while (!shell.isDisposed)
 		if (!display.readAndDispatch)
 			display.sleep;
 	display.dispose;
 }


 
 how's your dwt-win built?
 do you build dwt-win with -release?
 
 -- 
 ʹ�� Opera �����Եĵ����ʼ��ͻ�����: http://www.opera.com/mail/



-- 
yidabu <yidabu.nospam gmail.com>
SciTE4D Text Editor for D Programming Language:
http://scite4d.chinese-blog.org/

DWin library for D language, Windows COM support with Tango:
http://dwin.chinese-blog.org

yidabu wrote:

 larger executable building with DWT-WIN
     
 A helloworld.exe build with DWT-WIN (-release), the executable size is
 1.93 MB :
     
 import dwt.widgets.Display;
 import dwt.widgets.Shell;
 
 void main ()
 {
 Display display = new Display;
 Shell shell = new Shell(display);
 
 shell.setText = "Hello DWT World";
 shell.open;
 
 while (!shell.isDisposed)
 if (!display.readAndDispatch)
 display.sleep;
 
 display.dispose;
 }
 
 
 
 build with DFL (-release), the exectuable size is 284 KB :
     
 import dfl.all;
 
 int main()
 {
 Form myForm;
 
 myForm = new Form;
 myForm.text = "Hello world";
 
 Application.run(myForm);
 
 return 0;
 }
 
 Anybody now What's cause this,  How larger executable size building with
 DWT-WIN ?
 
 
 


It's bigger for several reasons (in no particular order):

1) DWT is much larger than DFL with many more widgets.  This means more
power... at a cost.

2) DWT supports multiple windows platforms in one library; this means it
contains specific support for both win98, windows XP, and Vista (among
others).  This means more code; the advantage is that binaries built with
dwt are more likely to be compatible with all windows platforms.  The
disadvantage, of course, is extra bloat.

3) The porting emphasis for DWT has been to "get it working"; little work
has yet gone into optimizing it for size.

4) DWT has a extensive network of interdependencies among it's modules and
many of its widgets have complex inheritance structures; it's almost like
spaghetti to put it plainly.  This forces a large number of objects to be
linked in that aren't necessarily visibly used.  This is probably not the
case with dfl, which has a decidedly lean profile since it was built from
scratch for D (not ported from a large Java project).

5) Porting from Java means adopting a large number of mechanisms that aren't
strictly necessary in D.  This style forces a larger footprint on DWT. 
Some other mechanisms are important for exception recovery and thread
safety.

That said, there is a plenty of opportunity for size improvement in DWT that
hasn't even been touched yet.  It will never shrink to the size of DFL, but
I imagine we can slim it down a bit from it's current size.  There are some
cleanup techniques still waiting to be applied to the code base.  

Even so, please understand that DWT, like SWT, is a large GUI library and
does not compete directly with DFL.  DFL wins hands down for size,
simplicity, and clean-coding.  DWT, I think, is a power-house of features
and will reach audiences that are a little more "greedy" for cross-platform
support and comprehensive GUI interface design in their applications. :)

-JJR

This is where better support for D and dynamic-loading would make a very 
useful impact. It seems like .so works quite well under linux, but .dll 
support (from DMD) is still miserable under win32.

Would be really interesting to hear of your efforts (if any) to turn DWD-WIN 
into a .dll

- Kris



"John Reimer" <terminal.node gmail.com> wrote in message 
news:fqg43r$1if1$1 digitalmars.com...
 yidabu wrote:

 larger executable building with DWT-WIN

 A helloworld.exe build with DWT-WIN (-release), the executable size is
 1.93 MB :

 import dwt.widgets.Display;
 import dwt.widgets.Shell;

 void main ()
 {
 Display display = new Display;
 Shell shell = new Shell(display);

 shell.setText = "Hello DWT World";
 shell.open;

 while (!shell.isDisposed)
 if (!display.readAndDispatch)
 display.sleep;

 display.dispose;
 }



 build with DFL (-release), the exectuable size is 284 KB :

 import dfl.all;

 int main()
 {
 Form myForm;

 myForm = new Form;
 myForm.text = "Hello world";

 Application.run(myForm);

 return 0;
 }

 Anybody now What's cause this,  How larger executable size building with
 DWT-WIN ?


 It's bigger for several reasons (in no particular order):

 1) DWT is much larger than DFL with many more widgets.  This means more
 power... at a cost.

 2) DWT supports multiple windows platforms in one library; this means it
 contains specific support for both win98, windows XP, and Vista (among
 others).  This means more code; the advantage is that binaries built with
 dwt are more likely to be compatible with all windows platforms.  The
 disadvantage, of course, is extra bloat.

 3) The porting emphasis for DWT has been to "get it working"; little work
 has yet gone into optimizing it for size.

 4) DWT has a extensive network of interdependencies among it's modules and
 many of its widgets have complex inheritance structures; it's almost like
 spaghetti to put it plainly.  This forces a large number of objects to be
 linked in that aren't necessarily visibly used.  This is probably not the
 case with dfl, which has a decidedly lean profile since it was built from
 scratch for D (not ported from a large Java project).

 5) Porting from Java means adopting a large number of mechanisms that 
 aren't
 strictly necessary in D.  This style forces a larger footprint on DWT.
 Some other mechanisms are important for exception recovery and thread
 safety.

 That said, there is a plenty of opportunity for size improvement in DWT 
 that
 hasn't even been touched yet.  It will never shrink to the size of DFL, 
 but
 I imagine we can slim it down a bit from it's current size.  There are 
 some
 cleanup techniques still waiting to be applied to the code base.

 Even so, please understand that DWT, like SWT, is a large GUI library and
 does not compete directly with DFL.  DFL wins hands down for size,
 simplicity, and clean-coding.  DWT, I think, is a power-house of features
 and will reach audiences that are a little more "greedy" for 
 cross-platform
 support and comprehensive GUI interface design in their applications. :)

 -JJR


 

Kris wrote:
 This is where better support for D and dynamic-loading would make a very 
 useful impact. It seems like .so works quite well under linux, but .dll 
 support (from DMD) is still miserable under win32.
 
 Would be really interesting to hear of your efforts (if any) to turn DWD-WIN 
 into a .dll
 
 - Kris
 
 



Totally agree.  I was thinking about that the other day.  I haven't 
tried making a shared library yet, but the difficulty will be on 
windows, no doubt.  It should be fairly simple to do on Linux.

-JJR