Ein Verstorbener hat mir einen MSDOS PC hinterlassen, auf dem viele
Software Werkzeuge zum Schreiben von Programmen bzw. Konfigurieren von
alten Steuerungen installiert sind. Die installierte Basis ist dabei
MSDOS 6.22. Ich bin jetzt auf ein Programm "spindu.exe" gestoßen, das im
Wesentlichen gut funktioniert. Lediglich eine Funktion, nämlich der
Aufruf der Dateiübersicht der abgespeicherten Konfigurationen antwortet
mit "falsche DOS Version". Jetzt habe ich spindu.exe auf einem anderen
PC mit MSDOS 5.00 gestartet. Darauf funktioniert auch dieser Teil des
Programmes.
Danach habe ich auf dem anderen PC spindu.exe mit MSDOS 6.22 gestartet.
Per "setver" Befehl habe ich das Programm "spindu.exe" mit 5.00"
eingetragen. Wenn ich "setver" eingebe, bekomme ich eine Liste an deren
Ende "spindu.exe 5.00" steht. Dennoch kommt in spindu.exe an der
bewussten Stelle die Meldung "falsche DOS Version".
Habe ich setver korrekt angewendet?
Hätte mit setver 5.00 das "falsche DOS Version" verschwinden müssen?
Theoretisch könnte ich das Programm spindu.exe auf einen separaten MSDOS
5.00 PC umziehen, was ich aber vermeiden möchte. Kann ich sonst noch
etwas tun, um es unter 6.22 zum Laufen zu bekommen? Unter installiertem
6.0 läuft es auch nicht.
supergrobi schrieb:> Besorg dir eine Liste der BIOS/DOS-Calls.>> Such den entsprechenden Call (DOSVER) in deinem Programm.>> Sorge dafuer, dass das Programm gluecklich ist!
Meinst Du, dass ich im Quelltext von spindu.exe arbeiten soll? Den habe
ich nicht.
Das "B4 30 CD 21" findet man im Hexdump bestimmt schneller
als im Quelltext.
AH=30h - GET DOS VERSION
Das folgende Beratungsmuster wurde auch gluecklich gemacht
und verweigerte danach nicht mehr die Kooperation mit seiner
Meinung nach falschen Versionen...
1
X:\>ver
2
3
Microsoft Windows XP [Version 5.1.2600]
4
5
X:\>netx
6
7
NetWare Workstation Shell v3.32 (940524) PTF
8
(C) Copyright 1994 Novell, Inc. All Rights Reserved.
9
Patent Pending.
10
11
Running on DOS V6.99
12
13
SHELL-332-23: IPX has not been loaded. Please load and then run the shell.
supergrobi schrieb:> Besorg dir eine Liste der BIOS/DOS-Calls.>> Such den entsprechenden Call (DOSVER) in deinem Programm.>>> Rufus Τ. F. schrieb:>>> Setver ist auch in der config.sys eingetragen?>> Kevin Lars schrieb:>> Ja
Damit ist klar, dass das nicht helfen kann, denn ziemlich genau das ist
ja die Aufgabe von setver, einen Interceptor für diesen Call für dieses
Programm zu installieren. Der wirkt aber offensichtlich nicht, ergo:
dieses ominöse "spindu.exe" benutzt eben nicht diesen call, um die
DOS-Version zu ermitteln. (oder liefert im schlimmsten Fall überhaupt
eine Fehlermeldung, die mit seinem tatsächlichen Problem rein garnix zu
schaffen hat).
Ich würde aber mal stark darauf tippen, dass das eine
"behavioral"-Geschichte ist. Sprich: das Programm will irgendwas machen,
was so unter DOS6.22 nicht geht (aber unter DOS5) und zieht DARAUS den
Schluss, dass es nicht unter DOS5 läuft. D.h.: es gibt überhaupt keinen
expliziten Aufruf von DOSVER. Dann kann man diesen natürlich auch nicht
patchen oder mit dosver überlisten.
Lösen kann man das Problem natürlich mit Assembler nach einer lustigen
Disassemblerorgie. Man stellt als erstes fest, wo das Programm diese
Fehlermeldung generiert. Dann: wie kommt es zu dieser Stelle. Bis
hierhin ist das alles noch relativ einfach. Aber dann wird's
kompliziert: man muss verstehen, was das Programm eigentlich zu tun
versucht und woran das dann unter DOS6.22 letztlich scheitert.
Hat man das verstanden, wird's wieder einfacher: man schreibt Code, der
das Gewünschte unter DOS6.22 leisten kann und patched das in den
Originalcode...
1. Kannst du die spindu.exe irgendwo hoch laden dann jage ich die mal
durch meinen IDA dissassembler, vielleicht laesst sich das wirklich
leicht patchen
2. Was macht das Programm denn genau, Hardware Kommunikation?
3. Hast du mal FreeDos probiert?
So steinalte Programme nehmen entweder selbst oder per dazugelinkter
Runtimelibrary die Funktion 30h von DOS.
Die ganze Uebung reduziert sich dann darauf. nach den oben schon
genannten Hexcodes zu suchen und entweder die weitere Auswertung
"totzulegen" oder ihr einen geeigneten Wert unterzuschieben.
Dazu brauchte man damals nicht mal IDA...
(Heute natuerlich auch nicht.)
Die Versionsabfrage war eher ein staendiger laufender Verkaufsmotor,
um den Kunden scheinbar "neue" Software andrehen zu koennen.
Rufus Τ. F. schrieb:> Was macht denn "spindu.exe" so interessantes, daß man sich ein> Vierteljahrhundert nach dem Ableben von DOS noch damit beschäftigen> will?
Beispiel: Es gibt eine Stadtbahnlinie (U79) zwischen den Nachbarstädten
Düsseldorf und Duisburg, die an den Endpunkten in beiden Innenstädten
unterirdisch fährt. Unterirdisch geht heutzutage nichts ohne Computer.
Diese Steuerung ist veraltet. Die Leute, die sich damit auskennen, sind
eigentlich schon in Rente oder gar gestorben. Da Duisburg anders als
Düsseldorf nicht das Geld hatte, um eine neue Steuerung zu kaufen,
drohte die Stilllegung ab Stadtgrenze.[1]
Man wirft also ein Stück Ubahn weg, weil die Steuerung veraltet ist.
Dabei ist die "Peripherie" des Computers also die eigentliche Ubahn noch
gut in Schuss. Für U-bahnen gäbe es aber wenigstens neue Steuerungen,
die dann aber mitsamt aller Sensoren und Aktoren entlang der Strecke und
in den Bahnen ausgetauscht werden muss. Fast immer ist die Software und
oft auch die Hardware proprietär. Häufig hat man eine technische
Einrichtung mit fertigen PCs als Blackbox mitsamt aufgespieltem
ausführbaren Programm (z.B. *.exe) geliefert bekommen und muss sich in
vielen Fällen sogar um die Sicherung desselben bemühen, also die
Festplatte imagen oder Eproms oder Microcontroller auslesen.
Anders als bei der Ubahn gibt es neue Steuerungen für viele technische
Einrichtungen nicht. Und ohne exakte Kenntnis jedes einzelnen kleinen
Mechanismus und des Anwendungsprozesses kann man auch keine neue bauen
bzw. programmieren. Häufig ist aber nur bekannt, wie sie bedient wird.
Genau so, wie in einem Haushalt niemand weiß, wie ein elektronisches
Klavier (z.B. die Anschlagdynamik) aufgebaut ist. Bedienen also Spielen
kann man es trotzdem.
Über den politischen Aspekt, dass der Neubau vieler
Verkehrsinfrastrukturprojekte gefördert wird, nicht aber deren
Unterhaltung (z. B. jede Menge marode Brücken in Deutschlands Kommunen)
wollen wir hier nicht diskutieren.
Ein Aspekt, sich damit zu beschäftigen ist es, diese alte Technik am
Laufen zu halten. Bei sehr speziellen Ausnahmefällen kann es sogar sein,
dass neuere Technik schlicht nicht existiert und noch MSDOS Technik
(oder aus der Vorcomputerzeit) gebraucht gesucht und gekauft wird. Es
muss sich erst mal eine Firma finden, die den Aufwand einer
Neuentwicklung wagt und finanziert. Oft ist schlicht deutlich günstiger,
das Alte weiter zu betreiben, als eine Neuentwicklung. Ich habe eine
Klinker- und eine Bürstenfabrik gesehen, wo man sich wie im Museum
fühlt. Da stehen teilweise rein mechanische Steuerungen mit
Kurvenscheiben und gekröpften Wellen. Das hat natürlich auch einen
nachhaltigen Aspekt und lässt sich offensichtlich so wirtschaftlich
betreiben.
Dieser Nachteil hat aber auch eine positive Seite. Man kann Elemente
solcher einstmals unerschwinglichen Steuerungen oder unbrauchbar
gewordene technische Einrichtungen heute günstig bei ebay also auch
privat kaufen. (U-bahnen habe ich allerdings noch nicht gesehen. ;-) Da
kommt für viele Nerds der Hackeraspekt zum Tragen, so etwas zu
ergründen. Beispielsweise Fabs können sich so manche Dinge (z.B.
Drehbänke und Fräsen) überhaupt erst leisten und dann durch Selbstbau
die Steuerung ersetzen oder überhaupt erst computerisieren. Man findet
im Internet viele Projekte, wo alte mechanische ursprünglich
industrielle Technik in privaten Garagen steht.
Letztendlich ist "spindu" nur ein Beispiel aus vielen (proprietären)
Softwarewerkzeugen auf dem besprochenen PC, mit denen man solche alten
Maschinen konfigurieren oder mit einer eigenen Programmiersprache
programmieren kann. Auch die besprochene Ubahn könnte über solche
Werkzeuge verfügen.
Das Problem ist bei technischen Einrichtungen aus der Vorcomputerzeit
nicht so ausgeprägt. Denn da gibt es keine unsichtbare Programmierung.
Man kann aus den Leiterbahnen und den ICs den Schaltplan reengineeren.
So etwas ist besser wartbar. Alte ICs gibt es meist noch auf ebay. Die
meisten Datenblätter sind gescannt. Das Problem kam also mit den
Computern.
Das Problem bei Spindu ist nicht so gravierend. Denn man kann sich die
Dateiliste auch auf dem Umweg über MSDOS anschauen. Da das aber nicht
multitaskenderweise geht, ist es umständlich. Es wäre schön gewesen,
wenn sich das mit Setver oder ähnlich hätte lösen lassen. Es ist aber
kein Weltuntergang, wenn es nicht geht.
[1]
https://de.wikipedia.org/wiki/D%C3%BCsseldorf-Duisburger_Kleinbahn#Zukunft
> der Hackeraspekt
SETVER ist fuer Warmduscher und wie man sieht ja auch erfolglos.
Das Wegpatchen der Versionsabfrage eigentlich nur eine
Fingeruebung.
Wenn dich das alte Zeug fasziniert, solltest du deine
Methoden mal ueberdenken.
Hallo Kevin Lars,
Dein letzter Eintrag ist sehr interessant. Mich würde aber Folgendes
interessieren:
1. Was macht das Programm spindu.exe genau?
2. Welche Unterschiede gibt es in der autoexec.bat zwischen den
Installationen MSDOS 5.0 und MSDOS 6.x (bitte genau vergleichen!)?
3. Welche Unterschiede gibt es in der config.sys zwischen den
Installationen MSDOS 5.0 und MSDOS 6.x (bitte genau vergleichen!)?
4. Falls autoexec.bat und config.sys von MSDOS 5.0 auf MSDOS 6.x
weitestgehend übertragbar sein sollte, was ist das Ergebnis?
5. Wieviel RAM ist in beiden Maschinen verbaut?
6. Startest Du das Programm direkt in MSDOS oder in der Windows-Command
Shell (DOS-Box)?
Mit der Bitte um Antworten!
Kevin Lars schrieb:> Rufus Τ. F. schrieb:>> Was macht denn "spindu.exe" so interessantes, daß man sich ein>> Vierteljahrhundert nach dem Ableben von DOS noch damit beschäftigen>> will?>> Beispiel: Es gibt eine Stadtbahnlinie (U79) zwischen den Nachbarstädten> Düsseldorf und Duisburg, die an den Endpunkten in beiden Innenstädten> unterirdisch fährt. Unterirdisch geht heutzutage nichts ohne Computer.> Diese Steuerung ist veraltet. Die Leute, die sich damit auskennen, sind> eigentlich schon in Rente oder gar gestorben. Da Duisburg anders als> Düsseldorf nicht das Geld hatte, um eine neue Steuerung zu kaufen,> drohte die Stilllegung ab Stadtgrenze.[1]
Naja, über das Thema Duisburg und Ubahn schweigen wir lieber:
https://www.ksta.de/region/rheinbahn-duesseldorf-neue-strassenbahn-zu-breit-fuer-duisburger-u-bahn-tunnel-31408636
>Es ist aber kein Weltuntergang, wenn es nicht geht.
Du laesst es uns ja nicht weitergehend probieren - siehe meine Fragen,
auf die du nicht geantwortet hast
auch Fragen von anderen sind noch offen
Ich finde deine Strategie gut und habe schon ein paar kleinere Dos
Programmen für sowas wieder zum Leben verholfen oder Nachbauten (ohne
Quelltext zu haben) erstellt
Kopiere dochmal die COMMAND.COM des DOS 5.0 auf den 6.22-PC und führe es
dort aus mit spindu.exe als Argument.
Ich hab auch viele uralte DOS-Programm auf modernen PCs unter DOSBox zum
Laufen gebracht. Sogar die COM1..4 laufen dort wieder (über
USB-Umsetzer).
https://www.dosbox.com/
supergrobi schrieb:> Das "B4 30 CD 21" findet man im Hexdump bestimmt schneller> als im Quelltext.>> AH=30h - GET DOS VERSION
es muss ja nicht sein, dass das AH Register direkt vor dem CALL geladen
wird.. ich würde erst mal nach CD 21 suchen und dann was davor passiert
es gibt auch noch sowas
Ab DOS 5.00 lässt sich die „wirkliche” Versionsnummer mit einer
Untervariante der Funktion 33h abfragen:
Aufruf: AH=33
AL=06 Untervariante „Get Version”
Return: AL=FF Fehler, diese Funktion wird nicht unterstützt
AL=06 diese Funktion wird unterstützt. Dann gilt:
BL= DOS-Version
BH= Revision
DX=Bitflag
Bits 0,1,2 Revisionsnummer im Bereich 0 bis 7
Bit 11 1=ROM-Version von DOS
Bit 12 1=DOS ist im HMA-Bereich geladens:
WR schrieb:> Was macht das Programm spindu.exe genau?
Es sind wie gesagt mehrere Programme auf dem PC. Spindu ist nur eines
von vielen. Es sind Programme zum Konfigurieren von Motorsteuerungen,
Mischautometen, Klimakammern, Türsteuerungen, Uhren, Verkaufsautometen,
Maschinen zur Herstellung von Wicklungen für Motoren und Trafos etc.
sowie diverse SPS Programmierumgebungen. Bei einigen muss ich noch
ergründen, wozu sie dienen. Das wird sich hoffentlich spätestens dann
herausstellen, wenn die zugehörigen Geräte ausfallen oder geändert
werden müssen. Wenn das nie der Fall sein wird, werden diese überhaupt
nicht mehr laufen müssen.
Es gibt also viel dringendere Probleme zu lösen, als das Setver. Wenn
ich spindu auf MSDOS 5.0 draufsetze, funktioniert es korrekt. Aber es
ist dann nicht gesagt, dass die anderen Programme dann noch
funktionieren. Da diese wie gesagt, teilweise noch nie probiert werden
konnten, belasse ich es bei dem oben beschriebenen Workaround. Das
Andere folgt, wenn ich mal ganz viel Zeit haben sollte ......
Es steht jetzt ins Haus, die Programme mit geklärtem Zweck auf neueren
Rechnern zum Laufen zu bekommen. Das größte Problem ist dabei
vermutlich, die COM Schnittstellen zu den Geräten ans Laufen zu
bekommen. Freedos, Dosbox und Virtualbox sind die Kandidaten.
Kevin Lars schrieb:> Es gibt also viel dringendere Probleme zu lösen, als das Setver. Wenn> ich spindu auf MSDOS 5.0 draufsetze, funktioniert es korrekt. Aber es> ist dann nicht gesagt, dass die anderen Programme dann noch> funktionieren. Da diese wie gesagt, teilweise noch nie probiert werden> konnten, belasse ich es bei dem oben beschriebenen Workaround. Das> Andere folgt, wenn ich mal ganz viel Zeit haben sollte ......
Früher wurde manchmal ziemlich häßlich programmiert (BTDT), da könnten
auch Systemdateien zur Prüfung gelesen worden sein oder bestimmte
DOS-Funktionen auf bestimmte Rückgabewerte (zwecks Unterstützung
bestimmter Features) aufgerufen werden.
Da heute Festplattenplatz extrem billig ist: mach dir doch einfach ein
Multiboot-System, auf dem du DOS 3.3, 4.0, 5.0 und 6.22 installierst.
Dann kannst du die alten Programme jeweils zum passenden OS packen.
Ein Bootmenü sollte sich auch noch finden lassen (notfalls nimmt man
dafür ein kleines Linux, um das über grub zu lösen).
Kevin Lars schrieb:> Theoretisch könnte ich das Programm spindu.exe auf einen separaten MSDOS> 5.00 PC umziehen, was ich aber vermeiden möchte. Kann ich sonst noch> etwas tun, um es unter 6.22 zum Laufen zu bekommen? Unter installiertem> 6.0 läuft es auch nicht.
Warum willst du es auf MS-DOS 6.x umstellen?
MS-DOS 6.x bietet jetzt nicht so viel neues gegenüber MS-DOS 5.x dass
man MS-DOS 6.x unbedingt braucht.
MS-DOS 6.x bietet weder fat32 noch kann es mit langen Dateinahmen
umgehen. Das kam alles erst mit MS-DOS 7 bzw. Win95 bzw. Win95b.
c-hater schrieb:> Lösen kann man das Problem natürlich mit Assembler nach einer lustigen> Disassemblerorgie. Man stellt als erstes fest, wo das Programm diese> Fehlermeldung generiert. Dann: wie kommt es zu dieser Stelle. Bis> hierhin ist das alles noch relativ einfach. Aber dann wird's> kompliziert: man muss verstehen, was das Programm eigentlich zu tun> versucht und woran das dann unter DOS6.22 letztlich scheitert.
Hypothese:
Diese Funktion könnte eine bloße Arbeitssicherungsmaßnahme gewesen sein.
Damit der Entwickler wieder den Job kriegt, wenn das Betriebssystem
irgendwann mal gewechselt und auf neue Systeme umgestellt wird.
Wenn dem so ist, dann macht die Funktion gar nichts außer zu prüfen, ob
das eine alte DOS Version ist.
Das geht schon in dem man einen kleinen Bytestrom des DOS Kernels
einliest, daraus einen Hash bildet und den Hash mit dem zu erwartenden
Hash vergleicht. Ist der dann nicht identisch, dann ist es die falsche
DOS Version.
Der Trick würde also in dem Fall also darin bestehen einfach die
Sprunganweisung zu ändern. Im Prinzip ist das wie beim Cracken eines
Kopierschutzes.
Letzten Endes will man ja nicht wissen, was das Programm bei der
Überprüfung macht, sondern was es danach macht, wenn die Prüfung
erfolgreich war.
Wenn das Programm für eine U-Bahn eingesetzt wurde, dann könnten aber
auch rechtliche Gründe der Grund sein warum man die DOS Version abfragt.
Denn das Programm wurde nur für eine bestimmte DOS Version spezifiziert
und darauf umfangreich geprüft.
Aus Haftungsfragen könnte der Hersteller also ein Interesse daran gehabt
haben, dass das Programm den Dienst verweigert, wenn es nicht das
System, für welches es spezifiziert wurde, vorfindet.
Will man setver überlisten, dann geht das wie oben beschrieben.
Wenn das Programm die DOS Version nur anhand der msdos.sys Datei auf dem
Datenträger überprüft und nicht an dem Kernel, der tatsächlich in den
Speicher geladen wurde, dann könnte man auch versuchen dem Programm
einfach die Datei eines alten Kernels unterzuschieben, während der neue
Kernel im Speicher läuft.
Versuch dazu mal die Dateien einfach mal umzukopieren.
Wenn der neue Kernel geladen ist, die Datei des neuen Kernel nach
msdos.bac
umkopieren und dann den alten Kernel nach msdos.sys kopieren.
Danach das Programm starten. Wenn die Funktion dann läuft, dann wird nur
die Kerneldatei überprüft.
