Treiber dynamisch nachladen
tschw...@fiducia.de
Ich suche eine Möglichkeit Treiber (die Zeilen mit DEVICE=xyz.sys in
CONFIG.SYS) dynamisch nachzuladen. Gibt es dafür ein Programm, das dies
auch äquivalent "DEVICEHIGH=xyz.sys" kann?
--
Thomas
Robert Riebisch
> auch äquivalent "DEVICEHIGH=xyz.sys" kann?
Hmm, dann heißt dann wohl sinnigerweise "devload" (DR-DOS) bzw.
"dynaload" (PC-DOS).
Ansonsten versuche es mal mit Google. Ist doch gar nicht so schwer und
geht schneller, als wenn du auf Antwort wartest.
http://www.google.com/search?q=devload&hl=de&sa=N&tab=gw
Robert Riebisch
--
BTTR Software
http://www.bttr-software.de/
ICQ: 112321692
Heiko Nocon
Ja, ctload. Allerdings funktioniert das nicht mit jedem Treiber.
tschw...@fiducia.de
> "dynaload" (PC-DOS).
Leider können beide Programme treiber nur in den unteren Speicherbereich
laden. Wenn ich diese benutze, bleibt mir nicht mehr genug platz frei, um
z.B. W2K zu installieren...
--
Thomas
tschw...@fiducia.de
Das kann es aber leider auch nicht in den HMA-Bereich... Und es
funktioniert offenbar noch schlechter als mit 'dynaload' oder 'devload'.
Scheinbar geht es damit nur für CDROM-Treiber...
--
Thomas
Thomas König
> CONFIG.SYS) dynamisch nachzuladen. Gibt es dafür ein Programm, das
> dies auch äquivalent "DEVICEHIGH=xyz.sys" kann?
LH DYNALOAD verwirklicht). Da ist in PC-DOS ab V 7.0 mit bei. DR-Dos hat
IMO auch sowas bei, ab welcher Version weiß ich nicht.
schöne Grüße,
Thomas
--
Thomas König [msk.Th...@usa.net] am 01/26/02 um 14:47 (Berliner Zeit)
http://msk.notrix.net/ (Merlins Stern Kids - Das Phantastikmagazin)
http://zauberwald.xww.de/ (Zauberwald - die Fantasy-Heftserie)
und http://gwk.xww.de/ (GeisterwaldKatalog)
Nutze: OUI 1.9.2 Pro
Thomas König
> Speicherbereich laden
schöne Grüße,
Thomas
!^NavFont02F00890004HG8AB5F2
--
Thomas König [msk.Th...@usa.net] am 01/27/02 um 18:53 (Berliner Zeit)
Thomas König
Wie soll dynaload etwas leisten, was device= nicht leistet?
schöne Grüße,
Thomas
--
Thomas König [msk.Th...@usa.net] am 01/28/02 um 21:04 (Berliner Zeit)
Stephan Grossklass
>
> Ich suche eine Möglichkeit Treiber (die Zeilen mit DEVICE=xyz.sys in
> CONFIG.SYS) dynamisch nachzuladen. Gibt es dafür ein Programm, das dies
> auch äquivalent "DEVICEHIGH=xyz.sys" kann?
Habe hier ein kleines Proggi device.com, ehedem von einer Diskette zu
einer Win95-OEM-Version kopiert. Das habe ich immer zum nachträglichen
Laden von CD-ROM-Treibern verwendet (per LH auch in die UMBs).
Stephan
--
Stephan Großklaß (7bit: Grossklass)
eMail: mailto:jgros...@t-online.de | Webmaster: http://www.i24.com/
Home: http://jgrossklass.bei.t-online.de/
P3@620, 128MB, 8+8+19GB HDD; Win2k; WfW 3.11, Calmira II 3.2; Win98SE
Thomas König
[ ] du willst mich veralbern
[ ] du willst irgendwie stören
[ ] du wolltest einfach irgendwas sagen
schöne Grüße,
Thomas
--
Thomas König [msk.Th...@usa.net] am 01/30/02 um 15:38 (Berliner Zeit)
http://msk.notrix.net/ (Merlins Stern Kids - Das Phantastikmagazin)
http://zauberwald.geisterwald.com/ (Zauberwald - die Fantasy-Heftserie)
Matthias Paul
> Also vom dosprompt aus? Da wäre dann DYNALOAD (DEVICEHIGH wird dann via
> LH DYNALOAD verwirklicht). Da ist in PC-DOS ab V 7.0 mit bei. DR-Dos hat
> IMO auch sowas bei, ab welcher Version weiß ich nicht.
Ja, ab DR-DOS 7.02+.
Grüße,
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
Matthias Paul
Wie wär´s mit "LH DEVLOAD treiber parameter"?
Oder, unter DR-DOS, vorher den UMB-Speicher explizit einblenden.
Das geht mit MEMMAX +U. Normalerweise wird der UMB-Speicher aus
Kompatibilität mit alten Programmen aus der vor-DOS 5 Ära nur für
die Dauer des LH-Befehls (oder entsprechender Alternativen einge-
blendet), aber unter DR-DOS kannst Du den mit MEMMAX +U auch
dauerhaft für normale Speicherallokationen "zuschalten".
Viel Erfolg,
Matthias Paul
> Das kann es aber leider auch nicht in den HMA-Bereich... Und es
> funktioniert offenbar noch schlechter als mit 'dynaload' oder
> 'devload'.
Hm, also mit den beiden letztgenannten Utilities sollte das sehr
gut funktionieren - soweit das prinzipiell eben machbar ist.
Wobei zumindest DEVLOAD auch noch mit MS-DOS 7.10 funktioniert,
DYNALOAD aber wahrscheinlich nicht (ich hab´s nicht ausprobiert,
aber zumindest für Blocktreiber ist das unwahrscheinlich, da sich
da mit der Einführung von FAT32 in den DOS-internen Datenstrukturen
einiges geändert hat und PC DOS 2000 kein FAT32 unterstützt, also
noch die klassischen Datenstrukturen benutzt - wie natürlich auch
DR-DOS 7.03, nur weiß ich bei DEVLOAD, daß wir da explizit Unter-
stützung für DOS 7.10 eingebaut haben... Bei Zeichentreibern hat
sich quasi nichts geändert, da müßte DYNALOAD auch ohne Anpassungen
bis MS-DOS 8.0 funktionieren (notfalls mit SETVER).
Was die andere Bemerkung mit HMA angeht, das Laden in die HMA
ist /so/ prinzipiell nicht möglich:
Die HMA ist nur durch einen Trick von Real Mode- (oder V86-Mode-)
DOS aus zu adressieren, eigentlich aber Teil des Extended Memory.
Wenn Programme oder Treiber in UMBs geladen werden, ändert sich damit
für die allermeisten Programme nichts, außer, daß sie "verwirrt"
darüber sein könnten, daß sie plötzlich oberhalb des Videospeichers
geladen wurden oder daß sie bei Speicherallokationen u.U. nur sehr
begrenzt Platz haben.
Werden die UMBs nicht direkt durch das Chipset zur Verfügung gestellt
(also soetwas wie "Permanentes Oberes RAM", wie das bei DR-DOS heißt)
sondern durch die Paging-Logik eines 386+ Prozessors im V86-Modus dort
hingemappt, dann gibt es noch ein paar Besonderheiten insbesondere bei
DMA-Zugriffen (etwa bei Disk-I/O) zu beachten, denn die physikalischen
Adressen, die der DMA-Kontroller (quasi an der CPU vorbei) sieht, müssen
nicht unbedingt den logischen Adressen entsprechen, die ein im UMB-
Speicher laufendes Programm sieht. Das Programm, das meint, im ersten
Megabyte des Rechners zu laufen, kann im V86-Modus, der ab 386+ Systemen
fast immer auch unter DOS aktiv ist, im Prinzip irgendwo im 4 GB
physikalischen Adreßraum der CPU liegen. Das könnte dann dazu führen,
daß der DMA-Kontroller am Speicherschutz der CPU irgendwelche anderen
Speicherbereiche überschreibt. Nun, dafür gibt es die VDS 1.0 (Virtual
DMA Specification), Disk Deblocking über einen Zwischenpuffer im kon-
ventionellen Speicher (DR-DOS CONFIG.SYS DEBLOCK=0000, A000 oder FFFF
sowie DBLBUF.SYS), und nicht zuletzt der Speichermanager EMM386.EXE,
der sich um das Übrige kümmert, indem er Zugriffe auf den DMA-Kontroller
trappt und entsprechend umsetzt.
Außerdem gibt es erweiterte Selbsthochlademethoden - etwa unter DR-DOS
mittels XMSUMB -, aber von solchen Tricks abgesehen klappt für die
überwiegende Mehrzahl der Programme auch die klassische LOADHIGH-
Methode, die den UMB-Speicher temporär freischaltet und das Programm
einfach da rein lädt. An den Programmen selbst sind dafür in der
Regel keine Änderungen notwendig.
Ganz anders sieht das beim Zugriff auf die HMA aus. Du kannst
nicht einfach ein Programm in die HMA laden und erwarten, daß
das funktioniert:
Das erste Problem ist das "berühmte" A20-Gate, mit dem man die
Adreßleitung A20 maskieren kann. A20 ist die Leitung, die für
2^20 zuständig ist, also den Adreßraum auf mehr als 1 MB erweitert.
Da es in grauer Vorzeit ein paar 8088/8086/80188/80186-Programme
gab, die es ausgenutzt haben, daß bei Zugriffen auf Adressen
oberhalb von 1 MB ein Warp-Around auftritt und man wieder den
Anfang des konventionellen Speichers erreicht - also Teile des
Segments 0000h, in dem die Interrupt-Vektor-Tabelle, der BIOS-
Datenbereich etc. liegen -, ohne dafür Segment-Register umsetzen
zu müssen, hat IBM beim Design des ATs das GateA20 erfunden, mit
dem man das Verhalten eines 8088/8086 auch auf einem 80286 nach-
bilden kann.
Will man Speicher oberhalb des ersten MB addressieren, braucht
man dafür Adreßleitungen A20 und höher und das GateA20 muß so
einstellt sein, daß diese Adreßleitung auch an den Hauptspeicher
"durchgereicht" wird. Aber da man das GateA20 über den Tastatur-
Kontroller umprogrammieren kann, ist nicht grundsätzlich sicher-
gestellt, daß die Maskierung deaktiviert ist, und da wie gesagt
ganz alte Programme die Maskierung u.U. wirklich brauchten,
ändert sich der Zustand des Gates je nach Bedarf (normalerweise
unter der Kontrolle der "Exec"-Programmlade-Routine des DOS-Kernels
(INT 21h/4Bh) und der des Speichermanagers). Will nun der DOS-Kern
oder auch ein anderes Programm auf die HMA zugreifen, muß es vor
jedem auch noch so kurzen Zugriff erst dafür sorgen, daß die
Maskierung aufgehoben wird und damit die HMA eingeblendet wird,
sonst liest oder schreibt es u.U. Speicher vom Anfang des ersten
Megabytes statt vom Anfang des zweiten Megabytes, wo die HMA liegt.
Nachher muß der alte Zustand wieder rekonstruiert werden.
Der Speichermanager HIMEM.SYS bzw. EMM386.EXE stellt dafür im
Rahmen der XMS-Spezifikation Funktionen zur Verfügung, die den
direkten Hardware-Zugriff auf das GateA20 abstrahieren (denn
obendrein hängt die Programmierung des GateA20 stark vom Mainboard-
und Chipsatz-Hersteller ab - jeder hat da sein eigenes Süppchen
gekocht und so muß der Speichermanager über ein Duzend verschiedene
Behandlungsroutinen mitbringen, um überall zu funktionieren).
Auch der DOS-Kern benutzt diese Funktionen, um auf die HMA zuzugreifen.
Das bedeutet aber, daß ein Teil des Treibers immer irgendwo im
Speicher unterhalb des ersten Megabytes bleiben muß und alle Zugriffe
auf den in die HMA geladenen Programmteil über diesen Stummel (Stub)
erfolgen müssen. In diesem Stub sorgt eine Routine dafür, daß die
HMA eingeblendet wird, bevor darein weiterverzweigt wird. Da sich
nun Programme bei Bedarf selbst in Interrupt-Funktionen einklinken,
anstatt das Betriebssystem damit zu beauftragen, gibt es keine
Möglichkeit, über die das System entsprechende Vorkehrungen treffen
könnte, selbst die Steuerung des GateA20 für das Programm zu über-
nehmen, d.h. dieser Stub muß von jedem Programm selbst bereitgestellt
und geladen werden, und das wiederum bedeutet, daß Programme und
Treiber, die nicht explizit dafür angepaßt wurden, alle ihre Zugriffe
durch einen solchen Stub zu tunneln, niemals stabil in der HMA
laufen können... Zumindest unter DR-DOS gibt es noch eine Hintertür
(eine sog. "Backdoor"), mit der sich Programme, die nur eine
INT 2Fh-Schnittstelle zur Verfügung stellen müssen, direkt in den
Kern einklinken (quasi dort "anmelden") können, und dann auch ohne
Stummel funktionieren, weil der Kernel dann sicherstellt, daß A20
aktiv ist, wenn die Kontrolle an das Programm übergehen wird.
DR-DOS SHARE und NLSFUNC machen zum Beispiel von dieser Möglichkeit
Gebrauch, bei KEYB geht das aber schon wieder nicht mehr so einfach,
da hier auch noch der INT 09h gebraucht wird, was etliche Race-
Conditions aufwirft. Deshalb braucht KEYB für´s HMA-Laden nach
wie vor einen Stub.
Gerätetreiber, die sich über die Gerätetreiberschnittstelle in DOS
einklinken, kommen grundsätzlich nicht ohne einen Stub aus, in dem
auch der Kopf des Gerätetreibers liegen muß, ganz einfach weil es
Programme gibt, die die Gerätetreiberkette durchhangeln und bei
deaktiviertem GateA20 plötzlich einfach im Niemandsland landen
würden, wenn der Kopf der Gerätetreibers in der HMA liegen würde,
diese aber zufälligerweise gerade nicht eingeblendet wäre...
Soweit noch die einfachen Dinge. In der Praxis gibt es aber noch
ein viel grundlegenderes Problem beim Laden in die HMA:
Die meisten kleinen Treiber und TSRs sind im Tiny-Speichermodell
programmiert, d.h. Code- und Datensegment sind gleich. Solche
Programme sind im Gegensatz zu .EXE-Dateien (die Relokations-
informationen enthalten, die beim Laden des Programms von der
Laderoutines des Kerns ausgewertet und entsprechend umgesetzt
werden) üblicherweise als Binärimage gespeichert und erwarten,
an ein bestimmtes Offset geladen zu werden.
.COM-Programme werden z.B. an Offset +100h und .SYS-Programme
an Offset +0h geladen.
Da die Programme in ihrer kleinen Welt von 64 KB, die man mit
16-bit Offsets adressieren kann, leben, kann man sie im Prinzip
in jedes beliebige Segment von 0000h bis FFFFh laden, durch
die Überlappung von Segment- und Offset-Werten in der Real Mode
und V86-Mode-Adressierung auf Intel-CPUs, also an jeder möglichen
Paragraphengrenze, d.h. alle 16 Bytes. Dem Programm ist das mehr
oder weniger egal, weil alle relativen Bezüge sich nur innerhalb
des eigenen Segments bewegen, egal, ob das Programm sagen wir mal
in Segment 2130h im konventionellen Speicher, oder irgendwo bei
D742h in den UMBs läuft. An den Offsets, d.h. den relativen
Bezügen innerhalb des Programms selbst, ändert sich dadurch
nichts, und absolute Bezüge auf Adressen außerhalb des
Programms (z.B. auf BIOS- oder DOS-Datenstrukturen) ändern
sich ebenfalls nicht.
Wenn man jetzt das oben Gesagte zum A20-Stub einmal außen
vor läßt und für den Moment einfach annimmt, die A20-Leitung
wäre ordnungsgemäß freigeschaltet, könnte man also das
Programm durch das Laden ins Segment FFFFh auch in die
HMA plazieren. Sagen wir mal, das Programm ist 5 KB (1400h)
groß, also wären dann FFFFh:0000h bis FFFFh:1400h belegt.
Soweit so gut.
Doch was passiert, wenn man jetzt das nächste Programm in
die HMA laden will? Beim Laden in UMBs könnte man einfach
ein anderes (höheres) Segment verwenden, aber ein höheres
Segment als FFFFh gibt es in der 16-Bit Welt von DOS nun
mal nicht; auf diese Weise könnte also nur *ein* Programm die
HMA nutzen (der MS-DOS/PC DOS Kern macht das im Prinzip so,
bei DR-DOS ist das etwas trickreicher implementiert).
Natürlich kann man tricksen:
Eine andere Möglichkeit wäre es, das Programm nicht für ein
Offset +0h oder +100h zu assemblieren ("ORGed"), sondern sagen
wir mal für ein Offset von +1400h. So könnte man das Programm
mit einem Segment von FFFFh hinter das andere Programm in die
HMA legen, aber das würde schon zum Kompilierungszeitraum das
Wissen darüber erfordern, an welche Zieladresse das Programm
geladen werden soll, für existierende Programme, wie auf
irgendwelchen Wald- und Wiesensystemen laufen sollten, scheidet
das also schon mal aus. Am flexibelsten ist man noch, indem
man das Programm so ORGed, daß es an 64 KB minus der eigenen
Programmgröße läuft, damit würde das Programm bei einem
Segment von FFFFh an das *Ende* der HMA (nicht an den Anfang)
geladen und man könnte kleinere Segmentwerte als FFFFh ver-
wenden, wenn man weitere Programme davor laden möchten. Aber
so ein Treiber würde dann z.B. nicht mehr in den ersten 64 KB
des konventionellen Speicher laufen, bzw. dort trotz nur 5 KB
Größe fast die gesamte ersten 64 KB "verbrauchen", ganz einfach
weil es keine kleineren Segmentwerte als 0000h gibt... ;-)
"Packet file corrupt" von Programmen, die mit alten Versionen
von Microsofts EXEPACK gepackt, oder mit Microsofts LINK zusammen-
gebaut wurden lassen grüßen. Wodurch die paradoxe Situation ent-
steht, daß man wegen der in diesen Entwicklungswerkzeugen ver-
wendeten Programmiertricks der übelsten Sorte neue Workarounds
brauchte, um die Nutzung der ersten 64 KB des Hauptspeichers
zu unterbinden, obwohl man doch gerade erst froh war, durch die
Möglichkeit des Hochladens dort Platz für Programme geschaffen
zu haben... ;-> Das zugehörige Workaround heißt LOADFIX bzw.
MEMMAX -L.
In der Praxis gibt es noch weitere Probleme, etwa, daß am Anfang
der HMA aus Kompatibilitäsgründen mit Zugriffsmethoden auf den
Erweiterten Speicher aus der Zeit vor der Einführung der XMS-
Spezifikation eine bestimmte Struktur liegen muß, der sog.
VDISK-Header. Außerdem sollte man für Zugriffe auf die HMA
möglichst immer den Segmentwert FFFFh oder besser FFFEh ver-
wenden, weil manche Software daran den Zugriff auf die HMA
erkennt. Eine praktikabele Lösung ist also die eigenständige
Relokation von Binärimages mit Intra-Segment-Offset-Anpassungen.
Um den Aufwand bei der Programmierung möglichst gering zu
halten, kann man den Treiber mit verschiedenen Offsets
kompilieren und das jeweils erzeugte Kompilat mit einem
externen Tool analysieren und alle Veränderungen zwischen
den Compiler-Läufen festhalten. Daraus kann das Tool dann
"von außen" die Stellen (d.h. Variablenreferenzen, Sprünge
usw.) ableiten, die bei einer Offset-Verschiebung entsprechend
angepaßt werden müssen, diese Informationen zu einer Tabelle
im Binärformat zusammenstellen und an das endgültige Programm-
Image anhängen. Wenn das Programm sich nun später selbst in die
HMA lädt (wie gesagt, ein externes Tool kann das niemals leisten),
kann es diese Tabelle auswerten und unter Berücksichtigung der
Ladeadresse sich selbst so umpatchen, daß alle Referenzen an die
Zieladresse angepaßt werden. So machen das die DR-DOS Tools KEYB,
NLSFUNC und SHARE, und wie man sieht, funktioniert das sehr
zuverlässig.
Aber da das ganze Prozedere nicht gerade trivial ist, gibt es
leider nur sehr wenige Programme und Treiber, die die HMA
nutzen können, so wenige, daß dort zumindest unter MS-DOS bis
6.22, PC DOS bis 2000, und DR-DOS 7.03 meist noch größere
Bereiche freien Speicherplatzes zum Hochladen von Treibern
verfügbar wären, der sonst nie genutzt werden kann...
Axel und ich hoffen, in Zukunft auch unseren erweiterten Tastatur-
treiber FreeKEYB mit HMA-Load-Funktionen ausstatten zu können,
zumindest haben wir für die auf Byte-Ebene arbeitende Deal Code
Elimination und XMSUMB-Relokation ein Tool geschrieben, das
solche Tabellen von internen Referenzen und Abhängigkeiten mehr
oder weniger automatisch erstellen kann. Allerdings ist das für
einen solchen Treiber noch sehr viel aufwendiger als für einen
klassischen von der Relokation abgesehen statischen Tastaturtreiber
wie DR-DOS KEYB, ganz einfach, weil die dynamische Optimierung
auf die Zielplattform zum Ladezeitpunkt abertausende mögliche
Kombinationen für das effektiv erzeugte Laufzeit-Image des
Treibers ergibt, die alle mit ihren relativen Bezügen aufeinander
berücksichtigt werden müssen (FreeKEYB ist immer noch ein
kombinierter .SYS/.COM-Treiber, d.h. Tiny-Modell). Und auch,
weil FreeKEYB durch seine Zusatz-Features in einer ganze Kaskade
von Interrupts hängt - und das alles mit Stubs durch die HMA
zu leiten, könnte die Systemperformance negativ beeinflussen...
Da muß also noch mehr Gehirnschmalz investiert werden, ehe das
vielleicht einmal funktioniert, wohingegen diverse UMB-Lade-
und Relokations-Methoden inzwischen einwandfrei arbeiten.
Ok, ehe ich jetzt völlig "aus dem Kontext" falle, höre ich
besser auf... ;-)
Viele Grüße,