retrospace - Beitrag lesen

Software | Microsoft Windows 3.x-Dienstprogramm Fix1MB

Mai 1995, Ausgabe des Microsoft Systems Journal, Spalte „Fragen und Antworten“
Autoren: Pietrek, Matt
Download: [inturl=./upload/files/1_fix1mb.zip]fix1mb.zip[/inturl]

In meiner ersten Kolumne für MSJ (Oktober 1993) schrieb ich etwas, das ich als Wegwerfdienstprogramm mit dem Namen Below 1MB bezeichnete. Diese Spalte, die vom üblichen Frage-Antwort-Format abweicht, beschreibt Fix1MB, ein Update zu Below1MB. Der Zweck von Below1MB bestand darin, Ihnen dabei zu helfen, festzustellen, welche Ihrer eigenen DLLs und Treiber den wertvollen linearen Adressraum unter 1 MB aufsaugen. Windows 3.x und Windows 95 benötigen für jede gestartete Aufgabe eine kleine Speichermenge von weniger als 1 MB. Wenn es den Speicher nicht zuweisen kann, erhalten Sie eine etwas verwirrende Meldung "Nicht genügend Speicher zum Ausführen dieses Programms", unabhängig davon, wie viel RAM Sie installiert haben. Als ich Below1MB schrieb, hätte ich mir kaum vorstellen können, dass es außerhalb von Programmierkreisen bemerkt werden würde. Endbenutzer haben es verwendet,

Leider ist die Speicherknappheit bei MS-DOS so schlimm (insbesondere in Windows for Workgroups 3.11), dass sogar Endbenutzer nach allem greifen, was helfen könnte, selbst wenn sie viele der bereitgestellten Informationen nicht verstehen . Hätte ich gewusst, dass Below1MB ein so breites Publikum haben würde, hätte ich es vielleicht anders geschrieben und dabei besonders darauf geachtet, Details zu reduzieren, die nicht direkt mit dem Hauptproblem zusammenhängen. Wie Sie vielleicht schon erraten haben, habe ich Below1MB endlich umgeschrieben, um die Verwendung zu vereinfachen und (was noch wichtiger ist) tatsächlich zu helfen, das Problem zu beheben. Mein Fix1MB-Programm sollte sowohl für Programmierer wegen der verwendeten Techniken als auch für Endbenutzer interessant sein, die nur nach einer schnellen Lösung suchen.

[align=right][size=5]Das unter einem Megabyte-Problem[/size][/align][hr]
Für diejenigen unter Ihnen, deren frühere MSJ-Probleme nicht praktisch sind, gebe ich einen kurzen Überblick über das Problem in Windows, das Fix1MB behebt. Jedes laufende Programm in Windows ist eine separate Aufgabe. Jeder Aufgabe ist eine Systemdatenstruktur zugeordnet, die als Aufgabendatenbank (oder TDB) bekannt ist. Eine Aufgabendatenbank enthält wichtige Informationen über eine Aufgabe, wie z. B. ihr aktuelles Verzeichnis, ihre HINSTANCE und ein MSDOS PSP (Program Segment Prefix). Die Größe jeder Task-Datenbank beträgt 0x200 Bytes (eine wichtige Zahl, die später noch genannt wird). In Windows 3.x muss jeder Task-Datenbank eine Adresse zugewiesen werden, die unter einer linearen Adresse von 1 MB liegt. Warum ist das so? Windows 3.x verwendet immer noch ausgiebig Real-Mode-MSDOS, und viele MS-DOS-Funktionen benötigen Zugriff auf eine PSP. Da die im Realmodus maximal zugängliche Adresse 1 MB beträgt (eigentlich 1 MB + 64 KB - 16),

Wenn Windows gestartet wird, platziert es jeden nicht verwendeten MS-DOS-Speicher unter 1 MB im globalen Heap. Dieser MS-DOS-Speicher bildet den untersten Teil des gesamten globalen Windows-Heapspeichers. Normalerweise befinden sich möglicherweise 300 KB im globalen Heap, das aus diesem niedrigen MS-DOS-Speicher stammt. Mit 300 KB Arbeitsspeicher zum Spielen sollten Sie in der Lage sein, ungefähr 2400 Aufgabendatenbanken zu erstellen, was selbst für die hartgesottensten Multitasker ausreichen sollte.

Das Problem bei diesem Setup hängt damit zusammen, wie Windows globalen Heap-Speicher zuweist. Normalerweise beginnt der globale Heap-Manager beim Zuweisen von Speicher seine Suche am unteren Ende des globalen Heaps und stoppt, wenn er den ersten Block findet, der groß genug ist. (Die Ausnahme ist das Zuweisen von Speicher für verwerfbare Codesegmente, was dazu führt, dass Windows die Suche am oberen Ende des Heaps beginnt. Da der untere Teil des globalen Heaps den übrig gebliebenen niedrigen MS-DOS-Speicher umfasst, enden viele globale Heap-Zuweisungen von Adressen unter 1 MB kommen.Wenn keine besonderen Vorkehrungen getroffen werden, belegt die globale Heap-Zuweisung schnell den gesamten Speicher unter 1 MB, wodurch es unmöglich wird, eine weitere Aufgabendatenbank zu erstellen (und somit eine neue Aufgabe zu starten).

Windows verhindert, dass der Speicher unter 1 MB schnell aufgebraucht wird, indem es die meisten Blöcke verschiebbar macht. Selbst wenn ein Block ursprünglich unter 1 MB zugewiesen wurde, verschiebt der globale Heap-Manager den Block im linearen Speicher nach oben, um Platz für einen anderen Block zu schaffen, der wirklich unter 1 MB liegen muss. Während dies immens hilft, gibt es immer noch das Problem der FIXED-Blöcke. Der globale Heap-Manager ist nicht in der Lage, FIXED-Blöcke zu verschieben, sodass alle Blöcke, die kleiner als 1 MB sind, wenn ihnen das FIXED-Attribut zugewiesen wird, dort verbleiben. Es sind diese FIXED-Blöcke, die den Speicher unter 1 MB aufsaugen und es unmöglich machen, eine neue Aufgabe zu starten.

Also, wie bekommt man FIXED Speicherblöcke? Es gibt drei Möglichkeiten. Erstens können Sie Speicher mit GlobalAlloc zuweisen und ihm das GMEM_FIXED-Flag geben. Windows ignoriert das GMEM-FIXED-Flag, wenn die Zuordnungsanforderung von EXE-Code stammt, berücksichtigt es jedoch, wenn die Zuordnungsanforderung von einer DLL stammt. Zweitens können Sie die Segmente Ihrer EXE- oder DLL-Datei mit dem FIXED-Attribut markieren. Aus einem inzwischen veralteten Grund machen einige Linker standardmäßig Segmente FIXED. (Die Lösung besteht darin, die Segmentattribute explizit in der DEF-Datei festzulegen.) Wie bei GlobalAlloc ignoriert Windows das FIXED-Attribut beim Zuweisen von Speicher für EXE-Dateisegmente. Ein Segment in einer DLL hat das FIXED-Attribut, wenn die DLL FIXED für dieses Segment angibt.

Die dritte Möglichkeit, FIXED-Speicher zu erhalten, besteht darin, beweglichen Speicher zuzuweisen und ihm dann explizit das FIXED-Attribut zuzuweisen. Sowohl die GlobalFix- als auch die GlobalPageLock-Funktion geben Segmenten das FIXED-Attribut. (GlobalPageLock ruft zuerst GlobalFix auf und sperrt dann das Segment.) Diese Funktionen sind besonders gefährlich für den niedrigen MS-DOS-Speicher, da sie versuchen, den Block so weit wie möglich im Speicher nach unten zu schieben, bevor sie ihn reparieren. Dies kann dazu führen, dass Blöcke, die zuvor über 1 MB groß waren, nach unten in den 1-MB-Bereich verschoben werden, was das Problem weiter verschlimmert.

Wenn Sie die Notwendigkeit von Aufgabendatenbanken unter 1 MB mit der globalen Heap-Zuweisungsstrategie kombinieren, können Sie sehen, dass es in vielen Fällen zu Problemen kommen wird. Viele Gerätetreiber und System-DLLs erfordern FIXED und/oder Pagelocked-Speicher, da sie über Interrupt-Handler verfügen oder mit MS-DOS-Programmen im Realmodus kommunizieren. Dies gilt insbesondere für Netzwerktreiber. Da die meisten dieser Treiber früh im Windows-Startvorgang geladen werden, können Sie sehen, wie eine beträchtliche Menge des für TDBs erforderlichen Real-Mode-MSDOS-Speichers verbraucht werden kann. Leute sagen mir oft, dass sie, nachdem sie ein bestimmtes Programm gestartet haben, keine anderen mehr starten können. Dies liegt fast immer daran, dass das erste Programm einige DLLs oder Treiber verwendet, die das letzte Bit an Speicher unter 1 MB geschluckt haben.

In Windows 95 verschwindet dieses Problem größtenteils. Windows 95 ändert die Funktionsweise von GlobalAlloc so, dass (größtenteils) FIXED-Blöcke nicht unter 1 MB zugewiesen werden. Wenn es unter Windows 95 ausgeführt wird, zeigt mein Below1MB-Programm nur sehr wenige FIXED-Blöcke von Treibern und DLLs, die Speicherplatz unter 1 MB belegen. Darüber hinaus müssen Aufgabendatenbanken in Windows 95 nicht unter 1 MB liegen. Die PSP wurde jedoch aus der Windows 95-Aufgabendatenbank herausgelöst und muss immer noch unter 1 MB liegen. Um dies zu testen, habe ich mein ursprüngliches Below1MB-Programm leicht modifiziert, um den gesamten Speicher in Blöcken von 0x120 Bytes (der Größe einer PSP in Windows 95) zuzuweisen. 1 führte dieses modifizierte Unter 1 MB unter Windows 95 (M8 Preview-Build) aus und ließ es den gesamten Speicher unter 1 MB zuweisen. Ich habe dann versucht, ein neues Programm zu starten. Wie ich vermutete, startete Windows 95 die neue Aufgabe nicht,

[align=right][size=5]Das Fix1MB-Programm[/size][/align][hr]
Um das Problem des unzureichenden Arbeitsspeichers unter 1 MB zu lösen, habe ich das Fix1MB-Programm geschrieben (siehe Abbildungen 1 und 2). Fix 1MB sind wirklich zwei, zwei-zwei Programme in einem. Der erste Teil analysiert die globalen Heap-Blöcke unterhalb von 1 MB und gibt Ihnen eine Liste mit Speicherblöcken, die möglicherweise unnötig Speicherplatz beanspruchen. Zusammen mit jedem Block benennt der Bericht die EXE- oder DLL-Datei, die den Speicherblock besitzt. Mit diesen Informationen bewaffnet, kennen Sie zumindest die Hauptschuldigen am Diebstahl Ihres geringen Gedächtnisses. Basierend auf diesem Wissen entscheiden Sie sich möglicherweise dafür, einen bestimmten Gerätetreiber oder ein bestimmtes Programm zu entfernen. Möglicherweise können Sie sogar den Hersteller des betreffenden Programms oder Treibers dazu drängen, Ihnen eine aktualisierte Version zu geben, die FIXED-Segmente nicht unnötigerweise verwendet.

Der andere Teil von Fix1MB tut tatsächlich etwas gegen das Problem unter 1 MB. Mit ausgefeilten Techniken, die gemeinsam mit NASA-Wissenschaftlern entwickelt wurden, schützt es die Stelle, an der die meisten FIXED-Speicherblöcke unter 1 MB tauchen und sich dauerhaft niederlassen. Indem die Tür zum Speicher in einem kritischen Moment unter 1 MB geschlossen bleibt, zwingt Fix1MB Programme und Treiber dazu, ihre FIXED-Speicherblöcke woanders hin zu nehmen. (Dies ist die Windows-Version von „Not in my backyard.“)

Wenn Sie das Fix1MB-Programm in Windows ausführen, hindert es alle nachfolgend geladenen EYES und DLLs daran, FIXED-Blöcke unter 1 MB zu erfassen (mit einigen geringfügigen Ausnahmen, die ich später beschreiben werde). Obwohl dies in vielen Fällen helfen sollte, kann Ihr Problem mit Treibern und DLLs zusammenhängen, die beim Start geladen werden (z. B. Netzwerktreiber). Das Ausführen von Fix1MB kann in dieser Situation normalerweise nicht helfen. Diese Treiber lagern bereits unterhalb der 1-MB-Tür, wenn Fix1MB startet. Indem Fix1MB jedoch früh genug in der Startsequenz geladen wird, kann es normalerweise verhindern, dass die störenden Treiber und DLLs erhebliche Mengen an FIXED-Speicher unter 1 MB an sich reißen. Daher verfügt Fix1MB über eine Option, die es ermöglicht, es an einer strategischen Stelle in der Datei SYSTEM.INI zu platzieren, sodass es jedes Mal, wenn Sie Windows booten, relativ früh in der Startsequenz geladen wird. (Dies ist n' Es ist nicht so einfach, Fix1MB in die Autostart-Gruppe zu setzen. Wie es tatsächlich funktioniert, beschreibe ich später.) Damit das Laden der SYSTEM.INI funktioniert, müssen sich sowohl FIX1MB.EXE als auch FX1MBDLL.DLL im selben Verzeichnis befinden. PROCHOOK.DLL sollte sich auch im selben Verzeichnis oder irgendwo auf dem Pfad befinden.

[align=center][inturl=./upload/files/1_fix1mb.jpg][imgleft=Abbildung 1]./upload/files/thumbs/1_fix1mb.jpg.jpg[/imgleft][/inturl][/align]Abbildung 1 zeigt, wie Fix1MB aussieht. Das Feld „Potential Free Space“ auf der oben zeigt, wie viel Speicher unter 1 MB verfügbar ist. Diese Figur ist nicht das, was ist zurzeit frei. Vielmehr ist es das, was kostenlos wäre, wenn Windows sich zurückziehen würde alle Anschläge, um sich im Speicher zu bewegen und den Speicherplatz unter 1 MB zu maximieren.

Das Listenfeld Potenzielle Speicherfresser ist eine nach Größe sortierte Liste von Speicherblöcken unter 1 MB, die nicht verschoben werden können. Diese Blöcke nehmen Platz unter 1 MB ein. Jede Zeile enthält eine Blockgröße, wofür der Block verwendet wird und den Besitzer des Speicherblocks. Fix1MB zeigt keine Blöcke an, für die Sie nichts tun können. Beispielsweise verwendet KRNL386.EXE (die Hauptsystem-DLL) ziemlich viel festen Speicher unter 1 MB. Aber da Sie nichts dagegen tun können, warum zeigen Sie es? Da es so gut wie unmöglich wäre, jede mögliche System-DLL herauszufiltern, zielt Fix1MB nur auf die Biggies ab (die tatsächliche Liste befindet sich in der Quelldatei FIX1MB.C). Wenn sich ein Block im Listenfeld „Fix1MB“ befindet, kann es sich um einen schlecht geschriebenen Treiber oder eine schlecht geschriebene DLL handeln, der berechtigte Speicherbedarf unter 1 MB hat oder eine System-DLL, die Sie nicht loswerden können. Zu einem gewissen Grad, Sie müssen sich die Liste ansehen und ein Urteil darüber fällen, ob Sie versuchen sollten, etwas gegen eine bestimmte Zeile zu unternehmen oder nicht. Oft kann es ausreichen, nur den Haupttäter (falls vorhanden) aufzuklären, um Sie wieder in Gang zu bringen.

Die Rewalk-Schaltfläche bewirkt, dass Fix1MB seine Analyse des Speichers unter 1 MB wiederholt. Immer wenn Sie Fix1MB aus einem symbolisierten Zustand wiederherstellen, wiederholt es seine Analyse. Wenn jedoch Programme oder DLLs geladen werden, während sich Fix1MB im nicht symbolisierten Zustand befindet, wird die Analyse von Fix1MB nicht mehr synchron sein. Um einen aktuellen Bericht zu erhalten, klicken Sie auf die Schaltfläche Rewalk.

Die Verwendung des Hilfe-Buttons sollte offensichtlich sein. Die verbleibende Schaltfläche in Fix1MB ist FIX1MB zu SYSTEM.INI hinzufügen. Dadurch fügt FIX1MB.DLL FX1MBDLL.DLL in die Zeile "drivers=" in SYSTEM.INI ein. Sobald Sie dies getan haben, führen nachfolgende Tastendrücke zu einer Fehlermeldung. Das Kontrollkästchen ganz unten ändert die Art und Weise, wie FIX1MB den Speicher unter 1 MB schützt. Standardmäßig ist es deaktiviert, was eine optimale Leistung ergibt. In einigen seltenen Fällen schützt die Standardeinstellung jedoch möglicherweise nicht ausreichend den niedrigen Speicher, sodass der Fehler „Nicht genügend Speicher“ zurückgegeben wird. Versuchen Sie in diesem Fall, das Kontrollkästchen zu aktivieren.

[align=right][size=5]Unter der Haube von Fix1MB[/size][/align][hr]
Wie ich bereits erwähnt habe, ist Fix1MB wirklich zwei Programme in einem. Wenn Sie sich nicht für die Heap-Analyse und meine minimalistische Benutzeroberfläche interessieren, können Sie diese Teile des Codes einfach extrahieren und neu kompilieren. Dennoch ist Fix1MB, wie es jetzt existiert, ziemlich klein und hilft bei der Bestimmung, welche neue Low-Memory-Guarding-Technologie hat.

Der Low-Heap-Analyseteil von Fix1MB ist ziemlich unkompliziert und hat sich gegenüber BELOW1MB.EXE nicht wesentlich geändert. Die Ergebnisse, die Fix1MB zeigt, sehen jedoch ganz anders aus und sind viel klarer. Die WalkHeap-Funktion in FIX1MB.C durchläuft die globalen Heap-Blöcke bis zum Adresslimit von 1 MB, indem sie die ToolHelp-Funktionen GlobalFirst und GlobalNext verwendet. Während Fix1MB jeden Block durchläuft, sucht es nach zwei Dingen. Zuerst sucht es nach Heap-Blöcken, die nicht verschoben werden können und über die der Benutzer möglicherweise eine gewisse Kontrolle hat. Zweitens sucht Fix1MB nach Lücken zwischen dem Ende eines FIXED-Blocks und dem Beginn eines anderen. Die Gesamtgröße all dieser Lücken wird als freier Speicher gezählt, auch wenn der Platz gerade von einem verschiebbaren Block belegt ist. Wenn Windows wirklich Speicher unter 1 MB benötigt (z. B. für einen GlobalDosAlloc-Aufruf),

Wenn die WalkHeap-Routine jeden Block findet, ruft sie die IsPotentialSpaceHog-Funktion auf, die den Status des Blocks bestimmt. Wenn IsPotentialSpaceHog TRUE zurückgibt, landet der Block im Listenfeld Fix1MB. IsPotentialSpaceHog wirft sofort freie Blöcke und Sentinel-Blöcke aus (die KRNL386 verwendet, um Regionen des globalen Heaps zu markieren). IsPotentialSpaceHog wirft auch Blöcke aus, die nicht das GMEM_FIXED-Attribut haben und nicht seitengesperrt sind. (Pagelocked ist eine Obermenge des FIXED-Attributs. Alle Blöcke, die diese Tests bestehen, sind unbeweglich. An diesem Punkt sucht IsPotentialSpaceHog nach einer Lücke zwischen diesem Block und dem vorherigen unbeweglichen Block, und wenn es eine gibt, fügt sie sie dem Lauf hinzu gesamt. Bevor TRUE zurückgegeben wird, IsPotentialSpaceHog überprüft, ob der Block eine Aufgabendatenbank ist oder einer System-DLL gehört, über die der Benutzer keine Kontrolle hat. Wenn dies der Fall ist, gibt IsPotentialSpaceHog FALSE zurück, um zu verhindern, dass WalkHeap den Block in das Berichtslistenfeld einfügt.

Das andere Unterprogramm mit Fix1MB ist etwas komplizierter. Sein grundlegendes Ziel ist es, den gesamten (oder den größten Teil) Speicher unter 1 MB zuzuweisen, bevor der Windows-Loader oder ein Programm versucht, FIXED-Speicher zuzuweisen. Indem unter 1 MB kein Speicher frei gemacht wird, landet die FIXED-Speicherzuordnung weiter oben im Adressraum (denken Sie daran, dass der globale Heap-Manager in den meisten Fällen von unten nach oben nach freien Blöcken sucht). Nachdem der FIXED-Speicher irgendwo anders als unter 1 MB zugewiesen wurde, gibt Fix1MB den zuvor zugewiesenen Speicher frei.

Fix1MB weiß aufgrund der LoadModule-Routine, wann große FIXED-Speicherzuordnungen auftreten werden. LoadModule ist der zentrale Windows-Loader. Die meisten Zuweisungen von FIXED-Speicher werden innerhalb von LoadModule vorgenommen, wenn es Speicher für die Code- und Datensegmente von EXEs, DLLs und Gerätetreibern zuweist. Um einen signifikanten Effekt zu erzielen, muss Fix1MB lediglich verhindern, dass LoadModule seinen FIXED-Speicher unter 1 MB zuweist. Was ist mit anderen Routinen, die Programme und DLLs laden? Fix1MB deckt diese Grundlagen ab. LoadLibrary und WinExec sind beide Wrapper um einen Aufruf von LoadModule. Die ShellExecute-Funktion ist ein Wrapper um WinExec. Indem es beobachtet, wann LoadModule aufgerufen wird, kann Fix 1MB vier Fliegen mit einer Klappe schlagen.

Fix1mb überwacht, wenn LoadModule aufgerufen wird, indem es PROCHOOK.DLL von James Finnegan aus der MSJ-Ausgabe vom Januar 1994 verwendet. Ich habe kurz über die Verwendung von Breakpoints diskutiert, um Fix1MB vollständig in sich geschlossen zu halten, aber die Benutzerfreundlichkeit von ProcHook hat am Ende gewonnen. Fix1MB installiert einen Hook auf LoadModule und gibt Fix1MBLoadModule in FIX1MB.C als Callback-Funktion an. Innerhalb von Fix1MBLoadModule hebt der Code vorübergehend den LoadModule-Rückruf auf, weist den gesamten Speicher unter 1 MB zu und ruft dann das ursprüngliche LoadModule auf. Nach der Rückkehr von LoadModule gibt Fix1MBLoadModule den gesamten zuvor zugewiesenen Speicher frei und installiert dann den LoadModule-Hook neu. Durch den direkten Aufruf von LoadModule weiß Fix1MB implizit, wann es sicher ist, den zugewiesenen Speicher freizugeben. Dies wäre schwieriger zu bestimmen, wenn der Hook den Aufruf einfach mit dem ursprünglichen Handler verkettet hätte. Zusätzlich, LoadModule ist rekursiv, sodass Fix1MB alle verschachtelten Aufrufe von LoadModule ignorieren kann, wenn der Callback ausgehängt und LoadModule direkt aufgerufen wird. Auf diese Weise führt Fix1MB nur die Zuordnungen beim primären Aufruf von LoadModule durch und muss nichts für die verschachtelten LoadModule-Aufrufe tun.

Wenn der gesamte Speicher unter 1 MB zugewiesen wird, speichert Fix1MB die Blöcke in einer verknüpften Liste. Das erste WORD jedes zugewiesenen Blocks enthält das Handle des nächsten zugewiesenen Blocks. AllocTiledBelow1MBMemory weist Speicher unter 1 MB zu, indem GlobalDosAlloc aufgerufen wird. Um den Speicher unter 1 MB schnell zu erschöpfen, weist die Funktion 32-KB-Blöcke in einer Schleife zu, bis GlobalDosAlloc fehlschlägt. Dann halbiert AllocTiledBelow1MBMemory die Blockgröße und springt zurück zum Anfang der Schleife. Dies wird fortgesetzt, bis alle Blöcke mit mehr als 0x200 Bytes zugewiesen wurden. (Denken Sie daran, dass 0x200 Bytes die Größe einer Aufgabendatenbank ist. Nachdem alle Blöcke mit mehr als 0x200 Bytes zugewiesen wurden, gibt die Funktion den ersten Block in der Liste frei. Dadurch erhält LoadModule mindestens einen Block mit ausreichender Größe, um eine Aufgabendatenbank zu erstellen.

Es ist wichtig zu beachten, dass dieser Algorithmus nicht narrensicher ist. Beispielsweise könnten Sie ein Szenario haben, in dem nach den Zuweisungen der globale Heap unter 1 MB nur einen freien Block mit einer Länge von 0 x 200 Bytes hat. Wenn eine EXE (oder eine ihrer DLLs) ein FIXED-Segment mit 0x200 Bytes oder weniger hat, wird dieser Block für das Segment zugewiesen, und es bleibt kein Platz mehr für eine neue Aufgabendatenbank. In solchen Situationen schlägt die Aufgabenerstellung mit der Meldung "Nicht genügend Arbeitsspeicher zum Ausführen dieses Programms" fehl. Eine Lösung, die in diesem Fall normalerweise funktioniert, besteht darin, allen niedrigen MS-DOS-Speicher in Blöcken von 0x200 Bytes zuzuweisen und dann jeden zweiten Block freizugeben. Dies sollte viele Blöcke hinterlassen, die groß genug für eine Aufgabendatenbank sind. Leider verschlingt die Zuweisung so vieler kleiner Blöcke viele Selektoren und verlangsamt die Ladezeit des Programms merklich. Aus diesem Grund ist dies nicht das standardmäßige Zuordnungsschema. Sie können Fix1MB jedoch zwingen, diese Methode zu verwenden, indem Sie auf das Kontrollkästchen "Worst-Case-Modus" klicken.

Eine weitere Lücke in den Fix1MB-Programmen ist dynamisch zugewiesener Speicher. Ein Programm kann beweglichen Speicher mit GlobalAlloc und dann GlobalFix oder GlobalPageLock zuweisen. Da Fix1MB diese Aufrufe nicht überwacht, könnte KRNL386 den Block unter 1 MB verschieben, wenn Fix1MB nicht sucht. Nach meinen Beobachtungen ist Speicher, der auf diese Weise FIXED ist, selten der Hauptnutzer von Speicher unter 1 MB. Wenn Sie diese Lücke schließen möchten, können Sie zusätzliche ProcHook-Callbacks für GlobalFix und GlobalPageLock hinzufügen und das Zuweisungs-/Aufhebungsschema verwenden, das ich für LoadModule verwende.

Ein interessantes Problem beim Schreiben von Fix1MB war, was mit DLLs und Treibern zu tun ist, die früh in der Startsequenz geladen werden. Da diese DLLs eintreffen, bevor Fix1MB von der Startup-Gruppe von PROGMAN gestartet werden konnte, war ein wenig taktische Planung erforderlich. Durch Studieren der Modulliste von Windows (die in Modulladereihenfolge geführt wird) konnte ich die erste DLL finden, die über einen Eintrag in der Datei SYSTEM.INI geladen wurde. In meinem Fall war es MMSYSTEM.DLL, das sich in der Zeile "drivers=" im Abschnitt [boot] von SYSTEM.INI befindet. Mein erster Ansatz bestand darin, FIX1MB.EXE vor MMSYSTEM.DLL in die Zeile "drivers=" einzufügen. Leider hat dies nicht funktioniert. Windows hat sich geweigert, die ausführbare Datei zu laden (anscheinend will es nur DLLs in dieser Zeile laden). Mein zweiter Gedanke war, den Fix1MB-LoadModule-Hooking-Code in eine DLL zu packen. Allerdings habe ich Sie möchten nicht zwei Versionen desselben Basiscodes erstellen. Schließlich hatte ich die Idee, eine kleine DLL zu erstellen, die einfach WinExec Fix1MB.EXE in der LibMain der DLL enthalten würde. Da ich dachte, dass ich nichts zu verlieren hatte, versuchte ich es. Zu meiner Überraschung hat es funktioniert! So wurde FX1MBDLL.DLL geboren.

Wenn Fix1MB über FX1MBDLL.DLL geladen wird, kann die verfügbare Speichermenge unter 1 MB deutlich erhöht werden. In meiner Maschine (die nur ein paar Gerätetreiber hat) sparte mir das Laden von Fix1MB über SYSTEM.INI immer noch ungefähr 80 KB. Ich würde erwarten, dass es bei stärker belasteten Maschinen noch mehr sparen würde. Als weiteren Test habe ich WinFax Pro 3.0 (die neueste Version, die ich habe) gestartet, sowohl mit als auch ohne Fix1MB. Ohne Fix1MB nahm das Starten von WinFax Pro 71 KB aus meinem Speicher unter 1 MB. Mit Fix1MB benötigte WinFax Pro nur 2 KB.

Was passiert, wenn schlecht geschriebene Programme durch die Verwendung von Fix1MB kaputt gehen? Diese Probleme wären auf eine fehlerhafte Annahme im anderen Programm zurückzuführen, nicht auf einen Fehler in Fix1MB. Zuvor habe ich beschrieben, wie Segmente ausführbarer FIXED-Dateien häufig unter 1 MB zugewiesen werden. Einige Programme benötigen Speicher, auf den MS-DOS zugreifen kann (unter 1 MB) und gehen davon aus, dass ihre FIXED-Segmente immer unter 1 MB liegen. Obwohl dies normalerweise der Fall ist (zumindest nicht, wenn Fix1MB nicht läuft), ist es nicht unbedingt erforderlich. Da Fix1MB die meisten FIXED-Segmente über 1 MB zwingt, werden Programme, die auf FIXED-Speicher von unter 1 MB angewiesen sind, eine große Überraschung erleben. Die richtige Möglichkeit für diese Anwendungen, ihren Speicher zuzuweisen, wäre die Verwendung von GlobalDosAlloc.

Ich habe darüber nachgedacht, Fix1MB um eine "Hall of Shame"-Funktion zu erweitern. Die Funktion würde erkennen, wenn LoadModule im Begriff ist, eine dieser fehlerhaften Apps zu laden, und sich vorübergehend selbst deaktivieren. Obwohl es eine coole Idee ist, wollte ich nicht, dass Fix1MB zu groß wird. Ich mag es nicht, Anpassungen für fehlerhafte Apps vorzunehmen. Ich möchte lieber, dass sie ausgespült und durch funktionierende Versionen ersetzt werden. Wenn Fix1MB dazu führt, dass sich eine bestimmte Anwendung seltsam verhält oder abstürzt, versuchen Sie, Fix1MB zu beenden, bevor Sie die betreffende Anwendung starten.

[Abbildung 1 Fix1MB ILLUSTRATION AUSGELASSEN]
[Abbildung 2 FIX1MB]
[PROGRAMMLISTE AUSGELASSEN]

[code]From May 1995 issue of Microsoft Systems Journal, Questions and Answers column:

--------------------------------------------------------------------------

Title:       Windows: Q&A. (Microsoft Windows utility Fix1MB)

Authors:     Pietrek, Matt

--------------------------------------------------------------------------

Subjects:    GUI;  Programming Utility;  Product Support;  Product Tutorial

Companies:   Microsoft Corp._Products

Products:    Microsoft Windows (GUI)_Programming

Reference #: A16745388

==========================================================================

In my first column for MSJ (October 1993), 1 wrote what I considered a throwaway utility called Below 1MB. This column, which deviates from the usual question and answer format, describes Fix1MB, an update to Below1MB. The purpose of Below1MB was to help you determine which of your own DLLs and drivers were sucking up the precious linear address space below 1MB. Windows[R] 3.x and Windows[R] 95 need a small amount of memory below 1MB for each task it starts up. If it can't allocate the memory, you get a somewhat confusing "insufficient memory to run this program" message, regardless of how much RAM you have installed. When I wrote Below1MB, little did I imagine that it would get noticed outside of programming circles. End users have been using it, and one person even sent me a British general computing magazine with a picture and a short column about Below1MB.

Alas, the low MS-DOS[R] memory shortage is so bad (especially in Windows[R] for Workgroups 3.11) that even end users are grasping at anything that might help, even if they don't understand much of the information provided. Had I known that Below1MB was going to have so broad an audience, I might have written it differently, paying particular attention to reducing details not directly related to the main problem. As you may have guessed by now, I have finally rewritten Below1MB to make it easier to use, and (more importantly) actually help correct the problem. My Fix1MB program should be of interest to programmers for the techniques it uses, as well as end users who are just looking for a quick fix.

The Below One Megabyte Problem

For those of you whose MSJ back issues aren't handy, I'll do a quick overview of the problem in Windows that Fix1MB corrects. Each running program in Windows is a separate task. Each task has a system data structure associated with it known as a task database (or TDB). A task database contains vital information about a task, such as its current directory, its HINSTANCE, and an MSDOS PSP (Program Segment Prefix). The size of each task database is 0x200 bytes (an important number that will come up later.) In Windows 3.x, each task database must be allocated at an address that's below a linear address of 1MB. Why's this? Windows 3.x still uses real-mode MSDOS extensively and many MS-DOS functions need access to a PSP. Since the maximum address accessible in real mode is 1MB (actually, 1MB + 64KB - 16), the PSP stored in each task database must be at a linear address below 1MB.

When Windows starts up, it places any unused MS-DOS memory below 1MB into the global heap. This MS-DOS memory makes up the very lowest portion of the entire Windows global heap. Typically, there may be 300KB in the global heap that comes from this low MS-DOS memory. With 300KB of memory to play with, you should be able to create something like 2400 task databases, which should be plenty even for the most hard-core multitaskers.

The problem with this setup has to do with how Windows allocates global heap memory. Normally when allocating memory, the global heap manager starts its search at the low end of the global heap and stops when it finds the first block big enough. (The exception is when allocating memory for discardable code segments, which causes Windows to start the search at the upper end of the heap. Since the low part of the global heap encompasses the leftover low MS-DOS memory, many global heap allocations end up coming from addresses below 1MB. Unless special precautions are taken, global heap allocation quickly snaps up all the below-1MB memory, making it impossible to create another task database (and hence, start a new task).

Windows keeps the below-1MB memory from quickly being eaten up by making most blocks moveable. Even if a block were originally allocated below 1MB, the global heap manager will move the block up in linear memory to make room for another block that really does need to be below 1MB. While this helps out immensely, there's still the problem of FIXED blocks. The global heap manager is unable to move FIXED blocks, so any blocks that are below 1MB when they're given the FIXED attribute remain there. It is these FIXED blocks that soak up the memory below 1MB and make it impossible to start a new task.

So, how do you get FIXED memory blocks? There are three ways. First, you can allocate memory with GlobalAlloc and give it the GMEM_FIXED flag. Windows ignores the GMEM-FIXED flag when the allocation request comes from EXE code, but honors it when the allocation request comes from a DLL. Second, you can mark your EXE's or DLL's segments with the FIXED attribute. For a now-obsolete reason, some linkers default to making segments FIXED by default. (The solution is to explicitly set the segment attributes in the DEF file.) As with GlobalAlloc, Windows ignores the FIXED attribute when allocating memory for EXE file segments. A segment in a DLL will have the FIXED attribute if the DLL specifies FIXED for that segment.

The third way of getting FIXED memory is to allocate moveable memory and then explicitly give it the FIXED attribute. Both the GlobalFix and GlobalPageLock functions give segments the FIXED attribute. (GlobalPageLock first calls GlobalFix, then pagelocks the segment.) These functions are especially hazardous to the low MS-DOS memory because they attempt to slide the block as far down as possible in memory before they fix it. This can cause blocks that previously were above 1MB to move down into the 1MB area, further compounding the problem.

When you combine the need for task databases to be below 1MB with the global heap allocation strategy, you can see there's going to be trouble in many cases. Many device drivers and system DLLs require FIXED and/or pagelocked memory because they have interrupt handlers or communicate with real-mode MS-DOS-based programs. This is especially true of network drivers. Since most of these drivers load early in the Windows boot process, you can see how a significant amount of the real-mode MSDOS memory required for TDBs can be eaten up. People often tell me that after they start one particular program, they can't start any others. This is almost always because the first program uses some DLLs or drivers that have swallowed up the last bit of memory below 1MB.

In Windows 95, this problem goes away for the most part. Windows 95 changes the way GlobalAlloc works so that (for the most part) FIXED blocks don't get allocated below 1MB. When run under Windows 95, my Below1MB program shows very few FIXED blocks from drivers and DLLs taking up space below 1MB. In addition, task databases don't need to come from below 1MB in Windows 95. However, the PSP has been split out of the Windows 95 task database, and it must still reside below 1MB. To test this out, I slightly modified my original Below1MB program to allocate all the memory in blocks of 0x120 bytes (the size of a PSP in Windows 95). 1 ran this modified Below 1MB under Windows 95 (M8 Preview build) and had it allocate all the memory below 1MB. I then tried to start up a new program. As I suspected, Windows 95 wouldn't start the new task, and gave me an error message about there not being enough memory to start the program.

The Fix1MB Program

To help with the problem of insufficient memory below 1MB, I wrote the Fix1MB program (see Figures 1 and 2). Fix 1MB is really two, two-two programs in one. The first part analyzes the global heap blocks below 1MB and gives you a list of memory blocks that are possibly taking up space unnecessarily. Along with each block, the report names the EXE or DLL that owns the memory block. Armed with this information, you'll at least know the major culprits in stealing your low memory. Based on this knowledge, you might decide to remove a particular device driver or program. You may even be able to press the manufacturer of the offending program or driver to give you an updated version that doesn't use FIXED segments needlessly.

The other part of Fix1MB actually does something about the below 1MB problem. Using sophisticated techniques developed jointly with NASA scientists, it guards the spot where most FIXED memory blocks dive below 1MB and take up residence permanently. By keeping the door to memory below 1MB shut at a critical moment, Fix1MB forces programs and drivers to take their FIXED memory blocks elsewhere. (This is the Windows version of "Not in my back yard.")

If you run the Fix1MB program from within Windows, it prevents all subsequently loaded EYES and DLLs from grabbing FIXED blocks below 1MB (with a few minor exceptions that I'll describe later). While this should help in many cases, your problem may be with drivers and DLLs loaded at startup (such as network drivers). Running Fix1MB normally can't help in this situation. These drivers are already camped out below the 1MB door when Fix1MB starts. However, by loading Fix1MB early enough in the startup sequence, it can usually prevent the offending drivers and DLLs from grabbing significant amounts of FIXED memory below 1MB. Therefore, Fix1MB has an option that allows it to be placed into a strategic spot in the SYSTEM.INI file so that it's loaded fairly early in the startup sequence each time you boot Windows. (This isn't as simple as just putting Fix1MB into the Startup group. I'll describe how it actually works later.) For the SYSTEM.INI load to work, both FIX1MB.EXE and FX1MBDLL.DLL need to be in the same directory. PROCHOOK.DLL should also be in the same directory or somewhere on the path.

Figure 1 shows what Fix1MB looks like. The Potential Free Space field at the
top shows how much memory is available below 1MB. This figure isn't what's
currently free. Rather, it's what would be free if Windows were to pull out
all the stops to move around memory and maximize the space below 1MB.

The list box entitled Potential Memory Hogs is a size-sorted list of memory blocks below 1MB that can't be moved. These blocks are what's taking up space below 1MB. Each line contains a block size, what the block is used for, and the owner of the memory block. Fix1MB doesn't show blocks that you can't do anything about. For instance, KRNL386.EXE (the main system DLL) uses quite a bit of fixed memory below 1MB. However, since you can't do anything about this, why show it? Since filtering out every possible system DLL would be well-nigh impossible, Fix1MB just aims for the biggies (the actual list is in the FIX1MB.C source file). If a block is in the Fix1MB list box, it may be a badly written driver or DLL, it may have legitimate needs for memory below 1MB, or it may be a system DLL that you can't get rid of. To some degree, you'll have to look at the list and make a judgment call about whether you should try and do something about a given line or not. Often, just clearing up the primary offender (if any) may be enough to get you going again.

The Rewalk button causes Fix1MB to redo its analysis of the memory below 1MB. Whenever you restore Fix1MB from an iconized state, it redoes its analysis. However, if programs or DLLs load while Fix1MB is in its noniconized state, Fix1MB's analysis will get out of sync. To get an up to date report, hit the Rewalk button.

The Help button's use should be obvious. The remaining button in Fix1MB is Add FIX1MB to SYSTEM.INI. This causes FIX1MB.DLL to insert FX1MBDLL.DLL into the "drivers=" line in SYSTEM.INI. Once you've done that, subsequent presses of the button result in an error message. The check box at the very bottom changes the way that FIX1MB guards the memory below 1MB. By default, it's unchecked, which gives optimal performance. However, in a few rare cases, the default may not sufficiently guard the low memory, allowing the out-of-memory error to return. If this happens, try checking the box.

Under the Hood of Fix1MB

As I mentioned earlier, Fix1MB is really two programs in one. If you don't care for the heap analysis and my minimalist UI, you can easily extract those portions of the code and recompile it. Still, as it exists now, Fix1MB is pretty small and is helpful in determining what new low-memory-guarding technology has.

The low heap analysis portion of Fix1MB is fairly straightforward, and isn't significantly changed from BELOW1MB.EXE. However, the results Fix1MB shows look quite different, and are much clearer. The WalkHeap function in FIX1MB.C walks the global heap blocks up to the 1MB address limit using the ToolHelp GlobalFirst and GlobalNext functions. As Fix1MB goes through each block, it looks for two things. First, it looks for heap blocks that can't be moved and that the user might have some control over. Second, Fix1MB looks for gaps between the end of one FIXED block and the start of another. The total size of all these gaps is counted as free memory, even if the space is currently occupied by a moveable block. When Windows really does need memory below 1MB (such as for a GlobalDosAlloc call), these moveable blocks are moved upwards in linear memory, removing them from the under-1MB region.

As the WalkHeap routine finds each block, it calls the IsPotentialSpaceHog function that determines the status of the block. If IsPotentialSpaceHog returns TRUE, the block will end up in the Fix1MB list box. IsPotentialSpaceHog immediately throws out free blocks and sentinel blocks (which KRNL386 uses to mark off regions of the global heap). IsPotentialSpaceHog also throws out blocks that don't have the GMEM_FIXED attribute and aren't page locked. (Pagelocked is a superset of the FIXED attribute. Any blocks that make it past these tests are immovable. At this point, IsPotentialSpaceHog looks for a gap between this block and the prior immovable block, and if there is one, adds it to the running total. Before returning TRUE, IsPotentialSpaceHog checks to see if the block is a task database or is owned by a system DLL that the user has no control over. If so, IsPotentialSpaceHog returns FALSE to keep WalkHeap from putting the block into the report list box.

The other subprogram with Fix1MB is a little more complicated. Its basic goal is to allocate all (or most of) the memory below 1MB before the Windows loader or a program tries to allocate FIXED memory. By making no memory free below 1MB, the FIXED memory allocation ends up coming higher up in the address space (remember, in most cases the global heap manager searches for free blocks from the bottom up). After the FIXED memory has been allocated someplace other than below 1MB, Fix1MB frees the memory it allocated previously.

Fix1MB knows when large FIXED memory allocations are about to occur because of the LoadModule routine. LoadModule is the core Windows loader. The majority of allocations of FIXED memory are made within LoadModule when it allocates memory for the code and data segments of EXEs, DLLs, and device drivers. To have a significant effect, Fix1MB merely needs to prevent LoadModule from allocating its FIXED memory from below 1MB. What about other routines that load programs and DLLs? Fix1MB has these bases covered. LoadLibrary and WinExec are both wrappers around a call to LoadModule. The ShellExecute function is a wrapper around WinExec. By watching when LoadModule is called, Fix 1MB can kill four birds with one stone.

Fix1mb monitors when LoadModule is called by using James Finnegan's PROCHOOK.DLL from the January 1994 issue of MSJ. I briefly debated using breakpoints to keep Fix1MB entirely self-contained, but the ease of use of ProcHook won out in the end. Fix1MB installs a hook on LoadModule, and specifies Fix1MBLoadModule in FIX1MB.C as the callback function. Inside Fix1MBLoadModule, the code temporarily unhooks the LoadModule callback, allocates all the memory below 1MB, and then calls the original LoadModule. After LoadModule returns, Fix1MBLoadModule frees all the memory it previously allocated and then reinstalls the LoadModule hook. By calling LoadModule directly, Fix1MB implicitly knows when it's safe to free the allocated memory. This would be harder to determine if the hook simply chained the call onto the original handler. In addition, LoadModule is recursive, so unhooking the callback and calling LoadModule directly lets Fix1MB ignore all the nested calls to LoadModule. This way, Fix1MB only does the allocations on the primary call to LoadModule and doesn't have to do anything for the nested LoadModule invocations.

When allocating all the memory below 1MB, Fix1MB stores the blocks in a linked list. The first WORD of each allocated block contains the handle of the next allocate block. The AllocTiledBelow1MBMemory allocates on memory below 1MB by calling GlobalDosAlloc. To quickly exhaust the memory below 1MB, the function allocates 32KB blocks in a loop until GlobalDosAlloc fails. Then AllocTiledBelow1MBMemory cuts the block size in half and jumps back to the top of the loop. This continues until all the blocks of more than 0x200 bytes have been allocated. (Remember, 0x200 bytes is the size of a task database. After allocating all the blocks of more than 0x200 bytes, the function frees the first block in the list. This gives LoadModule at least one block of sufficient size to create a task database.

It's important to note that this algorithm isn't foolproof. For instance, you could have a scenario where after the allocations, the global heap below 1MB has only one free block, 0x200 bytes in length. If an EXE (or one of its DLLs) has a FIXED segment that's of 0x200 bytes or less, that block will be allocated for the segment, and there won't be any space left over for a new task database. In situations like this, the task creation fails with the "insufficient memory to run this program" message. One solution that usually works in this case is to allocate all low MS-DOS memory in chunks of 0x200 bytes and then free every other block. This should leave plenty of blocks big enough for a task database. Unfortunately, allocating this many small blocks eats up a lot of selectors and noticeably slows program load time. For this reason, this isn't the default allocation scheme. However, you can force Fix1MB to use this method by clicking on the "Worst case mode" check box.

Another hole in the Fix1MB programs is dynamically allocated memory. A program can allocate moveable memory with GlobalAlloc and then GlobalFix or GlobalPageLock it. Since Fix1MB doesn't monitor those calls, KRNL386 could move the block below 1MB when Fix1MB isn't looking. From my observations, memory that's FIXED in this manner is rarely the primary user of memory below 1MB. If you want to close this loophole, you could add additional ProcHook callbacks for GlobalFix and GlobalPageLock, and use the allocation/deallocation scheme that I use for LoadModule.

An interesting problem in writing Fix1MB was what to do about DLLs and drivers that are loaded early in the boot sequence. Since these DLLs come in before Fix1MB could be fired up by PROGMAN's Startup group, a bit of tactical planning was necessary. By studying the module list of Windows (which is kept in module load order), I was able to locate the first DLL loaded via an entry in the SYSTEM.INI file. In my case, it was MMSYSTEM.DLL, which is on the "drivers=" line in SYSTEM.INI's [boot] section. My first approach was to stick FIX1MB.EXE before MMSYSTEM.DLL on the "drivers=" line. Unfortunately, this didn't work. Windows refused to load the executable file (apparently it only wants to load DLLs on that line). My second thought was to put the Fix1MB LoadModule hooking code in a DLL. However, I didn't want to create two versions of the same basic code. Finally, I had the idea of creating a small DLL that would simply WinExec Fix1MB.EXE in the DLL's LibMain. Figuring I had nothing to lose, I gave it a try. To my surprise, it worked! Thus was born FX1MBDLL.DLL.

When loaded via FX1MBDLL.DLL, Fix1MB can significantly increase the amount of memory available below 1MB. In my machine (which has only a couple of device drivers), loading Fix1MB via SYSTEM.INI still saved me roughly 80KB. I'd expect that on more heavily loaded machines, it would save even more. As another test, I fired up WinFax Pro 3.0 (the latest version I have), both with and without Fix1MB running. Without Fix1MB, starting WinFax Pro took 71KB out of my memory below 1MB. With Fix1MB running, WinFax Pro took only 2KB.

What if badly written programs break by using Fix1MB? These problems would be due to a faulty assumption in the other program, not a flaw in Fix1MB. Earlier, I described how FIXED executable file segments often end up being allocated below 1MB. Some programs need memory accessible by MS-DOS (below 1MB) and assume that their FIXED segments will always be below 1MB. While this is usually the case (at least not when Fix1MB isn't running), it's not absolutely required. Since Fix1MB forces most FIXED segments above 1MB, programs that rely on FIXED memory coming from below 1MB are in for a big surprise. The proper way for these applications to allocate their memory would be to use GlobalDosAlloc.

I thought about adding a "Hall of Shame" feature to Fix1MB. The feature would recognize when LoadModule is about to load one of these faulty apps and temporarily disable itself. While a cool idea, I didn't want Fix1MB to get too big. I don't like making accommodations for buggy apps. I'd rather they be flushed out and replaced with working versions. If Fix1MB does cause a certain application to act strangely or crash, try exiting Fix1MB before you start the application in question.

[Figure 1 Fix1MB ILLUSTRATION OMITTED]

[Figure 2 FIX1MB]

[PROGRAM LISTING OMITTED]

============================================================================[/code]

Beitrag hat keine Schlüsselwörter

Beitrag von freaked 303 Klicks | Quelle
Geschrieben am: 24.11.2022, 15:22:54 Uhr
Zuletzt überarbeitet: 24.11.2022, 15:54:51 Uhr

Kommentare