Forum: PC Hard- und Software OS: Firmware Update auf CF-Card


von Johannes (Gast)


Lesenswert?

Hi,

hab noch eine Frage zu Windows Xp Embedded: in dem von mir 
programmierten Kiosk-System fehlt bis jetzt noch die Update-Funktion für 
neue Firmware.

Angedacht ist, dass so ein Update via USB-Stick oder via Ethernet von 
einem FTP Server bezogen werden können sollte. Als Programmiersprache 
setze ich C++ (zusammen mit der MFC-Lib) ein. Gibt es in der MFC oder in 
Win Xpe bereits eine entsprechende Klasse / Programm (und wenn ja, taugt 
die auch was)?

Kennt jmd ein Beispiel-Projekt oder ähnliches, in dem man sich 
Anregungen/Tipps für eine Realisierung holen kann (muss kein Source-Code 
sein, sondern sollte eher Probleme  Schwierigkeiten  Tipps etc. 
aufzeigen zu diesem Thema)?

Vor allem wie das ganze auf einer CF-Card abgespeichert wird, würde mich 
interessieren. Zum einen ist auf dieser Card ja das OS, der Bootloader 
(welcher direkt nach dem Start des OSs geladen werden soll) und das 
eigentliche Programm (durch den Bootloader gestartet).

Suche ich einfach auf der CF-Card nach der Programm-Exe und ersetze 
diese durch die neue? Und gibt es hier z.B. auch Schutzmaßnahmen wie man 
eine kurrupte Datei erkennt (falls beim Ersetzen der Exe ein Fehler 
passiert - z.B. User trennt das Gerät vom Strom); so dass dieses Datei 
beim nächsten Start nicht automatisch geladen wird vom Bootloader?

Gruß
Johannes

: Verschoben durch User
von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

In Deiner Beschreibung ist die Funktion des Bootloaders etwas wirr (das 
ist das Ding, das das OS startet, nicht etwas, was vom OS gestartet 
wird), aber deine Annahmen, wie man ein unter XPe laufendes 
Windows-Programm aktualisieren kann (durch Austauschen der Exe-Datei) 
sind korrekt.

Das Verzeichnis, in dem diese Datei liegt, darf natürlich dann nicht vom 
FBWF geschützt sein (sonst ließe sich die Datei nicht überschreiben).

Die Exe-Datei darf aber beim Austauschen nicht in Verwendung sein, was 
sich aber lösen lässt. Das OS (bzw. das, was Du mit "Bootloader" 
vermutlich meinst) kopiert beim Starten die auszuführende Datei vom 
Verzeichnis X in das Verzeichnis Y und ruft sie aus dem Verzeichnis Y 
auf. So kann die Datei im Verzeichnis X zur Laufzeit durch eine andere 
ersetzt werden, die dann beim nächsten Systemstart automatisch 
ausgeführt wird.

Um nicht bei jedem Systemstart (unnötig) zu kopieren, kann auch als 
erster Schritt ein Vergleich der Dateien in den Verzeichnissen X und Y 
erfolgen und nur bei Unterschieden das Kopieren angestoßen werden. An 
dieser Stelle lässt sich auch ein Überprüfungsmechanismus einbauen; im 
Verzeichnis X liegt zusätzlich zur eigentlichen Exe-Datei noch eine 
Prüfsummendatei, die beim Update durch den Anwender ebenfalls dorthin 
kopiert wird.

Der Kopiervorgang wird nur durchgeführt, wenn die Prüfsumme der Datei 
der in der Prüfsummendatei entspricht.

von Johannes (Gast)


Lesenswert?

Rufus t. Firefly schrieb:
> In Deiner Beschreibung ist die Funktion des Bootloaders etwas wirr (das
>
> ist das Ding, das das OS startet, nicht etwas, was vom OS gestartet
>
> wird), aber deine Annahmen, wie man ein unter XPe laufendes
>
> Windows-Programm aktualisieren kann (durch Austauschen der Exe-Datei)
>
> sind korrekt.

sorry, wenn ich mich etwas kompliziert ausgedrückt habe :-); vielleicht 
liege ich in meiner Annahme falsch, aber brauche ich nicht ein Programm, 
welches direkt nach dem Start des Betriebssystems gestartet wird - quasi 
eine art Shell (bei einem ARM Prozessor auch Bootloader genannt), dass 
die Funktion z.B. besitzt das "eigentliche" Programm zu starten, 
upzudaten oder auch zu killen (wie eine Art Taskmanager)?

OS-startet --> Prog1 wird aufgerufen -> Prog2 (eigentliche Applikation) 
wird aufgerufen?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Gewiss, Du musst irgendeinen Mechanismus nutzen, damit das 
Betriebssystem noch was anderes tut als darauf zu warten, daß Du ihm 
sagst, was es zu tun hat.

Aber der Begriff "Bootloader" hat eine eindeutige und komplett andere 
Bedeutung - das ist ein Stückchen Firmware, ähnlich dem BIOS im PC, das 
in Embedded-Systemen nach dem Reset über eine Schnittstelle einen 
Programmdownload ermöglicht. Das ist z.B. die BSL-Schnittstelle im 
MSP430, oder SAM-BA bei ARMen von Atmel.

Ein "normales" Windows startet als letztes entweder den Login-Prozess, 
der darauf wartet, daß sich ein Benutzer interaktiv anmeldet, oder (bei 
automatischer Anmeldung) den Explorer als "Shell", der in diesem Fall 
das Startmenü und die Taskleiste darstellt, sowie den restlichen 
Desktop.

Das lässt sich ersetzen, in der Registry gibt es (irgendwo unter 
SessionManager) einen Eintrag, welcher Prozess nach erfolgter 
Benutzeranmeldung auszuführen ist.

(Details kann ich Dir im Moment nicht beschreiben, da hier gerade kein 
Windows-Rechner ist).

Das funktioniert bei XPe genauso, je nach Umfang der zum Image gepackten 
Komponenten.

Und das ist die Stelle, an der Du Deinen "Programmstarter" einbauen 
kannst, der sich dann so verhalten kann, wie von mir weiter oben 
beschrieben.

von Johannes (Gast)


Lesenswert?

hast du schon mal den "Device Update Agent" verwendet um ein Update von 
einem Webserver  / FTP-Server durchzuführen? Ist dieses Skript 
empfehlenswert oder sollte man seine eigene Solution basteln?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Nein, das war bei der Anwendung, für die ich XPe verwendet habe, kein 
Thema. Das waren Stand-alone-Systeme ohne Internetanbindung, und für ein 
Softwareupdate wurden manuell neue Dateien auf die enthaltenen CF-Karten 
kopiert.

Ist auch schon ein paar Jahre her.

von Johannes (Gast)


Lesenswert?

Folgendes Szenario: User lädt .exe von einem FTP-Server runter und 
kopiert diese auf einen USB-Stick.

Wie kann man z.B. jetzt feststellen, ob diese Exe auch wirklich das 
Programm darstellt, welches die Application beinhaltet, könnte ja auch 
eine ganz andere Anwendung verbergen?

von Frank K. (fchk)


Lesenswert?

Johannes schrieb:

> Suche ich einfach auf der CF-Card nach der Programm-Exe und ersetze
> diese durch die neue? Und gibt es hier z.B. auch Schutzmaßnahmen wie man
> eine kurrupte Datei erkennt (falls beim Ersetzen der Exe ein Fehler
> passiert - z.B. User trennt das Gerät vom Strom); so dass dieses Datei
> beim nächsten Start nicht automatisch geladen wird vom Bootloader?

Was willst Du updaten können - nur die Applikation oder auch das 
Betriebssystem selber? Was machst Du, wenn die Festplatte in Deiner 
Maschine hinüber ist?

Die radikale Lösung lautet Imaging. Du hast ein Mustersystem. Davon 
ziehst Du ein Festplattenimage. Leere Blöcke (nur mit 0 gefüllt) kannst 
Du dabei überspringen. (vorher Platte mit sdelete -c c: säubern, sdelete 
ist Teil der Sysinternals Suite). Dann bootfähige Cd oder Image machen 
mit einem FreeDOS, einem DOS-Imagetool und Deiner Imagedatei. User zieht 
sich das Image, packt es auf ein bootfähiges Medium und bootet den Kiosk 
von diesem Medium. Den Rest macht dann Dein Imagetool.

Bei Einzeldateien:
Pfad und CRC der zu ersetzenden Dateien speichern, dann weißt Du sicher, 
dass Du die richtigen Dateien hast und kannst die ersetzen.
Bei weiteren Updates muss der User entweder alle älteren Updates 
nacheinander anwenden, oder Du musst eine Liste mit den CRCs aller 
Vorversionen mitführen.

fchk

von Johannes (Gast)


Lesenswert?

Frank K. schrieb:
> Was willst Du updaten können - nur die Applikation oder auch das
>
> Betriebssystem selber?

Sowohl als auch; bei kleineren Updates nur die eigentliche Applikation 
und bei größeren (falls auch mal Erneuerungen im OS) anstehen, natürlich 
das komplette Image.

1) komplettes Image:
Wenn ich als Filesystem NTFS verwende, müsste ich auf eine bootfähige CF 
Card verzichten können, oder? Ist glaub ich nur bei FAT32 ein Thema. Der 
User würde das Image z.B. auf einen USB-Stick packen. Mit "Imagetool" 
meinst du ein kleines Programm, welches anschließend die Daten (das 
Image) auf die CF kopiert und anschließend einen Reset durchführt, so 
dass der FBA gestartet wird um das Image zu installieren?


2) nur Applikation:
Macht es hier z.B. Sinn eine MSI-Datei zu verwenden, und in diese die 
eigentliche Exe-Datei und eine Prüfsumme CRC zu packen? Der User sollte 
lediglich zu Beginn das Verzeichnis bzw. die Datei auswählen und 
anschließend auf Update klicken (mehr nicht!). Danach muss alles von 
allein laufen ohne User-Eingaben etc.

Frank K. schrieb:
> Bei weiteren Updates muss der User entweder alle älteren Updates
> nacheinander anwenden, oder Du musst eine Liste mit den CRCs aller
> Vorversionen mitführen.

irgendwie steh ich da graf auf`m schlauch; also schön wäre es, wenn der 
user nicht alle älteren Updates nacheinander installieren muss, sondern 
nur das letzte. Ein CRC gibt doch erst einmal darüber Auskunft, dass die 
Datei zu dem der CRC gehört, der Prüfsumme entspricht und somit nicht 
ausgetauscht worden ist; allerdings gibt es jetzt noch den Fall, dass 
eine ganz andere Datei als Applikation herangezogen wird mit dem 
dazugehörigen CRC. Wie erkenn ich jetzt, dass diese Datei nicht meiner 
Applikation entspricht (das hab ich leider noch nicht verstanden - mit 
der Liste von CRCs aller Vorversionen)?

von Frank K. (fchk)


Lesenswert?

Johannes schrieb:
> Frank K. schrieb:
>> Was willst Du updaten können - nur die Applikation oder auch das
>>
>> Betriebssystem selber?
>
> Sowohl als auch; bei kleineren Updates nur die eigentliche Applikation
> und bei größeren (falls auch mal Erneuerungen im OS) anstehen, natürlich
> das komplette Image.
>
> 1) komplettes Image:
> Wenn ich als Filesystem NTFS verwende, müsste ich auf eine bootfähige CF
> Card verzichten können, oder? Ist glaub ich nur bei FAT32 ein Thema.

Wieso? Wenn User das Filesystem geschrottet hat und die Kiste nicht mehr 
hochfährt, was macht User dann? Dummes Gesicht. Und weiter?

> Der
> User würde das Image z.B. auf einen USB-Stick packen. Mit "Imagetool"
> meinst du ein kleines Programm, welches anschließend die Daten (das
> Image) auf die CF kopiert und anschließend einen Reset durchführt, so
> dass der FBA gestartet wird um das Image zu installieren?

Nein. Du mußt immer damit rechnen, daß User die Kiste kaputtspielt. 
Sprich: Von der eingebauten Platte/SSD bootet das Teil nicht mehr. Dann 
muss User in der Lage sein, die Kiste wieder hochzuziehen, und dafür 
braucht er ein bootfähiges Bootmedium mit einem Plattenimage. Auf dem 
Bootmedium des Users ist dann ein Programm darauf, das das Image vom 
Bootmedium auf die Platte schreibt, und zwar sektorweise, ohne Rücksicht 
auf Filesystem oder Partitionen oder sonstwas.

Machst DU das nicht, hast Du nachher Servicefälle.


> 2) nur Applikation:
> Macht es hier z.B. Sinn eine MSI-Datei zu verwenden, und in diese die
> eigentliche Exe-Datei und eine Prüfsumme CRC zu packen? Der User sollte
> lediglich zu Beginn das Verzeichnis bzw. die Datei auswählen und
> anschließend auf Update klicken (mehr nicht!). Danach muss alles von
> allein laufen ohne User-Eingaben etc.

Kannst Du machen. Dann muß Deine Anwendung aber als MSI regelgerecht 
installiert worden sein, und was Du dann verteilst, sind dann keine .msi 
Dateien, sondern .msp Dateien, bei denen der Windows Installer prüft, ob 
da vorher schon das zugehörige .msi installiert ist.

> Frank K. schrieb:
>> Bei weiteren Updates muss der User entweder alle älteren Updates
>> nacheinander anwenden, oder Du musst eine Liste mit den CRCs aller
>> Vorversionen mitführen.
>
> irgendwie steh ich da graf auf`m schlauch; also schön wäre es, wenn der
> user nicht alle älteren Updates nacheinander installieren muss, sondern
> nur das letzte. Ein CRC gibt doch erst einmal darüber Auskunft, dass die
> Datei zu dem der CRC gehört, der Prüfsumme entspricht und somit nicht
> ausgetauscht worden ist

genau. Wenn die Datei aber in früheren Updates schon einmal geändert 
worden ist, dann weißt Du erstmal nicht ob User da schon ein Update 
installiert hat und wenn ja welches. Daher brauchst Du in diesem Fall 
eine Liste mit den CRCs alle möglichen Vorversionen.

> ; allerdings gibt es jetzt noch den Fall, dass
> eine ganz andere Datei als Applikation herangezogen wird mit dem
> dazugehörigen CRC.

Wenn ein Updater für eine App gestartet werden sollte, die nicht 
installiert ist, sollte er die zu updatenden Dateien gar nicht finden, 
oder?

Deine Idee, die Applikation als .msi zu installieren und anschließend 
nur noch .msp's rauszugeben, ist gut. Da sorgt nämlich der 
Windows-Installer dafür, daß das idiotensicher ist. Vorausgesetzt 
natürlich, daß der Windows Installer im XPE Image enthalten ist.

fchk

von Johannes (Gast)


Lesenswert?

Frank K. schrieb:
> Bootmedium des Users ist dann ein Programm darauf, das das Image vom
> Bootmedium auf die Platte schreibt, und zwar sektorweise, ohne Rücksicht
> auf Filesystem oder Partitionen oder sonstwas.

Kennst du bereits ein solches Programm? Schließlich hat ja jeder dieses 
Problem;

Frank K. schrieb:
> genau. Wenn die Datei aber in früheren Updates schon einmal geändert
> worden ist, dann weißt Du erstmal nicht ob User da schon ein Update
> installiert hat und wenn ja welches.

ok, dann hatte ich das zuvor falsch verstanden; im Prinzip muss ich 
vorneweg wissen, welche Version bereits auf dem System vom User 
vorhanden ist und anhand dessen kann / wird dann entschieden ob das 
aktuelle Update installiert werden kann oder nicht. Dann sollte es auch 
so gehn, dass auf dem System selbst eine Datei .txt oder ähnliches 
existiert, in der die aktuelle Firmware Version etc. abgespeichert ist 
und im MSI File existierit ebenfalls eine Datei, die die Voraussetzungen 
für die Installation beinhaltet -> beide vergleichen und entscheiden ob 
das Update durchgeführt werden soll oder nicht?

Frank K. schrieb:
> Wenn ein Updater für eine App gestartet werden sollte, die nicht
> installiert ist, sollte er die zu updatenden Dateien gar nicht finden,
> oder?

Hatte es mir so vorgestellt, das der User zu Beginn selbst den Ort 
angeben kann wo sich die Updater-Datei befindet (z.B. in einem 
Verzeichnis von einem USB-STick); eine .msi Datei besitzen ja jetzt 
mehrere Applikationen so dass ich da noch nicht selektieren kann, dass 
nur meine .msi Datei angezeigt wird; d.h. das muss zu Beginn des 
Installations-Prozesses irgendwie überprüft werden können? Gibt es da 
einschlägige Vorgehensweisen?

Frank K. schrieb:
> Deine Idee, die Applikation als .msi zu installieren und anschließend
> nur noch .msp's rauszugeben, ist gut. Da sorgt nämlich der
> Windows-Installer dafür, daß das idiotensicher ist.

Denn Windows-Installer (hab ich mir bis jetzt noch nicht so genau 
angeschaut) wird wahrscheinlich auch so zu konfigurieren sein, dass nur 
ein Fortschrittsbalken angezeigt wird und nicht mehr. So dass keine 
weiteren Usereingaben etc. möglich sind bzw. von nöten sind.

von Frank K. (fchk)


Lesenswert?

Johannes schrieb:
> Frank K. schrieb:
>> Bootmedium des Users ist dann ein Programm darauf, das das Image vom
>> Bootmedium auf die Platte schreibt, und zwar sektorweise, ohne Rücksicht
>> auf Filesystem oder Partitionen oder sonstwas.
>
> Kennst du bereits ein solches Programm? Schließlich hat ja jeder dieses
> Problem;

Ghost, DriveImage, ... der Markt ist voll davon, aber Du brauchst was, 
was keine GUI hat und automatisch abläuft und unter DOS - ich würde da 
ganz stumpf was selber schreiben. So schwer ist das nicht. INT13 läßt 
grüßen.

> Frank K. schrieb:
>> genau. Wenn die Datei aber in früheren Updates schon einmal geändert
>> worden ist, dann weißt Du erstmal nicht ob User da schon ein Update
>> installiert hat und wenn ja welches.
>
> ok, dann hatte ich das zuvor falsch verstanden; im Prinzip muss ich
> vorneweg wissen, welche Version bereits auf dem System vom User
> vorhanden ist und anhand dessen kann / wird dann entschieden ob das
> aktuelle Update installiert werden kann oder nicht. Dann sollte es auch
> so gehn, dass auf dem System selbst eine Datei .txt oder ähnliches
> existiert, in der die aktuelle Firmware Version etc. abgespeichert ist
> und im MSI File existierit ebenfalls eine Datei, die die Voraussetzungen
> für die Installation beinhaltet -> beide vergleichen und entscheiden ob
> das Update durchgeführt werden soll oder nicht?

Das sind zu viele Vorbedingungen, als das das zuverlässig laufen wird. 
Was machst Du, wenn User die Versionsdatei löscht, weil "wird ja nicht 
benutzt"? Der einzige Weg ist, daß Du Dir Deine Dateien anschaust und 
daraus ableiten kannst, ob die (a) gültig und (b) aktuell ist.


> Frank K. schrieb:
>> Wenn ein Updater für eine App gestartet werden sollte, die nicht
>> installiert ist, sollte er die zu updatenden Dateien gar nicht finden,
>> oder?
>
> Hatte es mir so vorgestellt, das der User zu Beginn selbst den Ort
> angeben kann wo sich die Updater-Datei befindet (z.B. in einem
> Verzeichnis von einem USB-STick); eine .msi Datei besitzen ja jetzt
> mehrere Applikationen so dass ich da noch nicht selektieren kann, dass
> nur meine .msi Datei angezeigt wird; d.h. das muss zu Beginn des
> Installations-Prozesses irgendwie überprüft werden können? Gibt es da
> einschlägige Vorgehensweisen?

Die von MS für diesen Zweck vorgesehene Vorgehensweise ist die 
Verwendung eines .msi *allein für die Erstinstallation(!)* und 
anschließend nur noch .msp's für Updates. Ansonsten gibt das Bruch, wenn 
die Applikation wieder ordnungsgemäß deinstalliert oder reinstalliert 
werden soll, weil die Datenbanken des Windows Installers sonst nicht mit 
aktualisiert werden.

> Frank K. schrieb:
>> Deine Idee, die Applikation als .msi zu installieren und anschließend
>> nur noch .msp's rauszugeben, ist gut. Da sorgt nämlich der
>> Windows-Installer dafür, daß das idiotensicher ist.
>
> Denn Windows-Installer (hab ich mir bis jetzt noch nicht so genau
> angeschaut) wird wahrscheinlich auch so zu konfigurieren sein, dass nur
> ein Fortschrittsbalken angezeigt wird und nicht mehr. So dass keine
> weiteren Usereingaben etc. möglich sind bzw. von nöten sind.

Genau.

von Johannes (Gast)


Lesenswert?

Frank K. schrieb:
> Das sind zu viele Vorbedingungen, als das das zuverlässig laufen wird.
> Was machst Du, wenn User die Versionsdatei löscht, weil "wird ja nicht
> benutzt"? Der einzige Weg ist, daß Du Dir Deine Dateien anschaust und
> daraus ableiten kannst, ob die (a) gültig und (b) aktuell ist.

ok, d.h. bei jedem Update (zu Beginn bei der Installation .msi und 
anschließend bei den weiteren .msp) etc. wird der dazugehörige CRC auf 
der CF-Card gespeichert, so dass deine besagte liste entsteht und diese 
wird immer mit der im nächsten Update vorhanden liste verglichen. Ist 
das ein standardisiertes Verfahren? Bzw. wie speichert man am besten die 
CRC-Werte ab?

In einem Extra-File könnte dieses ja durch den Benutzer auch wieder 
gelöscht werden?

von Frank K. (fchk)


Lesenswert?

Wenn Du .msp-Dateien erzeugst, brauchst Du Dich um nichts weiter zu 
kümmern, das macht der Windows Installer für Dich.

von Johannes (Gast)


Lesenswert?

Frank K. schrieb:
> Wenn Du .msp-Dateien erzeugst, brauchst Du Dich um nichts weiter zu
> kümmern, das macht der Windows Installer für Dich.

Werd ich mir mal ansehen, dann muss dieser Installer ja sehr intelligent 
sein.

Hab heut mal versucht nach Informationen zu suchen bezüglich des Bootens 
von USB-Stick. Also den Stick ansich bootfähig für DOS zu machen, hat 
geklappt. Hab hier erstmal das HP-Tool verwendet. Anschließend befinden 
sich dann die Dateien: Command.com, IO.sys und MSDOS.sys auf dem Stick.

Kann man auch einen bootfähigen USB-Stick mit NTFS erstellen?

Dann hab ich gelesen wird anscheinend die Datei "Autoexec.bat", die man 
selbst erstellen kann, automatisch vom DOS-System beim Booten gestartet.

D.h. innerhalb so einer Batch-Datei müsste ich dann zuerst die CF-Card 
formatieren und ebenfalls wieder bootfähig machen? Bis jetzt mach ich 
das immer über das Windows-Tool, welches ebenfalls über die CMD 
gestartet wird.

Und anschließend muss der eigentliche Inhalt von dem USB-Stick auf die 
CF-Card kopiert werden.

xcopy sourcepath destinationpath /e

Danach einfach einen Reset durchführen und den FBA von CF-Card starten?

von Frank K. (fchk)


Lesenswert?

Johannes schrieb:

> Hab heut mal versucht nach Informationen zu suchen bezüglich des Bootens
> von USB-Stick. Also den Stick ansich bootfähig für DOS zu machen, hat
> geklappt. Hab hier erstmal das HP-Tool verwendet. Anschließend befinden
> sich dann die Dateien: Command.com, IO.sys und MSDOS.sys auf dem Stick.
>
> Kann man auch einen bootfähigen USB-Stick mit NTFS erstellen?

Nein, bzw nicht so einfach. Denk dran, Du bootest ein DOS, und dos kann 
das nicht.

> Dann hab ich gelesen wird anscheinend die Datei "Autoexec.bat", die man
> selbst erstellen kann, automatisch vom DOS-System beim Booten gestartet.

> D.h. innerhalb so einer Batch-Datei müsste ich dann zuerst die CF-Card
> formatieren und ebenfalls wieder bootfähig machen? Bis jetzt mach ich
> das immer über das Windows-Tool, welches ebenfalls über die CMD
> gestartet wird.
>
> Und anschließend muss der eigentliche Inhalt von dem USB-Stick auf die
> CF-Card kopiert werden.
>
> xcopy sourcepath destinationpath /e
>
> Danach einfach einen Reset durchführen und den FBA von CF-Card starten?

... und schon hast Du die langen Dateinamen verloren, denn die kennt DOS 
auch nicht. Merkst Du jetzt, warum ich nicht von dateiweisem Kopieren,
sondern von sektorweisem Kopieren schrieb? Da ist es nämlich egal, was 
DOS kann und was nicht, denn stumpf Sektoren auf eine Platte schreiben, 
das kann es.

von Johannes (Gast)


Lesenswert?

Frank K. schrieb:
> Da ist es nämlich egal, was
> DOS kann und was nicht, denn stumpf Sektoren auf eine Platte schreiben,
> das kann es.

stimmt da war was; auf meiner Suche im Netz hab ich allerdings nur 
kleine Progs gefunden, die anscheinend sektorweise kopieren (wie z.B. 
h2copy.zip). Weißt du zufällig auch die commands die man z.b. in eine 
Batch-Datei eintragen müsste, damit diese das sektorweise kopieren 
durchführt?

Des Weiteren wäre es super, wenn bei fdisk, format etc. keine 
User-Eingaben erforderlich wären, die die jeweiligen Schritte bestätigen 
müssen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.