Symbroson hat folgendes geschrieben :

Die Idee/Notwendigkeit kam also noch vor Assembler - das ist heftig

Und es ist immernoch notwendig und wird es bleiben.

Wie erwähnt, denke an Imageprocessing. Im Endeffekt ist das nur ein großes Array von Zahlen, die man in ein anderes Array umwandeln muss.
Bei KI/machine learning ist das auch nicht viel anderes. Da hat man große Eingabevektoren (Zahlenarrays) die man schrittweise transformiert.

Hmm..

Und mal eine praktische Anwendung für Spieler:
Wenn Du anfängst, ein bisschen zu Cheaten, dann schaust Du dir die Spielstände von Spielen mit nem Hex-Editor an und kannst dort z.B. Atribute erhöhen..

Auch zum Erstellen von SaveGame-Editoren ist ein Hex-Editor notwendig, um die richtigen Bytes zu identifizieren..

Sprich er wird für alles gebraucht, wo Daten ohne das eigentliche Programm Byte-Weise 'verändert' werden sollen

Symbroson hat folgendes geschrieben :

Die Idee/Notwendigkeit kam also noch vor Assembler - das ist heftig

Dafür waren die damaligen Programme aus heutiger Sicht minimalistisch. Z.B. gab es bei / auf den Bildschirmen ausschließlich Textausgaben.

Eine elende, fehlerträchtige, langwierige Fummelei war die damalige Programmiererei dennoch. Aber ist sie es heutzutage nicht genaugenommen auch noch?

Auch gab es keine persönlichen Computer ("Personal Computer"), sondern Großrechenanlagen (groß i.S.v. Masse und Volumen, nicht in bezug auf Rechenleistung). Rechnerzeiten mußten gebucht - und ggf. auch bezahlt - werden. Programme wurden mit Lochstreifen und/oder Lochkarte vorbereitet und dann zur Mietzeit die Großrechner damit "gefüttert". Die Ausgaben waren oft genug auch nur Lochstreifen/-karten, evtl. auch Bildschirm und/oder Drucker?! Und dann mußte das alles in Ruhe ausgewertet, "nachbereitet" werden, denn auch damals schon war der erste Versuch nur selten fehlerfrei.

Erlebt habe ich das alles nicht mehr, ich kenne es nur aus Schilderungen.

Meine Güte, was waren das damals für Verrenkungen und Klimmzüge.

Bildschirme ? Ich kenne das noch als eine 8er-Reihe von LEDs... Da mußte die Adresse im RAM per Kippschalter eingestellt werden, das zu schreibende Hi- oder Lo-Nibble (!) ebenfalls per Kippschalter und geschrieben wurde es dann per Taster endgültig ins RAM.

Dann stellte man die Startadresse ein und stellte den Kippschalter von PROG auf RUN um und das Programm lief... Hoffentlich.

So wurde mal programmiert und natürlich mußte man dazu den kompletten Befehlssatz des Prozessors auswendig können (als Hexcode, nicht als Mnemonic) mit samt seinen noch sehr wenigen Adressierungsarten. Lochkarten waren da ja schon Massenspeicher Aus dieser Zeit stammte noch das anerkennende Nicken, wenn man am Ende des Tages 50 (!) Befehle fertig programmiert hatte und das auch noch funktionierte. Da wurde auch nicht um jedes Byte gekämpft, sondern um jedes Bit, denn 1K Speicher kostete damals abertausende D-Mark, da war man froh, wenn man 256 Bytes zur Verfügung hatte.

Die Erfindung der Bildschirmausgabe erleichterte das ganze Programmieren ungeheuer, die Erfindung von Assembler (die heute bekannten Mnemonics, die dann in Hexcodes übersetzt wurden) machte das ganze dann zum Kinderspiel - verglichen mit den oben geschilderten Zuständen.

Wenn ich dann heute sehe, das die Programmierer von der Uni kommen und ihr größtes Programm hatte 3000 Zeilen, davon 30% Kommentare... Da lächle ich innerlich. Aber nur innerlich. Denen darf man nicht erzählen, das das von der Länge her bestenfalls ne kompakte Utility-Routine ist.

Könntet Ihr bitte zum Thema zurück kommen?

Ich schlage mal vor ab hier abzutrennen. Dann kann mael, wenn er das möchte, den anderen Thread im Eingangspost verlinken. So findet die Frage und die Antworten darauf sonst ja niemand, der evtl. die gleiche Frage hat.

Hallo!

@mael:

DOS Datum = DiskOperatingSystem Datum, korrekt?

Ist das dann beabsichtigt so?
//Edit: Und OLETIME 30.12.1899? Was hat das zu bedeuten?

galagher hat folgendes geschrieben :

Hallo! @mael: DOS Datum = DiskOperatingSystem Datum, korrekt? Ist das dann beabsichtigt so? //Edit: Und OLETIME 30.12.1899? Was hat das zu bedeuten?

Was irritiert dich denn am Ergebnis? Es gibt verschiedene Datums/Zeitdatentypen, und die werden angezeigt.

OLETIME ist ein Windows/COM-Datentyp.
DOS-Date/Time wird z.B. im FAT-Dateisystem verwendet.

mael hat folgendes geschrieben :

Was irritiert dich denn am Ergebnis?

Das Ergebnis!

mael hat folgendes geschrieben :

Es gibt verschiedene Datums/Zeitdatentypen, und die werden angezeigt.

Na dann!

Jedenfalls: Ein ganz besonderes Programm, war mir schon oft sehr nützlich, möchte es nicht missen! Grossartig!

galagher hat folgendes geschrieben :

mael hat folgendes geschrieben : Was irritiert dich denn am Ergebnis? Das Ergebnis!

Aber warum? Scheint irgendwas falsch zu sein, und wenn was genau?

Zitat:

Jedenfalls: Ein ganz besonderes Programm, war mir schon oft sehr nützlich, möchte es nicht missen! Grossartig!

Danke.

mael hat folgendes geschrieben :

Aber warum? Scheint irgendwas falsch zu sein, und wenn was genau?

Nun, OLETIME 30.12.1899, FILETIME 26.04.9015 09:58:07, DOS Uhrzeit & Datum 04.02.1996 15:02:16 usw., was bedeutet das? Da du die Datei readme.txt ja nicht am 26. April des Jahres 9015 erstellt hast, (wenn doch, wie hast du das gemacht, oder wie wirst du das machen? ) bezeichnet 9015 also nicht neuntausendfünfzehn Jahre n.Chr., und auch nicht den 26. April. dieses Jahres!

Also was dann?

galagher hat folgendes geschrieben :

Nun, OLETIME 30.12.1899, FILETIME 26.04.9015 09:58:07, DOS Uhrzeit & Datum 04.02.1996 15:02:16 usw., was bedeutet das? Da du die Datei readme.txt ja nicht am 26. April des Jahres 9015 erstellt hast, (wenn doch, wie hast du das gemacht, oder wie wirst du das machen? ) bezeichnet 9015 also nicht neuntausendfünfzehn Jahre n.Chr., und auch nicht den 26. April. dieses Jahres! Also was dann?

Der Dateninspektor interpretiert den Inhalt einer Datei, nicht die Metadaten wie Erstellungsdatum, Änderungsdatum, Besitzer oder Ähnliches.

Der Dateninspektor interpretiert also den Inhalt einer Datei, ab der Cursorposition und bis zu einer Maximallänge die vom Datentyp abhängig ist. In deinem Bild war der Cursor am Anfang der Datei "Readme.txt". Für die Int32 Zeile im Dateninspektor werden daher die 4 ersten Bytes der Datei genommen und als Dezimalwert interpretiert (wobei Little Endian Bytereihenfolge angenommen wird).
Wenn du die aktive Zeile im Dateninspektor änderst, wirst du sehen dass ein Rahmen im eigentlichen Hexeditor-Steuerelement sich anpasst. So weiß man welche Bytes gerade interpretiert/übersetzt werden. Wechsle mal zwischen Int8, Int16, Int32, Int64 hin und her um den Effekt gut zu sehen.

OLETIME und FILETIME interpretieren die gleichen 8 Bytes am Dateianfang "48 78 44 20 48 65 78 20". Aber da sie Datum/Zeit unterschiedlich kodieren, unterscheidet sich auch das Interpretationsergebnis. Genauso verhält es sich mit DOS Datum&Uhrzeit, nur dass dort nur die ersten 4 Bytes beachtet werden (weil das eben das Datenformat ist das damals von den DOS-Entwicklern gewählt wurde).

Es werden also die Bytes ab der aktuellen Cursorposition interpretiert und nicht die Metadaten wie Erstellungsdatum einer Datei. Diese Metadaten werden außerhalb der Datei gespeichert.

Würde man in den Disk-Editor gehen und die richtige Position für diese Metadaten auf der Festplatte kennen (wo das ist hängt vom Dateisystem ab), würde man auch den Dateninspektor verwenden können um die entsprechenden Bytes zu dekodieren und z.B. das Erstellungsdatum einer Datei zu erfahren.

In normalen Programmen vermeidet man aber den direkten Zugriff auf Datenträger und verwendet API-Funktionen wie GetFileAttributesEx() bzw. Delphis FileAge() um diese Informationen abzufragen.


Oh, und warum sind die Datumswerte so seltsam? Naja, die ersten 8 Bytes sind eigentlich Text, nämlich "HxD Hex ". Interpretiert man Bytes als etwas anderes als sie eigentlich kodieren, dann können seltsame Ergebnisse herauskommen. Ist nicht anders als wenn ich in Pascal eine Int32-Variable zu einem Single caste (Typumwandlung), und dann komische Werte bekomme.

Jede Zeile im Dateninspektor zeigt nur die Interpretation der Bytes an der aktuellen Cursorposition an, unter der Annahme, dass die Bytes auch tatsächlich diesen Datentyp haben.

Ich hoffe das klärt das Problem, auch wenn ich etwas weit ausgeholt habe.

mael hat folgendes geschrieben :

Ich hoffe das klärt das Problem, auch wenn ich etwas weit ausgeholt habe.

Ok, es werden also Daten als Uhrzeit und Datum interpretiert. Danke!

Erst gestern benötigte ich HxD wieder: Damit kann man auch noch so lange Strings bearbeiten, mancher (jeder?) Texteditor schneidet irgendwann den String einfach ab - stellt ihn nicht mehr dar oder kürzt ihn tatsächlich, ich weiss es nicht. jedenfalls wird die Datei zerstört, wenn man das dann so speichert. Nicht so mit HxD!

Grad mal das HxD-Setup vom Oktober diesen Jahres aktualisiert, nachdem die 1.7.7.0 mit Full-HD auf Grund der fehlenden Gruppierung mit 64 Spalten je Zeile schlecht nutzbar war.

Dabei sind mir mehrere Sachen aufgefallen (alles eher Kleinigkeiten):
- Für die Alternativ-Hex-Farbe wäre das Festlegen eines eigenen Hintergrundes zu überlegen (ich vermute, er nimmt den der Primärfarbe).
- Beim Vergleichen zweier Dateien wäre ein Modus zum Markieren aller Änderungen in den beiden Dateien von Interesse, so dass man nicht jedes einzelne Byte einzeln durchsteppen muss mit F6.
- Die Vergleichsoperation auf mehreren Bytes ausführen (also 2 oder 4 Byte als Gruppe betrachtet) wäre gerade beim Vergleich von entsprechenden Tabellen manchmal sehr von Vorteil.
- Zuweisung der Alternativ-Farbe nicht an die Byte-Gruppen-Größe koppeln, sondern ggf. individuell einstellbar (Default darf gern die Kopplung beider Werte sein).

Ansonsten hat sich seit der 1.7.7.0 doch einiges getan.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

HxD 2.2 ist verfügbar.

Download: mh-nexus.de/en/downloads.php?product=HxD20
Changelog: mh-nexus.de/en/hxd/changelog.php#v_2.2.0.0

Es gibt nun ein Plugin-Framework um den Dateninspektor von HxD zu erweitern:
github.com/maelh/hxd-plugin-framework

Wem es gefällt kann gerne einen Stern verleihen oder es forken, damit mehr Leute es sehen.

Hallo
ich verwende HxD schon seit vielen Jahren und bin immer sehr zufrieden gewesen.

Eine Bitte hätte ich noch:
Ist es möglich die Umrechnung von 3 Bytes als int24 auch noch darzustellen?
Ich weis, es ist nicht einfach.
Ich mache viel mit wav-Dateien, die haben manchmal diese 24 bit-Auflösung und wenn man da einen Eintrag sucht...

Danke!
Hansi

Sollte ein Plugin mit dem neuen Framework nicht genau das leisten können?

Ja, eigentlich wäre das Plugin-Framework dafür geeignet.

Sind in dem WaveFile-Format 24-Bit-Integer dicht aneinander gepackt, ohne Füllbytes?

Hast du eine einfache WAVE-Datei als Beispiel?

Danke für die schnelle Antwort,

also: keine füll-bytes. Die Daten beginnen irgendwann mit dem Text "data", dann 4Byte Länge der Daten und danach die Daten.
siehe Anhang

---wav datei ist hier verboten, deshalb Dateierweiterung geändert!

Übrigens, Dein Property-Editor, da könnte man ja noch verschiedene andere Dateien von Windows (wie auch wav usw.) auseinander nehmen.
im Internet (Wiki) staht ja alles.

Hansi

Moderiert von Narses: Dateianhang als ZIP gepackt wieder hochgeladen.