32 Bit Programme auf 64 Bit Rechnern

[NicoDE]

Zitat von tommie-lie:

Ich hatte eigentlich gehofft, von dir zu erfahren, wie die Beschränkungen der Architektur aussehen, nicht die der Windows-Prozessverwaltung. Oder bist du doch noch nicht so intim mit deinem x86-64 geworden?

Die Hoffnung stirbt zuletzt
Da es Aufgabe des Betriebssystems ist, im 64-Bit-Modus so zu tun als ob ein 32-Bit-Kernel vorhanden ist, habe ich mich nicht um die Details gekümmert.
Durch den Prozessor ist es nur dadurch limiert, dass im 64-Bit-Modus kein vm86-Modus zur Verfügung steht. Der Prozessor-Support für die Vitualisierung ist erst in den neuesten AMD64 vorhanden (aber das dürfte nur VMware interessieren).

[delphifan2004]

Hallo!

Zitat von tommie-lie:

Es gibt keinen 16-Bit-Emulator (ntvdm) mehr!

Dann dürften auch 16 Bit Dlls aus Borland-Pascal-Zeiten nicht mehr ladbar sein, da dannn das nötige API fehlt. Hab allerdings in Delphi Funktionen wie LoadLibrary16... gefunden. Wenn ich deinen Einwurf, tommie-lie, richtig verstanden habe, gibt es diese Funktionen dann nicht mehr.

Die Dll könnte auch unter Borland Pascal so geschrieben werden, das beispielsweise Assemblerfunktionen aufgerufen werden, die mit den 32 Bit Registern
arbeiten: asm db 66h mov ax,bx, wobei durch das Byte 66h, wenn das der richtige OpCode dafür ist, dafür sorgt, das die 32 Bit, Äquivalente verwendet werden, falls der integrierte Assembler verwendet wird. Außerdem enthält Borland Pascal den Turbo-Assembler, der die Direktive .386 beherrscht, womit dann aus dem Code ein 32 Bit Programm entstht. Dann in der Dll Funktionen definieren, die in Turbo-Assembler geschrieben sind. (In der Dll Objektdatei dazulinken...).
Die Dll könnte außerdem 32Bit-Funktionen des Windows API aufrufen.
Die Dll ist doch aber dann immer noch 16 Bittig, zumindest das Ladeformat? Die Verwendung solch einer Dll wird doch sicher dann problematisch? In ihr werden zwar dann 32 Bit Funktionen aufgerufen, es gibt inzwischen auch eine 32 Bit Version des DOS Extenders von Borland Pascal, aber der BPascal Compiler erzeugt doch trotzdemnoch 16 Bit Code (16 Bit Aufrufadressen auch in Dll)? Da liege ich doch sicher richtig in der Annahme, das Borland Pascal DLLs, auch wenn sie nur 32 Bit-Funktionen aufrufen und den 32 Bittigen DOS-Extender voraussetzen, wie dann auch das übrige Programm, das die Dll verwendet, auf keinen Fall auf 64 Bit Rechnern im 32 Bit Modus laufen. Und wenn ich diese Borland Pascal Dll zusammen mit Delphi verwenden wollte, steht das Problem 16 Bittiger Aufrufadressen im Raum und außerdem die fehlenden Ladefunktionen für die 16 Bittige Dll. (LoadLibrary16,GetProcedureAddress16,...

Nun denn, ein schönes WE wünscht

Delphifan2004

[DelphiSourcer]

Hallo!

Zitat von delphifan2004:

Dann dürften auch 16 Bit Dlls aus Borland-Pascal-Zeiten nicht mehr ladbar sein, da dannn das nötige API fehlt. Hab allerdings in Delphi Funktionen wie LoadLibrary16... gefunden. Wenn ich deinen Einwurf, tommie-lie, richtig verstanden habe, gibt es diese Funktionen dann nicht mehr.

Ich habe zwar noch keinen 64 Bit Rechner, aber bei allem, was ich über erfahren und gelesen habe, ist das gsnau so.

Zitat von delphifan2004:

Die Dll ist doch aber dann immer noch 16 Bittig, zumindest das Ladeformat? Die Verwendung solch einer Dll wird doch sicher dann problematisch? In ihr werden zwar dann 32 Bit Funktionen aufgerufen, es gibt inzwischen auch eine 32 Bit Version des DOS Extenders von Borland Pascal, aber der BPascal Compiler erzeugt doch trotzdemnoch 16 Bit Code (16 Bit Aufrufadressen auch in Dll)? Da liege ich doch sicher richtig in der Annahme, das Borland Pascal DLLs, auch wenn sie nur 32 Bit-Funktionen aufrufen und den 32 Bittigen DOS-Extender voraussetzen, wie dann auch das übrige Programm, das die Dll verwendet, auf keinen Fall auf 64 Bit Rechnern im 32 Bit Modus laufen. Und wenn ich diese Borland Pascal Dll zusammen mit Delphi verwenden wollte, steht das Problem 16 Bittiger Aufrufadressen im Raum und außerdem die fehlenden Ladefunktionen für die 16 Bittige Dll. (LoadLibrary16,GetProcedureAddress16,...

Ich denke mal, da liegst Du genau richtig.
Wenn Du den Quelltext von so einer Dll hast, schreib ihn Dir so um, das Du ihn mit einem 32 Bittigen Delphi übersetzen kannst. Wenn Du den Quelltext der Dll nicht hast, Pech gehabt!

Andere Frage, Wozu soll das gut sein, 16 Bittige 32 Bit Dlls zu verwenden?

Der theoretische Teil dieser Fragestellung düfte ja mit all diesen Antworten abgehandelt sein, aber ich sehe keinen praktischen Nutzen, 16 Bittige Dlls in einem 32 Bittigen Betriebssystem verwenden zu wollen.

DelphiSourcer

[sakura]

Zitat von richard_boderich:

das kommt auf deine cpu an. also auf einen itanium laufen alle 32 bit programme aber arsch langsam.

Ich selbst habe leider "nur" einen 32 Bitter, aber mein Kollege hat einen 64 Bit Intel PC und dass die 32 Bit Anwendungen langsamer laufen als vorher, das kann er Dir garantiert nicht bestätigen... Das Ding ist verdammt schnell, ich will den auch haben

......

[xaromz]

Hallo,

Zitat von sakura:

Zitat von richard_boderich:

das kommt auf deine cpu an. also auf einen itanium laufen alle 32 bit programme aber arsch langsam.

Ich selbst habe leider "nur" einen 32 Bitter, aber mein Kollege hat einen 64 Bit Intel PC und dass die 32 Bit Anwendungen langsamer laufen als vorher, das kann er Dir garantiert nicht bestätigen... Das Ding ist verdammt schnell, ich will den auch haben

......

Dein Kollege hat aber doch keinen Itanium, oder? Wahrscheinlich eher einen P4 mit 64-Bit-Erweiterung. Das ist ja nur ein aufgebohrter 32-Bit-Prozessor, da gibt's keinen Unterschied. Nur der Itanium kann kein 32 Bit und emuliert das -> langsam.

Aber mal zur Ursprungsfrage: Nur weil in einem Programm die 8- oder 16-Bit-Register verwendet werden ist das Programm noch lange kein 16-Bit-Programm. Der Unterschied liegt primär in der Speicheradressierung und darin, dass Windows in der 64-Bit-Ausführung keine 16-Bit-Api mehr unterstützt. Der Prozessor kann die Programme selbstverständlich ausführen (es sind ja gültige Opcodes), aber die Api-Aufrufe laufen ins Leere. Unter Win9x liefen auch alle 16-Bit-Programme in einem gemeinsamen Adressraum, ich weiss aber nicht, ob das unter WinXP auch so ist.

Gruß
xaromz

[tommie-lie]

Zitat von delphifan2004:

Zitat von tommie-lie:

Es gibt keinen 16-Bit-Emulator (ntvdm) mehr!

Verleumdung! Das habe ich nie geschrieben!!!elfeins

Zitat von delphifan2004:

Dann dürften auch 16 Bit Dlls aus Borland-Pascal-Zeiten nicht mehr ladbar sein, da dannn das nötige API fehlt.

So isses ooch.

Zitat von delphifan2004:

Hab allerdings in Delphi Funktionen wie LoadLibrary16... gefunden. Wenn ich deinen Einwurf, tommie-lie, richtig verstanden habe, gibt es diese Funktionen dann nicht mehr.

Ich weiß nicht, was die Funktion genau macht und wo sie herkommt, aber wenn es eine aus Win3.x mitgeschleppte API-Funktion ist, wird sie höchstwahrscheinlich nicht mehr funktionieren, richtig.

Zitat von delphifan2004:

Die Dll könnte auch unter Borland Pascal so geschrieben werden, das beispielsweise Assemblerfunktionen aufgerufen werden, die mit den 32 Bit Registern arbeiten: asm db 66h mov ax,bx, wobei durch das Byte 66h, wenn das der richtige OpCode dafür ist, dafür sorgt, das die 32 Bit, Äquivalente verwendet werden, falls der integrierte Assembler verwendet wird.

Sicher, bei deiner Registeroperation wird's vermutlich auch noch mit den 16bit-Registern funktionieren (das war die Frage, die ich an Nico stellte, aber da er sie auch nicht beantworten kann, gehe ich einfach mal davon aus, daß AMD nicht schwachsinnigerweise Beschränkungen eingebaut hat, die vollkommen unnötig sind). Aber sag erstmal dem alten TurboPascal-Linker, daß er dir eine 32bit-PE machen soll.

Zitat von delphifan2004:

Außerdem enthält Borland Pascal den Turbo-Assembler, der die Direktive .386 beherrscht, womit dann aus dem Code ein 32 Bit Programm entstht.

Mit einem modernen Assembler und Linker kriegst du auch auf einem 32bit-Prozessor ein 64bit-Programm zustande, das ist kein Kunststück.

Zitat von delphifan2004:

Die Dll ist doch aber dann immer noch 16 Bittig, zumindest das Ladeformat? Die Verwendung solch einer Dll wird doch sicher dann problematisch?

Jupp, weil Windows sich die Emulation seines alten Adressmodells gespart hat.

Zitat von delphifan2004:

Da liege ich doch sicher richtig in der Annahme, das Borland Pascal DLLs, auch wenn sie nur 32 Bit-Funktionen aufrufen und den 32 Bittigen DOS-Extender voraussetzen, wie dann auch das übrige Programm, das die Dll verwendet, auf keinen Fall auf 64 Bit Rechnern im 32 Bit Modus laufen.

Weiß ich nicht, ich weiß nicht, was der Linker kann, ich weiß nicht, was dieser 32bit-Extender macht, und ich weiß nicht, was vorher an Initialisierung durch Borlands RTL abläuft (vergl. System.pas und SysInit.pas der Delphi-RTL).


In deinem, delphifan2004, Post habe ich irgendwie keinen Widerspruch und keine Anmerkung zu Nicos Aussage gefunden, daß die ntvdm nicht mehr existiert. Oder wolltest du nur bestätigt wissen, daß eine alte 16bit-DLL, die einem Win3.x-Linker entsprungen ist, nicht mehr von einem 32bit-Programm unter WoW64 geladen werden kann? Falls ja: Nein, kann sie nicht mehr.

[Mystic]

Zitat von NicoDE:

3) Einige Systemverzeichnisse werden innerhalb von WoW64 automatisch umgeleitet. Ein 32-Bit-Programm sieht zum Beispiel C:\WINDOWS\SysWOW64 als "C:\WINDOWS\system32" (unter C:\WINDOWS\SysWOW64 liegen die DLLs der Win32-API unter C:\WINDOWS\system32 die DLLs der Win64-API). Das gleiche gilt auch für das %ProgramFiles%-Verzeichnis und andere. Um die 'Umleitung' zu umgehen muss man diese mit einer neuen API deaktivieren. Es können also nur 32-Bit-Programme auf C:\WINDOWS\system32 zugreifen wenn sie die neuen APIs kennen...

Warum haben die denn nicht das system64-Verzeichnis eingeführt und das system32 für WOW64 belassen?

64-Bit DLLs im system32-Verzeichnis. Das passt doch nicht.

[delphifan2004]

Hallo!

Zitat von tommie-lie:

Oder wolltest du nur bestätigt wissen, daß eine alte 16bit-DLL, die einem Win3.x-Linker entsprungen ist, nicht mehr von einem 32bit-Programm unter WoW64 geladen werden kann? Falls ja: Nein, kann sie nicht mehr.

Danke. Genau um diese Bestätigung ging es mir. Habe nämlich aus dem Internet ne Grafikbibliothek (Hyper32V2) für Turbo/Borland-Pascal runtergeleden und wollte die nach Delphi portieren. Mit Delphi neu übersetzen erfordert zu viele Änderungen und die Freepascal Version setzt den DOS Extender Go32v2 voraus, und diese Unit gibt es wiederum nicht für Delphi. Und da kam mir der Gedanke mit der Dll. Funzt also nicht! Danke, Da brauch ich also nicht erst Zeit in die Enrwicklung dieser Dll investieren. Trotzdem schade. Hätte man als Grundlage für DOS Spiele nehmen können, da solche immer noch beleibt zu sein scheinen.

Schönes Wochenende wünscht Euch allen

Delphifan2004

[tommie-lie]

Zitat von delphifan2004:

Habe nämlich aus dem Internet ne Grafikbibliothek (Hyper32V2) für Turbo/Borland-Pascal runtergeleden

Bei Programmer's Heaven ist als Systemvorraussetzung DOS und Win9x angegeben, würde sie überhaupt auf einem NT laufen?

Zitat von delphifan2004:

Hätte man als Grundlage für DOS Spiele nehmen können, da solche immer noch beleibt zu sein scheinen.

Die könnte man zumindest in DOSBox zum Laufen kriegen (benutze ich, um ein DOS-Spiel zu spielen, das selbst unter Win98 nicht laufen wollte). Da man allerdings mit Delphi keine reinen DOS-Anwendungen schreiben kann, müsste man dazu aber trotzdem bei TurboPascal bleiben.

[NicoDE]

Zitat von delphifan2004:

Hab allerdings in Delphi Funktionen wie LoadLibrary16... gefunden. Wenn ich deinen Einwurf, tommie-lie, richtig verstanden habe, gibt es diese Funktionen dann nicht mehr.

Diese Funktion war nie Teil der dokumentierten Win32-API (sie wurde unter Win9x - davon gibt's keine 64-Bit-Version - fürs Thunking benötigt).

Zitat von Mystic:

Warum haben die denn nicht das system64-Verzeichnis eingeführt und das system32 für WOW64 belassen?

Die gleiche Diskussion gab's bei Linux (lib/lib32, lib/lib64, ...). Offensichtlich entschied man sich für die Abwärtskompatibilität, da viele Strings hart-codiert wurden (%SystemRoot%\system32 ein Klassiker...).

Zitat von delphifan2004:

Genau um diese Bestätigung ging es mir.

Dann probiere es aus, oder lass es ausprobieren...