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
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.
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?
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.
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?
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.
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?
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
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)?
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
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.
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.
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?
Wenn Du .msp-Dateien erzeugst, brauchst Du Dich um nichts weiter zu kümmern, das macht der Windows Installer für Dich.
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?
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.