Suche freien Speicherbereich unterhalb von 1 MB, das nicht von OS überschrieben wird...also stets resident ist
Christian Wallbaum
Mich würde interessieren, ob es irgendwie möglich ist, unterhalb der
magischen 1 MB Grenze irgendwie ein wenig Speicher, sage wir mal so etwa 1-5
KByte, zu reservieren (für eigene Zwecke), ohne, dass dieser Speicher von
einem Memory-Managment bzw. OS überschrieben wird. Klar handlet ein MM den
Speicher und kann ihn auch luchs überschreiben, aber gibt es irgendweine
Konvention, dass dieses verhindert? Problem ist ja, dass es keinerlei
definitiv freien Speicher gibt, meine ich jedenfalls; also fast alles belegt
bzw. vieles wird ja wieder überschrieben. Aber es muss doch irgendwie
möglich sein, denke ich?
Ach ja, ich meine jetzt BEVOR ich ein OS starte.
Ich experimentiere nämlich gerade ein wenig mit einem eigenen MBR.
Ich würde da gerne einige Interrupt-Vektoren verbiegen und etwas mit meinem
eigenen Code dort arbeiten, aber es soll OS unabhängig laufen, also auch
nicht überschrieben werden.
Die einzige Software, bei der ich sowas bisher gesehen habe, ist bei
Diskmanagern, z.B. von Ontrack oder Microhouse, aber dafür gibt es ja
Konventionen, dass z.B. Linux oder Windows bei der Installation (bzw. beim
Booten) einen Install-Check machen und dann ggf. weitere Massnahmen treffen.
Dieses EZ-Drive habe ich mir vor längerer Zeit mal angesehen, und da wird
beim Booten der Int $13 verbogen in Code, von abgefragt wird, ob AH mit
02,03,42,43h aufgerufen wurde und dann blablabla...wenn Windows dabei
gestartet wurde wird er doppelt verbogen etc.
Aber der eigentliche Code liegt bei mir, also von EZ-Drive, bei Adresse
06bd:0148. Aber wie wird dieser Code beim Installieren der Routine bzw.
Verbiegen des Vektors ausfindig gemacht bzw. woher ist man sicher, dass
dieser nicht wieder überschrieben wird? Ich finde auch nichts, dass ein
evtl. Speicherbereich dort frei oder sonstwie belegt sein soll... =(
Oder wird der Speicher nicht zufällig belegt sondern ist diese Adresse fest
implementiert im EZ-Code?
Oder checkt das MM des OS, welche Bereiche beim starten bereits durch
Software bzw. Geräte belegt ist und schliesst diesen dann aus bzw.
verschiebt den entsprechend, aber dass der trotzdem während der gesamten
Uptime des Rechners (oder des OS) resident ist???
Wer weiss at ??? ;)))
Gruss und schonmal danke für Eure Tips und Vorschläge,
Christian
Christian Wallbaum
Ach ja, und unten, wo "at" steht, ja, das sollte eigentlich "Rat" heissen
*g*
Manfred Hauser
> Oder checkt das MM des OS, welche Bereiche beim starten bereits durch
> Software bzw. Geräte belegt ist und schliesst diesen dann aus bzw.
> verschiebt den entsprechend, aber dass der trotzdem während der gesamten
> Uptime des Rechners (oder des OS) resident ist???
also das auf keinen Fall, woher soll denn das arme OS wissen, was vor ihm bereits belegt wurde und was nicht, schließlich ist es ja
genau seine Aufgabe, sowas zu handeln.
AFAIK kann ich nur sagen, daß Du wohl im "BIOS-Bereich" am ehesten fündig werden wirst. So bei Segment 0x40 rum gabs immer mal ein
paar Byte, die unbenutzt waren, aber auf 1-5KByte würde ich da nicht hoffen. Ne Garantie denke ich hast Du auf keinen Fall. Dazu
müßtest Du wohl ne VM realisieren, in der Du dann alle anderen OS laufen läßt, aber das ist wohl weniger in Deinem Sinne.
Aber vielleicht weis ja jemand anderes mehr, so Zeugs hab ich ja (leider) schon Jahre nicht mehr programmiert.
Hoffe das hilft Dir weiter,
Manfred
Christian Wallbaum
> also das auf keinen Fall, woher soll denn das arme OS wissen,
> was vor ihm bereits belegt wurde und was nicht, schließlich ist es ja
> genau seine Aufgabe, sowas zu handeln.
Irgendwie schon klar!
> AFAIK kann ich nur sagen, daß Du wohl im "BIOS-Bereich" am
> ehesten fündig werden wirst. So bei Segment 0x40 rum gabs immer mal ein
> paar Byte, die unbenutzt waren, aber auf 1-5KByte würde ich da nicht
hoffen.
> Ne Garantie denke ich hast Du auf keinen Fall.
Ja, aber eben das reicht nicht ganz =(
Und bezüglich Garantie: das denke ich ja auch.
Aber die Technik, wenns denn eine spezielle sein sollte, von Ontrack, das
würde mich sehr interessieren, also wie die das handeln. Der Code ist ja
auch nicht gerade klein. OK, ich denke mal sind so 4-6 KByte (resident),
aber wie??? *ggg*
> Dazu müßtest Du wohl ne VM realisieren, in der Du dann alle anderen
> OS laufen läßt, aber das ist wohl weniger in Deinem Sinne.
;))))))))))))))
> Aber vielleicht weis ja jemand anderes mehr, so Zeugs hab ich ja (leider)
schon Jahre nicht mehr programmiert.
>
> Hoffe das hilft Dir weiter,
Trotzdem danke!
Gruss,
Christian
Ralf A. Quint
Schon mal was von Rechtschreibprüfung gehört? ;-))))
Hubert Seidel
"Ralf A. Quint" schrieb im Newsbeitrag
news:nondlucdjtlgfkubv...@4ax.com ...
Im letzten Moment das ;-)... gesehen... ansonsten sch... was auf
Rechtschreibfehler und deren Prüfprogramme :-)
Warum kann die deutsche Rechtschreibung nicht so einfach wie X86-Assembler
sein ;-?
mfg. Herby
--
Mailto:Hubert...@T-Online.de
http://meine.seite.bei.t-online.de
Florian Mueller
>[...]
>Die einzige Software, bei der ich sowas bisher gesehen habe, ist bei
>Diskmanagern, z.B. von Ontrack oder Microhouse, aber dafür gibt es ja
>Konventionen, dass z.B. Linux oder Windows bei der Installation (bzw. beim
>Booten) einen Install-Check machen und dann ggf. weitere Massnahmen treffen.
Ich habe dies auch nur bei Ez-Drive beobachtet (Ontrack hatte ich nie
benutzt). Wenn man Ez-Drive auf der Festplatte hat und MS-DOS startet,
sieht man gleich, daß "mem" nur 639KB statt 640KB Hauptspeicher
anzeigt. Ez-Drive hat sich das oberste der 640KB abgezwackt. Die
Speichergröße unterhalb 1MB läßt sich mit dem Interrupt 12h
feststellen. Ich vermute jetzt mal, das sich Ez-Drive in den Interrupt
12h einklinkt und genau ein KB zuwenig an den Funktionsaufrufer
zurückliefert, damit kann sich das Programm getrost bei dem 640.
Kilobyte einnisten. Der Programmteil dürfte eigentlich nicht
überschrieben werden, da ein OS diese Speichergröße eigentlich
abfragen muß.
Gruß Florian
--
--- MoKel CoNNection LAN Parties ---
----- http://www.mokelz.de -----
Friedrich Gräter
> begin electrogrammati illius Hubert Seidel
>
>
>>Warum kann die deutsche Rechtschreibung nicht so einfach wie X86-Assembler
>
>
Da sagt mir mein "Lexikon der Datenverarbeitung" (Siemens, 1969) und
andere Fachbücher (auch aus neuerer Zeit) was anderes...
Aber solange die Rechtschreibung einheitlicher als BASIC ist, ist das
sowieso egal :-)
cu & FUP2P
FG
Steffen Christgau
Ich hab unter Turbo Pascal einen Funktionsplotter aus einem Buch. Da heißt
es: "Zu diesen Adressen muss man sagen, dass sie zu denen im unteren
Speicherbereich gehören, die von mehreren Programmen gleichzeitig verwendet
werden können." Gemeint sind hierbei die Adressen von 0000h:4FAh bis
0000:4FFh.
Vielleicht hilfts. Sind aber nur 16 Byte.
MfG Steffen
--
Webmaster des Ernst-Haeckel-Gymnasiums
Internet: www.ernst-haeckel-gymnasium.de
E-Mail: steffenc...@freenet.de oder
steffen....@ernst-haeckel-gymnasium.de
Steffen Christgau
> Gemeint sind hierbei die Adressen von 0000h:4FAh bis
> 0000:4FFh.
Sorry. Von 0:4F0h bis 0:4FFh
Hubert Seidel
"Steffen Christgau" schrieb im Newsbeitrag
news:3d57a147$0$23721$9b62...@news.freenet.de ...
> > Gemeint sind hierbei die Adressen von 0000h:4FAh bis
> > 0000:4FFh.
> Sorry. Von 0:4F0h bis 0:4FFh
War nicht auch der Bereich 0:0502h bis 0:05FFh für
künftige Erweiterungen (extended? BiosDataArea) reserviert?
Mit etwas Glück wurde dieser Bereich bisher nie verwendet.
Dann hätte man 254 (immerhin fast 256) Bytes.
0:0500h bzw. 0:0501h (einer oder beide) sind für die
Printtaste (Status) belegt. (so aus dem FF)
Aber die Variante sich in Int12h einzuklinken und Speicher
von oben (640KB) abzuzwacken ist natürlich eleganter.
Florian Mueller
>Ich vermute jetzt mal, das sich Ez-Drive in den Interrupt
>12h einklinkt und genau ein KB zuwenig an den Funktionsaufrufer
>zurückliefert, damit kann sich das Programm getrost bei dem 640.
>Kilobyte einnisten.
Hab' ich mir es doch wieder ein bißchen zu umständlich gemacht, man
muß sich natürlich nicht in den Interrupt 12h einklinken, da dieser
Interrupt die Hauptspeichergröße zurückgibt, welche im BIOS
Variablensegment als Wort an der Speicherstelle 0413h steht. D.h. Du
mußt nur den Wert an dieser Speicherstelle ändern.
Ich habe das mal mit MS-DOS getestet, ich habe den Wert einfach mal
ein bißchen verkleinert (natürlich vor dem Start des Betriebssystems).
Ein Aufruf von mem unter MS-DOS hat die maximale Hauptspeichergröße
von 382KB korrekt angezeigt.
Matthias Paul
> Mich würde interessieren, ob es irgendwie möglich ist, unterhalb der
> magischen 1 MB Grenze irgendwie ein wenig Speicher, sage wir mal so
> etwa 1-5 KByte, zu reservieren (für eigene Zwecke), ohne, dass
> dieser Speicher von einem Memory-Managment bzw. OS überschrieben
> wird.
Mir ist keine Methode bekannt, die wirklich betriebssystemunabhängig
arbeitet, deshalb gehe ich im folgenden in erster Linie auf DOS
(DR-DOS sowie MS-DOS/PC DOS) und Windows 95/98/SE/ME ein. Dies kann
zumindest als Beispiel für den Mechanismus gelten, wie er mehr oder
weniger auch bei anderen Systemen ablaufen muß, wenn diese solche vor
dem Betriebssystem geladenen Real Mode-Treiber überhaupt aktiv oder
passiv unterstützen.
Es gibt mehrere grundsätzliche Methoden:
- Du reservierst im oberen Speicher (Segment C000h..F000h) einen
kleinen Bereich, den Du als ROM-BIOS "tarnst". Dazu muß der
Speicherblock in einem bestimmten Format vorliegen, damit
das System-BIOS diesen Block finden kann und ggfs. eine
Initialisierungs-Routine aufruft. Allerdings passiert dies
lange bevor überhaupt ein MBR geladen wird und ist eigentlich
zur Einbindung von Hardware-Erweiterungen vorgesehen. Obwohl
es Fälle gibt, in denen man das auch für Software-Erweiterungen
zweckentfremden kann (mit "Zwischenboot"), dürfte das für
Deine Zwecke ziemlich ungeeignet sein, insofern erwähne ich
es hier nur der Vollständigkeit halber.
Aus RBIL61 FARCALL.LST:
|Format of Option ROM header:
|Offset Size Description (Table F0082)
| 00h WORD AA55h signature
| 02h BYTE length of option ROM in 512-byte pages
| (should be multiple 4)
| 03h 4 BYTEs standard initialization entry point
| (called with ES:DI -> PnP Installation Structure)
| --- PnP only ---
| 07h 19 BYTEs reserved
| 1Ah WORD offset to PnP Expansion Header
- Die zweite Methode basiert auf der Manipulation des INT 12h
bzw. der betreffenden Variablen im BIOS-Datensegment:
Aus RBIL61 INTERRUP.LST:
|--------B-12---------------------------------
|INT 12 - BIOS - GET MEMORY SIZE
|Return: AX = kilobytes of contiguous memory starting at absolute
| address 00000h
|Note: this call returns the contents of the word at 0040h:0013h;
| in PC and XT, this value is set from the switches on
| the motherboard
|SeeAlso: INT 11"BIOS",INT 2F/AX=4A06h,INT 4C"Tandy 2000",
| MEM 0040h:0013h
In jedem Fall ist das nur die halbe Miete, denn damit kann
man zwar ein paar Kb in der Nähe der 640 KB-Grenze für andere
Zwecke abzweigen, aber wenn man diesen Speicherbereich im
weiteren Verlauf des Bootvorgangs wieder anders nutzen will,
muß das dort liegende Programm aktiv in den Bootvorgang und
die Speicherverwaltung des Betriebssystems eingreifen,
um sich an einen anderen Ort zu relozieren. Da aber das
Betriebssystem selbst auch noch nicht vollständig "steht",
ist das nicht gerade trivial und erfordert einiges Detailwissen
über Interna des jeweiligen Betriebssystems.
- Neuere Betriebssysteme bieten in der Regel zusätzliche
Broadcasts und Hooks, durch die solche Treiber den richtigen
Moment abpassen können, die Kontrolle über ihren Speicherblock
an das Betriebssystem abzugeben (also quasi die "Tarnkappe"
fallen zu lassen), bzw. sich in definierter Manier ins System
einklinken zu können.
DOS 5+ unterstützt dafür RPL (Remote Program Loading), das
eigentlich für das Booten von sog. Diskless Workstations über
die Netzadapterkarte (mit eingestecktem Remote Boot PROM)
gedacht ist, aber prinzipiell auch für andere Zwecke benutzt
werden kann:
Aus RBIL61 INTERRUP.LST:
|--------D-2F4A06-----------------------------
|INT 2F CU - DOS 5+ - DOS SUPERVISOR "REBOOT PANEL" - ADJUST MEMORY
| SIZE
| AX = 4A06h
| DX = segment following last byte of conventional memory
|Return: DX = segment following last byte of memory available for use
| by DOS
|Desc: used to override the default memory size when booting
| diskless workstations
|Notes: called by MS-DOS 5+ IO.SYS and DR DOS 6.0+ IBMBIO.COM startup
| code if the signature "RPL" is present three bytes beyond
| the INT 2F handler; this call overrides the value returned
| by INT 12
| hooked by RPL code at the top of memory to protect itself
| from being overwritten; DOS builds a memory block with
| owner = 0008h and name "RPL" which must be freed by the
| RPL code when it is done.
| under DR DOS, it is sufficient to set the owner field of the
| MCB to 0000h.
| in addition to the test for "RPL", DR PalmDOS (since
| 1992-08-25), DR DOS 6.0 "Business update March 1993",
| DR DOS "Panther" and "StarTrek", and Novell DOS 7+ also
| check for a "RPLOADER" signature. If this 2nd signature
| is found, IBMBIO.COM will store the INT 2Fh vector for
| later use after the BIOS init, when, at several points,
| it will directly call the RPLOADER via an emulated
| INT 2Fh with AX=12FFh/BX=0005h/CX=0000h/DX=0001h and
| a phase code 1, 2 or 3 on the stack.
| This permits the RPLOADER to keep track of the
| initialization process and clean or fix up anything it
| likes. The "phase 1" broadcast is issued after the BIOS
| init code and data have been relocated (e.g. into the
| HMA), "phase 2" gets issued immediately before the
| CONFIG.SYS processing starts and the DOS code and data
| are relocated, and the closing "phase 3" happens to
| permit any final tidyups before the memory manager gets
| acknowledged of boot completion.
|SeeAlso: INT 12"BIOS",INT 18"BOOT HOOK",AX=4A07h,
| INT 2F/AX=12FFh/BX=0005h
- Wahrscheinlich könnte man auch die bei quasi alle neueren
Rechnern vorhandene XBDA/EBDA (Extended BIOS Data Area) ver-
größern, um den Code darin unterzubringen, aber mir fällt im
Moment kein Beispielprogramm ein, das das so macht. Außerdem
müßte der Code in jedem Fall damit rechnen, vom Speichermanager
nach Belieben verschoben zu werden.
> Dieses EZ-Drive habe ich mir vor längerer Zeit mal angesehen, und
> da wird beim Booten der Int $13 verbogen in Code, von abgefragt
> wird, ob AH mit 02,03,42,43h aufgerufen wurde und dann
> blablabla...wenn Windows dabei gestartet wurde wird er doppelt
> verbogen etc.
> Aber der eigentliche Code liegt bei mir, also von EZ-
> Drive, bei Adresse 06bd:0148. Aber wie wird dieser Code beim
> Installieren der Routine bzw. Verbiegen des Vektors ausfindig
> gemacht bzw. woher ist man sicher, dass dieser nicht wieder
> überschrieben wird? Ich finde auch nichts, dass ein evtl.
> Speicherbereich dort frei oder sonstwie belegt sein soll... =(
> Oder wird der Speicher nicht zufällig belegt sondern ist diese
> Adresse fest implementiert im EZ-Code?
Glaube ich eher nicht. Ich denke, der Treiber wird die RPL-
oder die INT 12h-Methode verwenden, um sich während der frühen
Initialisierungsphase des Betriebssystems davor zu schützen,
von diesem überschrieben zu werden und sich dann im geeigneten
Moment (z.B. durch Erkennen eines bestimmtes Aufrufmusters von
Interrupts, das auf eine bestimmte Bootphase des DOS-Kerns
hindeutet) an eine bessere Stelle zu relozieren, nachdem DOS
bereits die MCB-Kette aufgebaut hat.
Bei DR-DOS gibt es dafür sogar spezielle Broadcasts zur
Kommunikation der einzelnen Module (IBMBIO.COM, IBMDOS.COM,
EMM386.SYS/.EXE) miteinander, auf die solch ein Treiber
reagieren kann, bei MS-DOS/PC DOS gibt es sowas - von
obigem INT 2Fh/AX=4A06h selbst einmal abgesehen - nicht:
Aus RBIL61 (mit einigen Ergänzungen aus dem derzeit noch
unveröffentlichten RBIL62):
|--------O-2F12FFBX0000-----------------------
|INT 2F U - DR DOS 6.0+ IBMBIO.COM - QUERY SIZE OF THE BDOS
| AX = 12FFh
| BX = 0000h
|Return: AX = 0000h if supported
| DX = size of the BDOS in paragraphs
| Flags trashed
| ES,CL destroyed (DR PalmDOS)
|Note: this API is provided by IBMBIO.COM for the initialization
| phase of drivers loaded via DEVICE=/HIDEVICE=/DEVICEHIGH=
| directives and is only available during these short time
| intervals.
| it is called by DR DOS 6.0 EMM386.SYS and Novell DOS 7+
| EMM386.EXE to query the size of the BDOS kernel (the
| resident code of IBMDOS.COM).
|SeeAlso: AX=12FFh/BX=0001h,AX=12FFh/BX=0002h
|--------O-2F12FFBX0001-----------------------
|INT 2F U - DR DOS 6.0+ IBMBIO.COM - RELOCATE THE BDOS
| AX = 12FFh
| BX = 0001h
| CX = 0000h (DR PalmDOS)
| DX = segment to relocate to (FFFFh for HMA)
|Return: AX = 0000h if supported
| Flags trashed
| BX,CX,DX,DI,SI,DS,ES destroyed (DR PalmDOS)
|Notes: this API is provided by IBMBIO.COM for the initialization
| phase of drivers loaded via DEVICE=/HIDEVICE=/DEVICEHIGH=
| directives and is only available during these short time
| intervals.
| it is initiated by DR DOS 6.0 EMM386.SYS and Novell DOS 7+
| EMM386.EXE to relocate the BDOS kernel (e.g. into the HMA).
| this call is also issued by DR PalmDOS IBMBIO.COM which
| explicitly clears CX.
| under Novell DOS 7+ the actual relocation takes place at a
| later stage, but under DR PalmDOS the BDOS is relocated
| immediately.
|SeeAlso: AX=12FFh/BX=0000h,AX=12FFh/BX=0003h
|--------O-2F12FFBX0002-----------------------
|INT 2F U - DR DOS 6.0+ IBMBIO.COM - QUERY SIZE OF THE BIOS
| AX = 12FFh
| BX = 0002h
|Return: AX = 0000h if supported
| DX = size of the DOS BIOS in paragraphs
| CL and flags trashed
|Note: this API is provided by IBMBIO.COM for the initialization
| phase of drivers loaded via DEVICE=/HIDEVICE=/DEVICEHIGH=
| directives and is only available during these short time
| intervals.
| it is called by DR DOS 6.0 EMM386.SYS and Novell DOS 7
| EMM386.EXE to query the size of the DOS BIOS (the
| resident code of IBMBIO.COM).
|SeeAlso: AX=12FFh/BX=0000h,AX=12FFh/BX=0003h
|--------O-2F12FFBX0003-----------------------
|INT 2F U - DR DOS 6.0+ IBMBIO.COM - RELOCATE THE BIOS
| AX = 12FFh
| BX = 0003h
| CX = 0000h (DR PalmDOS)
| DX = segment to relocate to (FFFFh for HMA)
|Return: AX = 0000h if supported
| Flags trashed
|Notes: this API is provided by IBMBIO.COM for the initialization
| phase of drivers loaded via DEVICE=/HIDEVICE=/DEVICEHIGH=
| directives and is only available during these short time
| intervals.
| it is initiated by DR DOS 6.0 EMM386.SYS and Novell DOS 7
| EMM386.EXE to relocate the resident part of the DOS BIOS.
| The actual relocation takes place at a later stage.
| this call is also issued by DR PalmDOS IBMBIO.COM which
| explicitly clears CX.
|SeeAlso: AX=12FFh/BX=0001h,AX=12FFh/BX=0002h
|--------O-2F12FFBX0005-----------------------
|INT 2F U - DR DOS 6.0+ - BOOT PHASE BROADCASTS FOR MEMORYMAX /
| RPLOADER / SECURITY
| AX = 12FFh
| BX = 0005h
| CX = 0000h
| DX = function
| 0000h MemoryMAX cleanup broadcast
| Note: this is issued by IBMBIO.COM when it has
| finished CONFIG.SYS processing and the
| transient portion of the BIOS has unlinked
| the UMB memory, that is, immediately on
| the return from the phase 3 broadcast to
| RPLOADER, but before the BIOS continues to
| load the command processor. It is inter-
| cepted by the MemoryMAX driver to do any
| tidy-ups necessary.
| (future issues of the BIOS may possibly pass
| a structure on the stack. The first word
| on the stack would then be the length word
| and version indicator, and the SI, DI, and
| BP registers are reserved for future use.)
| all registers must be preserved.
| 0001h RPLOADER broadcast (with phase code on stack)
| Note: this gets issued at three distinct points
| inside IBMBIO.COM via an emulated
| interrupt to the INT 2Fh vector the BIOS
| had previously recorded on RPLOADER
| detection (see INT 2Fh/4A06h), so that the
| resident RPLOADER can relocate, fixup,
| or cleanup anything necessary during the
| boot phase.
| phase 1 gets initiated when the BIOS has
| relocated its code and data (e.g. into
| the HMA), and the internal device drivers
| are initialized, but before it relocates
| the DOS code and data.
| the phase 2 broadcast is issued immediately
| before the BIOS starts the CONFIG.SYS
| processing.
| after the BIOS has executed its cleanup code
| and unlinked from the UMB chain, it will
| enter phase 3 (0003h on stack) before
| issueing the cleanup broadcast to
| MemoryMAX and load the command processor.
| IBMBIO.COM calls this as in the following
| example (in pseudo-code):
|
| mov ax,phase_code ; phase code 1,2,3
| push ax ; on stack
| mov ax,12FFh ; select function
| mov bx,0005h
| mov cx,0000h
| mov dx,0001h
| pushf ; emulate an INT
| cli
| call rpl_int13_vector
| pop ax
|
| all registers (but AX,BX,CX,DX,ES) must be
| preserved for Novell DOS 7+.
|
|Notes: this API is probably supported since DR DOS 6.0+ (BDOS 1067h+)
| but it is not clear if this issue supported both individual
| broadcasts. At least Novell DOS 7 - DR DOS 7.05 are known
| to fully support the API as described here.
| the preloadable SECURITY.BIN driver $SECURE$ monitors this
| broadcast in order to find the optimal moment to invoke
| the NWLOGIN executable. (The optimal moment depends on
| the underlaying OS and version).
|SeeAlso: INT 2Fh/AX=4A06h
Es kann auch durchaus sein, daß Windows 9x-Versionen explizit auf
bestimmte Install-Checks von solchen Festplatten-Treibern eingehen.
Am besten suchst Du mal in RBIL61 nach "SWBIOS", "XBIOS", "Ontrack",
"EZ-Drive", etc.
Z.B.:
|----------13FF-------------------------------
|INT 13 - EZ-Drive - INSTALLATION CHECK
| AH = FFh
| DL = drive number (80h)
|Return: CF clear
| AX = AA55h
| ES:BX -> string "AERMH13Vxx", where xx is the version number
| of the EZ-Drive driver
| CF set on error
|Program: EZ-Drive is a driver by Micro House that is loaded from
| the hard disk MBR, replacing the ROM BIOS disk support,
| eg. ading LBA mode support, and read/write multiple.
|Note: this function is called by the Windows95 Master Boot Record
|SeeAlso: AX=E000h"XBIOS",AH=F9h"SWBIOS"
Wie auch immer, ist die DOS-Speicherverwaltung erst einmal
aufgebaut, d.h. herrschen definierte Verhältnisse, und der
betreffende Treiber hat sich sauber ins Betriebssystem ein-
gebunden, ist die Übermittlung der entsprechenden Informationen
an Betriebssystemaufsätze wie Windows kein grundsätzliches
Problem mehr:
Windows sendet beim Hochfahren einen Startup-Broadcast
(INT 2Fh/AX=1605h), den DOS-Treiber benutzen können, um
entsprechende virtuelle Gerätetreiber bei Windows anzumelden.
Diese Treiber sind üblicherweise schon Teil des jeweils
unter DOS geladenen Treiberimages, stellen allerdings unter
reinem DOS nur "toten Code" dar (außer unter dem preemptiven
Multitasker von DR-DOS).
Über die gleiche Schnittstelle kann ein Treiber, der bekannter-
maßen keine entsprechende Unterstützung für Windows mitbringt,
Windows auch daran hindern, überhaupt weiter zu starten. Dann
erscheint eine Fehlermeldung wie: "Ein DOS-Treiber hat das Laden
von Windows verhindert" und man landet üblicherweise wieder
am DOS-Prompt. Die Benutzung von Windows auf diese Weise
abzufangen ist in jedem Fall sinnvoller, als es wissentlich
im weiteren Verlauf abstürzen zu lassen, etwa weil es mit
einem ungeeigneten Windows-Treiber versuchen würde, auf die
Festplatte zuzugreifen.
In der Praxis gibt es natürlich noch etliche Fälle, wo Windows
solche Konflikte nicht nur "passiv" oder heuristisch anhand
der gesammelte Daten erkennt, sondern Windows überprüft während
der Startphase auch "aktiv" bestimmte Install-Checks. (Ob
EZ-Drive dazu gehört, kann ich nicht mit Sicherheit sagen, es
wäre aber gut möglich.) Mit Hilfe der \WINDOWS\IOS.INI kann
man das Verhalten teilweise auch manuell übersteuern.
An der DOS-Speicherverwaltung (MCB/DMD-Kette(n)) ändert sich
durch den Start von Windows im Prinzip nichts.
Der Windows-Speichermanager kommuniziert über die undokumentierte
GEMMIS (Global EMM Import Specification) Schnittstelle mit
dem EMM386-Speichermanager von DOS und erfährt so, welche
Speicherbereiche wie benutzt werden, so daß er die Kontrolle
übernehmen kann.
Und bei MS-DOS 7.0+ führt der Kernel während der Boot-Phase
zusätzlich Buch über etliche Eigenschaften geladener Real-Mode-
Treiber (z.B. Typ des Treibers, ersetzte BIOS- und Hardware-
Interrupts, ggfs. die Aufrufzeile in CONFIG.SYS usw.) und
sammelt diese Informationen in einer undokumentierten Real-Mode-
Mapper-Datenstruktur (die üblicherweise in der HMA liegt).
Diese Daten erlauben es zumindest theoretisch, bestimmte
möglicherweise inkompatible DOS-Treiber temporär wieder
auszuklinken, außerdem ergeben sich so weitere Einstiegspunkte,
mit denen Teile von DOS umgangen werden könnten.
In der Praxis wird davon allerdings quasi kein Gebrauch gemacht,
da sowas natürlich auch wieder neue Konsistenzprobleme aufwirft.
Ein paar verstreute oberflächliche Dokumentationsschnipsel
für unbedeutende Teile dieser RMM-Datenstruktur existieren
tatsächlich, aber die sind eher dazu geeignet, einen falschen
Eindruck zu erzeugen, als darzulegen, wofür das Ganze überhaupt
gut ist bzw. sein könnte - die eigentlich interessanten Infos
werden leider totgeschwiegen und man muß sie sich bei Bedarf
erst mühsam selbst erschließen. Einen groben Überblick
über einen Teil der erhobenen Daten bietet zumindest die
\WINDOWS\IOS.LOG Protokolldatei.
Wie auch immer, all diese Informationen nutzt Windows, um zu
entscheiden, ob eine Komponente über einen Protected Mode-
Windows-Treiber angesprochen werden kann (sofern vorhanden)
oder ob Windows für den Zugriff (z.B. auf die Festplatte)
auf den vorher geladenen Real Mode-DOS-Treiber zurückgreifen
muß. Sollte nun für eine solche BIOS-Erweiterung wie EZ-Drive
kein entsprechender Protected Mode-Treiber vorliegen (entweder
aus dem Lieferumfang von Windows selbst oder bei der
Installation von EZ-Drive eingerichtet) und der residente
EZ-Drive-Treiber auch keinen virtuellen Gerätetreiber
angemeldet haben (das macht auch nicht immer Sinn, je
nachdem, um was es geht), schaltet Windows einfach in den
"Kompatibilitätsmodus" und benutzt den Real Mode-DOS-Treiber
weiter. In der Regel ist der einzige Nachteil ein kleiner
Performance-Verlust, der einerseits dadurch entsteht, daß
Real Mode-Treiber üblicherweise auf minimale Codegröße,
weniger auf maximale Geschwindigkeit getrimmt wurden,
andererseits dadurch, daß während der Dauer dieses
Zugriffs kein oder zumindest nur eingeschränktes
Multitasking stattfinden kann, da der MS-DOS-Kern selbst
und das Treibermodell von DOS dafür nicht ausgelegt wurden.
Da in den seltensten Fällen konkurrierender Hardware-Zugriff
erlaubt ist, geschieht das effektiv gesehen natürlich auch
bei der Benutzung von Windows-Treibern, aber dort können
zumindest höhere Treiberschichten noch Multithreading/
Multitasking zulassen, wohingegen DOS, seine Treiber
und das Real-Mode-BIOS wie eine "Blackbox" als mehr oder
weniger monolithischer Block durchtunnelt werden. D.h.
die Zeitspanne, in der kein Umschalten auf andere Tasks/
Threads erlaubt ist, ist einfach etwas länger und es
ergeben sich weniger Angriffspunkte für Optimierungen.
Das macht das Multitasking etwas zäher als bei einem
System, das von Grund auf für Multithreading/Multitasking
ausgelegt ist.
> Oder checkt das MM des OS, welche Bereiche beim starten bereits
> durch Software bzw. Geräte belegt ist und schliesst diesen dann aus
Ja, z.B. indem der Speichermanager den Bereich zwischen den Adaptern
nach Signaturen von Options-ROMs (s.o.) durchsucht und diese Bereiche
von der Speicherverwaltung ausschließt. Außerdem kommen je nach
Speichermanager auch noch diverse andere (sowohl festverdrahtete,
als auch automatische) Methoden zum Einsatz, um z.B. Adapterkarten
mit Memory Mapped I/O etc. zu finden. Das reicht von echtem
Hardware-Probing bis hin zur Abfrage von Adapterkarten-IDs
(MCA/EISA) und Plug & Play-Daten. Konkret sieht das so aus,
daß solchen Bereichen ein MCB/DMD-Header vorangestellt wird,
der anzeigt, daß der folgende Bereich ausgeschlossen wurde
oder schon belegt ist (zum Aufbau der MCB/DMD-Kette bei DOS
siehe INT 21h/AH=52h in RBIL61).
Wie gesagt, das gilt so für DOS und DOS-ähnliche Betriebssysteme
inklusive Windows 95/98/SE/ME und kann sehr einfach auf andere
Real Mode- oder Mixed-Mode-Betriebssysteme übertragen werden.
Reinen Protected Mode-Betriebssystemen wie Linux, OS/2 oder
Windows NT/2K/XP nützt ein Real Mode-Treiber nichts, da diese
Systeme nicht über das Real Mode-BIOS (CBIOS), sondern entweder
über das ABIOS (OS/2 bei PS/2-Rechnern) oder mit eigenen Treiber
direkt auf die Hardware zugreifen.
Ein in der Real Mode-Bootphase geladener Treiber kann dann
höchstens dafür sorgen, daß das Betriebssystem anhand eines
Install-Checks o.ä. mitbekommt, daß ein entsprechender Spezial-
treiber benötigt wird, der dann ggfs. geladen wird.
Ich muß zugeben, daß ich da, was das konkrete Prozedere angeht,
im Moment überfragt bin und selbst erst wieder in den Linux-
Sourcen nachschauen müßte, ob und, falls ja, wie dort ggfs.
direkt auf DiskManager, EZ-Drive und Konsorten eingegangen
wird. Ich denke aber, daß es da keine betriebssystemüber-
greifende Lösung gibt.
D.h. entweder, es gibt separate betriebssystemspezifische
Treiber, oder das anfangs geladene Treiber-Image enthält
bereits Moldue zur Behandlung diverser grundverschiedener
Betriebssysteme, was in der Praxis entweder ziemlich
ineffizient oder äußerst komplex sein dürfte, in jedem
Fall aber auch nur eine begrenzte Zahl unterschiedlicher
Systeme abdecken könnte.
Im Zweifel sind die Komponenten einfach nicht miteinander
kompatibel, so wie es meines Wissens bei älteren Versionen
von DiskManager oder EZ-Drive mit NT oder Linux auch
tatsächlich der Fall war... Vielleicht weiß das ja jemand
anderes? Das würde mich durchaus auch selbst interessieren...
Ich hoffe, daß ich wenigstens den DOS/Windows-Teil einiger-
maßen verständlich vermitteln konnte und Dir das schon
etwas weiterhilft.
Viele 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
"Programs are poems for computers."
Florian Mueller
>[...]
>Aber die Variante sich in Int12h einzuklinken und Speicher
>von oben (640KB) abzuzwacken ist natürlich eleganter.
Was mir heute zufällig aufgefallen ist, daß das Phoenix BIOS meines
Dell Computers selbst schon 2KB vor dem Systemstart abzwackt. Ich
frage mich nur wofür, in diesem Speicherbereich stehen nach dem
Systemstart nämlich fast nur Nullen drin. Hat jemand von euch das auch
schon bei einem (modernen) Phoenix-, Award- oder Ami-Bios beobachtet,
das würde mich jetzt nämlich mal brennend interessieren.
Florian Mueller
>[...]
>Was mir heute zufällig aufgefallen ist, daß das Phoenix BIOS meines
>Dell Computers selbst schon 2KB vor dem Systemstart abzwackt.
Hat sich schon erledigt, ich habe google zuvor nicht gründlich genug
befragt. Es liegt an meinem Phoenix BIOS. Also scheint das mit dem
Speicher abzwacken in der BIOS-Variable 413h doch richtig zu
funktionieren.
Christian Wallbaum
ersteinmal rechtherzlichen Dank für Eure Beiträge.
Der Lösungsansatz von Florian mit dem Int $12 etc. gefällt und interessiert
mich doch sehr, daher werde ich mich morgen mal dran machen. Auch Matthias'
Beitrag gefällt mir, was mir bei meinem Problem zwar eher weniger hilft,
mich aber dennoch sehr interessiert und mir Denkanstösse für einige meiner
anderen Projekte gibt, also Lob und Danke für diesen ausführlichen und
informativen Beitrag!
Aber auch ein riesiges Dankeschön an alle anderen!!!!!
Gruss,
Christian
Florian Mueller
>[...]
>ersteinmal rechtherzlichen Dank für Eure Beiträge.
Bitteschön, dafür ist die NG ja da. Ich glaube das scheint 'ne
ziemlich sichere Methode zu sein, da sogar mein BIOS das so macht und
irgendetwas oberhalb von 638KB im Speicher ablegt.
Matthias Paul
> Ich glaube das scheint 'ne ziemlich sichere Methode zu sein,
> da sogar mein BIOS das so macht und irgendetwas oberhalb von
> 638KB im Speicher ablegt.
Vielleicht die XBDA/EBDA? Obwohl MEM normalerweise in der Lage
sein sollte, die als solche zu identifizieren. Was steht denn
an 0040h:000Eh für ein Segment-Wert?
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
---
Help the victims of the disastrous Danube, Moldau, and Elbe floodings
of the century in the Czech Republic, Austria, and Germany: www.ct1.cz;
www.orf.at; www.tagesschau.de; www.drk.de for latest news & donations.
Florian Mueller
>Vielleicht die XBDA/EBDA? Obwohl MEM normalerweise in der Lage
>sein sollte, die als solche zu identifizieren. Was steht denn
>an 0040h:000Eh für ein Segment-Wert?
Hab's schon, da haben Intel und Phoenix wieder irgendein Süppchen
zusammen gekocht, da liegt die FDPT Extension usw.
Roland Illig
> * "Christian Wallbaum" <christian...@web.de> wrote:
>
>>[...]
>>ersteinmal rechtherzlichen Dank für Eure Beiträge.
>
> Bitteschön, dafür ist die NG ja da. Ich glaube das scheint 'ne
> ziemlich sichere Methode zu sein, da sogar mein BIOS das so macht und
> irgendetwas oberhalb von 638KB im Speicher ablegt.
Nicht nur das BIOS, auch fast alle Bootsektorviren. Und die Methode ist
wirklich sehr sicher. Oder hast du schon mal einen Virus gesehen, der aus
Versehen ein System abstürzen ließ? ;-)
Roland
Florian Mueller
>[...]
>Nicht nur das BIOS, auch fast alle Bootsektorviren. Und die Methode ist
>wirklich sehr sicher. Oder hast du schon mal einen Virus gesehen, der aus
>Versehen ein System abstürzen ließ? ;-)
Denke ich auch so. Aber wenigstens mein BIOS hätte sparsamer damit
umgehen können, indem es diese Daten irgendwo in seinem
Variablensegment hält. In manchen BIOS-Vesionen gibt es ja auch eine
schöne Option den Speicher unterhalb von 1MB auf 512KB statt 640KB zu
beschränken, angeblich aus Kompatibilitätsgründen zu älterer Software.
Hubert Seidel
"Roland Illig" schrieb im Newsbeitrag
news:anqli1$gd2jb$1...@ID-16779.news.dfncis.de ...
> Nicht nur das BIOS, auch fast alle Bootsektorviren. Und die Methode ist
> wirklich sehr sicher. Oder hast du schon mal einen Virus gesehen, der aus
> Versehen ein System abstürzen ließ? ;-)
Ob ausversehen oder extra... wer erkennt bei einem Virus den Unterschied?