Laden einer alten 16 Bit dll unter WinXP?

[Nintendo]

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

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 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 von Nintendo:

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 von Nintendo:

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 von Nintendo:

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.

[Nintendo]

Hallo,

es hat sich eine neue Frage ergeben, die ich auch hier: http://www.delphipraxis.net/148977-d...nzubinden.html

gepostet habe, da das auch bei Dlls der gleichen Prozessorfamilie bei gleicher Wortbreite interessant ist, zum Beispiel halt für die Kommunikation mit Freepascal Programmen.

Die Exporttabelle mit den anzusprechenden Funktionen wird, wie ich bisher verstanden habe durch eine Struktur mit Namen

IMAGE_EXPORT_DIRECTORY

repräsentiert. Ich kann aber die Adrees dieser Tabelle in den im Netz verfügbaren Dokus nirgends finden.

*** Code im verlinkten Beitrag ***

Ist vieleicht hier schon in einem Datenfeld die Adresse der Exporttabelle verborgen?

Die Struktur der .EXE Datei ist nur bis hierher dokumnentiert. Danach kommen die Section Header. Wo aber ist die Exporttabelle -> IMAGE_EXPORT_DIRECTORY?

[Bernhard Geyer]

Wenn Du wissen willst di ein Exe/DLL aufgebaut ist so schau am besten in der MSDN nach