Ist 32bit bereits tot?
-
Zeus schrieb:
Aber Windows hat im Kontext einer 64/32bit-Architektur ihre Subsystem doppelt vorhanden, einmal als Win32, und einmal als SysWoW64.
Bin jetzt nicht sicher was du mit Win32 meinst - normalerweise ist damit die 32 Bit Windows Plattform gemeint.
So verstanden wäre deine Aussage zumindest irreführend, denn:SysWoW64 ist das 32 Bit Subsystem.
Und das "system32" Verzeichnis enthält die 64 Bit DLLs.Für 32 Bit Prozesse wird dann das echte "system32" Verzeichnis (mit den 64 Bit DLLs) ausgeblendet, und das "SysWoW64" Verzeichnis (mit den 32 Bit DLLs) als "system32" eingeblendet.
-
Fazit schrieb:
Zeus schrieb:
Fazit schrieb:
Du hast ein wesentliches Prinzip von Windows vergessen. Der da wäre, dass viele Funktionen, wie z.B. Directx bereits durch Windows übernommen werden, in Windows bereits enthalten sind, die dann von den Programmen nur noch genutzt werden. Also das Programm schickt den Befehl zur Erstellung einer Instanz und übergibt dann die Rechenaufgabe, die dann dieses 64-Bit Programm macht und dem 32-Bit Programm zurück gibt.
Aber Windows hat im Kontext einer 64/32bit-Architektur ihre Subsystem doppelt vorhanden, einmal als Win32, und einmal als SysWoW64.
Ja und? Normalerweise wird ein Windows Programm so compiliert das es dann auf die Klassen von Windows zeigt. Im Normalfall ändert sich beim Call zu einer Klasse zwischen x86 und x64 nichts aber die Klasse kann dann sehr wohl eine andere sein. Z.B. bei x64 eben so, dass sie die Rechenaufgabe schneller berechnen kann und somit das angeforderte vom Programm dem Programm schneller zurückgeben kann und somit kann das Programm früher weiter machen an der Stelle als bei x86.
Achjeh, Windows kennt doch keine Klassen. Aber egal, darum geht's jetzt nicht.
Ein 32 Bit Programm kann unter Windows nicht einfach so 64 Bit Code aufrufen. Du kannst unter Windows keine 64 Bit DLLs in einen 32 Bit Prozess laden, es geht einfach nicht. Genauso wenig kann man im Usermode "auf 64 Bit umschalten". Oder einfach so 64 Bit Code in den Speicher schreiben, anspringen, und dann hoffen dass es funktioniert (OK, hoffen kann man immer, aber es wird halt nicht funktionieren).
Die einzigen Möglichkeiten für einen 32 Bit Prozess 64 Bit Code "aufzurufen" sind ein Kernel-Call bzw. ein Remote-Procedure-Call in einen anderen (64 Bit) Prozess. Und beides wird relativ selten genutzt. Siehe meinen Beitrag von gerade eben.
----
BTW: bring doch mal ein paar Beispiele für rechenintensive Funktionen die Windows bereitstellen würde, und die viele Programme nutzen. Mir fällt da kaum was ein. Und das was mir einfällt (z.B. Videos oder Bilder encoden/decoden), wird in DLLs gemacht, wo die 32 Bit Version den rechenintensiven Teil als 32 Bit Code enthält.
-
@Fazit
Ich versteh deine Ausführung nicht.
IMO ist eine Befehl, im 32- oder 64-Bit Modus genauso schnell. Die Geschwindigkeitvorteil von 64-Bit Modus kommt daher, weil AMD der Architektur einige Register mehr geschenkt hat.
http://de.wikipedia.org/wiki/AMD64 schrieb:
Register R8–R15 und XMM8–XMM15 stehen ausschließlich im 64-Bit-Modus zur Verfügung
Daher in der Praxis der kleine Geschwindigkeitsvorteil von 10 bis 20%.
-
Danke, ich hab unzugeordnet gemeint.
-
@Zeus:
Ich glaube er glaubt, dass die meisten "Windows Funktionen" (Funktionen in diversen DLLs/ActiveX etc.) als 64 Bit Code laufen, auch in 32 Bit Prozessen. Wenn das so wäre, könnten sie die zusätzlichen Register nutzen, und müssten/könnten dadurch ne Spur schneller sein. Das würde dann die Ausführung von 32 Bit Programmen auf nem 64 bittigem Windows beschleunigen.Soweit stimmt die Logik schon.
Nur dass eben die meisten "Windows Funktionen" in 32 Bit Prozessen auch als 32 Bit Code laufen.
-
hustbaer schrieb:
Nur dass eben die meisten "Windows Funktionen" in 32 Bit Prozessen auch als 32 Bit Code laufen.
Im mixed Betrieb würde der Prozessor abstürzen
-
Zeus schrieb:
Im mixed Betrieb würde der Prozessor abstürzen
Und wenn man pech hat, voll durch die Grafikkarte krachen.
-
Ein 32-Bit Programm kann in einem 64-Bit Programm sehr wohl ein 64-Bit Programm oder eine 64-Bit DDL aufrufen. Also hört auf so einen quatsch zu erzählen. Oh man!!!
-
Ich hab kein Problem, dass du mir widersprechen willst, aber willst du auch MSDN widersprechen ?
http://msdn.microsoft.com/en-us/magazine/cc300794.aspx schrieb:
While running a fully 64-bit Windows system sounds great, the reality is that you'll very likely need to run Win32 code for a while. Towards that end, x64 versions of Windows include the WOW64 subsystem that lets Win32 and Win64 processes run side-by-side on the same system. However, loading your 32-bit DLL into a 64-bit process, or vice versa, isn't supported.
-
Du kapiert gar nicht was ich meine. Ein Programm was auf Windows läuft, hat generell die Möglichkeit ein anderes Programm zu starten oder eine DDL zu laden. Und wenn das Programm durch den User gestartet werden kann und eine DDL mit einem Resourcen Viewer durch den User, dann kann das ebenso gut auch ein anderes Programm selbst, was vom User gestartet wurde, denn dieser Aufruf Befehl geht an das System von Windows, was dann den Befehl ausführt. So kann es passieren, dass eine DDL oder Executable den selben Namen hat wie bei 32-Bit aber trotzdem 64-Bit Hardware nutzt.
-
Viele Servies die ein Windows-Programm von Windows nutzt, ist sehr oft nur ein Aufruf mit einer Parameterübergabe und dann das Zurücksenden des Ergebnis. Und das Aufrufen darf eben so ein 32-Bit Programm sein, da es aber vielleicht ein 64-Bit Windows ist der Service für 64-Bit genutzt und somit wird auch das zurückgegebene auf 64-Bit Technology basierend berechnet und somit ist das Ergebnis vielleicht schneller zurückgebar als von dem selben Dienst was für ein 32-Bit Windows ist.
-
Kannst Du eigentlich auch grammatikalisch korrekte Sätze formulieren? Es ist sehr schwer zu verstehen, was Du eigentlich sagen will.
Ja, ein Programm kann ein anderes aufrufen. Aber genau das passiert unter Windows doch eher selten. Und dass man eben NICHT von einem 32bit-Prozess auf 64bit-DLLs zugreifen kann, wurde Dir ja schon häufig genug gesagt - inzwischen auch mit MSDN-Zitat.
-
SG1 schrieb:
Kannst Du eigentlich auch grammatikalisch korrekte Sätze formulieren? Es ist sehr schwer zu verstehen, was Du eigentlich sagen will.
Ja, ein Programm kann ein anderes aufrufen. Aber genau das passiert unter Windows doch eher selten. Und dass man eben NICHT von einem 32bit-Prozess auf 64bit-DLLs zugreifen kann, wurde Dir ja schon häufig genug gesagt - inzwischen auch mit MSDN-Zitat.
Dem ist aber nicht so. Und nur die wenigsten Programmierer halten sich an MSDN. Das ist sehr wohl bekannt und auch eines der vielen Ursachen warum Windows früher oder später spackt. Der Punkt ist eine DDL, kann, wenn sie so geschrieben und compiliert wurde, ähnlich wie eine Executable ausgeführt werden und kann dann nicht nur mit einem 64-Bit DDL Loader geladen werden. Die 64-Bit DDL kann viele Verlinken tief ins 64-Bit System haben. Das 32-Bit Programm schickt dann eben dieser 64-Bit DDL einen Aufruf inkl. Parameter, der die Aufgabe darstellt, über das Windows schicken und die 64-Bit DDL arbeitet dann unabhängig vom Programm, von dem es aufgerufen wurde und schickt dann dem Programm das Ergebnis zurück. Es ist sehr wahrscheinlich dass diese 64-Bit DDL das Ergebnis schneller zurückgeben kann als die DDL in 32-Bit Variante.
-
SG1 schrieb:
Kannst Du eigentlich auch grammatikalisch korrekte Sätze formulieren? Es ist sehr schwer zu verstehen, was Du eigentlich sagen will.
Ja, ein Programm kann ein anderes aufrufen. Aber genau das passiert unter Windows doch eher selten. Und dass man eben NICHT von einem 32bit-Prozess auf 64bit-DLLs zugreifen kann, wurde Dir ja schon häufig genug gesagt - inzwischen auch mit MSDN-Zitat.
Dem ist aber nicht so. Und nur die wenigsten Programmierer halten sich an MSDN. Das ist sehr wohl bekannt und auch eines der vielen Ursachen warum Windows früher oder später spackt. Der Punkt ist, eine DDL kann, wenn sie so geschrieben und compiliert wurde, ähnlich wie eine Executable ausgeführt werden und kann dann nicht nur mit einem 64-Bit DDL Loader geladen werden. Die 64-Bit DDL kann viele Verlinkungen tief ins 64-Bit System haben. Das 32-Bit Programm schickt dann eben dieser 64-Bit DDL einen Aufruf inkl. Parameter, der die Aufgabe darstellt, über das Windows und die 64-Bit DDL arbeitet dann unabhängig vom Programm, von dem es aufgerufen wurde und schickt dann dem Programm das Ergebnis zurück. Es ist sehr wahrscheinlich dass diese 64-Bit DDL das Ergebnis schneller zurückgeben kann als die DDL in 32-Bit Variante.
Windows selbst hat sehr viele DDLs.
-
Wovon redest Du eigentlich? rundll32? Das verwendet jemand in ernstzunehmenden Programmen?
-
@SG1:
Ich glaube nicht, dass er überhaupt selbst weiss wovon er redet.
Ich denke, er hat eine reichlich nebulöse, vage Vorstellung davon, wie er meint dass Programme unter Windows funktionieren, und versucht das nun in Worte zu fassen. Deswegen kommt auch so wirres Zeug dabei raus.
-
hustbaer schrieb:
...
Hauptsache man widerspricht
-
Zeus schrieb:
hustbaer schrieb:
...
Hauptsache man widerspricht
Da liest noch jemand Dilbert
MfG SideWinder
-
SideWinder schrieb:
Zeus schrieb:
hustbaer schrieb:
...
Hauptsache man widerspricht
Da liest noch jemand Dilbert
MfG SideWinder
Dilbert? Ich hätte jetzt eher an xkcd gedacht.
Was ist eigentlich eine DDL? Ihr wollt mir doch nicht sagen, dass er sich andauernd verschreibt und DLL meint?
Grüssli
-
Dravere schrieb:
Was ist eigentlich eine DDL? Ihr wollt mir doch nicht sagen, dass er sich andauernd verschreibt und DLL meint?
Doch, ich glaube, das meint er.
