Oude DOS datafiles omzetten naar modern formaat

[kmsch]

Beste Tweakers,

Allereerst nog fijne feestdagen

De vraag. Een vriend van mij heeft een bedrijf. De administratie hiervoor doet hij in een custom made DOS-pakket van ruim 23 jaar oud. De bouwer van dit pakket bestaat al lang niet meer. We willen echter kijken of het haalbaar is om dit pakket te vervangen.

Hiervoor moet de oude data uit het systeem worden overgezet. Als ik de oude .DAT files echter open krijg ik heel veel onleesbare tekst met soms 'echte' data ertussen. Na Googelen heb ik de file met een hex-editor geopend, met dit als (stukje) resultaat: http://imgur.com/a/3bYJe (De naam en het telefoonnummer hierin zijn veranderd.)

Dit spul is ruim twee jaar ouder dan ik Vandaar mijn vraag of hier oude rotten zijn met tips? Hoe kan ik dit het best omzetten zodat ik het niet over hoef te typen?

Alvast bedankt!

Gr,
Koen

[Room42]

Reverse engineeren. Niet per se mijn afdeling en er zijn vast slimmere methodes, maar volgens mij komt het erop neer dat je door middel van wijzigingen maken gaat kijken wat er veranderd, om zo vast te stellen hoe de database in elkaar zit. Als je dat weet, kun je de data extraheren van de bestaande databestanden.

[Gerco]

Haal dat bestand eens door het linux "file" command of TrID. Redelijke kans dat het een "standaard" formaat als DBaseIII is of iets dergelijks waar tools voor zijn. Als dat niet het geval is gaat het moeilijk worden en waarschijnlijk niet de moeite waard om om te zetten. Je kan dan balansen handmatig overzetten naar een nieuw systeem en het oude ter hand houden als archief (desnoods alles uitprinten en dat als archief bewaren).

Als je de broncode van dat oude systeem hebt of kan krijgen kun je wellicht een programmeur betalen om exportroutines te schrijven naar CSV en op die manier te importeren in een nieuw systeem.

[RobIII]

Je screenshot is, helaas, de meest oninteressante ooit
Als we iets zinnig zouden kunnen zien in het bestand zijn het de eerste paar (honderd) bytes danwel de laatste. Dus doe daar eens een screenie van

Verder eens met Gerco in "Oude DOS datafiles omzetten naar modern formaat"

[ Voor 19% gewijzigd door RobIII op 26-12-2016 13:15 ]

[pistole]

Wellicht een open deur, maar zit er niet gewoon een 'export' commando in het programma? Of eventueel printen naar een virtuele tekst-only printer?

[farlane]

Heeft het pakket een naam?

[johnkeates]

Als je 21 bent is het misschien niet een taak voor jou je hebt de DOS tijd niet meegemaakt en daarmee ook de software-ontwikkelen-voor-DOS tijd niet, wat het hele concept van de software van toen eigenlijk te ver van je mogelijke kennis laat staan.

Aan de andere kant zijn de tips hier prima op te volgen:

- File header controleren op standaard formaten
- Programma decompileren om te kijken of er standaard bestandstoegang gebruikt wordt
- Programmanaam? (Grote Beer of Perfectview ofzo?)
- Exporteer functie? OCR op een text of pdf bestand uit een virtuele printer is makkelijker dan een bestandsformaat reverse-engineeren

Je kan ook het programma in DOS draaien en het geautomatiseerd besturen. Stel dat je bijv. een klantenbestand hebt en elke klant in 1 scherm past en er een "F8 voor volgende klant" knop is, dan kan je een stukje software maken dat een screenshot maakt, op F8 drukt en weer een screenshot maakt. Daarna doe je OCR op de screenshots en kan je de tekst in een echte database gooien.

[DJMaze]

"9" (0x39) ziet er uit als het veld type.
Vervolgens is de volgende byte de lengte van de waarde.
0x0D = 13 en het telefoon nummer is 13 bytes.

Maar het is lekker gissen en niet weten

[Dysmael]

Ik zie vaak dat de applicatie als archief bewaard wordt, werkend in een virtuele omgeving.
Qua omvang zit waarschijnlijk niemand dit in de weg en kan je er meerdere kopieën van bewaren.

Vervolgens met een schone lei beginnen en alleen wat courant is, desnoods handmatig overnemen.
Je kan dan prima het archief ter naslag ernaast houden en op het moment dat je iets in de nieuwe administratie mist dat ad-hoc invoeren.

Mijn gevoel zegt dat het allemaal niet zo omvangrijk zal zijn en bovenstaande veel minder tijd zal kosten dan andere trucages uithalen. De data blijft gewoon beschikbaar want ook een 16-bit dos applicatie kan je prima ergens (statisch) beschikbaar stellen voor naslag.

Als het wel wat spannender was geweest dan had het nooit zover gekomen en dat er nooit is geïnvesteerd in vernieuwing is vaak ook een indicatie dat het nu ook niet teveel geld mag kosten.

Waarschijnlijk een kwestie van "ik kijk wel even wat ik kan doen" en nog niet de ervaring hebben om gelijk af te kunnen kappen. Stel maar eens de vraag "mag het 10.000,- kosten?". Als het antwoord gelijk een volmondig "Ja!" is dan ga je verder en anders suggereer je dat wat handmatig tikwerk voordeliger is.

Edit: Uiteraard; als het een bekend formaat is waar een simpele conversie voor mogelijk is (DBaseIII naar Excel bv) dan kan een investering van een paar uur zich lonen. Maar dan moet je wel aanzienlijke tijd resultaat hebben. Vergeet niet dat je daarna de inhoud in een formaat hebt vanuit waar het nog naar de nieuwe applicatie moet worden ingelezen.

[ Voor 12% gewijzigd door Dysmael op 27-12-2016 19:07 ]

[BCC]

RolfLobker schreef op dinsdag 27 december 2016 @ 19:04:
Mijn gevoel zegt dat het allemaal niet zo omvangrijk zal zijn en bovenstaande veel minder tijd zal kosten dan andere trucages uithalen. De data blijft gewoon beschikbaar want ook een 16-bit dos applicatie kan je prima ergens (statisch) beschikbaar stellen voor naslag.

Dat kan zelfs via dosbox (javascript). Maat DBIV of DBIII zou ook mijn eerste gok zijn.

[ Voor 5% gewijzigd door BCC op 27-12-2016 19:07 ]

[Dysmael]

Dat is één van de vele mogelijkheden inderdaad.

[weebl]

Leuk projectje voor een regenachtige zondagmiddag, als het allemaal lukt inderdaad.
Vanuit een ondernemers perspectief zou ik er inderdaad niet al teveel aandacht aan besteden en het hele systeem vervangen. Oude systeem vanaf 1 januari 2017 (bijvoorbeeld) nog 7 jaar bewaren en daarna gewoon weggooien. Virtualiseer hiervoor het huidige systeem, of kijk of je de software onder DOSBox draaiend krijgt. Maar raad je vriend eerst aan een ander boekhoudpakket aan te schaffen, anno 2017 hiervoor nog met DOS werken kan echt niet meer...

[ToFast]

Je kunt het op zoveel systemen draaien, van een Nintendo ds tot Wii, van linux tot aan Windows10, op Android tot macos. Voor bijna alle systemen is wel een dosbox (port) beschikbaar :d

[ Voor 3% gewijzigd door ToFast op 27-12-2016 19:18 ]

[Dysmael]

En brengt steeds meer ellende met zich mee.

Zo mag ik over een paar dagen Exact voor DOS nog even naar een andere omgeving overbrengen. Op zich geen probleem. Dat is mooi te regelen door dit op een Windows Server 2008 (x86) met RemoteApp te integreren maar het aansturen van printers via printer queue redirection naar LPT poorten is verre van ideaal en stabiel.

[kmsch]

Goed, bedankt allemaal voor de ideeën en raad! Het kan dat dit project wat ambitieus is, maar ik wil het toch graag proberen. Desnoods ga ik er een middag voor zitten, handen afwisselend op de verwarming / toetsenbord en alles overtypen.

Dan ga ik het programma echter eerst aan de praat moeten krijgen. Bij mijn klant draait het onder Win7 32-bit. Als ik het via DOSBOX of WinXP draai krijg ik echter de volgende melding: http://imgur.com/a/JiPN9

INTNO.exe staat in een andere directory in dit programma. Ik heb het al gekopieerd / gepaste in verschillende mappen, maar dat lijkt niet de oplossing. Moet dit misschien in een van de Windows-systeemdirectories staan? Als ik het hier niet werkend krijg zal ik een middag bij mijn klant gaan zitten, kan natuurlijk ook.

Gerco schreef op maandag 26 december 2016 @ 05:52:
Haal dat bestand eens door het linux "file" command of TrID. Redelijke kans dat het een "standaard" formaat als DBaseIII is of iets dergelijks waar tools voor zijn. Als dat niet het geval is gaat het moeilijk worden en waarschijnlijk niet de moeite waard om om te zetten. Je kan dan balansen handmatig overzetten naar een nieuw systeem en het oude ter hand houden als archief (desnoods alles uitprinten en dat als archief bewaren).

"File" onder macOS geeft me http://imgur.com/a/PWMj1. Heb geen VM van Linux klaarstaan, maar dat kan ik nog proberen als dat uitmaakt?

Hierna heb ik TrID gedraaid. Dit heb ik gedaan op KLANTEN.DAT en KLANTEN.IND. TrID geeft aan dat de .DAT file eigenlijk een VXD-driver is. Wikipedia legt me wel ongeveer uit wat dat is, maar daar word ik nog niet zoveel wijzer van. Ofwel TrID herkent dit niet goed, of het is echt geen database-file. De .IND herkent hij niet. Hier de screenshot: http://imgur.com/a/nZUYC

RobIII schreef op maandag 26 december 2016 @ 13:08:
Je screenshot is, helaas, de meest oninteressante ooit
Als we iets zinnig zouden kunnen zien in het bestand zijn het de eerste paar (honderd) bytes danwel de laatste. Dus doe daar eens een screenie van

Verder eens met Gerco in "Oude DOS datafiles omzetten naar modern formaat"

Geanonimiseerd: http://imgur.com/a/Bjl8X

pistole schreef op maandag 26 december 2016 @ 13:18:
Wellicht een open deur, maar zit er niet gewoon een 'export' commando in het programma? Of eventueel printen naar een virtuele tekst-only printer?

Dit ga ik proberen zodra ik het aan de praat heb. Ik weet dat er uit het pakket geprint kan worden, dus een virtuele text-only printer kan een oplossing zijn, thanks!

farlane schreef op maandag 26 december 2016 @ 19:54:
Heeft het pakket een naam?

Het is geen standaardpakket. Dus de naam is in de trend van "Klusbedrijf Bob Berendsson".

Mocht dit allemaal te ambitieus blijken wordt het gewoon handwerk hoor! Maar ik hoor graag of jullie misschien iets begrijpen van de TrID-screenshots of HEX-editor. Alvast bedankt weer voor de hulp! Gr, Koen

[Foeijonghaai]

kmsch schreef op vrijdag 30 december 2016 @ 14:28:
Dan ga ik het programma echter eerst aan de praat moeten krijgen. Bij mijn klant draait het onder Win7 32-bit. Als ik het via DOSBOX of WinXP draai krijg ik echter de volgende melding: http://imgur.com/a/JiPN9

INTNO.exe staat in een andere directory in dit programma. Ik heb het al gekopieerd / gepaste in verschillende mappen, maar dat lijkt niet de oplossing. Moet dit misschien in een van de Windows-systeemdirectories staan? Als ik het hier niet werkend krijg zal ik een middag bij mijn klant gaan zitten, kan natuurlijk ook.

PATH goed zetten?

[McKaamos]

Foeijonghaai schreef op vrijdag 30 december 2016 @ 14:31:
[...]

PATH goed zetten?

Nee, INTNO goed zetten
PATH is slechts een enviroment variable. INTNO is dat ook.

Gewoon op de prompt 'set INTNO=getal' tikken, net zoals je doet met 'set PATH=C:\DOS' etc

Edit: Duw dat bestand anders eens door een online file-type checker, b.v. http://www.checkfiletype.com/
Misschien komt daar wat zinnigs uit.

[ Voor 18% gewijzigd door McKaamos op 30-12-2016 14:42 ]

[Foeijonghaai]

McKaamos schreef op vrijdag 30 december 2016 @ 14:40:
PATH is slechts een enviroment variable. INTNO is dat ook.

As de executable niet gevonden kan worden kan dat ook aan het pad liggen.

[McKaamos]

Foeijonghaai schreef op vrijdag 30 december 2016 @ 14:44:
[...]

As de executable niet gevonden kan worden kan dat ook aan het pad liggen.

True, maar ik gok dat de enviroment variable plausibeler is.
Meestal staat een applicatie niet in de PATH variable en wordt er gezocht naar bepaalde vaste/relatieve paden, maar een waarde specifiek voor de applicatie komt vaker voor.

Maargoed, het zou inderdaad kunnen. Ik zou eerst de INTNO variable goed zetten en dan pas gaan kijken naar PATH.

[kmsch]

McKaamos schreef op vrijdag 30 december 2016 @ 14:40:
[...]

Nee, INTNO goed zetten
PATH is slechts een enviroment variable. INTNO is dat ook.

Gewoon op de prompt 'set INTNO=getal' tikken, net zoals je doet met 'set PATH=C:\DOS' etc

Edit: Duw dat bestand anders eens door een online file-type checker, b.v. http://www.checkfiletype.com/
Misschien komt daar wat zinnigs uit.

Intno set heeft geholpen, dank! Ik kan het programma nu draaien. Ga straks de virtual printer testen.

Checkfiletype geeft helaas ook niet zoveel terug; op zowel KLANTEN.DAT als KLANTEN.IND krijg ik: http://imgur.com/a/2SMdh

Begin langzamerhand ook te begrijpen wat jullie bedoelen met het DOS-tijdperk niet meegemaakt hebben

[ Voor 6% gewijzigd door kmsch op 30-12-2016 15:04 ]

[DJMaze]

kmsch schreef op vrijdag 30 december 2016 @ 14:56:
KLANTEN.DAT als KLANTEN.IND

Oh die extensies ken ik uit een ver verleden. Klinkt als xBase

Maar toendertijd hadden we ook ".dbf" en ".ndx"

[ Voor 8% gewijzigd door DJMaze op 30-12-2016 15:56 ]

[jeroen3]

Precies DJMaze, het programma zal een databasestructuur gebruiken. Zoals inderdaad iets als xBase of FoxPro.
Hier kun je gewoon windows viewers of editors voor krijgen. Dus geen DOS.

kmsch schreef op maandag 26 december 2016 @ 02:13:
De bouwer van dit pakket bestaat al lang niet meer.

Waarschijnlijk nog wel. Maar is het overgenomen en overgenomen en overgenomen.

[ Voor 40% gewijzigd door jeroen3 op 30-12-2016 15:20 ]

[KatirZan]

Top, DBase, dat is lang geleden! Conversieprogramma's bestaan niet meer, dus dat wordt reverse coding, wat een hel gaat worden qua tijd.

Geen opties binnen het programma voor export in anders formaat? Vaak bestaat de mogelijkheid tot export in ascii formaat....

Ook oudere Microsoft producten willen dit nog wel eens voor je kunnen doen , denk aan 1 van de eerdere Access versies....

[kmsch]

Goed, vanavond zowel MS Access als FoxPro als printen naar Generic text geprobeerd, maar dat heeft nog niets opgeleverd. MS Access en FoxPro herkennen in elk geval geen structuur in de databasebestanden en het pakket krijgt nog geen verbinding met de printer.

johnkeates schreef op maandag 26 december 2016 @ 22:04:
Je kan ook het programma in DOS draaien en het geautomatiseerd besturen. Stel dat je bijv. een klantenbestand hebt en elke klant in 1 scherm past en er een "F8 voor volgende klant" knop is, dan kan je een stukje software maken dat een screenshot maakt, op F8 drukt en weer een screenshot maakt. Daarna doe je OCR op de screenshots en kan je de tekst in een echte database gooien.

Dit ben ik gaan doen. Ik heb Greenshot en Jitbit Macro Recorder gebruikt om geautomatiseerd screenshots te nemen en door het programma heen te bladeren. Ik heb nu zo'n 500 screenshots van de actieve klantenkaarten.

Ik ga nu eens een Photoshop-macro maken om de screenshots wat verder uit te snijden en daarna OCR toepassen. Daarmee heb ik alle data die ik nodig heb.

Bedankt voor de hulp allemaal! En fijne feestdagen

[McKaamos]

Is het niet handiger om de textuele output van het scherm op te vangen in een logbestand en dan een Regular Expression (aka 'regex')er overheen te halen om de individuele beelden te scheiden?
(ik neem aan dat het beeld tekstbased met kleur is, zoals de foutmelding screenshot?)
Zou moeten kunnen met de debugger functie van Dosbox. Alle textuele output wegschrijven naar een log-file.

Iets als ^('eerste regel van het beeld')(.*)('laatste regel van het beeld')$.
uiteraard met correcte escaping, en een correcte definitie van de eerste en laatste beeldregel van 1 scherm.
Een dergelijke regex is 'greedy', en zal dus het eerste beeldeinde na een beeldbegin pakken, waarmee je effectief beelden kan scheiden.
De ( en ) tekens zorgen voor groepering, zodat je het middenstuk er uit kan pakken en weer kan voeren aan een nieuwe regular expression, of alles zelfs regel-voor-regel laten verwerken met if/then/else-jes in een programmeertaal die makkelijk werkt met platte tekst. PHP is er best goed in, vind ik. Pyhton is ook een prima taal. Visual Basic zal allicht ook een prima keus zijn, etc etc.

En dan prak je de output in een nette gesorteerde CSV of XLS (indien XLS output beschikbaar voor de gekozen taal)

[ Voor 4% gewijzigd door McKaamos op 30-12-2016 23:51 ]

[kmsch]

Verschillende OCR-programma's geprobeerd, waarvan Adobe Acrobat nog het beste resultaat levert. Hier helaas veel fouten in. OCR heeft moeite met de lage resolutie + DOS-lettertype, dus elke record bevat wel een fout.

Zal eens kijken McKaamos of ik verder kom met loggen. Denk dat dat meer kans heeft.

[Rukapul]

kmsch schreef op zaterdag 31 december 2016 @ 01:49:
Verschillende OCR-programma's geprobeerd, waarvan Adobe Acrobat nog het beste resultaat levert. Hier helaas veel fouten in. OCR heeft moeite met de lage resolutie + DOS-lettertype, dus elke record bevat wel een fout.

Los van de vraag of grafisch screenshotten + OCR de handigste aanpak is voor dit probleem, is bovengenoemde methode van OCR natuurlijk niet geoptimaliseerd voor de toepassing.

OCR in de applicaties die je getest hebt zijn bedoeld voor afbeeldingen met ruis, want gescand, etc.

De screenshots bevatten echter nul ruis aannemende dat er niet geschaald wordt. OCR in dat geval is triviaal als het puur DOS in textmode is, zeker als er gebruik gemaakt wordt van fixed width fonts zoals gebruikelijk.

Met nul eerdere ervaring heb ik laatst in een uurtje letters herkend met een eenvoudig python script. Juist als er geen ruis is hoef je alleen maar x by y pixels in een grid te matchen tegen een dictionary die je on the go kunt uitbreiden (max benodigde aantal samples bepaald doorhet gebruikte deel van de character set).

[ Voor 3% gewijzigd door Rukapul op 31-12-2016 07:30 ]

[Dacuuu]

Probeer als ocr software, Abbyy of omnipage eens, dit zijn prima ocr paletten waar ik zelf de beste ocr ervaring heb.

[Squ1zZy]

Ik zie nog niet om hoeveel data het gaat. Hoe groot is klanten.dat? Als het 100 regels zijn was overtypen inderdaad sneller geweest als het alleen om de platte data gaat.

Kan je het programma niet ergens online zetten zonder klantendata erin?

[JosSchaars]

.IND was eens de extensie voor DataPerfect indexbestanden.
Dat wil nog niet zeggen dat het DOS programma inderdaad in DP geschreven is. Dit is vrij simpel te controleren: DP start met DP<versie nummer>.exe.

Als je het programma onder DOSBox kunt draaien, zal het ook wel onder vDos (www.vdos.info) werken. Hierin kun je tekst rechtstreeks van het scherm kopiëren, of overzichten afdrukken naar Windows printers. De afdruk zelf (eventueel naar een PDF document) is niet eens interessant: vDos maakt tevens een tweetal tekstbestanden van de afgedrukte data. Een in ASCII en een in Unicode, de laatste is wellicht het meest geschikt om de data in een Windows programma te importeren.

[niekvanprooijen]

Misschien haal je wel het beste resultaat door de overzichten op papier, dat witte rechthoekige spul, te printen en vervolgens in te scannen om vervolgens OCR te gebruiken. Waarschijnlijk krijg je dan betere resultaten dan wanneer je een screenshot pakt, gezien de hogere resolutie van het printen.

[McKaamos]

Squ1zZy schreef op zaterdag 31 december 2016 @ 10:22:
Ik zie nog niet om hoeveel data het gaat. Hoe groot is klanten.dat? Als het 100 regels zijn was overtypen inderdaad sneller geweest als het alleen om de platte data gaat.

Kan je het programma niet ergens online zetten zonder klantendata erin?

Hij had het over een stuk of 500 pagina's met klant informatie.
Tenminste, wat er nu gescreenshot is. Het zal allicht meer zijn.

En idd, het programma met een lege database (of gevuld met dummydata) mag best even online
Je zou er een coding challenge van kunnen maken. Wie haalt zo efficient mogelijk de data over naar CSV/XLS?

niekvanprooijen schreef op zaterdag 31 december 2016 @ 10:57:
Misschien haal je wel het beste resultaat door de overzichten op papier, dat witte rechthoekige spul, te printen en vervolgens in te scannen om vervolgens OCR te gebruiken. Waarschijnlijk krijg je dan betere resultaten dan wanneer je een screenshot pakt, gezien de hogere resolutie van het printen.

Op het huidige tempo verbras je dan minstens een heel pak printerpapier. Lijkt me niet echt ideaal.
En scannen is nou ook niet echt snel als actie opzich, laat staan het steeds moeten invoeren van een nieuw velletje op je fancy flatbed scanner
Leuk als je engelengeduld hebt, en veeeeeeel teveel vrije tijd.

Nee, ik denk dat je beter kan kijken of je text output in een textfile kan krijgen en dat parsen met regexjes in een makkelijk te gebruiken taal.
Even USB Webserver op je PC plempen, PHP scriptje kalken en het hele zooitje linea-recta een MySQL database in trappen. Kan je daar na evt exporteren naar CSV, XLS of een SQL-file.

[ Voor 47% gewijzigd door McKaamos op 31-12-2016 11:16 ]

[Squ1zZy]

McKaamos schreef op zaterdag 31 december 2016 @ 11:12:
[...]

Hij had het over een stuk of 500 pagina's met klant informatie.
Tenminste, wat er nu gescreenshot is. Het zal allicht meer zijn.

En idd, het programma met een lege database (of gevuld met dummydata) mag best even online
Je zou er een coding challenge van kunnen maken. Wie haalt zo efficient mogelijk de data over naar CSV/XLS?

Hmm ok. Weten we al of alle data er plat in staat? Misschien is de naam, straat etc. in platte text opgeslagen, maar staat er ook data encrypted.

Programma online zou wel helpen. Ik kan wel even snel kijken door het te reverse engineren.

[McKaamos]

Squ1zZy schreef op zaterdag 31 december 2016 @ 11:13:
[...]


Hmm ok. Weten we al of alle data er plat in staat? Misschien is de naam, straat etc. in platte text opgeslagen, maar staat er ook data encrypted.

Programma online zou wel helpen. Ik kan wel even snel kijken door het te reverse engineren.

Ah jij denkt aan reverse engineeren van de database files zelf?
Voor zover de screenshots verraden is het plaintext met database structuur er omheen. Dus dat zou opzich geen probleem mogen zijn voor de leesbaarheid. De vraag is of je de data bij elkaar kan krijgen die bij elkaar hoort.

Encryptie is waarschijnlijk geen issue. Dat was destijds nog helemaal niet ingeburgerd, en als het er al wel was, dan kan je dat met een PC van tegenwoordig binnen 5 minuutjes kraken.

[ Voor 12% gewijzigd door McKaamos op 31-12-2016 11:20 ]

[Sendy]

Als je gaat reverse engineren wil je ook weten welke velden er zijn (welke invulvelden heb je in de UI?), hoe lang die velden zijn (hoe lang zijn de invoervelden in de UI?), welke mogelijke waarden er zijn (wat mag er getypt worden in welk veld?). Dit soort informatie maakt het interpreteren van de data aanzienlijk makkelijker.

[Squ1zZy]

McKaamos schreef op zaterdag 31 december 2016 @ 11:18:
[...]

Ah jij denkt aan reverse engineeren van de database files zelf?
Voor zover de screenshots verraden is het plaintext met database structuur er omheen. Dus dat zou opzich geen probleem mogen zijn voor de leesbaarheid. De vraag is of je de data bij elkaar kan krijgen die bij elkaar hoort.

Kijken hoe de applicatie de data wegschrijft. Als je weet hoe de data wordt weggeschreven is het makkelijk uit te lezen.

[G.Shumway]

Wat ik me afvroeg: "Zijn de dos-scherm-rubrieken te Kopieren?"
Zo ja, dan kan je relevante klanten toch overnemen (bv mbv AutoIt) naar een nieuwe applicatie.

[jeroen3]

Copy-Pasten met AutoIt kan wellicht werken. Tame kan hier wellicht hulp in bieden.

[Yucon]

Kun je niet gewoon een backup van de bestanden maken, 1 record toevoegen, en dan met een compare tool beide bestanden met elkaar vergelijken? Dat is hierboven al eens geopperd en ik zou toch echt eens in die richting zoeken.

[DutchKel]

Ik weet dat in het dos tijdperk het behoorlijk gewoon was om een eigen dataset te maken in C. Dit is data wat in het geheugen staat van variabelen wat letterlijk naar een binair bestand wordt beschreven. Meestal krijg je een soort scheidingsteken gevolgd door leesbare tekst, maar dit is wel afhankelijk van het datatype.

Dit was in die tijd erg normaal omdat er in dos niet standaard database drivers zijn en deze in C of Pascal gebruiken was niet makkelijk.

Ik gok dat dit ook zo'n eigen dataformaat is. Zelf heb ik in borland C zo ook vaak data weggeschreven, het was makkelijk en snel. Hoe het in details in code werkt weet ik niet meer want de laatste keer dat ik iets in borland C schreef is toch wel ergens in 1999 ofzo geweest.

Een nadeel van deze methode was dat als 1 teken in het bestand verkeerd was, dan kon je het hele bestand niet meer laden.

[SMSfreakie]

Interessante materie ook wel wat van voor mijn tijd... maar dit topic maakt me wel even nieuwschierig

[technorabilia]

Het volgende is geen optie?
http://wiki.bgbm.org/rebi...ex.php/Export_DataPerfect
https://github.com/DANS-KNAW/dans-dp-lib

[ Voor 17% gewijzigd door technorabilia op 31-12-2016 23:06 ]

[Marc H]

Bekijk de applicatie zelf eens met een hex editor. Met een beetje mazzel kan je zien in welke taal of applicatie het gemaakt is.

Kan je een zip maken van het programma met een dummy database? Dan kunnen we zelf experimenteren.

[oldsmelly]

.ind en.dat files komt redelijk overeen uit mijn tijd toen ik nog cobol kraste met accu-cobol etc en microfocus cobol.

Oude Foxpro files en andere "'dbf" kun je makkelijk openen met excel !
Desnoods download je de ODBC driver voor foxpro.

[JosSchaars]

De complexiteit van (DOS) database bestanden wordt hier blijkbaar zwaar onderschat. Zelfs zonder de indexbestanden van een ISAM database erbij te betrekken. Er waren ten tijde van DOS wel degelijk “standaard” bibliotheken met een API om geïndexeerde databases te onderhouden.

Schijfruimte was nogal beperkt, de gegevens werden vaak gecomprimeerd weggeschreven. Strings met (varianten van) RLE, floating point getallen in een zestal varianten, integers afhankelijk van mogelijke waarden, fixed decimal point getallen als ASCII, binary integers, decimal packed, datums in legio formaten, BLOB’s… En (extended) ASCII tekens zonder bijbehorende codepage hebben weinig betekenis.
Een fysieke database record kan een variabele lengte hebben, die weer over meerdere logische pagina’s in het databestand is verspreid.

Reverse enginering van een, iets meer dan rudimentaire, database is daarmee monnikenwerk. Overtypen van een 500 records meer realistisch (maar ook niet nodig).

[ShitHappens]

Is het inderdaad mogelijk een deel van de bestanden, of leeg, of met dummy data gevuld (al dan niet met programma) te publiceren? Ik heb met enige regelmaat te maken met antieke databases dus kan best zo zijn dat hier iets staat dat ermee overweg kan.