Ein paar Beispielprogramme in x86 Assembler für DOS - letzter Teil: HDDIU Hard Disk Drive Imaging Utility

  • Es wird, noch ein paar Tests und ich kann's veröffentlichen - allerdings ist es jetzt doch ein Misch-Masch aus "Turbo C" und aus INT 13h BIOS Aufrufen geworden.

    Das mit Assembler alleine zu programmieren wird sehr umfangreich und daher auch sehr zeitintensiv, da ist 'C' die bessere Wahl.

    Es basiert aber auf den Erkenntnissen des 5.ten Beispielprogramms hier im Forum.

    Einer der Ziele war, es MUSS auf einem IBM PC/XT lauffähig sein, ein anderes dass man auch Teile der Image-Datei auf ZIP 100 (oder andere Wechselträger) speichern kann.

    Dazu kann man zuerst die als Image zu sichernde Festplatte auswählen, dann kann man auch weniger Sektoren angeben (zum Test) und man kann die Größe der Zieldatei (pro Teil) angeben.

    Letztendlich kann man auch noch den Dateinamen selbst (ohne File-Extension) wählen.

    Das habe ich auch schon ausprobiert, das Programm erzeugt Dateien, die man dann auch mit WinImage laden kann.

    Wenn man die so erzeugte Image-Datei als RAW-Datei für ein Virtualisierungsprogramm nutzen will, geht auch (bspw. in PCEm).

    Es wird unabhängig von der Partitionierung der Platte alles gesichert, so dass bspw. Platten mit einer XENIX oder OS/2 Installation auch kein Problem darstellen.

    Ich habe noch nicht alle Fehleingaben seitens des Benutzers abgefangen, da habe ich noch ein paar Minuten dran zu basteln.

    Ich hoffe aber, dass das mal ein sinnvolles Programm ist, was hier alle auch im echten Sammler-Leben nutzen können - also ist es eigentlich keine Demo, sondern viel mehr.


    Hier im Beispiel ist die erste Festplatte vom Typ 2 (20MB), und die zweite Festplatte vom Typ 17 (40MB). Damit wird man eine ZIP100-Diskette natürlich nicht füllen können, aber es wird ja auch noch größere Festplatten geben. Übrigens wird das Programm auf moderneren Rechnern mit Festplattengrößen größer 4GB nicht korrekt laufen, weil nur 32bit Integer im Programm genutzt werden. Wie ich das abfange, weiss ich noch nicht, ggfls. reicht ja einfach ein Hinweis vorab.

    Ist mehr als eine Datei erzeugt worden, können diese in korrekter Reihenfolge einfach auf dem Zielrechner mit copy /b part1 part2 part3 result zu einer einzigen Datei wieder zusammengesetzt werden.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Einmal editiert, zuletzt von Peter z80.eu ()

  • So, soweit inkl. Fehlerbehandlung läuft alles, daher mein Release für die Version 1.0 des Programms hier.

    Solange man Quelle und Ziel nicht gleich wählt, passiert auch definitiv nichts schlimmes.

    D.h. wer 2 Festplatten bspw. im System hat, sollte bei "Nummer der Festplatte" für das Sichern der ersten Platte auf die zweite Platte die Festplatte #1 für die Quelle auswählen, und bei der Angabe der Zieldatei muss er D:FILENAME eingeben (FILENAME ist hier ein Platzhalter).


    Theoretisch geht auch das Speichern auf der gleichen Platte wie die, von der man liest, weil das Sektoren-Lesen unabhängig von dem Schreiben der Zieldatei ist. Allerdings ist der Ergebnis mit Sicherheit nicht konsistent, weil die Zieldatei dann u.U. nur teilweise dem Inhalt der Platte entspricht (eben zum Zeitpunkt des Sektorenlesens, egal wieviel von der Zieldatei geschrieben wurde).


    Ich habe das auch "in echt" bereits mit einer ZIP100 auf einem PC/XT ausprobiert, dort muss man aber bei der Zieldateigröße *WENIGER* als 100 (MByte) eingeben, weil die ZIP100 eben nur ca. echte 90MByte fasst, also passt da bspw. 90 als Zielgröße in MByte.


    Wenn man die erzeugten Dateien dann auf einer viel größeren Platte (auf dem modernen Rechner) wieder zusammenfügen will, muss in der richtigen Reihenfolge der COPY /B Befehl in der Kommandozeile genutzt werden.

    Wenn also bspw. D:TEST als Dateiname eingegeben wurde, werden TEST.001, TEST.002 usw usw erzeugt.

    Beim Wechsel der Zieldatei kommt eine Aufforderung dazu.

    Verpasst man das Wechseln und es kommt zu einem Fehler beim Dateierstellen, bricht der komplette Prozess ab.

    Da könnte man noch eine Schleife einbauen, dass man solange probieren kann, bis man meint, das richtige Wechselmedium eingelegt zu haben.


    Ausführbare Datei natürlich mit Quelldatei in Turbo C anbei in der ZIP.


    P.S.: Die Fehlerbehandlung beim Lesen eines Sektors der zu sichernden Festplatte sieht momentan so aus:

    Tritt ein Fehler auf, bietet das Programm drei mögliche Reaktionen - Retry, Ignore oder Quit (mit R, I oder Q auswählbar).

    Wenn man Retry wählt, wird der Sektor erneut gelesen (aber wenn ohne Erfolg, weiterhin nicht in die Zieldatei geschrieben).

    Wenn man Ignore wählt, wird ein leerer, genullter Sektor geschrieben und mit dem nächsten Sektor weitergemacht.

    Wer Quit wählt, bricht das Programm ab (Zieldatei wird geschlossen).

    Dateien

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Einmal editiert, zuletzt von Peter z80.eu ()

  • Ok, werde einfach eine 4. Wahlmöglichkeit einbauen, also bspw. 'A' für 'All subsequent errors ignoring' oder ähnlich.


    Nochmal Edit: Ich sehe gerade, beim Auslesen der Parameter der 2. oder weiteren HDD ist wohl mind. ein Anzeigefehler vorhanden, muss dann auch noch korrigiert werden. Denn die 2.Platte, ca. 40MB groß, hat keine 81 Sektoren, sondern nur 17 (siehe erster und zweiter Screenshot).

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

    Einmal editiert, zuletzt von Peter z80.eu ()

  • Ok. Ignoriert die Version 1.0 weiter oben, beim Auswerten der Sektorenzahl war eine falsche Bitmaske (Anzahl Sektoren sollten nur 1-63 möglich sein).

    Das ist in der V1.01 behoben, die Parameter werden jetzt immer korrekt ausgelesen, es sei denn die Platte ist größer als 2GB bzw. 4GB (die alte BIOS Grenze).

    Ggfls. muss bei Platten zwischen 2GB und 4GB aus dem "long" ein "unsigned long" noch gemacht werden, hab' das nicht testen können.

    Außerdem habe ich eine Option zur Auswahl von "Fehler immer ignorieren" hinzugefügt, die wird angezeigt, sobald der erste Fehler auftritt.

    Last but not least habe ich auch noch ein kleines Read Me hinzugefügt.


    Wer eine teilweise kaputte Platte hat, sollte das Fehlerhandling auch ausprobieren können - habe ich nicht. Feedback dazu aber willkommen.

  • Update auf V1.3 in meinem Blog, Kompression (via zlib) für die gespeicherten Teile des Images jetzt eingebaut.

    Eine Version von "unpack" werde ich auch als Konsolenanwendung für Windows noch nachreichen.

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • Hier die "unpack" Konsolen-Anwendung für Windows, inklusive der zlib 1.2.11 DLL. Damit kann man die vorher erstellten, komprimierten Image-Teilsicherungen nun auch direkt unter Windows wieder zu unkomprimierten Image-Teilsicherungen umwandeln, und die mit dem besagten COPY /B Befehl dann zusammenkleben.


    Bin irgendwie zu blöde, Visual Studio 2019 beizubringen, die statische Bibliothek stattdessen dazu zu linken, aber mit vorhandener zlibwapi.dll geht's schon mal. Suche dazu noch einen wesentlich einfacheren Windows Compiler für Konsolenanwendungen, wo ich das mit der zlib einbinden kann.