www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - larger executable building with DWT-WIN

reply yidabu <yidabu.nospam gmail.com> writes:
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
Mar 02 2008
next sibling parent davidl <davidl 126.com> writes:
在 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/
Mar 02 2008
prev sibling next sibling parent yidabu <yidabu.nospam gmail.com> writes:
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 +0800yidabu <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
Mar 02 2008
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
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
Mar 02 2008
parent reply "Kris" <foo bar.com> writes:
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

Mar 02 2008
parent John Reimer <terminal.node gmail.com> writes:
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
Mar 03 2008