[MFC] Meelinken, DLL grootte, ordinals

[Xymox]

Ik heb een probleem met wat dll's die blijkbaar gebruik maken van MFC.
Het probleem is aan het licht gekomen tijdens wat tests om de bestaande applicaties onder XP te draaien. Op dit moment wordt Windows NT 4 (build 6) hier gebruikt.

De DLL's worden hier zelf ontwikkeld met Visual Studio 5 en draaien al jaren prima, echter onder Windows XP crashen de dll's wanneer deze aangeroepen worden.

Met de tool WinfCheck heb ik gekeken welke andere dll's intern weer gebruikt worden (imported functions) en zie een hele reeks met fouten :

! 800 MFC42. << ordinal not found >>>
etc etc

Ik ben zelf geen C(++) specialist en hier blijkt niemand iets te weten over MFC. Zelfs diegenen die de dll's gebouwd hebben klooien maar wat aan heb ik het idee.

In de project settings heb ik gezien dat daar een optie is voor het wel/niet gebruiken van MFC (static of shared). Snel dus een testje gedaan door deze optie in te stellen op "geen MFC". Blijkt dat deze nieuwe gecompileerde dll geen crash geeft bij gebruik onder XP, maar de dll is wel 4 tot 5 keer groter !

Het gekke is dat als ik naar de imported functions van de oude dll onder NT kijk er ook dezelfde fouten (ordinals not found) bij MFC42 staan. Maar onder NT werkt de dll prima (???).

Kan iemand uitleggen wat dat hele MFC gebeuren nu eigenlijk is en hoe het komt dat de imported functions met de verkeerde ordinals aangeroepen worden ?
Is er ergens een instelling dat deze niet op ordinals de functies aanroept maar op functienaam zodat de dll zowel onder NT en XP werken ?

[curry684]

MFC = Microsoft Foundation Classes = Microsoft's Fokking Crap.

Helaas ben je er al van afhankelijk De setting die je hebt veranderd draait om het volgende: je linkte eerst shared. Dit houdt in dat de MFCxx.dll op runtime aan de exe vastgelinked wordt. Ik kan me goed voorstellen dat de XP-dll's incompatibel zijn met VS5 DLL's (doe eens upgraden). Je hebt daarna veranderd naar 'static' linking oftewel de functies worden inline meegenomen tijdens de compile uit d VS5 libs. Dit is vanzelfsprekend wel stabiel.

[Xymox]

Dat begrijp ik niet. De setting stond op MFC shared en levert een grootte op van 57Kb.
Na de setting op Not using MFC en dit levert een dll op van 209Kb !

MFC heb je toch helemaal niet nodig als je geen speciale MFC classes gebruikt ?
Het is een simpele dll, zonder GUI's en andere Microsoft shit. Diegene die de dll gemaakt heeft zegt dat er gebruik gemaakt wordt van cstring functies en die zouden in MFC zitten. Voor zover ik weet pak je dan gewoon de cstring.h header file.

Welke settings zouden onderwater stiekum toch MFC aanroepen ? Ik zie wel iets staan zoals _USRDLL.
Zou het ook zo kunnen zijn dat als in de workspace een ander project MFC wel meelinkt dat de gehele workspace dan daar gebruik van maakt ?

[madwizard]

Probeer eens een mapfile te maken bij het compileren, dan zie je precies wat er in gebruikt wordt. Je hebt best kans dat er een hoop dingen door CString meegenomen worden, of dat er toch nog ander MFC dingen gebruikt worden. Zeker als file handling ook via MFC gaat kan dat wel redelijk groot worden denk ik..

[farlane]

Xymox schreef op 01 juli 2003 @ 22:17:
Diegene die de dll gemaakt heeft zegt dat er gebruik gemaakt wordt van cstring functies en die zouden in MFC zitten. Voor zover ik weet pak je dan gewoon de cstring.h header file.

CString is een MFC klasse die ( misschien ) gedeclareert wordt in cstring.h, maar de definitie van die klasse zal toch echt uit een mfcXX.obj, mfcXX.lib en/of mfcXX.dll moeten komen.

Dat is dus het gedeelte dat wordt meegelinked.

[edit]
Oh ja, CString wordt gedeclareerd in AFX.H, niet in cstring.h.

[ Voor 7% gewijzigd door farlane op 02-07-2003 20:23 ]

[madwizard]

farlane schreef op 02 July 2003 @ 20:22:
[...]
CString is een MFC klasse die ( misschien ) gedeclareert wordt in cstring.h, maar de definitie van die klasse zal toch echt uit een mfcXX.obj, mfcXX.lib en/of mfcXX.dll moeten komen.

Dat is dus het gedeelte dat wordt meegelinked.
[..]

Das waar, maar niet per se in z'n geheel. Als je statisch linkt krijg je alleen de .obj files uit de libraries (.lib) die ook echt gerefereerd worden.. Vaak gebruiken die elkaar ook weer dus er komt altijd wel wat mee, maar dus niet alles in 1 keer. Of MFC moet ook in 1 object/source file gecompileerd zijn maar dat is niet zo.

[MSalters]

Xymox schreef op 01 July 2003 @ 10:53:
Ik heb een probleem met wat dll's die blijkbaar gebruik maken van MFC.
Het probleem is aan het licht gekomen tijdens wat tests om de bestaande applicaties onder XP te draaien. Op dit moment wordt Windows NT 4 (build 6) hier gebruikt.

De DLL's worden hier zelf ontwikkeld met Visual Studio 5 en draaien al jaren prima, echter onder Windows XP crashen de dll's wanneer deze aangeroepen worden.

Met de tool WinfCheck heb ik gekeken welke andere dll's intern weer gebruikt worden (imported functions) en zie een hele reeks met fouten :

! 800 MFC42. << ordinal not found >>>
etc etc

Ik ben zelf geen C(++) specialist en hier blijkt niemand iets te weten over MFC. Zelfs diegenen die de dll's gebouwd hebben klooien maar wat aan heb ik het idee.

Als je er niets van afweet is de beschuldiging dat anderen wat afklooien op z'n minst een grove belediging.

In de project settings heb ik gezien dat daar een optie is voor het wel/niet gebruiken van MFC (static of shared). Snel dus een testje gedaan door deze optie in te stellen op "geen MFC". Blijkt dat deze nieuwe gecompileerde dll geen crash geeft bij gebruik onder XP, maar de dll is wel 4 tot 5 keer groter !

Het gekke is dat als ik naar de imported functions van de oude dll onder NT kijk er ook dezelfde fouten (ordinals not found) bij MFC42 staan. Maar onder NT werkt de dll prima (???).

Dan werkt je tooltje dus niet.

Het is logisch dat een statische link dit (load)probleem oplost; in dat geval worden de benodigde functies direct in de .DLL in kwestie geplaatst. Het resultaat kan echter zijn dat er geheugencorruptie ontstaat. Omdat je in een static link meerdere instanties van MFC hebt kunnen de DLLs geen MFC objecten meer uitwisselen - de ene MFC herkent de andere niet. Dat probleem is afwezig als je een enkele MFC.DLL shared. Kortom, dat valt onder het kopje "aanklooien".

Kan iemand uitleggen wat dat hele MFC gebeuren nu eigenlijk is en hoe het komt dat de imported functions met de verkeerde ordinals aangeroepen worden ?
Is er ergens een instelling dat deze niet op ordinals de functies aanroept maar op functienaam zodat de dll zowel onder NT en XP werken ?

Een van de eerste dingen die je moet uitzoeken is welke DLL versies je aan het bekijken bent. Het is gebruikelijk dat een enkele PC grote aantallen MFC42.DLLs bevat, inclusief versies in de system32 dir.

Windows XP zal dus een nieuwere MFC32.DLL bevatten.

Linken op naam gaat niet werken; MFC42.DLL bevat geen namen. Dat zouden ook ca. 6000 namen worden, dus de besparing in laad-tijd en geheugengebruik is aanzienlijk. Dan hebben we het nog niet eens over het feit dat de namen mangled zijn - MFC is een C++ DLL.

Ik raad je aan de applicatie te starten binnen Visual Studio, met halt on exceptions.