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
D:\d\dmd\bin\..\..\dm\bin\link.exe test,,,user32+kernel32/noi/SUBSYSTEM:windows:
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