32 Bit Programme auf 64 Bit Rechnern

[delphifan2004]

Hallo!

Wenn ich mir so die Quelltexte von 32 Bit Programmen angucke, sehe ich im Assemblerteil immer wieder Zuweisungen an al, ah, ax, bl, bh, bx, cl, ch, cx, dl, dh, dx. Nun habe ich in Fachzeit- schriften gelesen, das 16 Bit Dos Programme auf 64 Bit Rechnern nicht mehr laufen. Weiterhin habe ich gelesen, das es nur noch eax,ebx,ecx,edx, die 32 Bit oder rax,rbx,rcx,rdx, die 64 Bit Register geben wird. Wenn es sich um ein 32 Bit Programm handelt, müssen doch deshalb dennoch alle Zuweisungen an die kurzen Register al,ah,ax,bl,bh,bx,cl,ch,cx,dl,dh,dx geändert, das heißt in eax,ebx,ecx,edx geändert werden. Sonst läuft doch ein 32 Bit programm auf dem 64 Bit Rechner auch nicht, auch wenn es sonst 32 Bittig ist? Oder sehe ich da was falsch?

Würde mich über ne kompetente Antwort freuen

Delphifan20

[himitsu]

Also ich hab einen 64-Bit Rechner und bei mir läuft alles noch genaus wie vorher, allerdings hab ich derzeit auch noch ein 32-Bit-Windows drauf ^^

Ich vermute aer mal, der in den 64-Bit für die 64-Bit-Register andere Codes verwendet werden, denn sonst könnte und wird es ja Probleme mit den "alten" 8, 16 und 32-Bit Registern kommen.

[richard_boderich]

@delphifan

das kommt auf deine cpu an. also auf einen itanium laufen alle 32 bit programme aber arsch langsam. weil die cpu den 32 bit zugriff emuliert. 16 bit läuft da gar
nicht mehr drauf.

anders beim althon64

er ist ein 32 bit cpu mit 64 bit erweiterung. dort laufen die 32 bit programme und die 64 bit progs beide
ohne probleme und auch dos hab ich drauf laufen fuer meine notfallkonsole.

Gruß richard

[tommie-lie]

Zitat:

Zitat von delphifan2004

Wenn ich mir so die Quelltexte von 32 Bit Programmen angucke, sehe ich im Assemblerteil immer wieder Zuweisungen an al, ah, ax, bl, bh, bx, cl, ch, cx, dl, dh, dx.

Das sind allesamt 16- oder 8-bittige Register.

Zitat:

Zitat von delphifan2004

Nun habe ich in Fachzeit- schriften gelesen, das 16 Bit Dos Programme auf 64 Bit Rechnern nicht mehr laufen.

Das hängt primär vom Betriebssystem ab und nicht von den Prozessoren. Bei IA64 weiß ich es nicht, AMDs x86-64 ist aber ein komplett x86-kompatibler Prozessorkern, somit im Realmode nur 16-bittig. Erst Das Betriebssystem sorgt dafür, daß er in den 64bit-Modus geschaltet wird, weswegen auch ein dafür entwickeltes Betriebssystem notwendig ist, um 64bit-Anwendungen auszuführen.

Zitat:

Zitat von delphifan2004

Weiterhin habe ich gelesen, das es nur noch eax,ebx,ecx,edx, die 32 Bit oder rax,rbx,rcx,rdx, die 64 Bit Register geben wird.

Kann ich nichts drüber sagen, ich weiß nicht inwiefern der 64bit-Modus der x86-64-Architektur den Zugriff auf Register einschränkt, kann mir aber nicht vorstellen, daß es eine architekturbedingte Beschränkung ist. Allerdings ist es eine andere Speicherverwaltung, und AFAIK lässt Windows es nicht zu, 32bit-Programme im 64bit-Modus zu verwenden. Stattdessen wird bei Windows (für 64bit) eine Emulationsschicht eingeführt, also ein Windows on Windows64 (WoW54), das sämtliche Aufrufe für 32bit implementiert.
Nico hat so ein Ding und wie ich den kenne hat er sicherlich schon mit rumgespielt, er kann sicherlich mehr darüber sagen, wie die Architektur (nicht das Betriebssystem) den Zugriff im 64bit-Modus beschränkt.

[himitsu]

Zitat:

Zitat von richard_boderich

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

anders beim althon64
...

Dann hab ich wohl mit meinen Athlon64 Glück, das ich mehr aus AMD's stehe :mrgreen:

Na Dann warten wir mal auf Nico ^^

[tommie-lie]

Zitat:

Zitat von himitsu

Dann hab ich wohl mit meinen Athlon64 Glück, das ich mehr aus AMD's stehe :mrgreen:

Hättest ja auch ein 64bit-Betriebssystem (und dazu passende Software) nehmen können, die gibt's ja auch schon seit Jahrzehnten wie Sand am Meer.

[Daniel Schuhmann]

Zitat:

Zitat von himitsu

Zitat:

Zitat von richard_boderich

[...]also auf einen itanium laufen alle 32 bit programme aber arsch langsam.[...]anders beim althon64.

Dann hab ich wohl mit meinen Athlon64 Glück, das ich mehr aus AMD's stehe :mrgreen:[...]

Du solltest dabei bedenken, daß der Itanium eine komplett andere Architektur ist. Die CPU ist ein reiner Server-Prozessor. Cachegrößen (L3) bis zu 9 MB machen deutlich, daß diese CPU nichts auf dem Desktop verloren hat. Auch preislich kommen da mal eben $5800 zusammen, nur für die CPU, versteht sich. Wenn, dann mußt Du das mit den Desktop-CPUs von Intel vergleichen (neuere 500-Serie, 600-Serie, 800-Serie), die haben 64 Bit genauso implementiert wie AMD und liegen da Geschwindigkeitsmäßig bei 32 und 64 Bit ähnlich.

Daniel

[Traudix]

Hallo!

Ich guck grad, was hier so heute für Themen sind, wobei ich auch das hier entdeckt habe.

Zitat:

Zitat:

Zitat von delphifan2004

Wenn ich mir so die Quelltexte von 32 Bit Programmen angucke, sehe ich im Assemblerteil immer wieder Zuweisungen an al, ah, ax, bl, bh, bx, cl, ch, cx, dl, dh, dx.

Das sind allesamt 16- oder 8-bittige Register.

Zitat:

Zitat:

Zitat von delphifan2004

Nun habe ich in Fachzeit- schriften gelesen, das 16 Bit Dos Programme auf 64 Bit Rechnern nicht mehr laufen.

Das hängt primär vom Betriebssystem ab und nicht von den Prozessoren. Bei IA64 weiß ich es nicht, AMDs x86-64 ist aber ein komplett x86-kompatibler Prozessorkern, somit im Realmode nur 16-bittig. Erst Das Betriebssystem sorgt dafür, daß er in den 64bit-Modus geschaltet wird, weswegen auch ein dafür entwickeltes Betriebssystem notwendig ist, um 64bit-Anwendungen auszuführen.

Aus diesen Ausführungen entnehme ich, das ich 32 Bit Programme nicht ändern muß, wenn sie auf einer 64 Bit CPU laufen sollen. Denn, wenn der Prozessorkern auch beim 64 Bitter X86-kompatibel ist und im RealMode nur 16 Bittig, kennt er ja auch die 8- und 16-bittigen Register. Da fällt mir ein Stein vom Herzen. Hab schon befürchtet, nun überall auf die 32Bit-Äquivalente umstellen zu müssen. Hab nämlich momentan noch einen 32 Bit Rechner und für den 32-Bittige Assembler-Programme, bei denen zwar in .asm-Dateiein die Direktive .386 gesetzt ist, aber trotzdem an vielen Stellen die 8- oder 16-bittige Version der Register verwendet wird (Bios-Interrupts, Farbpaletten-Einstellungen, Maussteuerung...) Hab auch paar Delphi Programme mit Assemblerteilen, wo sinngemäß das gleiche Problem vorliegt. Nun, wenn das später auf dem 64 Bitter kein Problem ist, brauche ich da nix zu ändern.

Schönen Tag noch von

Traudix

[NicoDE]

Zitat:

Zitat von Traudix

Aus diesen Ausführungen entnehme ich, das ich 32 Bit Programme nicht ändern muß, wenn sie auf einer 64 Bit CPU laufen sollen. Denn, wenn der Prozessorkern auch beim 64 Bitter X86-kompatibel ist und im RealMode nur 16 Bittig, kennt er ja auch die 8- und 16-bittigen Register.

Da ist für die x86-64 (amd64, em64t) meist zutreffend. Der 32-Bit-Emulator (WoW64) den Microsoft entwickelt hat, sorgt dafür, dass die meisten 32-Bit-Anwendungen wie bisher funktionieren.

1) Schwierig wird es zum Beispiel dadurch, dass 32-Bit-Module nicht in 64-Bit-Prozesse geladen werden können (und vis versa). Das heißt, dass man für Shellerweiterungen eine 64-Bit-DLL schreiben muss um in den 64-Bit Explorer zu kommen. Wenn man Strukturen aus anderen Prozessen liest (so wie LuckieDIPS; siehe TLvItemBuffer), darf man nicht vergessen, dass es sich um die 64-Bit-Versionen der Strukturen handelt.

2) Die Registrierung für 32-Bit-Anwendungen ist in die 64-Bit-Registrierung eingehängt. Um aus WoW64 Zugriff auf die 64-Bit-Registrierung zu erhalten muss der API spezielle Flags übergeben.

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...

Zitat:

Zitat von Traudix

(Bios-Interrupts, Farbpaletten-Einstellungen, Maussteuerung...) Hab auch paar Delphi Programme mit Assemblerteilen, wo sinngemäß das gleiche Problem vorliegt. Nun, wenn das später auf dem 64 Bitter kein Problem ist, brauche ich da nix zu ändern.

Es gibt keinen 16-Bit-Emulator (ntvdm) mehr!
Das ist mir bei BiosHelp auf die Füße gefallen. Ich musste eine Weile Suchen bevor ich eine Lösung für Win64 gefunden hatte (Microsoft musste eine neue API einführen um diese speziellen Bereiche auslesen zu können, da die bisherigen Methoden nicht mehr funktionierten).

Kurz: Es geht nicht ohne Tests auf einem echten Win64-System (sollte man seine Software nicht ohnehin auf den Zielplattformen testen ;))

[tommie-lie]

Zitat:

Zitat von NicoDE

1) Schwierig wird es zum Beispiel dadurch, dass 32-Bit-Module nicht in 64-Bit-Prozesse geladen werden können.
[...]
2) Die Registrierung für 32-Bit-Anwendungen ist in die 64-Bit-Registrierung eingehängt.

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?

[NicoDE]

Zitat:

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:

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:

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:

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:

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 :cry:

...:cat:...

[xaromz]

Hallo,

Zitat:

Zitat von sakura

Zitat:

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 :cry:

...:cat:...

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:

Zitat von delphifan2004

Zitat:

Zitat von tommie-lie

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

Verleumdung! Das habe ich nie geschrieben!!!elfeins :mrgreen:

Zitat:

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:

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:

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:

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:

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:

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:

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. :roll:

[delphifan2004]

Hallo!

Zitat:

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:

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:

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:

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:

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:

Zitat von delphifan2004

Genau um diese Bestätigung ging es mir.

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