[Delphi] Hoe maak ik m'n EXE kleiner?

[Osiris]

Ik zit nu ff lekker te kloten in Delphi 6 en da's harstikke leuk, maar nu valt me één ding op:
M'n EXE's worden zo groot. Ik heb nu één proggie waar alleen maar wat labels, checkboxen en wat andere dingen in staan en dat programma is al bijna 500 kB!

Weet iemand een manier om de grootte van de EXE naar beneden te halen?

_{Een compressie-prog ofzo?}

[The-Source]

Volgens mij kon je dat doen door een aantal meegeleverde packages in je exe uit te schakelen. Dit doe je volgens mij in Project Options of zoiets (het is alweer een poosje geleden dat ik met Delphi aan de slag ben gegaan).

[MisterData]

ZIPPEN

[Verwijderd]

Op maandag 17 december 2001 20:40 schreef MisterData het volgende:
ZIPPEN

Op m'n werk hebben ze daar het proggie UPX voor:

C:\>upx
Ultimate Packer for eXecutables
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001
UPX 1.20w Markus F.X.J. Oberhumer & Laszlo Molnar May 23rd 2001

Usage: upx [-123456789dlthVL] [-qvfk] [-o file] file..

Commands:
-1 compress faster -9 compress better
-d decompress -l list compressed file
-t test compressed file -V display version number
-h give more help -L display software license
Options:
-q be quiet -v be verbose
-oFILE write output to `FILE'
-f force compression of suspicious files
-k keep backup files
file.. executables to (de)compress

This version supports: dos/exe, dos/com, dos/sys, djgpp2/coff, watcom/le,
win32/pe, rtm32/pe, tmt/adam, atari/tos, linux/386

UPX comes with ABSOLUTELY NO WARRANTY; for details type `upx -L'.

Werkt perfect! [edit] Nou ja, bijna altijd, je moet 'm altijd nog even opnieuw runnen om te kijken of 'tie het nog wel doet

[Osiris]

Nee, dat van die packages uitschakelen helpt niet

En dat van ZIPPEN was natuurlijk nutteloos! Onzin posten doe je maar in de HK!
Ik heb het niet voor niets over de EXE! Ik weet ook heus wel dat zippen het kleiner maakt...

En met dat UPX, blijft het dan een normale executable?

[RickN]

Op maandag 17 december 2001 20:43 schreef Osiris_NL het volgende:
Nee, dat van die packages uitschakelen helpt niet

En dat van ZIPPEN was natuurlijk nutteloos! Onzin posten doe je maar in de HK!
Ik heb het niet voor niets over de EXE! Ik weet ook heus wel dat zippen het kleiner maakt...

En met dat UPX, blijft het dan een normale executable?

DAMN, beetje gauw aangebrand niet waar. geeft nog duidelijker aan dat het een geintje is dan als je het mij vraagt...

[MisterData]

Op maandag 17 december 2001 20:43 schreef Osiris_NL het volgende:
En dat van ZIPPEN was natuurlijk nutteloos! Onzin posten doe je maar in de HK!
Ik heb het niet voor niets over de EXE! Ik weet ook heus wel dat zippen het kleiner maakt...

Hmm, en een Self-extracting zip-file dan ?? Wordt ook een exe

Dat van dat zippen was trouwens gewoon een grapje. Kan natuurlijk altijd dat ik andere humor heb dan jij

[serieus-mode]
Maar inderdaad, dat UPX ziet er wel interresant uit. Waar is dat ergens te downloaden ???
[/serieus-mode]

[BasieP]

bij je 'uses' dingen weghalen die je niet nodig hebt, als je geen forms hebt, kun je die bijv uitschakelen

[Verwijderd]

UPX comprimeerd de data, en unzipt t naar het geheugen voordat de app gestart wordt.

Nadelen:
-Trager opstarten
-Als de app meerdere keren draait iedere keer evenveel geheugengebruik
-Foute virusmeldingen bij oude scanners

Volgens mij kun je bij Delphi heel veel dingen uit zetten die niet gebruikt worden maar standaard wel meegebakken.

[Osiris]

Ik snapte ook nog wel dat dat van ZIPPEN een grapje was, maar grapjes maken doe je maar in de HK...

_{Ennuh, dat was nog niet geladen voordat ik op de Reply-knop douwde}

edit: Url voor UPX (untested): Klik hier!

edit 2 : Url updated

[MisterData]

Ik ken Delphi zelf helemaal niet, maar in Java is het zo dat je overbodige imports er beter uit kan halen om zo een stuk geheugen en een stuk bestandsgrootte kan besparen.

En zit er in de compiler (als die er is) geen optimize optie om de code te verkleinen ??

[Verwijderd]

Met UPX mag 'tie dan een miliseconde langzamer starten, dat neem je dan toch wel op de koop toe. Wat ik je kan vertellen over delphi (5, misschien ook 6), is dat als je bijv. een aantal DB-componenten op je form sleept, en je gooit alle db-componenten er weer af, dat dan bovenin de Form1.pas nog steeds Uses staat met _al die db-componenten-dcu's_, dus als je ze even allemaal weggooid, opnieuw saved, dan zet delphi opnieuw de goeie neer, en deze keer niet teveel.

[roelio]

volgens mij geldt dat totaal *niet* voor Java omdat de compiler (.java >>> .class) er wel voor zorgt dat de juiste imports wel en niet meegenomen worden, de overbodige laat ie erbuiten. Dus als je java.awt.*; importeert dan zoekt ie zelf uit wat ie nodig heeft, voor de leesbaarheid van je code is het soms slimmer om klassen expliciet aan te geven, bijvoorbeeld als je Vector gebruikt is import java.util.Vector; duidelijker dan java.util.*; omdat lezers van je code anders niet meteen zien wat er allemaal gebruikt wordt uit .util ...

[Osiris]

Hé! Met UPX is ie nog maar 18- kB. Nu nog ff wat nutteloze dingen eruit pleuren en klaar is Osiris!

[Verwijderd]

Build with runtime packages aanvinken in het packages tabblad van de project opties.

Je moet dan wel een of meerdere bpl bestanden meeleveren als je de applicatie op een computer zet zonder delphi.

Bpl's zijn eigenlijk gewoon DLL's en bevatten de componenten sets. Een combinatie bpl's + exe is trouwens meestal groter dan een standaard gecompilde exe omdat daar alleen het nodige toevoegt uit de source van de bpl's in de exe.

De compiler stopt trouwens naar mijn weten nooit source in de exe die niet wordt gegebruikt, dus het verwijderen van units uit de uses regel heeft geen zin naast leesbaarheid verbetering
Bij een standaard exe kun je trouwens nog wel een paar KB wegsnoepen door al de debugging opties uit te vinken onder het compiler tabblad (project opties) en natuurlijk optimisation aan laten.

[MisterData]

[reactie op limoentje]
Ow. Eerlijk gezegd dacht ik dat eerst wel
Het scheelt natuurlijk wel in geheugen gebruik

[mulder]

Maar dan is de volgende vraag: waarom? 500 Kb is dat nou zo groot tegenwoordig?

[chris]

Met delphi kan je hele kleine exe's maken, maar dan moet je in de Project Source gaan kutten, en alle forms en units verwijderen. Maar om op je vraag terug te komen: meestal zitten er behoorlijk wat nutteloze (voor jou dan) functies in, je zou kunenn overwegen alle gebruikte functies copy en pasten in een unit zodat je alleen compileert wat je nodig hebt. Je kan ook ff zoeken op google, kwam daar laatst ook nog zoiets tegen.

[Verwijderd]

Je kunt ook zelf de api's gaan callen voor het maken van forms ipv de zooi in de forms unit te gebruiken. Dan krijg je exe's van <20KB

[Osiris]

Op maandag 17 december 2001 20:57 schreef El_Mundo het volgende:
Maar dan is de volgende vraag: waarom? 500 Kb is dat nou zo groot tegenwoordig?

D'r zijn nog mensen met normale modems hoor. 'k Had eens een Flashje naar een vriend van me gestuurt. Werd ie pissig, omdat ie te groot was!

[Skinkie]

je had toch ook speciaal voor delphi files een packer die de resources ging inpakken.

volgens mij bij http://www.torry.ru/ is wel wat te vinden.

[_JGC_]

Op maandag 17 december 2001 20:48 schreef dev het volgende:
UPX comprimeerd de data, en unzipt t naar het geheugen voordat de app gestart wordt.

Nadelen:
-Trager opstarten
-Als de app meerdere keren draait iedere keer evenveel geheugengebruik
-Foute virusmeldingen bij oude scanners

Volgens mij kun je bij Delphi heel veel dingen uit zetten die niet gebruikt worden maar standaard wel meegebakken.

Dat trager opstarten merk je bij ons op school nix van, juist sneller. Wat zou sneller zijn? Een EXE van 2MB van een fileserver halen die ondertussen 2x op z'n gat ligt, of 200K van de fileserver halen en uitpakken in geheugen?
Ik denk het laatste, aangezien dan de server hooguit 1x op z'n gat ligt (ja, op school draaien we W2K Pro als fileserver, stoer he?)

[Verwijderd]

Het ligt er maar aan waar je t voor wilt gebruiken. Als je een app meerdere malen wilt draaien moet je t zeker niet doen. Probeer maar ns iets in te pakken met UPX en dat 3x te starten Het geheugen gebruik is dan veel hoger als in normale situaties.

[mulder]

Op maandag 17 december 2001 21:00 schreef Osiris_NL het volgende:

[..]

D'r zijn nog mensen met normale modems hoor. 'k Had eens een Flashje naar een vriend van me gestuurt. Werd ie pissig, omdat ie te groot was!

Maar dan is gewoon zippen toch de oplossing? Wat ik bedoel te zeggen: je had ze nu misschien heel wat op de hals, maar is het echt nodig, levert het je nou echt voordeel op? Maar dat neemt dan ook niet weg dat het wel weer interessant is om een mooie oplossing te vinden natuurlijk.

[_JGC_]

Windows met UPX compressen, mag je weer om extra geheugen

BTW: Als ik een EXE file zo bekijk met een HEX-Editor, zie ik aan het eind een hele berg 0000000'en, waar je programma ook zonder kan (nemen alleen maar ruimte in)
Weet iemand waarom een compiler die dingen erin zet aan het eind (en waarom ertussen? Je komt soms ook gewoon 32K lege ruimte in een DLL tegen)

[roelio]

Op maandag 17 december 2001 20:55 schreef MisterData het volgende:
[reactie op limoentje]
Ow. Eerlijk gezegd dacht ik dat eerst wel
Het scheelt natuurlijk wel in geheugen gebruik

hmmm volgens mij ook niet omdat de onnodige imports gewoon niet meegenomen worden door de compiler... het enige verschil wat het expliciet aangeven dan de imports volgens mij geeft, is dat je een klein beetje (en ik denk een een heul klein bietje) compile-time bespaart...

[JayTaph]

Op maandag 17 december 2001 21:32 schreef _JGC_ het volgende:
Windows met UPX compressen, mag je weer om extra geheugen

BTW: Als ik een EXE file zo bekijk met een HEX-Editor, zie ik aan het eind een hele berg 0000000'en, waar je programma ook zonder kan (nemen alleen maar ruimte in)
Weet iemand waarom een compiler die dingen erin zet aan het eind (en waarom ertussen? Je komt soms ook gewoon 32K lege ruimte in een DLL tegen)

Omdat dat variable's zijn uit je .DATA segment.

Eventjes een korte demonstratie (LCCWIN32, aangezien ik nu eventjes onder windows aan het werken ben).

Programma 1:

code:

#include <stdio.h>

char s[10240];

void main (void) {
  printf ("hello world\n");
}

Programma 2:

code:

#include <stdio.h>

char s[10240] = "blaat";

void main (void) {
  printf ("hello world\n");
}

Het enige verschil is dat in programma 1 de variabele S ongedefineerd is en in programma 2 is dat "blaat".

Ongedefineerde variabelen vallen (meestal) in het .BSS segment. Een exe-file zegt gewoon tegen het OS: dit is mijn programma en dat bevat een variabele die 10240 bytes ruimte nodig heeft. REGEL DAT!

Als de variabele in .DATA zou staan dan zou het programma zelf voor die ruimte zorgen (en hoe doe je dat, door het programma 10240 bytes langer te maken).

Waarom zou je dus iets in data zetten?
Als je bijvoorbeeld een variabele hebt waar al iets in staat, bijvoorbeeld "blaat".
Je declareert welliswaar maar 5 bytes, maar je moet de hele variabele in .DATA zetten.

Programma 1 zou dus heel erg klein zijn (aangezien S in BSS staat) en programma 2 dus heel erg groot (aangezien S in DATA staat).

Wat programma's zoals ULX zouden doen:
Stel je hebt dus s in je .DATA staan, en deze bevat "blaat" met 10235 nullen. Hij compressed zo'n string tot grofweg: "blaat + 10235 * 0". (dit moet je niet te letterlijk nemen, maar hier komt het op neer). De string is nu dus geworden: "blaat" + een getal + een "0" is 7 a 8 characters.. Scheelt al flink in de data :-) (feitelijk is ULX een realtime-unzipper, dus ik vond de eerste opmerking "zippen" waar zo agressief op gereageerd werd niet eens zo erg dom).


[post_it]
Nou niet gaan mierenneuken als ik het niet helemaal goed uitleg, het gaat om de grove lijnen hier
[/post_it]

edit:

Bij de weg: heb je gewoon als eens geprobeerd om je DEBUG-opties uit te zetten?

[Osiris]

Debug-opties uitzetten? Zal ff kijken.

_{Ow, laat ik effe noemen, dat dit mijn eerste keer is dat ik met Delphi 6 kloot. Ik ben gewend aan Borland Pascal en dat soort ouwe troep...}

edit: nope, geen effect, 't blijft ongeveer 500 kB

[Creepy]

Op maandag 17 december 2001 20:54 schreef XSDnied het volgende:
De compiler stopt trouwens naar mijn weten nooit source in de exe die niet wordt gegebruikt, dus het verwijderen van units uit de uses regel heeft geen zin naast leesbaarheid verbetering

Moet je natuurlijk van die units WEL de source gebruiken! Delphi gebruikt standaard de DCU's (das al gecompileerde units). Als je die gebruikt d.m.v. uses, zal de complete unit worden gebruikt, en aangezien alles al is gecompileerd, kan de compiler er niks meer uitgooien. Als je die unit niet gebruikt is dit dus lekker overbodig. De "uses overbodige_unit" weghalen scheelt in dit geval flink!.

[JayTaph]

Ik geloof dat turbo pascal toendertijd een smart linker had die overbodige functies (en dus ook units) die niet werden aangeroepen standaard niet meelinkte. Ik neem aan dat dit ook in delphi zit..

[Verwijderd]

Op maandag 17 december 2001 20:43 schreef Boer_Frients het volgende:

[..]

Op m'n werk hebben ze daar het proggie UPX voor:

...

'k Vraag me alleen af wat er gebeurd als je je exe COM-enabled maakt en vervolgens met zo'n compressor toevoegt. De exe zal danwel gewoon starten vanuit de explorer, maar hoe gaat het bijv. vanuit VB als je een reference naar de exe zet?

[Verwijderd]

Op dinsdag 18 december 2001 09:11 schreef Osiris_NL het volgende:
Debug-opties uitzetten? Zal ff kijken.

_{Ow, laat ik effe noemen, dat dit mijn eerste keer is dat ik met Delphi 6 kloot. Ik ben gewend aan Borland Pascal en dat soort ouwe troep...}

edit: nope, geen effect, 't blijft ongeveer 500 kB

Valt trouwens reuze mee t.o.v. Delphi 4. Deze maakt sowieso al een exe van 800 kb als ik het goed heb. 't Is wel zo dat de exe niet veel groter wordt als je heel veel forms/code toevoegt. De grootste exe (welke alleen gebruik maakt van forms en de Standard Components = alleen labels, editboxes, buttons etc) die ik ooit gerealiseerd heb was 1200 kb (en daar zaten heel veel formulieren en code in. Na zippen bleef van deze exe toch nog 700 kb. over.

[Verwijderd]

Op maandag 17 december 2001 20:43 schreef Osiris_NL het volgende:
Nee, dat van die packages uitschakelen helpt niet

En dat van ZIPPEN was natuurlijk nutteloos! Onzin posten doe je maar in de HK!
Ik heb het niet voor niets over de EXE! Ik weet ook heus wel dat zippen het kleiner maakt...

En met dat UPX, blijft het dan een normale executable?

Misschien weet ik een oplossing. Maar ik durf 'm eigenlijk niet te zeggen, straks schiet je ook tegen mij zo uit de slof en daar kan ik niet zo goed tegen. Gewoon een beetje je fatsoen houden jo, daar kom je een stuk verder mee en hoef ik me niet aan jou w gedrag te ergeren. 2 mensen blij, wat wil je nog meer.
Kusjes xxx

[Delpix]

Op dinsdag 18 december 2001 10:26 schreef hvdberg het volgende:

[..]

Valt trouwens reuze mee t.o.v. Delphi 4. Deze maakt sowieso al een exe van 800 kb als ik het goed heb. [......]

800KB ????? Ik heb 2 jaar lang met Delphi 4 CS gewerkt en me EXE's waren kleiner dan die van Delphi 6. Standaard zo rond de 400KB.

[Rense Klinkenberg]

Op maandag 17 december 2001 20:40 schreef MisterData het volgende:
ZIPPEN

idd.: http://www.pkware.com/products/pklite.html

Dat proggie gebruikte microsoft vroeger in de dos tijd ook op al hun proggies. Zlef heb ik het ook eens losgelaten op mijn proggies in de turbo pascal tijd en dat werkte zwaar goed. Je merkt helemaal niet dat ie langzamer is, omdat ie de .exe moet uitpakken, terijwl het bestand toch een heel stuk kleiner wordt.

[Verwijderd]

Op dinsdag 18 december 2001 10:19 schreef hvdberg het volgende:
'k Vraag me alleen af wat er gebeurd als je je exe COM-enabled maakt en vervolgens met zo'n compressor toevoegt. De exe zal danwel gewoon starten vanuit de explorer, maar hoe gaat het bijv. vanuit VB als je een reference naar de exe zet?

Als 't voor compressie een COM-server was, zal 't dat daarna ook nog wel zijn.

[Osiris]

Whahaha! Met PKLite doet ie 'et niet meer!

_{'k Gebruik UPX wel...
't Programma kan maar één keer opgestart worden, dus geheugenproblemem krijgt ie ook niet...}

[fw]

Op maandag 17 december 2001 23:21 schreef JayTaph het volgende:

[..]
...
[post_it]
Nou niet gaan mierenneuken als ik het niet helemaal goed uitleg, het gaat om de grove lijnen hier
[/post_it]

...

Ik vond het wel een mooi verhaaltje, mooie globale uitleg imho.

[Verwijderd]

Op dinsdag 18 december 2001 22:10 schreef Afterlife het volgende:

[..]

Als 't voor compressie een COM-server was, zal 't dat daarna ook nog wel zijn.

Misschien, maar het lijkt me heel sterk. En daarna, kun je dit ook gebruiken voor DLL's Als ik er zo over nadenk niet naar alle waarschijnlijkheid.

[Guillome]

Probeer eens te zoeken naar ASPack ( of mail mij )
Die pakt EXE files (en DLL en OCX ofzo) tot wel 60 - 80 % in.
Echt hoor, een file van 1.4MB is daarna nog zo`n 400 kb.
En hij is meteen beveiligd tegen De-Compilers.

[warp]

Compilen zonder debugging symbols e.d. wil ook wonderen doen

[Kool]

1.
Gebruik GEEN exe-compressors als het mogelijk/nuttig is dat gebruikers meerdere instanties van je prog openen. Dan wordt de geheugenruimte namelijk NIET gedeeld en neemt je prog in het geheugen veel meer ruimte in. En wat is schaarser, schijfruimte of ram-ruimte De distributefiles kun je TOCH zippen.

2.
Handmatig functietjes uit SysUtils ofzo kopieren naar je eigen unit heeft geen enkele zin. Delphi neemt alleen de code die broodnodig is mee in je source. Overbodige units uit je uses halen heeft WEL zin.

3.
Alle debug info uitzetten en optimalizatie aan in je project opties.

4.
Dubbel gebruikte code onderbrengen in een functie. Blz. 1, regel 1 uit programmeren voor beginners trouwens Maar je moet eens weten hoeveel mensen dat verdommen.

Er is dus eigenlijk niet veel wat je kunt doen, behalve zelf je windows messages afhandelen en daar niet de VCL voor gebruiken, maar waarom zou je anders Delphi gebruiken...

Groeten en suc6 Kool

[Delpix]

Tip: Gebruik Delphi 2 om de kleinste 32 bits delphi apps te maken. Een lege Delphi 2 app met een form was dacht ik maar 156KB groot.

[Killemov]

Er zijn in grote lijnen 2 manieren waarop je met Delphi een executeable kan maken: Alle benodigde code in een exe (static linking?) of alleen JOUW code in een exe en de rest uit de runtime-libraries (dynamic linking?) halen. Met dat laatste komt een simpele app zoals jij die beschrijft maar uit op een paar tiental KB's. Dat laatste is sowieso handig om te gebruiken als je een suite van programma's maakt.
Maar goed, als jouw programma groeit dan wordt de exe relatief dus maar een klein beetje groter.

[Delphi32]

Even voor alle mensen die debug options uitzetten om de exe kleiner te maken:
er is maar één debug option die je exe doet groeien (en flink ook): dat is TurboDebug aanzetten. Dat doet gelukkig bijna niemand. Alle andere opties hebben GEEN invloed op de grootte van de exe.
Wel van invloed:
-optimization (een klein beetje)
-stack frames
-alle error protection (divide by zero, i/o errors en nog 1 die ik niet uit mn hoofd weet)
en misschien nog een paar op dat project-options scherm, maar Debug Info heeft GEEN invloed op de omvang van je exe.

[Tomatoman]

Waarom wil je eigenlijk een kleine executable hebben? In de laatste vijf jaar is een typische Delphi executable misschien 50% groter geworden, maar is de gemiddelde harddisk minstens 10 keer zo groot geworden. Schijfruimte kan dus onmogelijk het probleem zijn.

En als je een executable wilt mailen over een trage telefoonlijn, dan zip je het bestand toch gewoon? Ik begrijp echt niet wat hier mis mee is.

[Verwijderd]

Op vrijdag 15 februari 2002 12:39 schreef XLerator het volgende:
Probeer eens te zoeken naar ASPack ( of mail mij )
Die pakt EXE files (en DLL en OCX ofzo) tot wel 60 - 80 % in.
Echt hoor, een file van 1.4MB is daarna nog zo`n 400 kb.
En hij is meteen beveiligd tegen De-Compilers.

Ik ben geen expert op het gebied van kraken, maar ik dacht ergens gelezen te hebben dat packagers in het algemeen juist NIET een goede beveiliging vormen, omdat er de-packagers voor beschikbaar zijn; dus een vals gevoel van veiligheid.

Nog een reactie op tomatoman hierboven: ik heb net UPX en WinRAR (alle met hoogste compressie) losgelaten op een Delphi progje van 1882kb. Resultaten:

ZIP: 705kb
RAR: 620kb
UPX: 552kb
UPX en dan geRARd of geZIPt: 538 kb

Het scheelt toch wel zo'n 30% tussen direct zippen of eerst UPXen; als telefoonmodem-gebruiker zal ik het altijd waarderen als een download zo klein mogelijk is en meer dan 30% verschil vind ik toch niet verwaarloosbaar .

[edit]
Mocht iemand het niet weten, UPX is een gratis/GnuGPL exe/dll packager. Adres: http://upx.sourceforge.net/

[WOmBaT]

Ik heb ASPack geprobeerd over een winampplugin en dan koekt het zaakje helemaal vast. Die UPX werkte wel bij mij en de dll is nu nog maar 60% van het origineel

[freddifish]

met veel inline assembler krimpt hij misschien ook wel

[Verwijderd]

Als je een grafisch interface niet echt nodig hebt dan kun je er een console application van maken zodat je start bij een exe grootte van 'slechts' 40kb. Nog steeds veel voor een proggramma dat nog niks doet maar het scheelt een heel stuk.

[Verwijderd]

Programma's als UPX zijn natuurlijk heel mooi. Maar is het niet interessanter om na te gaan waarom de Delphi executables zo groot zijn?

Het komt door de forms unit. Op het moment dat je deze unit in je uses clausule zet, wordt je executable al bijna 200K. Dat is natuurlijk niet echt gewild, maar het gebruik van de forms unit maakt het designtime ontwikkelen van je forms wel een stuk makkelijker.

Is er een oplossing? Niet echt, maar je kunt bijv. de forms unit uit je uses clausule halen en je forms met Windows API calls aanmaken (CreateWindowEx).

[jelmervos]

Hoe komt het dan dat Delphi die EXE zo groot krijgt, waarom is die forms unit zo groot?

[Verwijderd]

Just some damn bad programming

[kvdveer]

Ook de schuld van de compiler.
Die behoort ongebruikte functies, variabelen en objecten er uit te filteren. Dat doet 'ie alleen voor globale functies. Niet voor memberfuncties. Bovendien laat 'ie onegbruikte objecten gewoon zitten! (dus hoewel je hele project geen checkbox gebruikt, wordt 'ie toch meegenomen.
De formsunit is hier trouwens niet eens de grote dader, dat is de classes-unit. Die overigens wordt geinclude door de forms unit. De forms-unit draagt hier natuurlijk wel aan bij.