Laden einer alten 16 Bit dll unter WinXP?

[Nintendo]

Hallo,

ich habe eine alte dll aus win3.1 Zeiten. Ich besitze den Quelltext, weiß aber auch, das unter windows NT das Laden und Verwenden von 16 Bit dlls nicht mehr so einfach möglich ist.

Um nun nicht alles neu schreiben zu müssen und auch aus Interesse am Problem an sich, will ich diese DLL nun mit eigenen Routinen in den Speicher laden.
Meine konkrete Dll verwendet außerdem Bibliotheken, die ich momentan nur im 16 Bit Format verfügbar habe. Neben dem Ouellcode der Dll besitze ich noch den Binärcode der Dll.

Meine Überlegung ist folgende:

Die CPU (32Bit) kann 16 Bit Code noch immer ausführen. Win 3.1 Programme laufen auf Windows XP.

Deshalb sollte es doch möglich sein, unter Beachtung des anderen Formats der Startadresse der Funktionen in der DLL

(32 Bit -> Flat Modell -> 32 Bit Offset)
(16 Bit -> Segment Modell -> 32 Bit Pointer -> Segment:Offset)

Lineare Adresse := Sement * 16 + Offset
Offset := Lineare Adresse - Segment * 16
Segment := (Lieare Adresse - Offset) div 16

So sollte es doch möglich sein, die in der DLL codierten Funktionen dennoch aufzurufen, ja wenn ich das exakte Format der guten alten 16 Bit DLL genau kennen würde. Dann nämlich könnte ich mir die Laderoutinen schreiben und eine Tabelle mit den von der DLL exportierten Funktionen bereit setellen. Von dieser Tabelle aus sollte der Aufruf doch dann klappen, oder?

Ich bin nicht ausschließlich an der Nutzung der DLL Funktionen, sondern auch an der Lösung des hier geschilderten Problems interessiert. Die DLL enthält zudem auch sehr viele Funktionen. Eine Neukodierung würde also auch recht vielZeit in Anspruch nehmen, nicht nur wegen veränderter Direktiven (stdcall statt export, ...)

Wo also finde ich das genaue Format der alten 16 Bit dll.

Ich habe das hier: file:///C:/Daten/SystemAdmin/Eigene%...og_public.html

gefunden. Das bezieht sich aber auf heutige 32 Bit DLLs und die Beschreibung des Formates ist mir dort nicht dateiliiet genug. Die Seite verlinkt außerdem auf eine c++ Bibliothek zum Laden einer DLL in den Ram, nutzt aber auch Standard Windows Funktionen zum Laden.

Wegen der Problematik, das eine 16 Bit DLL unter Windows NT nur mit Einschränkungen nutzbar ist, will ich die Laderoutinen komplett selber schreiben und die Exporttabelle auf der 32 Bit Seite als Array bereit stellen.

Wenn das klappt, könnte man damit auch Dlls die von anderen Compilern übersetzt wurden und bisher in Delphi Probleme machen auf die gleiche Weise verfügbar machen, solange entweder der Quellcode der DLL verfügbar ist oder eine .def Datei mit den exportierten Funktionen.

Wo finde ich exakte Informationen zum Dll Format?

Sowohl für 16 Bit als auch für 32 Bit.

64 Bit dlls will ich vorerst ausklammern. Zuerst will ich das oben genannte Problem lösen.

[Neutral General]

Hallo,

Ich kann mich irren, aber ich glaube es gibt da ein weiteres Problem und zwar, dass sich die Opcodes eines Befehls in 16- und 32-Bit Assembler z.T. unterscheiden.

Ich bin mir nicht 100%ig sicher, aber ich habe da was im Kopf. Und von daher würde es nicht reichen die Adressen der Funktionen rauszufinden und dir eine Tabelle zu machen.

Informationen wie DLLs aufgebaut sind:

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

(DLLs sind zu 99% normale .exe Dateien)

Andere Frage:
Kannst du die DLL nicht einfach als 32-Bit DLL neu compilieren wenn du den Code hast?
Müsste doch relativ einfach machbar sein oder?
Zumindest kann ich mir nicht vorstellen, dass es aufwendiger ist als das was du vorhast.

[Nintendo]

Danke für den Link. Werde ich mir anschauen.

Zitat:

Zitat von Neutral General

Ich kann mich irren, aber ich glaube es gibt da ein weiteres Problem und zwar, dass sich die Opcodes eines Befehls in 16- und 32-Bit Assembler z.T. unterscheiden.

Das sich die Opcodes regelrecht unterscheiden, kann ich mir nicht vorstellen. Höchstens, das halt die 16 Bit Äquivalente verwendet werden. Die Prozessorfamilie bleibt ja gleich (x86). Oder brauche ich mehr, um 16 Bit Code auf einer 32 Bit Maschine ausführen zu können. Dank Dosbox klappt das ja mit DOS Programmen.

Und hier in diesem Fall?

Zitat:

Zitat von Neutral General

Ich bin mir nicht 100%ig sicher, aber ich habe da was im Kopf. Und von daher würde es nicht reichen die Adressen der Funktionen rauszufinden und dir eine Tabelle zu machen.

Warum reicht das nicht? Wenn ich da die Adressen korrekt von 32Bit Flat in Seg:Ofs umrechne und dann die Funktion aufrufe? Oder braucht da zwingend den 16 Bit Layer, wie für DOS Programme die DOSBox?

Ich habe zwar den Quellcode der Dll aber nicht von allen in dieser dll verwendeten Bibliotheken.

[Namenloser]

Was Neutral General da sagt über unterschiedlich interpretierte OPCodes bei 16-Bit und 32-Bit, kommt mir auch dunkel bekannt vor. Ich hatte vor einiger Zeit mal versucht, einen Disassembler zu schreiben, und hatte da glaube ich auch so ein Problem...

Aber du schreibst was von Windows XP. Da kann man 16-Bit-Programme ja noch direkt laufen lassen. Wäre es nicht einfacher, eine 16-bittige Wrapper-Applikation für die DLL zu schreiben und diese vom Hauptprogramm aus mit Pipes o.ä. anzusteuern?

Spätestens wenn mal auf ein neues Windows geupdatet werden soll, wird es dann aber wieder haarig. Da müsste man dann wohl die DLL bzw. den Wrapper emulieren, vielleicht mit DOSBox als Vermittlungsstelle (ich weiß nicht ob das so schon geht, oder ob man diese Funktionalität erst noch in DOSBox einbauen müsste...). So baut man Schicht um Schicht um eine antike Bibliothek... ob man das wirklich will?

Also alles in allem wird das nicht gerade einfach, denke ich. Wäre vermutlich effizienter, die Bibliotheken der DLL einfach zu ersetzen/neu zu schreiben.

[glotzer]

Wie wärs damit die DLL mit Wrapper-Programm in QEMU laufen zu lassen?
Dann würde das ganze auch auf aktuellen Betriebsystemen laufen.

[himitsu]

Aber ganz im Ernst, wenn du den Quelltext besitzt, warum dann mühevoll versuchen das Alte irgendwie brutal in die eigene Anwendung reinzuhäcken oder es über wilde Umwege und mithilfe von Zusatzprogrammen zum Laufen bekommen,

Wenn es wesentlich leichter wäre den Quellcode an 32 Bit anzupassen und vielleicht auch gleich auch mit für 64 Bit
und die DLL dann ganz normal ins Programm einzubinden?

OK, eine 16-Bit-Host-Anwendung als Out-Of-Process-Server zu verwenden, wäre der andere "einfache"/gängige Weg,
aber bei aktuellen 64-Bit-Windowsen wurde nun endlich das 16-Bit-Subsystem komplett rausgeworfen, womit da 16-Bit-Anwendung garnicht mehr laufen. (Emulatoren und VMs mit Emulierung ausgeschlossen)

[jaenicke]

Zitat:

Zitat von Nintendo (Beitrag 1237680)

Warum reicht das nicht? Wenn ich da die Adressen korrekt von 32Bit Flat in Seg:Ofs umrechne und dann die Funktion aufrufe? Oder braucht da zwingend den 16 Bit Layer, wie für DOS Programme die DOSBox?

Es hat einen Grund warum 64-Bit Versionen von Windows keine 16-Bit Programme mehr ausführen können. Eben weil die nicht so direkt ausgeführt werden können. Heutige CPUs kennen einen 32-Bit und einen 64-Bit Mode, aber keinen 16-Bit Mode. Deshalb müsstest du nicht nur die Einsprungadressen suchen, sondern auch jeden einzelnen Befehl nach 32-Bit übersetzen, ausführen und das Ergebnis zurück übersetzen. Im Grunde ist das dann ein Interpreter, der die Befehle der Reihe nach ausführt. Das ist ein hoher Aufwand.

Deshalb wäre ein 16-Bit Wrapper am sinnvollsten, aber 64-Bit Betriebssysteme wären dann tabu.

[JamesTKirk]

Zitat:

Zitat von Nintendo (Beitrag 1237680)

Zitat:

Zitat von Neutral General

Ich kann mich irren, aber ich glaube es gibt da ein weiteres Problem und zwar, dass sich die Opcodes eines Befehls in 16- und 32-Bit Assembler z.T. unterscheiden.

Das sich die Opcodes regelrecht unterscheiden, kann ich mir nicht vorstellen. Höchstens, das halt die 16 Bit Äquivalente verwendet werden. Die Prozessorfamilie bleibt ja gleich (x86). Oder brauche ich mehr, um 16 Bit Code auf einer 32 Bit Maschine ausführen zu können.

Der wichtigste Punkt ist, dass Windows XP es dir enorm übel nehmen könnte, wenn du das System in einem inkonsistentem Zustand hinterlässt, wenn die Zeitscheibe deines Prozesses aufgebraucht ist (was du ja nicht beinflussen kannst). Deswegen "leben" 16-Bit Programme ja auch in der NTVDM, welche die ganzen "gefährlichen" Befehle nur emuliert. Da in ReactOS aktuell an der Implementierung der NTVDM gearbeitet wird könnstet du dir deren 486-Emulater-Bibliothek anschauen und vielleicht verwenden, so dass du quasi eine "16-Bit Skript Engine" implementieren könntest, die dir deine 16-Bit DLL auf Anforderung aufruft und emuliert.

Zitat:

Zitat von Nintendo (Beitrag 1237680)

Dank Dosbox klappt das ja mit DOS Programmen.

DOSBox emuliert eine komplette CPU, deswegen funktioniert das da auch ohne Probleme.

Gruß,
Sven

[Blup]

Zu den gennanten Problemen kommt hinzu, so eine DLL läuft ja nicht im leeren Raum.
Da werden 16-Bit API-Funktionen aufgerufen, mit 16-Bit Parametern und Rückgabewerten, aus weitere 16-Bit DLLs des Betriebssystems z.B..
Neben der CPU müsste man die 16-Bit Betriebssystem-Umgebung emulieren.

[Nintendo]

Danke Euch allen. Werde mich jetzt erst mal mit der Problematik beschäftigen. Ich tendiere zur Nutzung des 486 Emulators, wie ihn JamesTKirk vorgeschlagen hat. Oder VirtualBox, QEmu,...

Allerdings interessirt mich auch der Aufbau des 486 Emulators. Und da kann ich ja den Quellcode studieren. Dann sehe ich weiter.

8-)