[w32/c++] low-fragmentation heap

[demonite]

Heren (en wellicht dames)

Heeft iemand wel eens geprobeerd een low fragmentation heap op te zetten ?
Volgens de MSDN moet dat mogelijk zijn :

code:

ULONG ulHeapCompatibilityInformation ;
   ulHeapCompatibilityInformation = 2;
   if(HeapSetInformation(hCHeap,HeapCompatibilityInformation,&ulHeapCompatibilityInformation,
      sizeof(ulHeapCompatibilityInformation))) {
      wprintf(L"Heap algorithm set to %s Low-fragmentation heap(handle=0x%x)\n", 
         buf[ulHeapCompatibilityInformationRequested], hCHeap);
   }
   else
      wprintf( L"Unable to set  Heap information to %s (handle=0x%x)GetLastError()= %d 0x%x\n", 
         buf[ulHeapCompatibilityInformationRequested],hCHeap, GetLastError(), GetLastError());
   }

Deze functionaliteit zou in windows XP moeten zitten. Maar ik krijg dus alleen maar een error (31=A device attached to the system is not functioning)

Zo wel met hCHeap = GetProcessHeap() als met hCHeap = HeapCreate(..)

...

[SWfreak]

Ik kwam dit nog tegen met Google
MSDN link
Schijnbaar moet je _get_heap_handle gebruiken. IS weliswaar CRT only, maar misschien werkt dat wel?

[ Voor 9% gewijzigd door SWfreak op 15-07-2003 09:46 ]

[demonite]

Die heb ik ook gezien.. Maar bij de functie HeapSetInformation wordt niet gesproken over _get_heap_handle.. Daar staat juist weer dat CreateHeap() of GetProcessHeap() moet gebruiken...

En het vreemde is dat _get_heap_handle() niet voorkomt in msdn van april 2002 en ook niet voorkomt in de malloc.h die ik hier heb (visual studio 6 sp5 + platform sdk 2003 )
en ik zie die functie ook niet de *crt*.dll 's en libcmt's staan die ik hier heb...

Terwijl er staat dat die functie compatible is met alle crt's van win95 t/m winxp ...

[farlane]

Hmmm, mijn MSDN zegt dit:

Requirements
Routine Required header Compatibility
_get_heap_handle <malloc.h> Win 98, Win Me, Win NT, Win 2000, Win XP

Dus vanaf W98 ...

[demonite]

Ja idd... Maar in mijn malloc.h staat ie toch echt niet
Bij jou wel ?

[farlane]

Heb het ff gechecked, bij VC7 staat ie na de declaratie van _msize(void *), bij VC6 staat ie er idd niet in.

Ben bang dat je iets anders moet verzinnen.


[edit]

Misschien moet je WINVER naar een bepaalde versie zetten ( 0x0501 voor XP en hoger ) ?

[edit2]

Deze code doet het goed op ons XP testsysteem ( Win32 console app )

C++:

    ULONG ulHeapCompatibilityInformation = 2;

    HANDLE hCHeap = GetProcessHeap();

    if(HeapSetInformation(hCHeap,HeapCompatibilityInformation,&ulHeapCompatibilityInformation, sizeof(ulHeapCompatibilityInformation)))
    {
        wprintf(L"Heap algorithm set to Low-fragmentation heap(handle=0x%x)\n", hCHeap);
    }
    else
    {
        wprintf( L"Unable to set Low-fragmentation heap (handle=0x%x) GetLastError()=   %d 0x%x\n", L"",hCHeap, GetLastError(), GetLastError());
    }

[ Voor 82% gewijzigd door farlane op 15-07-2003 12:50 ]

[MSalters]

Eerste vraag: heb je dat nodig? Is een per-process low fragmentation heap niet wat je zoekt? Waarom moet het op OS niveau?

Persoonlijk vond ik een snelheidswinst door aparte heaps per class op te zetten, vanwege de locality of reference die ik daarvan kreeg.

[farlane]

MSalters schreef op 15 July 2003 @ 13:01:
Eerste vraag: heb je dat nodig? Is een per-process low fragmentation heap niet wat je zoekt? Waarom moet het op OS niveau?

Ik heb het idee dat als je GetProcessHeap gebruikt, enkel de heap voor dat proces wordt aangepast.

Of begrijp ik je opmerkingen verkeerd ?

[MSalters]

Eigenlijk wel, maar dat was omdat ik de Heap functies van Win32 nooit gebruik. De C++ library is meestal wel goed genoeg, zeker voor kleine allocaties. Die doet standaard hetzelfde.
Een ander alternatief is std::allocator. Die hoeft niet at random groottes te gokken, zoals de LFH in XP maar alleen de groottes die je voor je classes daadwerkelijk nodig hebt. Dat lost het probleem van de onvoorspelbare heapallocaties niet op (string lengtes varieren at runtime) maar omdat de classes dan uit een andere C++ heap komen is de fragmentatie van je originele heap minder.

[demonite]

Dat idee had ik ook idd. GetProcessHeap lijkt me ook de heap voor alleen het process.. niet de OS heap.
Ik heb dit nodig omdat een applicatie zoveel geheugen gebruikt, dat grote mallocs op een gegeven moment mislukken terwijl er bv pas 900 meg gealloceerd is is het al niet meer mogelijk om een chunk van meer als 128 mb te alloceren... d'r zou nog 1100 mb beschikbaar moeten zijn.

Ik had gehoopt dat een low fragmentation heap betere resultaten zou geven.. Maar ik krijg het dus niet aan de praat.

Farlane, heb je dat stuk code met vc6 of met vc7 gecompileerd? (en draait het dan ook op een systeem met het .NET framework geinstalleerd... ? )

ik heb hier winxp pro met sp1
vc6 met sp5

[demonite]

Dat is ook wel een idee, om meerdere heaps te gebruiken...

[MSalters]

De LFH werkt alleen voor kleine objecten, <16K AFAIK

Wat moet je eigenlijk met blokken van 128Mb? Dat is ERG groot voor een enkel object. Als het een array is zou je std::deque als alternatief kunnen gebruiken, dat is een random-access container met pages.

[ Voor 68% gewijzigd door MSalters op 15-07-2003 14:00 ]

[farlane]

demonite schreef op 15 July 2003 @ 13:45:
Farlane, heb je dat stuk code met vc6 of met vc7 gecompileerd? (en draait het dan ook op een systeem met het .NET framework geinstalleerd... ? )
ik heb hier winxp pro met sp1
vc6 met sp5

Gecompileerd met VC7, als native applicatie dus het zou ook moeten draaien op een systeem zonder CLR.

Echter, zoals MSalters al aangaf, de LFH is alleen nuttig bij allocaties <16K. Dus bij een allocatie van 128MB neemt ie weer de standaard heap. ( Ik vraag me af of bij die groottes wel zoveel fragmentatie optreedt trouwens )

Het is ook wel erg veel om te alloceren, misschien moet je daar iets anders op verzinnen.

[Soultaker]

farlane schreef op 15 July 2003 @ 14:14:
Gecompileerd met VC7, als native applicatie dus het zou ook moeten draaien op een systeem zonder CLR.

Enigszins off-topic, maar ik wil je hier toch even voor waarschuwen: VC7 gebruikt weer een nieuwe standaard library die (in tegenstelling tot de VC6 library) niet op gangbare systemen geïnstalleerd is. Het voordeel van een native applicatie compileren wordt dan wat minder, aangezien de gebruiker ofwel Windows moet updaten ofwel de DLL meegeleverd moet worden.

[demonite]

Ik ben bang dat veel kleine malloc / frees juist de boel fragmenteren en dat daarom de paar grote malloc's dus mislukken.

In het geval van die 900 mb die al gealloceerd was, was de maximale chunk grootte op dat moment nog maar 128 mb .. Maar, ik kon op dat moment wel 650 keer een malloc van 1 mb doen.

Hierdoor vermoed ik dus dat boel gefragmenteerd is...

Overigens zal het niet gaan om die grote allocaties te verkleinen, 1 omdat er erg veel fortran code in de applicatie zit en 2 omdat dit juist weer snelheids winst oplevert.

[farlane]

demonite schreef op 15 July 2003 @ 15:07:
Ik ben bang dat veel kleine malloc / frees juist de boel fragmenteren en dat daarom de paar grote malloc's dus mislukken.

Dat zou inderdaad goed kunnen.

Ik heb net je code gecompileerd met de Oktober 2002 SDK in VS6 en dat gaat wel goed.( Alhoewel die get_heap_handle er ook weer niet bijzit )

[demonite]

En dat draaide op een winxp machine, met of zonder .net geinstalleerd?

GetProcessHeap() geeft mij wel een geldige waarde terug (denk ik) 0x0040000 o.i.d.
Maar de HeapSetInformation mislukt.. Wellicht dat het iets nieuws is, wat pas werkt als VC 7 hebt geinstalleerd, of de .net upgrade ofzo...

Zou je perhaps die executable ergens kunnen zetten zodat ik hem kan downloaden, ik ben nml wel benieuwd of ie het bij mij dan ook doet...

[farlane]

Ik zal hem ff opnieuw testen nu ik hem met VS6 heb gecompileerd, en als tie het doet mag je hem van mij best downloaden, maar ik heb geen webspace om hem neer te zetten .

Daar zou je dan ff zelf voor moeten zorgen

( Overigens, ik heb VS.NET versie 2003 met de 1.1 .NET SDK, applicatie getest op XP2002 SP1 )

[edit]
Kan hem natuurlijk ook ff mailen ....

[ Voor 14% gewijzigd door farlane op 15-07-2003 16:02 ]

[demonite]

hmnn ok, is email ook goed? [e-mail] (nickname=demonite) ... ivm spam spider dingetjes

dank u zeer !

[MSalters]

Soultaker schreef op 15 July 2003 @ 14:21:
[...]
Enigszins off-topic, maar ik wil je hier toch even voor waarschuwen: VC7 gebruikt weer een nieuwe standaard library die (in tegenstelling tot de VC6 library) niet op gangbare systemen geïnstalleerd is. Het voordeel van een native applicatie compileren wordt dan wat minder, aangezien de gebruiker ofwel Windows moet updaten ofwel de DLL meegeleverd moet worden.

Dat was een issue in 1995. Als je code op een floppy verscheept en op een 1Gb harddisk installeerd wil je de libraries delen. Tegenwoordig distribueer je op CD, en zorg je ervoor dat al je DLLs (MSVCRT*.DLL inclusief) in je eigen directory staan. Of je dan MSVCRT60 of MSVCRT70 in je eigen directory hebt maakt dan helemaal niets uit.
PS. De CLR gebruikt de VC7 libs dacht ik, dus CLR impliceert VC7 runtime libs maaar niet andersom.

[farlane]

Np,
Hij is onderweg.

Hij lijlt het zowel met VS.NET als met VS6 SDK Oktober 2002 goed te doen.

[ Voor 66% gewijzigd door farlane op 15-07-2003 16:33 ]

[Soultaker]

MSalters schreef op 15 July 2003 @ 16:23:
Dat was een issue in 1995. Als je code op een floppy verscheept en op een 1Gb harddisk installeerd wil je de libraries delen. Tegenwoordig distribueer je op CD, en zorg je ervoor dat al je DLLs (MSVCRT*.DLL inclusief) in je eigen directory staan. Of je dan MSVCRT60 of MSVCRT70 in je eigen directory hebt maakt dan helemaal niets uit.

Ik bedoelde meer dat je daar wel even aan moest denken. Overigens vind ik het ook niet zo netjes om zomaar allerlei onnodige DLL's mee te installeren. Laat dan de installer die DLL's in de Windows directory plaatsen, zodat je ze tenminste niet voor elke applicatie opnieuw hoeft te installeren.

[MSalters]

Onnodige DLLs is een kwestie van opinie. Vanuit een bedrijfszekerheidsoogpunt is een aparte kopie in je eigen directory wenselijk (versieconflicten/upgrades in eigen hand), vanuit een oogpunt van HD kosten is een shared DLL wenselijk. HD ruimte kost niets meer (dwz de HD ruimte die een extra kopie van de DLL kost is te verwaarlozen t.o.v de overige kosten van de applicatie) dus dan is elk beetje bedrijfszekerheid al een reden.

[Verwijderd]

't veroorzaakt alleen wat extra paging omdat de windows memory manager die gebruikte pages niet kan sharen met andere processen.

[MSalters]

Ik heb het even gecheckt: Het is 800Kb, niet echt veel dus. Het disk verhaal gaat evengoed op voor geheugen; 800Kb aan geheugen kost ook minder dan een euro.

[demonite]

Hmn dit is wel vreemd.

De executable die jij me hebt gestuurd Farlane doet het hier wel, maar als ik diezelfde code hier compileer doet ie het niet...

Misschien dat er wat mis met mijn development omgeving... Ik moet ook de libraries en include files van de SDK vooraan in het searchpath zetten want anders wordt HeapSetInfo e.d. niet herkend... misschien dat die libs niet goed overeenkomen met de bijbehorende dll's ofzo

[farlane]

Als je de SDK installeert staat er in het menu een link waarmee je de registraties kunt uitvoeren.

( Volgens mij werkt dit alleen voor VS6 )

Misschien moet je je SDK ff opnieuw installeren ?

[elevator]

MSalters schreef op 16 juli 2003 @ 10:21:
Ik heb het even gecheckt: Het is 800Kb, niet echt veel dus. Het disk verhaal gaat evengoed op voor geheugen; 800Kb aan geheugen kost ook minder dan een euro.

wat op een Terminal Server weer een compleet ander verhaal wordt, als 30 man tegelijkertijd die DLL graag zou willen gebruiken.

[Verwijderd]

leuk dat HDD ruimte en geheugen zo weinig kosten tegenwoordig, maar zeker bij grote bedrijven zit je aan bepaalde hardware vast. Je gaat nou eenmaal niet 'even' 8000 systemen een memory upgrade geven omdat je graag je dll's per applicatie wil scheiden...
Zelfde geldt voor diskruimte. Niet alle machines bij ons zijn van de PIV-256MB-20GB klasse.

Dan is er nog het argument van softwaredistributie : bij 50 applicaties x 2MB aan DLL's, waarvan er gemiddeld zo'n 10 wijzigen per release, is toch weer 20MB extra (per werkstation dus), das alles bij elkaar een hoop dataverkeer. Tel daar nog bij dat ook softwaredistributie nooit fullproof is en dat de kans dat er iets mis gaat ietsje groter wordt...

Al met al toch wel een aantal redenen niet alle redistributable dll's per applicatie te packagen.

[Soultaker]

Een belangrijker argument (behalve de efficiëntie) vind ik dat DLL's normaal gesproken externe libraries zijn die je onafhankelijk wilt kunnen updaten. Ik vind het een beetje vervelend als ik (bijvoorbeeld) onder Windows XP met een Windows 98 page preview venster zit, om maar wat te noemen.

Het idee van een DLL is nu juist dat 'ie abstracte functionaliteit biedt en daarmee consistentie tussen applicaties die van die functionaliteit gebruik maken mogelijk maakt. Als je per se je eigen versie wilt/moet gebruiken (zoals in het geval van een runtime library, misschien) link dan direct statisch.

[MSalters]

elevator schreef op 16 juli 2003 @ 16:08:
[...]

wat op een Terminal Server weer een compleet ander verhaal wordt, als 30 man tegelijkertijd die DLL graag zou willen gebruiken.

In dat geval wordt de DLL dus wel geshared als alle 30 gebruikers jouw applicatie gebruiken. Het zou overigens daarvoor handig zijn als Terminal Server DLL zou sharen op content, niet op (pad)naam - dan share je die DLL dus als het kan.

[MSalters]

Verwijderd schreef op 17 July 2003 @ 00:09:
leuk dat HDD ruimte en geheugen zo weinig kosten tegenwoordig, maar zeker bij grote bedrijven zit je aan bepaalde hardware vast. Je gaat nou eenmaal niet 'even' 8000 systemen een memory upgrade geven omdat je graag je dll's per applicatie wil scheiden...
Zelfde geldt voor diskruimte. Niet alle machines bij ons zijn van de PIV-256MB-20GB klasse.

Dan is er nog het argument van softwaredistributie : bij 50 applicaties x 2MB aan DLL's, waarvan er gemiddeld zo'n 10 wijzigen per release, is toch weer 20MB extra (per werkstation dus), das alles bij elkaar een hoop dataverkeer. Tel daar nog bij dat ook softwaredistributie nooit fullproof is en dat de kans dat er iets mis gaat ietsje groter wordt...

Al met al toch wel een aantal redenen niet alle redistributable dll's per applicatie te packagen.

Klopt; maar meestal heb je op 8000 systemen niet "opeens" een nieuwe applicatie nodig. In dat soort bedrijven gaat nieuwe software net zoals nit hardware in release cycles.

Software distributie, en het af en toe falen daarvan, is dus precies de reden dat je wel aparte DLLs wil. Update een applicatie op een foute manier met gedeelde DLLs, en je hebt opeens 50 applicaties die het niet meer doen. Dat is pas oeps.

20MB dataverkeer (extra) is niets; zelfs niet met 8000 machines. In zo'n professionele situatie mag je uitgaan van 80 servers, die elk 4*100 Mb bandbreedte naar 100 clients elk hebben, oftewel 100 Mbit shared over 25 workstations. Zelfs als die allemaal tegelijk inloggen voor een upgrade heb je nog 4 Mb = 0.5MB/s, dus dan is de datatransfer 40 seconde. Loggen ze achter elkaar in, dan is elke machine 1.6 seconde bezig. Ter vergelijking: er zijn genoeg bedrijven die wekelijks 5 minuten per PC kwijt zijn aan een virusscanner upgrade .

Gelukkig is het extreem zeldzaam dat zo'n potentiële shared DLL verandert; er zijn er simpelweg niet zo veel. MSVC heeft er 2, en die zijn samen 800K. Je eigen DLLs moeten sowieso in je eigen directory (nameclash risico)

[MSalters]

Soultaker schreef op 17 July 2003 @ 00:16:
Een belangrijker argument (behalve de efficiëntie) vind ik dat DLL's normaal gesproken externe libraries zijn die je onafhankelijk wilt kunnen updaten. Ik vind het een beetje vervelend als ik (bijvoorbeeld) onder Windows XP met een Windows 98 page preview venster zit, om maar wat te noemen.

Het idee van een DLL is nu juist dat 'ie abstracte functionaliteit biedt en daarmee consistentie tussen applicaties die van die functionaliteit gebruik maken mogelijk maakt. Als je per se je eigen versie wilt/moet gebruiken (zoals in het geval van een runtime library, misschien) link dan direct statisch.

Precies, onafhankelijk. Je wilt niet dat je runtime lib wordt geupdate omdat de user zo graag IE wil updaten.

Statisch linken van de MSVC libs kan alleen als je zelf geen C++ DLLs maakt. Als je namelijk meerdere instanties van de MSVC libs statisch linkt (1 per DLL), krijg je ook meerdere heaps. Dat gaat ernstig fout als je een std::string of CString meegeeft als argument aan een DLL functie; de DLL heap kent het geheugen van de applicatie heap niet -> crash. Dynamisch linken fixt dit, dan wordt er load-time een enkele kopie van de MSVC DLL geladen met dus ook een enkele heap.

[Soultaker]

MSalters schreef op 17 July 2003 @ 01:07:
Precies, onafhankelijk. Je wilt niet dat je runtime lib wordt geupdate omdat de user zo graag IE wil updaten.

Jawel, dat wil ik dus wel! Dat werkt onder Linux/UNIX systemen ook zo en dat werkt uitstekend. Als de library verbeterd is maar dezelfde interface aanbiedt, dan wil ik inderdaad dat alle programma's die van die interface gebruik maken de verbeterde library gebruiken. Anders moet ik zeker handmatig alle DLL's gaan opsporen en overschrijven, wanneer er een security bug in één van de standaardlibraries gevonden is!

Statisch linken van de MSVC libs kan alleen als je zelf geen C++ DLLs maakt. Als je namelijk meerdere instanties van de MSVC libs statisch linkt (1 per DLL), krijg je ook meerdere heaps. Dat gaat ernstig fout als je een std::string of CString meegeeft als argument aan een DLL functie; de DLL heap kent het geheugen van de applicatie heap niet -> crash. Dynamisch linken fixt dit, dan wordt er load-time een enkele kopie van de MSVC DLL geladen met dus ook een enkele heap.

Dat geldt in het algemeen: als elke applicatie-DLL zijn eigen runtime-DLL gebruikt, is dat nog steeds het geval. Het hele idee van een DLL is dat het een herbruikbaar component is en wanneer je eist dat de user-applicatie de heap deelt met de provider-applicatie dan had je ofwel geen aparte DLL moeten maken, of je DLL API anders moeten organiseren!

Maar goed, je schetst dan ook wel een situatie waarin je absoluut niet statisch wilt linken (al is het alleen maar omdat je library code/geheugen dupliceert). Ik zie echter niet waarom je in jouw situatie niet van (dezelfde) gedeelde runtime DLL's gebruik zou kunnen maken, want dan is dat probleem ook opgelost.

[demonite]

we gaan een beetje offtopic ofzo

ff nog over die dll hell enzo.. Ik kom er dus net achter dat macromedia shockwave een andere c:\windows\system32\msvcrt.dll heeft geinstalleerd.

dit is nou niet echt waar ik op zit te wachten...
die pc hier is nml zwaar onstabiel en ik heb geen idee waar het nou aan ligt. IE crasht echt om het uur ofzo (trace leid naar flash.ocx) terwijl ik er bijna nix op geinstalleerd heb.. nou wil ik niet beweren dat shockwave deze onstabiliteit veroorzaakt, maar helemaal uitsluiten kan ik het nu dus niet. Zeker niet aangezien ie steeds crasht in Flash.. Maar ik heb nog meer crashes in cdfs.sys en in kmixer.sys

het zou gewoon verboden moeten worden (ala otodrop) dat applicaties veranderingen maken aan het operating system. Als een applicatie een nieuwere versie van een DLL nodig heeft om wat voor reden dan ook is dat toch geen reden om het OS aan te passen...
Daar hebben we service packs voor..

[Soultaker]

demonite schreef op 17 July 2003 @ 18:12:
we gaan een beetje offtopic ofzo

Idd... ik wil er ook best over ophouden, als het stoort, maar de laatste tijd zie ik toch geen on-topic reacties meer.

ff nog over die dll hell enzo.. Ik kom er dus net achter dat macromedia shockwave een andere c:\windows\system32\msvcrt.dll heeft geinstalleerd.
[...]
het zou gewoon verboden moeten worden (ala otodrop) dat applicaties veranderingen maken aan het operating system. Als een applicatie een nieuwere versie van een DLL nodig heeft om wat voor reden dan ook is dat toch geen reden om het OS aan te passen...
Daar hebben we service packs voor..

Onder veel UNIX-achtige besturingssystemen gaat dat ook zo. Dat neemt niet weg dat elke volgende library versie een verbetering zou moeten zijn (en dus ook volledig backward compatible, anders is het een nieuwe major version die los van de oude major version geinstalleerd dient te worden). Als Flash dus een betere msvcrt.dll heeft, zou die geen problemen mogen geven.

Ik ben het met je eens dat 'ie eigenlijk die zut niet moet installeren, maar onder Windows is er nu eenmaal geen standaard manier om aan het besturingssysteem te vragen om een bepaalde library te installeren. (Windows installers kennen geen systeem van "dependencies" of iets dergelijks). De installer moet dus wel een eigen versie van de DLL aanleveren, maar ik neem aan dat 'ie voor het overschrijven even controlleert of de nieuwe DLL wel compatibel met en beter dan de oude DLL is.

[ Voor 8% gewijzigd door Soultaker op 17-07-2003 18:41 ]

[farlane]

Soultaker schreef op 17 July 2003 @ 18:40:
[...]
De installer moet dus wel een eigen versie van de DLL aanleveren, maar ik neem aan dat 'ie voor het overschrijven even controlleert of de nieuwe DLL wel compatibel met en beter dan de oude DLL is.

Dat wordt vaak geheel aan de maker van de installatie overgehouden. In InstallShield was het zo dat je erg snel vergat het vinkje "Only overwrite if newer" aan te vinken.

Persoonlijk zet ik al mijn zut, ( of dat nu oudere of nieuwere dan de gangbare dll's/ocx'en/ andere crap is ) bij mijn applicatie in.
Het is al ik weet niet hoe vaak voorgekomen dat een nieuwere versie van een ( zelfgeschreven ) lib een oude applicatie deed afstorten.

Ik heb begrepen dat de 'nieuwe' windows installer echter ook een database van dependencies bijhoudt?

[ Voor 4% gewijzigd door farlane op 17-07-2003 21:36 ]

[Soultaker]

farlane schreef op 17 July 2003 @ 21:35:
Ik heb begrepen dat de 'nieuwe' windows installer echter ook een database van dependencies bijhoudt?

Geen idee; ben hier ook wel benieuwd naar. Het idee van één installer spreekt me wel aan, maar of die Windows installer beter is dan die dingen die InstallShield produceert, zou ik niet weten...