Dateispeicherung in Dos-Zeiten

[Johannes]

Hallo Programmierfreaks,

ich habe da mal eine Frage an alle, die sich noch aus Dos-Zeiten auskennen. Ich habe ein Dos-Programm, das aller Wahrscheinlichkeit in Basic geschrieben wurde, von dem ich die Anwenderdaten, die in ".dat"-Dateien gespeichert wurden, extrahieren muß. Viele der einfach in diesen Dateien gespeicherten Daten lassen sich einfach in Form von Ascii-Zeichen rausziehen. Dann kommt es aber vor, daß Zahlenfelder, insbesondere Datumsangaben, in gepackter Form gespeichert wurden. Ich habe HexCode mit dem ich nichts anfangen kann. Weiß irgendjemand, wo man mehr darüber erfahren kann, wie solche Daten in Basic damals gespeichert wurden, damit ich sie rekonstruieren kann?

Würde mich über eine Antwort sehr freuen. Vielen Dank!

[Johannes]

Achso, das Programm stammt von ungefähr Mitte bis Ende der 80ger Jahre ;-)

[Tom]

Hello,

Weiß irgendjemand, wo man mehr darüber erfahren kann, wie solche Daten in Basic damals gespeichert wurden, damit ich sie rekonstruieren kann?

Das beste wäre dazu sicher eine solche Datei zu haben,
denn Formate gabs irre viel.

BCD Binary Coded Decimals z.B.. Die haben dann nur Halbbytes benutzt pro Ziffer.
Dann muss man wissen, ob das Speicherformat Bigendian oder Littleendian ist.
Dann gabs auch schon genau solche irren Sachen, wie Unix-Timestamp, nur dass die Basic-Fritzen zwei andere Offset-Daten benutzen.

usw...

Mit geübtem Blick auf das Hexformat kann man bestimmt eine Menge erkennen ;-)

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Johannes]

also hex 0325 müßte 09.09.1999 bedeuten

[Tom]

Hello,

also hex 0325 müßte 09.09.1999 bedeuten

Da sehe ich aber keinen mir bekannten Zusammenhang.
Ist auch ein bisschen sehr dünne, was Du da schickst.

Von wo stammt denn der Hex-Abzug? Aus dem Arbeitsspeicher oder von der Platte?
Auf welcher Plattform hast Du ihn gefertigt?
Was steht so drum herum?

Wenn es eine echte Word-Größe ist (16 Bit) dann kann man damit bekanntlich 65.536 Möglichkeiten signieren. In tagen würde das so ungefähr 179 Jahre umfassen. Wenn es auch noch Jahre in die Vergangenheit sein sollen, dann sind es eben z.B. -90 | +89 Jahre. Wo nun der Bezugspunkt liegt, muss man natürlich auch wissen.

Und dann gab es da doch auch mal das "Jahr-2000-Problem". Erinner Dich mal daran. Das bezog sich aber nicht auf die gepackte Form. Mit der werden wir vermutlich erst 2069 Probleme bekommen.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[Der Martin...]

Hallo miteinander,

also hex 0325 müßte 09.09.1999 bedeuten

Das bezweifle ich mal. Unter DOS war ein Timestamp (Dateidatum) nämlich auch schon 32bit lang und löste auf 2s auf. Dabei war die Uhrzeit komnplett im ersten Wort (5bit Sekunden, 6bit Minuten, 5 bit Stunden), das Datum im zweiten (5bit für den Tag, 4bit für den Monat, 7bit für das Jahr). Das Bezugsdatum in diesem System ist übrigens der 01.01.1980.
Dein Beispiel mit 0x0325 wäre in diesem Format der 05.09.1981, um das nochmal aufzugreifen.

Ist auch ein bisschen sehr dünne, was Du da schickst.

Das finde ich auch. Vielleicht sollte Johannes mal einen Auszug aus dem Hexdump posten, sagen wir mal, z.B. die ersten 256 Bytes. Dann könnte ich wahrscheinlich schon sehr viel mehr erkennen.

Und dann gab es da doch auch mal das "Jahr-2000-Problem".

Aber nicht mit diesem Timestamp-Format, wie du richtig bemerkt hast.

Mit der werden wir vermutlich erst 2069 Probleme bekommen.

Eigentlich erst in 2107 (127 Jahre nach 1980).
Bin gespannt auf weitere Informationen zur Entschlüsselung. ;-)

So long,

Martin

[Johannes]

OK. Also vielen dank für das Interesse erst mal. Das Programm speichert Formulardaten in Feldern mit bestimmter Zeichenlänge in Dateien. Gerade habe ich festgestellt, wenn ich die Zahl 55555.55 auf 66666.66 ändere unterscheiden sich die beiden .Dat Dateien nur in diesen Zeichen "63C554" und "AAB965". Ein ganzer Block aus mehreren Feldern sähe z.B. so aus:

Ascii:                        Gepackte Daten:
Bezeichnerfeld______________30cÅT

000fa605h: 42 65 7A 65 69 63 68 6E 65 72 66 65 6C 64 5F 5F ;
000fa615h: 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 33 30 63 C5 ; 000fa625h: 54 00 20 D5 DC 32 00 47 F4 10 00 1C D1 43 00 E1 ; T. 000fa635h: DC 32 00 E2 DC 32 00 E3 DC 32 00 E4 DC 32 00 03 ; 000fa645h: 7E 3A 00 04 7E 3A 00 05 7E 3A 00 06 7E 3A       ;

000fa605h: Bezeichnerfeld__
000fa615h: ____________30cÅ
000fa625h: ÕÜ2.Gô...ÑC.á
000fa635h: Ü2.âÜ2.ãÜ2.äÜ2..
000fa645h: ~:..~:..~:..~:

Die veränderte Datei sieht so aus

000fa605h: 42 65 7A 65 69 63 68 6E 65 72 66 65 6C 64 5F 5F ; 000fa615h: 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 33 30 AA B9 ; 000fa625h: 65 00 20 D5 DC 32 00 47 F4 10 00 1C D1 43 00 E1 ; e. 000fa635h: DC 32 00 E2 DC 32 00 E3 DC 32 00 E4 DC 32 00 03 ; 000fa645h: 7E 3A 00 04 7E 3A 00 05 7E 3A 00 06 7E 3A       ;

000fa605h: Bezeichnerfeld__
000fa615h: ____________30ª¹
000fa625h: ÕÜ2.Gô...ÑC.á
000fa635h: Ü2.âÜ2.ãÜ2.äÜ2..
000fa645h: ~:..~:..~:..~:

[e7]

Hi,

OK. Also vielen dank für das Interesse erst mal. Das Programm speichert Formulardaten in Feldern mit bestimmter Zeichenlänge in Dateien.

typisch Basic, das bietet so was von Haus aus

Gerade habe ich festgestellt, wenn ich die Zahl 55555.55 auf 66666.66 ändere unterscheiden sich die beiden .Dat Dateien nur in diesen Zeichen "63C554" und "AAB965".

Kann ich nachvollziehen, das kommt hin, hier in VB:

  
Option Explicit  
Private Declare Sub CopyMemory Lib "kernel32" Alias _  
    "RtlMoveMemory" (Destination As Any, Source As _  
    Any, ByVal Length As Long)  
  
Private Sub Form_Load()  
Dim B As Byte, C As Long  
B = &H63  
CopyMemory ByVal VarPtr(C) + 0, B, 1  
B = &HC5  
CopyMemory ByVal VarPtr(C) + 1, B, 1  
B = &H54  
CopyMemory ByVal VarPtr(C) + 2, B, 1  
Me.Caption = C  
End Sub  

Hier wird für das 63C554 als Zahl deine 555555 ausgegeben

E7

[Johannes]

OK. Super. Vielen Dank für die Antwort. Aber ich muß zugeben, mir ist das irgendwie ziemlich kryptisch. Habe noch nie was mit Basic zu tun gehabt. Wenn ich ehrlich bin, verstehe ich Deine Routine nicht. Aber ich werde versuchen, schlau daraus zu werden. Ich habe das ganze Netz nach Konvertierungsroutinen wie MKI$, MKS$, MKD$ abgesucht und ich weiß nicht, was es alles gibt. Bringt mich das weiter? Kennst Du vielleicht eine alte Syntax, die so eine Feldkonvertierung verursacht?

Naja, jedenfalls vielen Dank für die Antwort.

[e7]

Hi,

Aber ich muß zugeben, mir ist das irgendwie ziemlich kryptisch.

ne, der Code ist eigentlich relativ einfach, keine Schleifen, keine Bedingungen, nur eine Funktion.

Wenn ich ehrlich bin, verstehe ich Deine Routine nicht.

Sie kopiert einfach die einzelnen Bytes im Arbeitsspeicher auf die 4 Bytes, wo ein Long-Wert steht... Ist vermutlich falsch da du ein Komma angegeben hast, also eher vom Typ Single (== Suchwort) oder Double.

Kennst Du vielleicht eine alte Syntax, die so eine Feldkonvertierung verursacht?

Wenn mich nicht alles täuscht funktioniert die Sache an sich so:

a& = 1212
b = "test"
open "datei" for random as 1
put #1, 1, a
put #1, , b
close 1

Achtung, das Beispiel ist vermutlich nicht in Basic lauffähig!

Schau mal hier

E7

[Johannes]

Ja, du hast Recht. Ich habe ein bißchen rumgefummelt: 66666.66 haben die Säcke einfach als LONG abgespeichert und beim Auslesen wohl durch 100 dividiert. Jedenfalls komme ich so auf die Hexwerte. Jetzt muß ich nur herausfinden, wie Sie das Datumsformat abgespeichert haben und den ganzen anderen Krempel. Naja, hab ja das Wochenende über noch Zeit ;-)... Bin durch Dich ein großes Stück weiter voran gekommen. Vielen Dank nochmals!

[Der Martin...]

Hi Johannes,

jetzt verstehe ich die Welt nicht mehr!

Gerade habe ich festgestellt, wenn ich die Zahl 55555.55 auf 66666.66 ändere unterscheiden sich die beiden .Dat Dateien nur in diesen Zeichen "63C554" und "AAB965".

Also du hast das Programm, du kannst gezielt einzelne Felder verändern und du kennst die Struktur der Datensätze - ja was fehlt dir denn dann noch?
Dann leg doch einfach den Hexdump und den Screenshot eines Datensatzes (im Klartext) nebeneinander und ordne die Bytes der Reihe nach zu:

30 Byte  string,    Feldbezeichner (kennen wir aus deinen Postings)
(der Rest ist jetzt Phantasie von mir)
  4 Byte  float,     Einzelpreis
  2 Byte  integer,   Anzahl
  4 Byte  timestamp, Kaufdatum
und so weiter bis zur Datensatzlänge von 78 Bytes, die du ja auch schon herausgefunden hast...
Was ist jetzt eigentlich noch das Problem?

So long,

Martin

[fanelf.de]

nennt sich auch dezimal gepackt. ist immer noch aktuell im mainframe bereich, und wirds auch noch ein paar jährchen bleiben.

die meist in cobol erstellten programme stammen sogar aus der vor 80er zeit. diese nannten sich 60er.

also mal nach dezimal gepackt googeln.