->barroshelder
Speicherabnutzung: der Speicherfehler tritt nicht in der device.xml auf, die wird ja von nur bei einem BMP Kaltstart überschrieben, also nur dann wenn das
Becker Logo erscheint. Mein Copy führt dazu, dass die neue Datei device.xml auf einen neuen Speicherplatz kommt, also nicht dauernd den gleichen Speicherbereich schrubbt. Deine Aussage, dass der Speicher durch mein Verfahren belastet wird, ist also schlichtweg falsch, belastet wird der vielmehr Speicherbereich des Index, dafür ist
Becker verantwortlich. Da du anscheinend wenig Ahnung von Speichertechnik hast hiermal eine Erklärung: Die auch bei SSD verwendete Technik beruht auf der Festplattentechnik. Eine oder mehrere übereinanderliegende magnetische Scheiben werden werden in nebeneinander liegende Kreise formatiert, jeder Kreis wird wird in Spuren unterteilt, z.B. 4096 Bytes groß, die senkrecht übereinander liegenden Kreise nennt man Zylinder. Gelesen/geschrieben wird mit einem kammartigen Gebilde. Soll nun auf eine Datei zugegriffen werden, müsste wie bei einem Magnetband die Platte sequentiell gelesen werden. Um das zu verhindern wird ein Index gebildet, er enthält die Adressen aller Spuren (Plattennummer, Zylinder, Spur), hat also eine feste Größe auf einem festen Speicherplatz und wird bei der Initialisierung der Platte erstellt.
Soll ein Satz in einer Datei geändert werden geschieht dies nicht auf der Platte, der Satz wird in den Hauptspeicher geladen und dort geändert, das Zurückschreiben geschieht später, spätestens beim close. Der Index ist eine Datei, auch er wird in den Hauptspeicher geladen und dort geändert und spätestens beim Shutdown zurückgeschrieben. Das Verfahren ist bei rasend schnellen SSD (BMP-Speicher) natürlich Blödsinn, nur hätte Microsoft neue I/O-Routinen schreiben müssen. Also bildeten die SSD-Hersteller das Index-Verfahren softwaremäßig ab. Lange Rede, kurzer Sinn: bei jedem shutdown wird der Index vom Hauptspeicher auf den Originalplatz des Index zurückgeschrieben. Das hat dann aufgrund der mangelhaften Qualität der von
Becker verwendeten Speicherchips folgenden Effekt: du setzt den Schreibschutz der device.xml (Attribut bit auf 1), kontrollierst mehrmals ob noch gesetzt, du startest den PC neu, du zweifelst an deiner Zurechnungsfähigkeit: der Schreibschutz ist weg. Warum? Der Index wird erst beim Shutdown vom Hauptspeicher (den siehst du am PC) auf den BMP zurückgeschrieben, dort kann das defekte bit aber nicht auf 1 gebracht werden. Schau mal auf den 160 Seiten hier wie oft der Fehler schon auftrat und überlege, warum naviteam in Polen blendende Geschäfte mit dem Speicheraustausch für 98 € macht.
Dein Verfahren mit im Namen geänderten Dateien ändert ja nichts am
Becker Verfahren beim Kaltstart:
BMP bekommt Strom
BIOS startet
BIOS lädt Windows CE
Windows lädt Firmware (Treiber für GPS Sensor, Sound, Display etc.)
Firmware liest auf BIOS Gerätenummer und überschreibt die device.xml mit dieser Nummer.
Windows startet AutoRun.exe
Autorun.exe startet HmiStartup.exe
Hmistartup vergleicht Gerätenummer in device.xml mit Lizenz.
Mit anderen Worten, es dauert nur eine Zeit, bis der Speicherfehler in deinen Dateien auftritt.
Bevor hier EDV-Laien mit dem Hex-Editor Dateien zerstören wäre es vielleicht sinnvoll, du erstellst ein Programm, mit dem die Gerätenummer im BMP geändert werden kann. Das scheint mir wesentlich zielgerichteter, da kann wesentlich weniger passieren. Du kannst ja mal mit einem disassember/Hexeditor die Firmware nach der Updateroutine untersuchen, das Programm erstellen und hier ins Board bringen. Tip: mit mortscript kannst du den versteckten Bereich des BMP freischalten.
