---

Hej
Jeg er nybegynder.
Er der nogen der gider forklare mig hvad en *.dll er.
Det eneste jeg ved, er at det står for Dynamic link libery.
Hvad bruger man den til og hvad gavn gør den.

Venlig Hilsen
Rasmus Steffensen

---

"Rasmus" <rasmus-88@steffensen.as> wrote in message
news:9q1ka1$9dr$1@news.cybercity.dk...
> Det eneste jeg ved, er at det står for Dynamic link libery.

Dynamic Link Library

> Hvad bruger man den til og hvad gavn gør den.

Det er funktions- (og måske klasse-) biblioteker, som gør det muligt at
genbruge kode binært.
De kan enten loades ind i programmet automatisk (vha. import libraries)
eller dynamisk under programmørens kontrol.

De adskiller sig fra statisk linkede biblioteker, ved
* at kunne loades dynamisk
* ikke at være indeholdt i ens endelige program (EXE-filen), hvorfor
DLL'er skal distribueres til brugeren af ens programmer.

Du spørger ikke hvilken _skade_ de gør (intet at er så godt at det ikke er
skidt for noget).
Ofte giver de flere problemer end de løser, fordi de bliver anvendt
upassende og alt for meget.
Søg eventuelt efter "DLL Hell" på nettet. Det er et anerkendt (selv af
Microsoft) begreb.

DLL'er er omgivet af forkerte myter såsom:
* de sparer hukommele
* de kan bruges til at distribuere fejlrettelser md

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> DLL'er er omgivet af forkerte myter såsom:
> * de sparer hukommele


Jeg ved ikke med Microsoft Windows, men i de fleste UNIX'er deles
dynamisk linket kode mellem processer, dvs. at alle programmer der fx.
bruger libc deler den hukommelse, og dermed sparer.

Venlig hilsen
Morten

---

"Morten Poulsen" <morten@flug.dk> wrote in message
news:3BC45B07.6090807@flug.dk...
> Mogens Hansen wrote:
>
> > DLL'er er omgivet af forkerte myter såsom:
> > * de sparer hukommele
>
>
> Jeg ved ikke med Microsoft Windows, men i de fleste UNIX'er deles
> dynamisk linket kode mellem processer, dvs. at alle programmer der fx.
> bruger libc deler den hukommelse, og dermed sparer.

Har du _målt_ det ?

Sådan er det ikke nødvendigvis på MS-Windows.
Husk at det er _kun_ kodeplads man sparer - ikke data, for de er typisk
private for hver process.
Husk at hvis man kun bruger en lille del af koden i et library, vil en
statisk linker være i stand til at fjerne det overflødige - det vil _altid_
være med i et DLL. Så det giver et overhead. Den virtuelle memory-manager
tage kan page det overflødige ud.
Når man bruger _al_ koden i et DLL vil hukommelsesforbruget være stort set
magen til at bruge statisk linkede biblioteker.

Mine _målinger_ på MS-Windows NT 4.0 viser at man sommetider sparer _lidt_
hukommelse ved at anvende DLL'er i stedet for statisk linkede biblioteker,
men ofte bruger man noget mere hukommelse og sommetider _meget_ mere
hukommelse.
Jeg har ikke lige tallene her - men jeg kan poste dem hvis nogen er
interesseret.

Men som sagt: det er en myte på MS-Windows er der spares hukommelse ved at
anvende DLL'er, og ofte er det forkert.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk>
>
> Jeg har ikke lige tallene her - men jeg kan poste dem hvis nogen er
> interesseret.

Her er tallene stammer fra en artikel jeg begyndte på for år tilbage (derfor
er noget af det på engelsk).
Den er ikke så interessant mere, set i lyset af Microsoft .NET initiativ.

Programmerne, som der er målt på er:

* Scribble1 Tutorial program for Microsoft Foundation Classes (MFC),
which uses a small part of MFC.
* Scribble7 Tutorial program for Microsoft Foundation Classes (MFC),
which uses a large part of MFC
* Wordpad A small word processor, which is distributed as part of
Microsoft Windows NT 4.0
* Ch3Server A small CORBA server, from chapter 3 in "Advanced CORBA
programming with C++" using the open source CORBA implementation TAO. It
only uses a small part of the CORBA implementation.

Filstørrelse:

Program EXE file size DLL file size EXE file size
Using DLL Sum of non OS DLL's Using static linked
Scribble1 36 kbyte 0 272 kbyte
Scribble7 52 kbyte 0 380 kbyte
Wordpad 164 kbyte 0 532 kbyte
Ch3Server 40 kbyte 3480 kbyte 1228 kbyte

Hukommelses forbrug:

Program Memory usage Memory usage Memory usage
Using DLL Using static lib Difference
Scribble1 5628 kbyte 4952 kbyte 13 %
Scribble7 6356 kbyte 6744 kbyte - 5 %
Wordpad 8852 kbyte 8984 kbyte - 1 %
Ch3Server 6408 kbyte 3652 kbyte 75 %

Men hvad så hvis man starter flere instancer af det samme program.
Så må det da kunne spare noget kodeplads ? Nej!

Instance Scribble1 Scribble1
dynamic use static use
0 0 0
1 556 516
2 1092 1032
3 1628 1548
3 2152 2064
4 2692 2584
5 3228 3100
6 3764 3616
7 4300 4132
8 4836 4648
9 5372 5164

Instance Scribble7 Scribble7
dynamic use static use
0 0 0
1 632 816
2 1264 1644
3 1896 2472
4 2528 3300
5 3164 4132
6 3808 4972
7 4452 5812
8 5096 6652
9 5740 7492

Instance Wordpad Wordpad static use
dynamic use static use
0 0 0
1 2140 2284
2 4276 4580
3 6392 6880
4 8544 9192
5 10704 11508
6 12856 13820
7 15048 16132
8 17168 18444
9 19324 20800

Instance ch3server ch3server
dynamic use static use
0 0 0
1 2904 1228
2 5596 2404
3 8280 3600
4 10976 4804
5 13660 5924
6 16352 7128
7 19048 8336
8 21748 9528
9 24440 10736


Man skal ikke tro på alt hvad der står i de flotte brochurer og sponserede
artikler!
Det gælder ikke kun når det kommer fra Microsoft, naturligvis.

Er der ikke noget godt ved DLL'er ?
Naturligvis er de nyttige. F.eks. til printerdrivere, grafikdrivere etc.

Venlig hilsen

Mogens Hansen

---

On Wed, 10 Oct 2001 18:59:54 +0200, "Mogens Hansen"
<mogens_h@dk-online.dk> wrote:

>Programmerne, som der er målt på er:
>
> * Scribble1 Tutorial program for Microsoft Foundation Classes (MFC),
>which uses a small part of MFC.
> * Scribble7 Tutorial program for Microsoft Foundation Classes (MFC),
>which uses a large part of MFC
> * Wordpad A small word processor, which is distributed as part of
>Microsoft Windows NT 4.0
> * Ch3Server A small CORBA server, from chapter 3 in "Advanced CORBA
>programming with C++" using the open source CORBA implementation TAO. It
>only uses a small part of the CORBA implementation.

Nu er det jo tilfældet, at der findes flere typer DLL'er.
Disse programmer, som du har testet, benytter alle DLL'er, der først
skal registreres i Windows registreringsdatabase.

Andre DLL'er, som for eksempel MSVCRT.DLL eller KERNEL32.DLL, skal
ikke først registreres. Programmer, der benytter sig af disse, har en
anden tilgang til funktionerne end for eksempel MFC42.DLL.

Jeg gad derfor nok vide om, din hukommelsestest viser det samme for
denne type DLL'er, som de C++ og ActiveX DLL'er, du brugte i din test.

Spændt på flere testresultater
Chris

---

"Chris" <dsl3353@vip.cybercity.dk> wrote in message
news:3bc4c8f3.56922408@news.cybercity.dk...
> On Wed, 10 Oct 2001 18:59:54 +0200, "Mogens Hansen"
> <mogens_h@dk-online.dk> wrote:
>
>
> Nu er det jo tilfældet, at der findes flere typer DLL'er.
> Disse programmer, som du har testet, benytter alle DLL'er, der først
> skal registreres i Windows registreringsdatabase.

Hvad får dig til at tro det ?
Det er i hvertfald forkert.

Scribble1 og Scribble7 bruger:
GDI32.DLL
KERNEL32.DLL
MFC42.DLL
MSVCRT.DLL
NTDLL.DLL
USER32.DLL

Wordpad bruger:
ADVAPI32.DLL
COMCTL32.DLL
COMDLG32.DLL
GDI32.DLL
KERNEL32.DLL
MFC42.DLL
MSVCRT.DLL
NTDLL.DLL
OLE32.DLL
RPCRT4.DLL
SHELL32.DLL
SHLWAPI.DLL
USER32.DLL

Ch3Server:
ACE.DLL
ADVAPI32.DLL
DNSAPI.DLL
GDI32.DLL
KERNEL32.DLL
MSVCP60.DLL
MSVCRT.DLL
MSWSOCK.DLL
NTDLL.DLL
RPCRT4.DLL
USER32.DLL
WS2HELP.DLL
WS2_32.DLL
WSOCK32.DLL

Wordpad benytter af registry pga. OLE32.DLL, for at kunne få OLE
funktionalitet. Men de andre går ikke.
Specielt er CORBA dejlig fri for registrydatabasen - i sammenligning med
f.eks. DCOM.
Bemærk iøvrigt også at .NET heller ikke baserer sig på registrydatabasen, og
COM componenter i Windows XP heller ikke registreres globalt! Men det er en
anden historie.

Hvilken rolle mener du at det spiller at DLL'erne skal registreres i Windows
registreringsdatabasen, i relation til hukommelsesforbrug ?

Jeg mener ikke at det spiller nogen rolle om det er funktions- eller
klassebiblioteker eller COM componenter.

>
> Andre DLL'er, som for eksempel MSVCRT.DLL eller KERNEL32.DLL, skal
> ikke først registreres. Programmer, der benytter sig af disse, har en
> anden tilgang til funktionerne end for eksempel MFC42.DLL.

På hvilken måde ?
De 3 DLL du nævner bruges alle på samme måde: enten dynamisk loaded eller
via import libraries.
Forskellen er, så vidt jeg kan se, at MSVCRT.DLL og KERNEL32.DLL bruger C
(eller Windows) kaldekonvention, som er tilgængeligt for praktisk taket alle
udviklingsmiljøer.
MFC42.DLL bruger C++ kaldekonvention som er mere kompliceret (f.eks. pga.
muligheden for exceptions, udlæg af den virtuelle funktiontabel, håndtering
af multiple arv etc.), som kun er tilgængelig fra samme compiler som det er
lavet med (og måske versions-varianter af samme compiler).

Hvilken rolle mener du at det spiller for hukommelsesforbruget ?

>
> Jeg gad derfor nok vide om, din hukommelsestest viser det samme for
> denne type DLL'er, som de C++ og ActiveX DLL'er, du brugte i din test.

Jeg mener ikke at det spiller for hukommelsesforbruget, om det er C eller
C++ baserede DLL.
Ligeledes vil jeg ikke forvente at det spiller en rolle om det er ActiveX
DLL'er - det er blot et spørgsmål om hvordan funktionerne bliver aktiveret
(via f.eks. CoCreateInstance).

>
> Spændt på flere testresultater

Desværre, der kommer nok ikke flere.
Det er et stort arbejde at lave.

Venlig hilsen

Mogens Hansen

---

"Chris" <dsl3353@vip.cybercity.dk> wrote in message
news:3bc4c8f3.56922408@news.cybercity.dk...
> On Wed, 10 Oct 2001 18:59:54 +0200, "Mogens Hansen"
> <mogens_h@dk-online.dk> wrote:
>

>
> Jeg gad derfor nok vide om, din hukommelsestest viser det samme for
> denne type DLL'er, som de C++ og ActiveX DLL'er, du brugte i din test.

Min sammenling går på:
* Givet en vis funktionalitet i et program (f.eks. Scribble), som bruger
et generelt bibliotek (f.eks. Microsoft Visual C++ run-time library og MFC),
bruger programmet så mere eller mindre hukommelse når funktionaliteten er
linket statisk ind i én EXE-fil end når det anvender de generelle
biblioteker som DLL'er.
* Når flere instancer af samme program kører, bruger de efterfølgende så
mindre hukommelse end det første, fordi de deler kodepladsen.
* Hvor mange instancer skal man køre for at nå break-even - hvis det
overhovedet nåes

Giver det i den sammenhæng mening at tale om ActiveX ?
Selve ActiveX ordet har gennem tiden betydet forskellige ting, men jeg
vælger at opfatte det som visuelle controller der er baseret på COM
(OCX'er).
Det er typisk in-process COM componenter (kan det være andet ?).
Det bruger COM for at give mulighed for binært genbrug. Dermed er det givet
at de _ikke_ _kan_ linkes statisk, og derfor kan man ikke sammenligne
statisk linkede ActiveX med dynamisk linket ActiveX.

COM bliver ofte anvendt og anset som middel til genbrug - binært genbrug.
Jeg mener at COM bidrager med en ikke uvæsentlig kompleksitet, som primært
er berettiget hvis man skal krydse:
* Sprog-grænser - f.eks. C++, Visual Basic og Delphi
* Process-grænser - f.eks. af hensyn til stabilitet og synkronisering
* Netværksgrænser
* Platformsgrænser (den er lidt ulden)

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev den 11-Oct-01:

> * Givet en vis funktionalitet i et program (f.eks. Scribble), som bruger
> et generelt bibliotek (f.eks. Microsoft Visual C++ run-time library og MFC),
> bruger programmet så mere eller mindre hukommelse når funktionaliteten er
> linket statisk ind i én EXE-fil end når det anvender de generelle
> biblioteker som DLL'er.

For 1 program er resultatet at operativsystemet cacher tekstsegmentet
1 gang og bruger det til alle instanser. Det uanset om segmentet er i
EXE eller DLL.

For N forskellige programmer skal enslydende tekstsegmenter caches N
gange i EXE, mens man genbruger 1 caching ved DLL.


Hvis man altid højst har 1 kørende program til at bruge
tekstsegmentet, vil det være mere økonomisk (med undtagelse af
harddiskplads) at linke det statisk, da man så slipper for overhead af
relokationer, som kan være en bekostelig affære.



Jeg forsøgte at lave tests til at eftervise dette (under Linux), og
selv om resultaterne pegede i rigtig retning, var der problemer pga.
cache mv. En ordentlig test vil kræve mange reboots for at tømme
hukommelsen helt før hver kørsel - og det orker jeg ikke.


--
Regards, Anders

....if a Microsoft product fails, who do you sue?

---

"Anders Melchiorsen" <anders@kalibalik.dk> wrote in message
news:m2669l7qlp.fsf@dolle.kalibalik.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> skrev den 11-Oct-01:
>
> > * Givet en vis funktionalitet i et program (f.eks. Scribble), som
bruger
> > et generelt bibliotek (f.eks. Microsoft Visual C++ run-time library og
MFC),
> > bruger programmet så mere eller mindre hukommelse når funktionaliteten
er
> > linket statisk ind i én EXE-fil end når det anvender de generelle
> > biblioteker som DLL'er.
>
> For 1 program er resultatet at operativsystemet cacher tekstsegmentet
> 1 gang og bruger det til alle instanser. Det uanset om segmentet er i
> EXE eller DLL.
>

Ja, sådan siger teorien.
Det må betyde at man skal kunne se at ændringen i hukommelsesforbrug er
større ved første program end ved de efterfølgende.
Det har jeg ikke kunnet _måle_ på MS-Windows NT4.0, selvom jeg har prøvet.

> For N forskellige programmer skal enslydende tekstsegmenter caches N
> gange i EXE, mens man genbruger 1 caching ved DLL.
>

Ja, sådan ville jeg også forvente at det er.

Men de målinger jeg har lavet på MS-Windows NT4.0, og præsenteret i denne
tråd, indikerer at det ikke sker hverken for EXE-filer eller DLL'er.
Jeg kan, med baggrund i målingerne, tro på at implementeringen af DLLer på
MS-Windows NT 4.0, med hensyn til hukommelsesforbrug, er dårligere end hvad
man teoretisk burde forvente. Det kræver troværdige målinger, at få mig til
at tro andet.
Med de RAM-priser vi har i dag, har det givetvis kun sjældent en praktisk
betydning.
Det ændrer dog ikke ved min oprindelige påstand i denne tråd: at det er en
myte at DLL'er (på MS-Windows NT 4.0) hjælper med at spare hukommelse.

>
> Hvis man altid højst har 1 kørende program til at bruge
> tekstsegmentet, vil det være mere økonomisk (med undtagelse af
> harddiskplads) at linke det statisk, da man så slipper for overhead af
> relokationer, som kan være en bekostelig affære.
>

Jeps.
Og hukommelses forbruget ved statisk linkning nærmer sig forbruget ved
dynamisk linkning, når man nærmer sig et brug at _alle_ funktionerne i
DLLet.

>
>
> Jeg forsøgte at lave tests til at eftervise dette (under Linux), og
> selv om resultaterne pegede i rigtig retning, var der problemer pga.
> cache mv. En ordentlig test vil kræve mange reboots for at tømme
> hukommelsen helt før hver kørsel - og det orker jeg ikke.
>

Det vil ellers være interessant, hvis der blev præsenteret troværdige
målinger for andre platforme.
Nogen må da kunne finde ud af at implementere det ordentligt.
Men jeg ved godt at det er et stort arbejde.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev:

> > Jeg forsøgte at lave tests til at eftervise dette (under Linux), og
> > selv om resultaterne pegede i rigtig retning, var der problemer pga.
> > cache mv. En ordentlig test vil kræve mange reboots for at tømme
> > hukommelsen helt før hver kørsel - og det orker jeg ikke.
>
> Det vil ellers være interessant, hvis der blev præsenteret
> troværdige målinger for andre platforme. Nogen må da kunne finde ud
> af at implementere det ordentligt. Men jeg ved godt at det er et
> stort arbejde.

Min lille test viste tydeligt at ved .so var der et voldsomt forbrug
ved at starte ét program og næsten intet ekstra ved samtidig at starte
yderligere herefter, mens der ved .exe var et jævnt forbrug for hver
start. Altså som teorien forudsiger. Men det er Linux, ikke NT som
du har målt på.

Dér, hvor min måling blev lidt tåget, var ved problemet med
relokationer, idet én .so kørsel brugte dobbelt så meget hukommelse
som én .exe kørsel. Det kunne jeg fifle på ved at lave færre
funktionskald og mere beregning, men så var det, at der kom så mange
parametre, at jeg gav op (og smed de hidtidige målinger ud).



Men for at vende tilbage til din oprindelige liste af myter: hvorfor
mener du ikke, at man kan fejlrette vha. en .dll?


--
Regards, Anders

....if a Microsoft product fails, who do you sue?

---

"Anders Melchiorsen" <anders@kalibalik.dk> wrote in message
news:m2vghjgm3q.fsf@dolle.kalibalik.dk...
>
> Men for at vende tilbage til din oprindelige liste af myter: hvorfor
> mener du ikke, at man kan fejlrette vha. en .dll?
>

Lad os blot slå fejlretning og f.eks. performance optimering sammen. Det er
ændringer generelt.
Lad os også antage at DLL'et er lavet fordi det bliver delt af flere
applikationer (uanset om det reelt giver en hukommelsesbesparelse eller ej).

Lad os tage et konkret (fiktivt) eksempel:
* Jeg laver et dato beregnings DLL - HYPERDATE.DLL - , som jeg sælger.
* Min kunde som laver en applikation med mit DLL. Han finder ud af at der
er en fejl i det, når man trækker 2 datoer fra hinanden regner mit DLL een
dag for lidt. Han skal snart frigive sit produkt, og kompenserer derfor
fejlen i sin kode. Samtidig rapporterer han fejlen til mig.
* Jeg retter fejlen.
* En af mine andre kunder bruger mit nye DLL.
* En slutbruger, som installerer begge applikationer på sin maskine vil
ikke være i stand til (før Windows 2000 med side-by-side installation) at
have to korrekt fungerende applikationer. Hvis mit produkt var linket
statisk, ville begge applikationer have fungeret uden problemer.

Det er måske et ekstremt tilfælde, men ikke forskelligt fra hvad man ser i
den virkelige verden.
Problemet er at man _skaber_ afhængigheder mellem applikationer, der ikke
_er_ afhængige. Enhver der udvikler software ved formodentligt at man
afhænger af sine afhængigheder, og at afhængigheder er kompleksistet som
skal håndteres. Det rigtigt grimme er at man gør afhængighederne synlige for
slutbrugeren, hvor det egentligt burde være softwareudviklerens ansvar at
inkapsle kompleksiteten i en applikation der er målrettet til at løse
slutbrugerens problemer.
Jeg syntes oplagt at det både er et teoretisk og et praktisk problem. Det er
derfor der er det anerkendte problem "DLL Hell".
Problemet er naturligvis særligt stort på MS-Windows platformen på grund at
dens store udbredelse.

Der findes idag (og de sidste mange år) masser af erfaring fra MS-Windows
platformen, hvor man giver brugerne problemer ved at have et opdatere DLL så
andre fungerende programmer bryder sammen. Se f.eks. Microsofts tekniske
rapporter Q190536, Q177977 og Q190536 for nogle detaljer. Det er ikke for at
kritisere Microsofts DLL'er at jeg nævner disse eksempler. De giver blot den
konkrete dokumentation. Jeg vil tro at Microsoft gør en væsentligt større
arbejde for at teste end de fleste.

Min pointe er, at ved at minimere brugen af DLL'er på MS-Windows og
foretrække statisk linkning forhindrer man en hel gruppe af fejl, uden at
man får større hukommelsesforbrug - ofte tværtimod.

Hvis du kigger på de tiltag som Microsoft har gjort på .NET platformen (men
også mindre grad på Windows 2000 og Windows XP), omkring brug af dynamiske
libraries og versioner, vil du se at de kræver at programmer køres med den
version af dynamisk linkede komponenter som de blev udviklet med (dog med
mulighed for at system administratoren overwriter det). Det betyder bl.a. at
een process kan have flere versioner af samme komponent loaded i hukommelsen
samtidig. Det er for at sikre at et program kører med den version af en
komponent som den blev udviklet og testet med. Det er en model som i praksis
ligger tæt på statisk linkning.

Registry, som var et af de store dyr i åbenbaringen i Windows95, har nogle
næsten tilsvarende problemer. Nogen syntes dengang at globale variable var
_rigtigt_ smart. Så vidt jeg ved gjorde IBM AIX på et tidspunkt præcist det
samme, med samme resultat. Men det har givet store vedligeholdelsesproblemer
for mange mennesker (ikke blot software udviklerne) - som globale variable
typisk gør. Når man retter eet sted, bryder noget andet og fuldstændigt
uventet sammen. Sådan har globale variable altid opført sig, og vi har vist
det i over 30 år.
Microsoft .NET og Windows XP bruger ikke længere registry til at registrere
komponenter med.

Afhængigheder mellem ting, der af natur er uafhængige er ondsindet -
"accidential complexity".
Det skal begrænses i softwareudvikling - vi har rigeligt at gøre med at
håndtere den indbyggede kompleksitet.

Venlig hilsen

Mogens Hansen

---

Den Sun, 14 Oct 2001 08:25:41 +0200 skrev Mogens Hansen:
>
>"Anders Melchiorsen" <anders@kalibalik.dk> wrote in message
>news:m2vghjgm3q.fsf@dolle.kalibalik.dk...
>>
>> Men for at vende tilbage til din oprindelige liste af myter: hvorfor
>> mener du ikke, at man kan fejlrette vha. en .dll?
>>
>
>Lad os blot slå fejlretning og f.eks. performance optimering sammen. Det er
>ændringer generelt.
>Lad os også antage at DLL'et er lavet fordi det bliver delt af flere
>applikationer (uanset om det reelt giver en hukommelsesbesparelse eller ej).
>
>Lad os tage et konkret (fiktivt) eksempel:
> * Jeg laver et dato beregnings DLL - HYPERDATE.DLL - , som jeg sælger.
> * Min kunde som laver en applikation med mit DLL. Han finder ud af at der
>er en fejl i det, når man trækker 2 datoer fra hinanden regner mit DLL een
>dag for lidt. Han skal snart frigive sit produkt, og kompenserer derfor
>fejlen i sin kode. Samtidig rapporterer han fejlen til mig.
> * Jeg retter fejlen.
> * En af mine andre kunder bruger mit nye DLL.
> * En slutbruger, som installerer begge applikationer på sin maskine vil
>ikke være i stand til (før Windows 2000 med side-by-side installation) at
>have to korrekt fungerende applikationer. Hvis mit produkt var linket
>statisk, ville begge applikationer have fungeret uden problemer.

Det du nævner der er kendt som "Windows DLL Hell". Igen har du ret, så
længe vi snakker Windows.

Jeg har fx. to versioner af SDL installeret - version 1.1 fra
installations-CD'en, da et enkelt spil (Maelstrom) ikke vil køre med
den nye, og version 1.2. Ingen problemer med det under Linux.

Mvh
Kent
--
War does not determine who is right, only who is left.

---

"Kent Friis" <kfr@fleggaard.dk> wrote in message
news:9qbicv$46d$1@sunsite.dk...
>
> Det du nævner der er kendt som "Windows DLL Hell". Igen har du ret, så
> længe vi snakker Windows.
>
> Jeg har fx. to versioner af SDL installeret - version 1.1 fra
> installations-CD'en, da et enkelt spil (Maelstrom) ikke vil køre med
> den nye, og version 1.2. Ingen problemer med det under Linux.
>

Da jeg bestemt ikke er nogen Linux haj, så kan du (eller andre) måske
fortælle mig om der er en fundamental forskel på den måde Windows håndterer
DLL'er og Linux håndterer so'er på i relations til versionering ?

Jeg tænker på noget á la Windows 2000 side-by-side installation, eller
brugen af softlinks (hedder det ikke det på Linux ? - eller måske symlink
?). Eller måske fordi man i højere grad distribuerer source-kode ?
Eller er det blot et "tilfælde" at der ikke er tilsvarende problemer på
Linux ?

Venlig hilsen

Mogens Hansen

---

Den Sun, 14 Oct 2001 10:53:58 +0200 skrev Mogens Hansen:
>
>"Kent Friis" <kfr@fleggaard.dk> wrote in message
>news:9qbicv$46d$1@sunsite.dk...
>>
>> Det du nævner der er kendt som "Windows DLL Hell". Igen har du ret, så
>> længe vi snakker Windows.
>>
>> Jeg har fx. to versioner af SDL installeret - version 1.1 fra
>> installations-CD'en, da et enkelt spil (Maelstrom) ikke vil køre med
>> den nye, og version 1.2. Ingen problemer med det under Linux.
>>
>
>Da jeg bestemt ikke er nogen Linux haj, så kan du (eller andre) måske
>fortælle mig om der er en fundamental forskel på den måde Windows håndterer
>DLL'er og Linux håndterer so'er på i relations til versionering ?
>
>Jeg tænker på noget á la Windows 2000 side-by-side installation, eller
>brugen af softlinks (hedder det ikke det på Linux ? - eller måske symlink
>?). Eller måske fordi man i højere grad distribuerer source-kode ?
>Eller er det blot et "tilfælde" at der ikke er tilsvarende problemer på
>Linux ?

Ganske simpelt:

Windows:
MSVCRT.DLL

Linux:
libc.so.4 -> libc.so.4.7.6
libc.so.4.6.7
libc.so.6

(-> angiver symlink).

Jeg er ikke lige klar over hvorfor jeg har libc4 installeret, men ikke
libc5. Jeg har før haft alle tre installeret.

Ideen er at programmer linker til "libc.so.4", og efter en opgradering
bliver linket blot rettet til den nyeste version (klares automatisk af
ldconfig). libc6 burde også have haft et versions-nummer, men det har
SuSE åbenbart fjernet

I dit eksempel, hvor man indberetter en bug, men ikke kan vente på
rettelsen, vil man så i stedet linke til libc.so.4.7.6, så man altid
får den gamle version.

Mvh
Kent

PS: Grunden til at jeg ikke brugte SDL som eksempel er at de ikke kan
finde ud af at overholde den naming-convention, men kalder det
libSDL-1.1.so.0.0.2 og libSDL-1.2.so.0.0.2 - med det resultat at
ldconfig ikke kan finde ud af hvad der skal linkes.
--
War does not determine who is right, only who is left.

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev:

> Da jeg bestemt ikke er nogen Linux haj, så kan du (eller andre)
> måske fortælle mig om der er en fundamental forskel på den måde
> Windows håndterer DLL'er og Linux håndterer so'er på i relations til
> versionering ?

Jeg er til gengæld ikke Windows haj, men i Linux kan man ved en
environment variabel instruere linkeren i, hvilke biblioteker, den
skal indlæse:

LD_PRELOAD
A whitespace-separated list of additional, user-
specified, ELF shared libraries to be loaded before
all others. This can be used to selectively over­
ride functions in other shared libraries. [...]


Endvidere benyttes symlinks til at skelne mellem major-versioner (ABI
ændringer), som Kent skitserede.


> Eller er det blot et "tilfælde" at der ikke er tilsvarende problemer på
> Linux ?

Der er skam masser af problemer med .so under Linux, især hvis man
starter på at lege med C++, hvor ABI i de seneste år er blevet ændret
for et godt ord. At man har adgang til kildeteksten hjælper en del, da
API ofte er en del mere stabil.


--
Regards, Anders

....if a Microsoft product fails, who do you sue?

---

"Anders Melchiorsen" <anders@kalibalik.dk> wrote in message
news:m24rp2wflh.fsf@dolle.kalibalik.dk...
>
> Der er skam masser af problemer med .so under Linux, især hvis man
> starter på at lege med C++, hvor ABI i de seneste år er blevet ændret
> for et godt ord. At man har adgang til kildeteksten hjælper en del, da
> API ofte er en del mere stabil.
>

Sådan er det også på MS-Windows platformen.
F.eks. når sizeof(bool) ændres fra 4 til 1 fra en compiler version til
næste.
Binær compabilitet for C++ kode mellem compilere fra forskellige
leverandører er ofte ikke eksisterende.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:9qbb37$2l6v$1@news.cybercity.dk...
>
> "Anders Melchiorsen" <anders@kalibalik.dk> wrote in message
> news:m2vghjgm3q.fsf@dolle.kalibalik.dk...
> >
> > Men for at vende tilbage til din oprindelige liste af myter: hvorfor
> > mener du ikke, at man kan fejlrette vha. en .dll?
> >
>
> Lad os blot slå fejlretning og f.eks. performance optimering sammen. Det
er
> ændringer generelt.
> Lad os også antage at DLL'et er lavet fordi det bliver delt af flere
> applikationer (uanset om det reelt giver en hukommelsesbesparelse eller
ej).
>
> Lad os tage et konkret (fiktivt) eksempel:
> * Jeg laver et dato beregnings DLL - HYPERDATE.DLL - , som jeg sælger.
> * Min kunde som laver en applikation med mit DLL. Han finder ud af at
der
> er en fejl i det, når man trækker 2 datoer fra hinanden regner mit DLL een
> dag for lidt. Han skal snart frigive sit produkt, og kompenserer derfor
> fejlen i sin kode. Samtidig rapporterer han fejlen til mig.
> * Jeg retter fejlen.
> * En af mine andre kunder bruger mit nye DLL.
> * En slutbruger, som installerer begge applikationer på sin maskine vil
> ikke være i stand til (før Windows 2000 med side-by-side installation) at
> have to korrekt fungerende applikationer. Hvis mit produkt var linket
> statisk, ville begge applikationer have fungeret uden problemer.


så kunne du evt. have en HyperDate_GetVersion() som du kunne tjekke? Det er
sådan man normalt gør...

---

"Rasmus Christian Kaae" <macaw@hotmail.com> wrote in message
news:9qh54n$1dhh$1@news.cybercity.dk...
>

>
> så kunne du evt. have en HyperDate_GetVersion() som du kunne tjekke? Det
er
> sådan man normalt gør...
>

Hvis det var tilfældet, ville begrebet "DLL Hell" så eksistere ?
Ville Microsoft investere væsentlige resourcer i side-by-side installation i
Windows 2000 og endnu flere i Windows XP og fuldstændigt lave om på hvordan
man binder sig til binære komponenter i .NET ?

I hvilke vidt udbredte DLL'er (f.eks. MFC42.DLL eller MSVCRT.DLL) ser du
dette anbefalet som normal praksis ?

Venlig hilsen

Mogens Hansen

---

"Anders Melchiorsen" <anders@kalibalik.dk> wrote in message
news:m2vghjgm3q.fsf@dolle.kalibalik.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> skrev:
>
>
> Men for at vende tilbage til din oprindelige liste af myter: hvorfor
> mener du ikke, at man kan fejlrette vha. en .dll?
>

Det teoretiske spørgsmål er vel:
Hvordan kan man lave ændringer (f.eks. fejlrettelser eller performance
forbedring) i en komponent, og samtidig sikre at den opfører sig 100 % magen
til den gamle ?

Man kan sige at komponenten ikke skal være kompatibel med den foregående,
men derimod overholde en præcis specifikation.
Det er dog vanskelligt i praksis.
Dels er få software komponenter tilstrækkeligt godt specificeret, og dels
tester man sjældent op imod specifikationen, men op imod en og gerne flere
(ikke nødvendigvis korrekte) implementeringer af specifikationen.

Hvis man tager et konkret eksempel.
C++ programmeringssproget er temmeligt præcist formelt specificeret. Der
findes ikke nogen 100 % implementering af specifikationen i dag (mange er
tæt på), og der findes ingen reference implementering.
Når man skriver et program, bruger de fleste en compiler til at checke at
det overholder sprog specifikationen. Man læser ikke specifikationen og
programmet samtidigt, for at sikre sig at programmet er korrekt. Hvis man
vil øge tilliden til at ens program faktisk overholder standarden, så
oversætter man det med flere compilere. Når man har problemer, kontrollerer
man i specifikationen hvad der er rigtigt. I praksis er det sådan, at når
man har benyttet 2-3 forskellige gode compilere, vil fejlene på de næste
compilere typisk skyldes fejl i compileren.
Et C++ program der 100% overholder standarden, men som ikke kan oversættes
pga. manglende implementeringer er ligeledes ikke særligt nyttigt.

Tilsvarende når man bruger DLLer, med velspecificerede interfaces som f.eks.
printer-drivere.
Man tester op i mod en række velfungerende implementeringer, og accepterer
hvis der kommer een som fejler.
Samtidigt er det nemmere at implementere test for interfaces med mange
implementeringer over en lang tidsperiode, og derved opnå stabilitet.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

>> Jeg ved ikke med Microsoft Windows, men i de fleste UNIX'er deles
>> dynamisk linket kode mellem processer, dvs. at alle programmer der fx.
>> bruger libc deler den hukommelse, og dermed sparer.
>
> Har du _målt_ det ?


Nej, det er ren teori.

> Sådan er det ikke nødvendigvis på MS-Windows.

> Husk at det er _kun_ kodeplads man sparer - ikke data, for de er typisk
> private for hver process.


Ja, naturli'vis.


> Husk at hvis man kun bruger en lille del af koden i et library, vil en
> statisk linker være i stand til at fjerne det overflødige - det vil _altid_
> være med i et DLL.


Ja, men jeg har _mange_ processer der allesammen bruger ld, libc, libz,
libgnome, libglib, libX11, libpng, libgtk, libgdk, etc.

> Så det giver et overhead. Den virtuelle memory-manager
> tage kan page det overflødige ud.


Den kan page ubrugte sider ud, hvad enten det er fra et statisk eller
dynamisk linket program.


> Når man bruger _al_ koden i et DLL vil hukommelsesforbruget være stort set
> magen til at bruge statisk linkede biblioteker.


Ja, hvis du kun har EEN process, der bruget det. Hvis du har to eller
flere, vil det oftest vaere en foredel. Hvis det som process A bruger
fra biblioteket + det som process B bruger + det som process C bruger >
det som det dynamiske bibliotek fylder, saa er det en foredel at have
det dynamisk.

> Mine _målinger_ på MS-Windows NT 4.0 viser at man sommetider sparer _lidt_
> hukommelse ved at anvende DLL'er i stedet for statisk linkede biblioteker,
> men ofte bruger man noget mere hukommelse og sommetider _meget_ mere
> hukommelse.


Jeg vil ikke udelukke at det er tilfaeldet, hvis ikke du har flere
processer der deler de biblioteker, men det er ikke altid saadan.

> Men som sagt: det er en myte på MS-Windows er der spares hukommelse ved at
> anvende DLL'er, og ofte er det forkert.

Saa er de brugt forkert.

Venlig hilsen
Morten

---

"Morten Poulsen" <morten@flug.dk> wrote in message
news:3BC559EB.7090604@flug.dk...
> Mogens Hansen wrote:
>

>
> > Så det giver et overhead. Den virtuelle memory-manager
> > tage kan page det overflødige ud.
>
>
> Den kan page ubrugte sider ud, hvad enten det er fra et statisk eller
> dynamisk linket program.
>

Ja, men den skal muligvis lave mindre, hvis den samlede størrelse på koden
er mindre.

>
> > Når man bruger _al_ koden i et DLL vil hukommelsesforbruget være stort
set
> > magen til at bruge statisk linkede biblioteker.
>
>
> Ja, hvis du kun har EEN process, der bruget det. Hvis du har to eller
> flere, vil det oftest vaere en foredel. Hvis det som process A bruger
> fra biblioteket + det som process B bruger + det som process C bruger >
> det som det dynamiske bibliotek fylder, saa er det en foredel at have
> det dynamisk.
>

Det er det jeg har læst, men aldrig har været i stand til at _måle_ på
MS-Windows NT 4.0, selvom jeg har prøvet.

>
> Jeg vil ikke udelukke at det er tilfaeldet, hvis ikke du har flere
> processer der deler de biblioteker, men det er ikke altid saadan.
>

Er det noget du har målt ?
Under hvilke omstændigheder ?
Jeg har ikke været i stand til at påvise at hvis flere processer deler samme
DLL (f.eks. MFC42.DLL) så sparer de hukommelse, selvom jeg har prøvet.

En situation, hvor jeg kan se at anvendelsen af DLL kan spare hukommelse, er
hvis flere DLL inden for _samme_ process deler det samme DLL.

F.eks. MSVCRT.DLL er Visual C++ V6.0 run-time library, som kan blive brugt
således:

MYAPP.EXE
|--YOURDLL.DLL
| |--MSVCRT.DLL
| --MSVCRT.DLL

i denne konfiguration vil MYAPP.EXE og YOURDLL.DLL dele funktioner og f.eks.
kun have een memory manager. Det vil spare hukommelse.

I en anden konfiguration kan såvel MYAPP.EXE og YOURDLL.DLL have linket
Visual C++ V6.0 run-time library statisk.

MYAPP.EXE
|--YOURDLL.DLL

her vil der være 2 instanser af samme funktion (f.eks. malloc) i memory og
der vil være 2 memory managere med hver sin heap.

> > Men som sagt: det er en myte på MS-Windows er der spares hukommelse ved
at
> > anvende DLL'er, og ofte er det forkert.
>
> Saa er de brugt forkert.

Jeg forstår ikke hvad du mener.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> Det er det jeg har læst, men aldrig har været i stand til at _måle_ på
> MS-Windows NT 4.0, selvom jeg har prøvet.


Jeg har ikke adgang til en MS-Windowsm saa jeg ved det ikke.

> Er det noget du har målt ?
> Under hvilke omstændigheder ?
> Jeg har ikke været i stand til at påvise at hvis flere processer deler samme
> DLL (f.eks. MFC42.DLL) så sparer de hukommelse, selvom jeg har prøvet.


Paa enhver UNIX kan du med ps se hvormeget af et program der (kan)
deles, jeg ved ikke med MS-Windows. En stor del af Mozilla er dynamisk
linket, og det bliver delt mellem processer, paa samme maade som selve
programmet.

> En situation, hvor jeg kan se at anvendelsen af DLL kan spare hukommelse, er
> hvis flere DLL inden for _samme_ process deler det samme DLL.


Jeg kan ikke se hvorfor det skal vaere i samme process, med mindre
Microsoft's maade at haandtere dynamisk linkning paa stinker. Et
read-only TEXT-segment kan let deles, men det kan da godt vaere at deres
memory manager ikke kan finde ud af det.

>>> Men som sagt: det er en myte på MS-Windows er der spares hukommelse ved
>>> at anvende DLL'er, og ofte er det forkert.
>>
>> Saa er de brugt forkert.
>
> Jeg forstår ikke hvad du mener.

Hvis man smider kode som *ingen* bruger ud i en DLL og loader den, saa
bruger man det forkert. Hvis man putter kode som een process bruger ud i
en DLL saa er det break-even. Hvis man putter kode som flere processer
bruger ud i en DLL (og vi antager at de kan dele TEXT) saa har man
sparet hukommelse.

Venlig hilsen
Morten

---

"Morten Poulsen" <morten@flug.dk> wrote in message
news:3BC52D2C.7090707@flug.dk...
> Mogens Hansen wrote:
>
> >> Saa er de brugt forkert.
> >
> > Jeg forstår ikke hvad du mener.
>
> Hvis man smider kode som *ingen* bruger ud i en DLL og loader den, saa
> bruger man det forkert. Hvis man putter kode som een process bruger ud i
> en DLL saa er det break-even. Hvis man putter kode som flere processer
> bruger ud i en DLL (og vi antager at de kan dele TEXT) saa har man
> sparet hukommelse.
>

Situationen er jo typisk den, at man bruger en del af koden i et DLL (f.eks.
en del af MFC), og noget bruger man ikke.
Man kan ikke gøre andet, hvis man bruger generelle DLL'er - er der noget
forkert i det ?

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> Situationen er jo typisk den, at man bruger en del af koden i et DLL (f.eks.
> en del af MFC), og noget bruger man ikke.
> Man kan ikke gøre andet, hvis man bruger generelle DLL'er - er der noget
> forkert i det ?

Hvis dem der har leveret dit operativsystem har valgt at laegge deres
kode i en DLL, saa er det sikkert fordi de forventer at koden vil blive
brugt.

Venlig hilsen
Morten

---

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> Har du _målt_ det ?

Næh, det er teori.

> Sådan er det ikke nødvendigvis på MS-Windows.

Det er Unix teori

Jeg har hørt folk påstå meget bestemt at .so filer (unix "shared
objects") er teknisk bedre end .dll filer, men det er ikke noget jeg
har forstand på.

> Husk at det er _kun_ kodeplads man sparer - ikke data, for de er typisk
> private for hver process.

"Kun" kodeplads kan være ret meget når man bruger store libraries.

> Husk at hvis man kun bruger en lille del af koden i et library, vil en
> statisk linker være i stand til at fjerne det overflødige - det vil _altid_
> være med i et DLL.

Ideen med at "fjerne det overfødige" virker vist bedst med gammeldags
funktionsorienterede C biblioteker. Jeg prøvede at gøre "mit program"
til at statisk bibliotek under Unix, og linke det med et simpelt main
program. Resultatet blev en tom skal af et program, fordi linkeren
havde frasoreteret alle de selv-registrerende objekter, tilsyneladende
regnede den ikke statiske kontruktører i biblioteket med som "eksterne
kald". På den anden side hvis den havde gjort det ville den ikke have
sparet noget. Pointen er, at det med moderne programmeringsteknik
ikke længere er så simpelt at finde ud af på link tidspunktet hvad der
vil bliver brugt på run-time. Derfor satset jeg i dag mere på at VM
systemet bør sikre at overflødig kode ikke bliver læst ind (ikke at
jeg tror på det, de statiske konstruktører er nok spredt over hele
text segmentet).

> Men som sagt: det er en myte på MS-Windows er der spares hukommelse ved at
> anvende DLL'er, og ofte er det forkert.

Så under MS Windows bør man linke statisk med MFC og C runtime
DLL'erne?

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
news:rjitdmux23.fsf@ssv2.dina.kvl.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> writes:
>
> > Husk at det er _kun_ kodeplads man sparer - ikke data, for de er typisk
> > private for hver process.
>
> "Kun" kodeplads kan være ret meget når man bruger store libraries.
>

Ja, naturligvis.
Det afhænger selvfølgelig meget af ens applikation.
Men prøv at se på mine målinger.
Jeg ser aldrig store fordele. Sommetider små fordele, sommetider små ulemper
og sommetider store ulemper.

>
> Ideen med at "fjerne det overfødige" virker vist bedst med gammeldags
> funktionsorienterede C biblioteker. Jeg prøvede at gøre "mit program"
> til at statisk bibliotek under Unix, og linke det med et simpelt main
> program. Resultatet blev en tom skal af et program, fordi linkeren
> havde frasoreteret alle de selv-registrerende objekter, tilsyneladende
> ...

Jeg har oplevet præcist det samme på MS-Windows, når jeg prøvede at lave
statiske LIB'er.

>
> > Men som sagt: det er en myte på MS-Windows er der spares hukommelse ved
at
> > anvende DLL'er, og ofte er det forkert.
>
> Så under MS Windows bør man linke statisk med MFC og C runtime
> DLL'erne?

Det er hvad jeg normalt anbefaler - og selv gør.
Jeg mener man skal have en _god_ grund til at gøre andet.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> Hukommelses forbrug:
>
> Program Memory usage Memory usage Memory usage
> Using DLL Using static lib Difference
> Scribble1 5628 kbyte 4952 kbyte 13 %
> Scribble7 6356 kbyte 6744 kbyte - 5 %
> Wordpad 8852 kbyte 8984 kbyte - 1 %
> Ch3Server 6408 kbyte 3652 kbyte 75 %

Har du kørt dem samtidig? Hvad er det samlede forbrug?

> Men hvad så hvis man starter flere instancer af det samme program.
> Så må det da kunne spare noget kodeplads ? Nej!

Kun hvis MS har været usædvanligt dumme i deres VM system. Flere
instanser af samme program bør altid dele TEXT segment, uanset hvordan
de er linket.

Shared objects er relevante for _forskellige programmer_ der bruger
_samme_ kode _samtidig_. MFC og MSVCRT burde være gode eksempler.

Der kan selvfølgelig være noget kulturel forskel for hvor relevant det
er, Unix har haft en god multitasking implementation meget længere end
MS, så måske er brugerne mere vandt til at køre en masse forskellige
programmer samtidig. Min Unix desktop har altid en masse små
programmer aktive. Det har min NT desktop også, men de fleste er
remote X11 programmer fra min Unix

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
news:rjbsjeuwlo.fsf@ssv2.dina.kvl.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> writes:
>
> > Hukommelses forbrug:
> >
> > Program Memory usage Memory usage Memory usage
> > Using DLL Using static lib Difference
> > Scribble1 5628 kbyte 4952 kbyte 13 %
> > Scribble7 6356 kbyte 6744 kbyte - 5 %
> > Wordpad 8852 kbyte 8984 kbyte - 1 %
> > Ch3Server 6408 kbyte 3652 kbyte 75 %
>
> Har du kørt dem samtidig? Hvad er det samlede forbrug?

Nej, eet program af gangen for ovennævnte målinger.

>
> Kun hvis MS har været usædvanligt dumme i deres VM system. Flere
> instanser af samme program bør altid dele TEXT segment, uanset hvordan
> de er linket.
>

Ja, det lyder rimeligt.
Måske er det forklaringen på at der ikke måles nogen fordel når flere
instanser af samme program køres.
Jeg har ikke verificeres (f.eks. med SoftICE) om de faktisk deler
kodesegment.

MS-Windows har nogle komplikationer omkring "Image Base" og sammenfald i
hvor et DLL gerne vil loades, som oven i købet _kan_ give problemer, så
samme DLL har forskelligt udseende i memory.

> Shared objects er relevante for _forskellige programmer_ der bruger
> _samme_ kode _samtidig_. MFC og MSVCRT burde være gode eksempler.
>

Det har jeg også prøvet, men har ikke kunne måle nogen reduktion i
hukommelsesforbrug for de efterfølgende programmer.
Jeg mener at jeg kender teorien rimeligt, men har ikke kunnet påvise de
hukommelsesmæssige fordele, der hævdes at være.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> Det har jeg også prøvet, men har ikke kunne måle nogen reduktion i
> hukommelsesforbrug for de efterfølgende programmer.

Det er nok nødvendigt at kigge på det samlede forbrug, med mindre du
er helt sikker på hvordan et delt memory segment bliver registreret
hos de enkelte applikationer. Den oplagte løsning ville være at tælle
det med i memoryforbruget for hver enkelt applikation.

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
news:rjd73utc6h.fsf@ssv2.dina.kvl.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> writes:
>
> > Det har jeg også prøvet, men har ikke kunne måle nogen reduktion i
> > hukommelsesforbrug for de efterfølgende programmer.
>
> Det er nok nødvendigt at kigge på det samlede forbrug, med mindre du
> er helt sikker på hvordan et delt memory segment bliver registreret
> hos de enkelte applikationer. Den oplagte løsning ville være at tælle
> det med i memoryforbruget for hver enkelt applikation.
>

Det er det jeg har gjort vha. Task Manager.

Nu har jeg målt det en gang til på en nyinstalleret NT-Windows NT4.0 SP3 UK
Workstation, som end ikke havde MFC42.DLL installeret på forhånd.

Program: Task Mgr. Diff
Total Commit
Intet 14488 kbyte
Scribble1 15112 kbyte 624 kbyte
Scribble1 15708 kbyte 596 kbyte
Scribble1 16312 kbyte 604 kbyte

Intet 13848 kbyte
Scribble7 14532 kbyte 684 kbyte
Scribble7 15240 kbyte 708 kbyte
Scribble7 15984 kbyte 744 kbyte

Intet 14048 kbyte
Scribble1 14620 kbyte 572 kbyte
Scribble7 15296 kbyte 676 kbyte

Intet 14048 kbyte
Scribble7 14704 kbyte 656 kbyte
Scribble1 15296 kbyte 584 kbyte

Jeg kan ikke se af de målingen af det første program betaler prisen for at
loade MFC42.DLL (og eventuelt MSVCRT.DLL, som dog kan være loaded af andre
programmer), og at de efterfølgende nyder godt af at det første program har
loaded DLL'et.

Det kan naturligvis være målemetoden, der er forkert.
Jeg har kun målt det på MS-Windows NT4.0. Det kan være anderledes på andre
Win32 udgaver - jeg ved det ikke.
Jeg siger ikke at shared object på Unix og Linux ikke kan spare hukommelse -
jeg har aldrig målt det.

Jeg kan godt forstå at det virker provokerende, når jeg påstår at der ikke
spares hukommelse ved at bruge DLL'er. Det er stik imod hvad man har læst.
Praktisk taget alle som jeg har sagt det til gennem de sidste par år, har
ikke troet på at det var rigtigt.
Men ingen har kunne vise _målingen_ eller andre _hårde_ der viser noget
andet.
Hvis noget andet kan _påvises_ vil jeg naturligvis gerne se det.

Venlig hilsen

Mogens Hansen

---

---

---