FiveTech Software tech support forums

I wonder why the size of the EXEs generated with FWH is growing so much in the last times.

EMG

All the new developments are resulting in linking of many new functions, all of which may or may not be really necessary for the actual application.

Probably we may need to examine what all the functions that are included in the final exe and split some library modules so that only the needed functions are linked.

Enrico,

Have you compared the size of an EXE with and without FWH ?

nageswaragunupudi wrote:All the new developments are resulting in linking of many new functions, all of which may or may not be really necessary for the actual application.

Probably we may need to examine what all the functions that are included in the final exe and split some library modules so that only the needed functions are linked.

That's what exactly what I had in my mind but I think it would be too much work for our friend and master Antonio.

EMG

Antonio Linares wrote:Enrico,

Have you compared the size of an EXE with and without FWH ?

Yes:

Code: Select all  Expand view

#include "Fivewin.ch"


FUNCTION MAIN()

    RETURN NIL

Harbour: 615424
Harbour+FWH: 1817600
xHarbour: 765952
xHarbour+FWH: 1887232

EMG

Enrico,

Please add a RDD function call (i.e. DbCreate()) to force the link of the RDD system in the non FWH app

Antonio Linares wrote:Enrico,

Please add a RDD function call (i.e. DbCreate()) to force the link of the RDD system in the non FWH app

Done:

Harbour: 615936
xHarbour: 765952

This is the sample:

Code: Select all  Expand view

FUNCTION MAIN()

    USE TEST

    RETURN NIL

EMG

Enrico,

OLE support should be also added

CreateObject()

Code: Select all  Expand view

FUNCTION MAIN()

    LOCAL oWord := CREATEOBJECT( "Word.Application" )

    oWord:Quit()

    USE TEST

    RETURN NIL

xHarbour: 787968

EMG

Enrico,

Its almost impossible to reduce size due the use of Object Oriented programming, because classes inherit ones from anothers so finally we get the whole "gorilla" even if we just want the "banana"

http://en.wikipedia.org/wiki/Object-oriented_programming

Joe Armstrong, the principal inventor of Erlang, is quoted as saying "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

Anyhow when you are going to build a professional app you do need all those classes. In case that you are just going to build a small tool and not a complete app, then you can replace FWH Classes with dummy functions to remove the "gorilla"

Code: Select all  Expand view

function TWindow()
return nil
 

Antonio Linares wrote:Enrico,

Its almost impossible to reduce size due the use of Object Oriented programming, because classes inherit ones from anothers so finally we get the whole "gorilla" even if we just want the "banana"

Yes, but I'm wondering why the size has grown so much in relatively recent times.

Antonio Linares wrote:In case that you are just going to build a small tool and not a complete app, then you can replace FWH Classes with dummy functions to remove the "gorilla"

Code: Select all  Expand view

function TWindow()
return nil
 

Thanks for the tip.

EMG

Enrico,

> Yes, but I'm wondering why the size has grown so much in relatively recent times.

If you build an EXE and review the generated MAP file, there you can see all the modules that get linked in and their sizes.

FWH has grown due to more features requirements and that makes the resulting EXEs grow too. Anyhow those sizes, and much larger, are perfectly managed by modern computers

Ok.

EMG

With FWH 9.12

Code: Select all  Expand view

#include 'fivewin.ch'

function Main()

  msginfo( 'ok' )

return nil

FWH and Harbour 1,389,056
FWH and xHarbour 1,423,360

I just tried: it's a wonderful result! My compliments!

EMG