Archiv verlassen und diese Seite im Standarddesign anzeigen : Erster Eindruck: Windows XP 64Bit-Edition
klumy
2003-09-07, 13:34:39
"Die Internetseite GamePC.com hat einen Artikel veröffentlicht, in dem der erste Eindruck der 64Bit-Edition von Windows XP auf einem AMD64 geschildert wird. Das Ganze ist leider in Englisch verfasst wurden, weshalb man entsprechende Sprachkenntnisse mitbringen sollte."
aus Winfuture.de
http://www.gamepc.com/labs/view_content.asp?id=amd64xp&page=1&cookie%5Ftest=1
Metzler
2003-09-07, 14:13:23
Mich wundert, dass das Ding mit 512 MB Speicher läuft... Auf der Microsoft Homepage selbst wird von 1 Gig RAM gesprochen, welches zum laufen notwendig ist...
Warum sollte die AMD64-Version mehr Arbeitsspeicher brauchen als die x86-Version? Dafür gibt es keinen Grund!
Metzler
2003-09-07, 16:29:05
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/reskit/prka_fea_ppnm.asp
Gibt trotzdem keinen Grund für diese Aussage!
Außerdem ist das imho die Itanium-Version von XP! Über die AMD64-Version gibt es afaik keine öffiziellen Angaben...
In dem Artikel steht:To put it in simple terms, 32-bit device drivers on the market today simply will not work. A 32-bit operating system means all drivers must be 32-bit code, whereas a 64-bit operating system means all drivers must be 64-bit code.WinDOS 95 lief dank DOS-Basis noch mit den 16-Bit-Treibern. Bei XP-64 gibt es keinen Rettungsring Legacy-Treiber.
Das bedeutet: XP-64 hat das Zeug, eine Totgeburt zu werden. Wenn es rauskommen wird, neigt sich der XP-Support von MS dem Ende zu. XP ist mittlerweile schon ein recht altes OS, und nur ein Jahr nach XP-64 soll endlich Longhorn kommen, das einen gewaltigen Einschnitt bei der Windows-Entwicklung bedeuten soll. Kaum ein Hardware-Hersteller wird sich lange die Mühe machen, XP und Longhorn parallel zu unterstützen. Schon 2002 zeichnete sich der Trend ab, dass kein OS vor Win2000 mehr unterstützt würde. Matrox weigerte sich sogar, einen bereits angekündigten WinMe-Treiber anzubieten.
XP-64 braucht spezielle Treiber, denn die von XP und Longhorn werden nicht funktionieren. Man wird ein paar Monate nach XP-64 auf Longhorn umrüsten dürfen oder müssen.
Muh-sagt-die-Kuh
2003-09-08, 01:09:59
Original geschrieben von Gast
Kaum ein Hardware-Hersteller wird sich lange die Mühe machen, XP und Longhorn parallel zu unterstützen. Schon 2002 zeichnete sich der Trend ab, dass kein OS vor Win2000 mehr unterstützt würde. Matrox weigerte sich sogar, einen bereits angekündigten WinMe-Treiber anzubieten.
XP-64 braucht spezielle Treiber, denn die von XP und Longhorn werden nicht funktionieren. Man wird ein paar Monate nach XP-64 auf Longhorn umrüsten dürfen oder müssen. Auch Longhorn wird auf dem NT-Kernel basieren...da ändert sich für die Treiberentwickler wenig bis nichts. Windows 2000 Treiber laufen in 99% aller Fälle schliesslich auch unter XP.
LOCHFRASS
2003-09-08, 07:05:50
Notfalls gibts halt ein paar Leute, die die Treiber hacken, so wie das damals bei den 3dfx Win2k Treibern der Fall war.
ActionNews
2003-09-08, 08:29:50
Naja wie ist das denn unter Linux? Da müsste ich die Treiber ja nur mit eine 64bit-Kompiler neu kompilieren und fertig. Oder ist das zu kurz gedacht?
CU ActionNews
Demirug
2003-09-08, 09:09:42
Original geschrieben von ActionNews
Naja wie ist das denn unter Linux? Da müsste ich die Treiber ja nur mit eine 64bit-Kompiler neu kompilieren und fertig. Oder ist das zu kurz gedacht?
CU ActionNews
Wenn die Treiber richtig programmiert wurden muss man sie nur neu kompilieren. Der NT-Kern war ja von Anfang an auf Platformunabhänigkeit ausgelegt. Man konnte damals aus dem gleichen Sourcecode problemloss einen Treiber für x86, Alpha, ... erzeugen. Bei Linus sollte das nicht viel anders sein sollange man es bleiben lässt den Treiber mit Inlineassembler zu schreiben.
Ein ganz extremes Beispiel ist hier nVidia die erzeugen alle Treiber (alle Windows versionen, Linux, Mac, BSD) aus dem gleichen Sourcecode. Dabei sind jeweils nur etwa maximal 5% platformspezifisch.
Crushinator
2003-09-08, 11:08:13
Original geschrieben von Demirug
Wenn die Treiber richtig programmiert wurden muss man sie nur neu kompilieren. Der NT-Kern war ja von Anfang an auf Platformunabhänigkeit ausgelegt. Man konnte damals aus dem gleichen Sourcecode problemloss einen Treiber für x86, Alpha, ... erzeugen. Bei Linus sollte das nicht viel anders sein sollange man es bleiben lässt den Treiber mit Inlineassembler zu schreiben. (...) So ganz kann ich das nicht stehen lassen. In vielen Fällen muß man aufpassen, da sich das OS-Verhalten bezüglich ACPI verändert hat. Es gibt z.B. - nicht näher genannte - Feinheiten zwischen 2K und XP , wenn man Treiber für Karten mit mehreren Chips drauf (NICs oder SCSI) schreibt.
Nachdem ich festgestellt habe, daß auch Intel & Co. diesbezüglich Probleme mit ihren Multi-Port/Chips-NICs unter XP haben, glaube ich nicht mehr daran, daß ich irgendwas in der Spezifikation und dem DDK übersehen habe. ;)
Demirug
2003-09-08, 11:34:32
Original geschrieben von crushinator
So ganz kann ich das nicht stehen lassen. In vielen Fällen muß man aufpassen, da sich das OS-Verhalten bezüglich ACPI verändert hat. Es gibt z.B. - nicht näher genannte - Feinheiten zwischen 2K und XP , wenn man Treiber für Karten mit mehreren Chips drauf (NICs oder SCSI) schreibt.
Nachdem ich festgestellt habe, daß auch Intel & Co. diesbezüglich Probleme mit ihren Multi-Port/Chips-NICs unter XP haben, glaube ich nicht mehr daran, daß ich irgendwas in der Spezifikation und dem DDK übersehen habe. ;)
Ich meinte gleiche OS-Version aber unterschiedliche Hardwareplatformen. Das es da von OS-Version zu OS-Version immer wieder unterschiede gegeben hat ist mir schon klar davon kann ich auch ein Lied singen. Gerade im Bereich der Resourcenzuordnung hat sich ja viel getan.
Original geschrieben von Demirug
Ein ganz extremes Beispiel ist hier nVidia die erzeugen alle Treiber (alle Windows versionen, Linux, Mac, BSD) aus dem gleichen Sourcecode. Dabei sind jeweils nur etwa maximal 5% platformspezifisch. Wie soll das denn gehen? Und verschenkt NV hier nicht Leistung? Bin ich wirklich in einer zu antiken Zeit geboren, so dass ich noch plattformabhängigen C++-Code mit Inline-Assembler für die performanteste Lösung halte?
Crushinator
2003-09-08, 14:18:25
Original geschrieben von aths
Wie soll das denn gehen? Und verschenkt NV hier nicht Leistung? Bin ich wirklich in einer zu antiken Zeit geboren, so dass ich noch plattformabhängigen C++-Code mit Inline-Assembler für die performanteste Lösung halte? Unter Windows benutzt man ja meist den selben Compiler, so daß Performance-Unterschiede nur noch durch die verscheidenen Wege entstehen, wie das jeweilige OS das Grafik-Subsystem ansteuert. Das von Dir angesprochene Inline-ASM wird AFAIK auch noch benutzt, dessen Anteil liegt aber im Gesamtcode bei weniger als 2%.
Unter Linux spielt zu dem auch noch der Compiler eine Rolle, wobei der GNU-cpp nicht gerade der optimierndeste seiner Art ist.
Demirug
2003-09-08, 14:26:43
Original geschrieben von aths
Wie soll das denn gehen? Und verschenkt NV hier nicht Leistung? Bin ich wirklich in einer zu antiken Zeit geboren, so dass ich noch plattformabhängigen C++-Code mit Inline-Assembler für die performanteste Lösung halte?
Die erhältlichen Compiler sind inzwischen so gut das man von Hand in der Regel nicht mehr viel rausholen kann aber die Kosten dafür in ungeahnte höhen schnellen. Zudem ist Assemblercode komplexer in der Wartung und Fehleranfälliger.
Was mit zudem auf keinen Fall vergessen darf. Ein gutes Verfahren mit einem schlechten Compiler ist in der Regel schneller als ein schlechtes Verfahren welches mit Assembler umgesetzt wurde.
Exxtreme
2003-09-08, 14:33:28
Original geschrieben von crushinator
Unter Linux spielt zu dem auch noch der Compiler eine Rolle, wobei der GNU-cpp nicht gerade der optimierndeste seiner Art ist.
Ja, wenn man einen optimierten Code unter Linux haben will, dann nimmt man am besten den Compiler von Intel.
Der Vorteil des GGC ist seine Robustheit und Plattformunabhängigkeit. :)
Damit lässt sich ein OS-Kernel mit vielen Millionen Zeilen korrekt übersetzen. :)
Crushinator
2003-09-08, 14:44:12
Original geschrieben von Exxtreme
Der Vorteil des GGC ist seine Robustheit und Plattformunabhängigkeit. :) Seine Vorteile diesbezüglich in allen Ehren, aber er könnte ruhig abisserl mehr optimieren, schließlich ist er der meistbenutzte Compiler unter den UNICes. *hoff*
Damit lässt sich ein OS-Kernel mit vielen Millionen Zeilen korrekt übersetzen. :) Hehehe...eine hervorragende Umschiffung des Problems, daß der Intel-Compiler keinen Kernel übersetzen kann. ;)
zeckensack
2003-09-11, 19:59:05
GCC ist ja nun auch nicht langsam ;)
Die 3er Serie frißt jeden beliebigen MS-Compiler bei lebendigem Leibe.
Der ICC ist vor allem deswegen auf Intels besser, weil das große blaue i optimierungsspezifische Informationen wie Staatsgeheimnisse behandelt.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.