Das deutsche QBasic- und FreeBASIC-Forum

[Question]

Hallo alle zusammen,

etwas Off-Topic, aber ich nehme mir mal die Freiheit, kurz etwas von mir zu sagen, schließlich ist es mein erstes Posting.
Ich höre auf den Namen Thomas, zu „Question“ kam ich, weil ich immer irgendwelche Fragen habe, bin 37, nach einer Operation verrentet und durch meine Medikamente leider nicht immer ansprechbar. Trotzdem versuche ich mich immer wieder mal an meinem "alten" Hobbie, Programmieren (QBasic4.5, Batch, JavaScript, HTML, VB6.0).

Ab und zu brauche ich mal eine saubere DOS-Umgebung, nicht alles lässt sich in einer DOS-Box realisieren.
Ich erstellte eine bootfähige CD: Eine Diskette mit MS-DOS 6.2 bildet die Grundlage. Der "echte CD-Teil" enthält Archive, die ich mir für DOS zusammengestellt habe.

Kurze Zusammenfassung:
System bootet von MS-DOS 6.20, läd zwei RAM-Disks, entpackt die auf der CD enthaltenen Archive auf sie und "entlässt" mich ins DOS. Meine Daten sichere ich auf Diskette (unter DOS reicht mir das).
Die CD funktioniert nur auf meinem Computer.
DOS erkennt die Windows-formatierten Platten natürlich nicht, vergibt an die RAM-Disks also die Buchstaben C und D. Okay soweit. Die CD-Treiber beginnen demnach bei E, das Diskettenlaufwerk erhält den LW-Buchstaben B, denn A ist ja für den Boot-Teil der CD reserviert.

Jetzt zu meinem "Problem":
Damit der Boot-Vorgang auch auf einem Rechner klappt, der anders konfiguriert ist, der vielleicht noch eine Platte hat, die von MS-DOS erkannt wird, müsste ich bereits beim Abarbeiten der AUTOEXEC Kenntnis von den verfügbaren Laufwerken haben (weil die RAM-Disk dann statt C vielleicht E zugewiesen bekommt und die CD-ROM-Laufwerksbuchstaben ebenfalls nach hinten "rutschen"). Schließlich sollen die Archive auf die "richtige" RAM-Disk kommen und auch der Path sollte später ordentlich funktionieren.

Bisher "identifiziere" ich die Laufwerke mit einem QB4.5-Programm, welches über den Shell-Befehl einen
COMMAND /F /C VOL Laufwerk:
(von C bis Z) abfragt. Anschließend lese ich den Bildschirm aus und suche nach "MS-RAMDRIVE" bzw. dem Volumen-Namen der CD.
Findet das Programm ein (oder zwei) Ram-Laufwerk(e), erstellt es auf dem ersten eine Batch-Datei, die SET-Befehle enthält (Z.B. SET RAM1=C und so fort).
Schließlich führt das Programm einen letzten Shell-Befehl aus, um auf die erste RAM-Disk zu wechseln, damit die AUTOEXEC mit der RAM-Disk als aktuelles Laufwerk eine Umgebung hat, die Schreibzugriffe erlaubt.

Das funktioniert zwar soweit, aber ich halte es nicht für "perfekt".

Nun kenne ich mich in Interrupt-Programmierung nicht aus, weiß nicht, ob damit auch RAM-Disks erkannt werden, und so kam ich auf eine andere Idee.
MS-DOS läd alle Treiber in seinen 1MB großen Speicher, der sich aus Basic heraus leicht mit DEF SEG=segment und PEEK(offset) auslesen lässt.
Irgendwo im Speicher müssten also die Informationen über RAMDRIVE.SYS und MSCDEX.EXE zu finden sein, oder?
Gibt es nicht sogar eine "Laufwerkstabelle", die ausgewertet werden könnte?

Ich habe zwar mal einige Blicke in einen RAM-Dump geworfen, aber klarschriftliche Einträge fand ich keine, also vermute ich, dass diese Infos kodiert im Speicher liegen.
Kennt sich irgendjemand damit aus (oder weiß, nach was ich googlen könnte)?

Frage 1 lautet also: Wie finde ich im Speicher von DOS die Einträge über RAM-Disks und CD-Treiber, und wie kann ich sie auswerten?

Eine zweite Frage habe ich auch:
Lässt sich mit QB4.5 eine Umgebungsvariable setzen? SHELL "SET VARIABLE=IRGENDWAS" funktioniert ja nicht, denn der Shell-Befehl läd eine neue Instanz von COMMAND.COM, so dass die Variable beim Beenden dieser Instanz verloren ist. Es wäre aber "nett", wenn ein Programm Variablen setzt, die von der aufrufenden Batchdatei verarbeitet werden können. Der Umweg, eine Datei anzulegen, funktioniert ja auch erst, wenn das Programm "weiß", wo ein RAM-Laufwerk ist... und wie teilt man dann der Batch-Datei mit, auf welchem Laufwerk diese Datei ist...

So, jetzt habe ich euch genug gequält.

Vielen Dank fürs Lesen,
einen schönen Tag wünscht

Thomas

[dreael]

Zum Thema Umgebungsvariablen: Schau Dir

http://www.dreael.ch/Deutsch/BASIC-Knowhow-Ecke/EinbettungBSY.html

und studiere speziell den letzen Artikelteil. Du musst das Prinzip von Vater-Sohnprozess genau verstanden haben!

Zum Thema Interrupts:

http://www.dreael.ch/Deutsch/BASIC-Knowhow-Ecke/DOS-Interrupts.html
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[Question]

Danke erstmal.

Ja, das Problem ist mir klar, insbesondere in meinem Fall.
Start von einem schreibgeschützten Datenträger, Schreibzugriffe sind nur auf die RAMDISK möglich, deren Laufwerksbuchstabe nicht bekannt ist.
Starte ich aus dem Batchfile ein (kompiliertes) Basic-Programm, wird in jedem Fall ein Sohnprozess von command.com gestartet. Es ist also wurscht, ob ich via »SHELL "SET VARIABLE=WERT"« aufrufe oder per »ENVIRON "VARIABLE=WERT"« eine Zuweisung veranlasse, das Batchfile bekommt von alledem nichts mit.
Meine Frage bezog sich auch eher darauf, ob es eine "Hintertür" gibt, einen "Trick", mit dem eine Variable auf den Elternprozess "zurückfällt"?
Oder womöglich eine Veränderung im Speicher "gewaltsam" durchführen, um einen vom Elternprozess belegten Speicherinhalt einer bereits definierten Variable zu lokalisieren und zu modifizieren?

Wie ich schon schrieb, habe ich mit Interrupts bisher keine Programmiererfahrung. Ich versuche mich durch Günter Borns DOS-Programmierungshandbuch (borncity.de) durchzuwurschteln, aber mir fehlt es da an Ausdauer (liegt auch an den Medikamenten) und Hintergrunderfahrung. Heißt: Das wird bei mir etwas länger dauern

Vielleicht fällt ja jemandem noch etwas zum Eingangsthread ein?

Danke und schöne gute Nacht!

Thomas

[Sebastian]

Hallo.

Ich habe mir den Thread nicht gründlich durchgelesen, aber wie wäre es damit, eine Variable über %errorlevel% zurückzuliefern? Das darf eine Zahl zwischen 0 und 255 sein, wenn ich mich nicht irre. Ideal also, um den ASCII Code eines Laufwerksbuchstabens zu übergeben.

Viele Grüße!
Sebastian
_________________

Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!