Frage Warum benötigt 64-Bit-Windows einen separaten Ordner "Programme (x86)"?


Ich weiß, dass auf einer 64-Bit-Version von Windows der Ordner "Programme" für 64-Bit-Programme und der Ordner "Programme (x86)" für 32-Bit-Programme, aber Warum ist das überhaupt nötig?

Mit "notwendig" meine ich nicht "warum hätte Microsoft keine anderen Designentscheidungen treffen können?" weil sie natürlich haben könnten. Ich meine, "warum müssen 32-Bit-Programme angesichts des aktuellen Designs von 64-Bit-Windows einen separaten Ordner der obersten Ebene von 64-Bit-Programmen haben?" Anders ausgedrückt: "Was würde schief gehen, wenn ich irgendwie den Umleitungsmechanismus umgehen würde und alles gezwungen hätte, es in das Reale zu installieren? C:\Program Files\"

Es gibt viele Fragen zu Super User und anderswo, die behaupten "Einer ist für 32-Bit-Programme, einer ist für 64-Bit-Programme", aber keiner, den ich finden kann, gibt den Grund. Aus meiner Erfahrung ist es nicht scheinen Es spielt keine Rolle, ob ein 32-Bit-Programm am richtigen Ort installiert ist oder nicht.

Stellt Windows sich irgendwie anders als ein Programm, das von "Programmdateien (x86)" läuft, vor? Gibt es eine Beschreibung, die genau zeigt, was für ein Programm anders ist, das in "Programme (x86)" anstelle von "Programme" installiert wird? Ich denke, es ist unwahrscheinlich, dass Microsoft einen neuen Ordner ohne einen legitimen technischen Grund einführen würde.


175
2018-06-27 17:19


Ursprung


Anstatt Ihre Frage zu beantworten, würde ich fragen - wie würden Sie mit \ program files \ common files umgehen? - sgmoore
One-Liner-Antwort (und damit ein Kommentar): Da Sie problemlos jede Anwendung aus jedem Ordner ausführen können, ohne ihre Architektur zu kennen, gibt es eindeutig keine verpflichtend Grund für diese Trennung. Es ist eine Frage der Bequemlichkeit um doppelte Installationen von Anwendungen mit beiden Architekturen zu unterstützen. In einigen Fällen macht es einen Unterschied, da es sich nicht unbedingt um einfache Neukompilierungen handelt. Das Hauptproblem besteht darin, dass 32-Bit-Apps keine 64-Bit-DLLs laden können. Daher können Sie beide Versionen normalerweise nicht an derselben Stelle installieren. Die andere Alternative besteht darin, für jede Anwendung zwei Ordner "bin" zu haben. - Sklivvz
@Synetech Ich hatte sogar Programme, die unter (x86) installieren, nur um x64-Binärdateien zu haben. Es ist manchmal schrecklich. - sinni800
Ich habe mich immer gewundert, warum Microsoft 64-Bit-Programme nicht in "Programme (x64)" abgelegt hat, anstatt "das" alte "Programmverzeichnis in Programme (x86) zu verschieben" - LawrenceC
Das eigentliche Problem bei der 64/32-Bit-Unterscheidung ist, dass / Windows / System32 64-Bit-Inhalt enthält, während / Windows / SysWOW64 das 32-Bit-Zeug enthält ... - poke


Antworten:


Kurze Antwort: Um sicherzustellen, dass 32-Bit-Legacy-Anwendungen weiterhin auf die gleiche Weise funktionieren, ohne dass hässliche Regeln für 64-Bit-Anwendungen gelten, die zu einer dauerhaften Unordnung führen würden.

Es ist nicht erforderlich. Es ist einfach praktischer als andere mögliche Lösungen, die beispielsweise erfordern, dass jede Anwendung ihre eigenen Möglichkeiten zur Trennung von 32-Bit-DLLs und ausführbaren Dateien von 64-Bit-DLLs und ausführbaren Dateien erstellt.

Der Hauptgrund ist, dass 32-Bit-Anwendungen, die nicht einmal 64-Bit-Systeme kennen, "einfach funktionieren", selbst wenn 64-Bit-DLLs dort installiert werden, wo die Anwendungen aussehen könnten. Eine 32-Bit-Anwendung kann keine 64-Bit-DLL laden. Daher wurde eine Methode benötigt, um sicherzustellen, dass eine 32-Bit-Anwendung (die 64-Bit-Systeme vorausdatieren kann und daher keine 64-Bit-Dateien hat) sogar existieren) würde kein 64-Bit-DLL finden, versuchen, es zu laden, fehlschlagen und dann eine Fehlermeldung generieren.

Die einfachste Lösung hierfür sind konsistent getrennte Verzeichnisse. Wirklich die einzige Alternative ist, dass jede 64-Bit-Anwendung ihre ausführbaren Dateien irgendwo "versteckt", wo eine 32-Bit-Anwendung nicht aussehen würde, wie z bin64 Verzeichnis in dieser Anwendung. Aber das würde auf 64-Bit-Systemen permanente Hässlichkeit auferlegen, nur um Legacy-Anwendungen zu unterstützen.


89
2018-06-27 18:18



Sie mussten nicht durch diese Rahmen springen, um 32-Bit- und 16-Bit-Programme auf demselben System zu ermöglichen. Ich kann mich nicht erinnern, jemals eine gesehen zu haben ProgramFiles (16) oder einige solcher. Außerdem, wie genau würde ein 32-Bit-Programm "eine 64-Bit-DLL finden und versuchen, sie zu laden"? Welche Programme jagen um zufällige DLLs in %programfiles%? Wenn es eine freigegebene DLL ist, dann geht es in WinSxS; Wenn es nicht geteilt wird, dann liegt es am Programmierer, seine eigenen DLLs zu verwalten. Der Teil darüber, dass es als Annehmlichkeit für Programmierer vernünftig getan wird, obwohl. - Synetech
IIRC Win3.1 hatte kein Programmdateiverzeichnis (oder die meisten Apps ignorierten es); Daher würde es keine veralteten Win16-Apps geben, die zunächst nach Programmdateien suchen. Stattdessen wurden IIRC shared libraries oft irgendwo im Windows-Ordner selbst abgelegt. Win32 mit Windows \ System und Windows \ System32 ist ein Artefakt davon. - Dan Neely
Windows 3.1 unterstützte lange Dateinamen nicht, so dass es keinen Ordner "Programmdateien" hätte. - Darth Egregious
@ JarrodRoberson: Ganz im Gegenteil, weil Microsoft die Rückwärtskompatibilität extrem hoch schätzt. - David Schwartz
@Jarrod: Tatsächlich weiß Microsoft, wie jeder Entwickler weiß, Rückwärtskompatibilität auch höchst. Buchstäblich jede API, die sie hat, hat veraltete Methoden, die sie oft nicht entfernen wollen ernst Fehler, die sie nicht beheben möchten, weil sie Angst davor haben, ältere Programme zu brechen, die für diese API geschrieben wurden. Das gleiche gilt für die meisten APIs, aber nicht für die von Microsoft. - BlueRaja - Danny Pflughoeft


Damit können Sie sowohl die 32-Bit- als auch die 64-Bit-Version einer Anwendung installieren, ohne dass sie sich selbst überschreibt.


Nachdem ich diese Antwort am nächsten Tag angeschaut und einen Thread kommentiert habe, erkenne ich in meiner Antwort ein mögliches großes Versehen. Ich habe fälschlicherweise einen Programmierhintergrund angenommen und wenn ich darüber gesprochen habe Sie In meinen Kommentaren meinte ich nicht den Benutzer, sondern den Programmierer.

Ich arbeite nicht für Microsoft und habe keine Ahnung, was das ist echt Die Begründung hinter diesen Ordnern ist, aber ich denke, der Grund, diese Ordner zu haben, ist so offensichtlich, dass ich kein Problem damit habe, sie zu streiten.

Also lass es uns kaputt machen!

  1. Ordner sind großartig!

    Lasst uns etwas vereinbaren. Ordner sind großartig! Wir brauchen sie nicht, wir haben genug mögliche Dateinamen, um jede einzelne Datei in das Stammverzeichnis Ihrer Festplatte zu legen, also warum überhaupt Ordner?

    Nun, sie helfen uns, unsere Sachen zu bestellen. Und das Zeug ist großartig. Es hilft uns, die Dinge leichter zu verarbeiten. Dies ist besonders nützlich, wenn Sie mit einer Maschine arbeiten, die eine Struktur benötigt.

  2. Daten und Logik zu trennen ist großartig!

    Ein Paradigma, das oft bei der Programmierung gefunden wird, besteht darin, Daten von der Logik zu trennen. Sie wollen einen Teil davon weiß es Wie etwas zu tun und du willst einen anderen Teil von dir kann etwas tun mit


65
2018-06-27 17:31



Ist das der ursprüngliche Grund? Kann ich nicht einfach die App installieren? C:\Program Files\App32 und C:\Program Files\App64? - Stephen Jennings
@ StephenJennings: Aber das würde erfordern, dass Sie die Entscheidung manuell treffen. Der Prozess läuft jetzt automatisch ab, da Windows weiß, welcher Ordner beim Aufruf einer Anwendung bereitgestellt werden soll SHGetSpecialFolderPath um den Installationsort zu bestimmen. - Der Hochstapler
@Synetech: Warum installieren in %PROGRAMFILES% an erster Stelle? Warum nicht die 32-Bit-Version auf den Desktop des Benutzers und die 64-Bit-Version in den Papierkorb? Nur weil es gemacht werden kann, bedeutet das nicht, dass es eine gute Idee ist. Entschuldigung, ich folge deinen Überlegungen nicht. - Der Hochstapler
@Synetech: Ja, Sie haben ein perfektes Beispiel dafür gegeben, wie es gemacht werden könnte. Ein anderes perfektes Beispiel dafür, wie es gemacht werden könnte, ist die Art und Weise ist wird gerade jetzt gemacht. Einfach eine Datei in% PROGRAMFILES% schreiben und sicher sein, dass sie im richtigen Ordner landen wird, ist eine Sache. Überprüfen Sie selbst, welcher Ordner der ist richtig einer ist ein anderer. Wenn Sie den Vorteil des ersten Ansatzes nicht sehen, kann ich Sie nicht überzeugen. Die Frage war, warum es 2 Ordner gibt. Ich denke, meine Antwort ist in dieser Hinsicht vollkommen vernünftig. - Der Hochstapler
@OliverSalzburg, Nein ganz. Die Frage ist, warum zwei Ordner sind erforderlichnicht warum sind. Tatsächlich hat er es sogar hervorgehoben: Warum ist das überhaupt nötig? Du hast nicht erklärt, warum es so ist notwendig und das Beispiel, das ich gab (und sogar dein eigenes sarkastisches Beispiel), zeigt nur, dass es nicht so ist haben so gemacht werden wie es ist. - Synetech


TL; DR:

Um es zusammenzufassen, nein, ist es nicht notwendig; Sie könnte haben einen einzigen Ordner verwendet, und nein, Windows zeigt sich nicht anders als ein Programm von einem Ort oder einem anderen Ort ausgeführt wird.


Nun, jeder scheint seine Meinung dazu zu äußern, also werde ich meine 2 ¢ einwerfen. Andere haben bereits die Gründe dafür vermutet Warum Microsoft entschied sich, separate Top-Level-Ordner für 32-Bit- und 64-Bit-Versionen von Programmen zu erstellen, also werde ich diesen Teil verlassen (der beste Grund war Davids Erklärung, dass es für Programmierer eine Erleichterung darstellt). Natürlich geht es auch dann nicht direkt auf die direkte Frage ein Warum ist das überhaupt nötig?, auf die die Antwort vermutlich lautet: es ist nicht.

Stattdessen werde ich den Hauptteil der Frage ansprechen

Stellt Windows sich irgendwie anders als ein Programm, das von "Programmdateien (x86)" läuft, vor?

Nicht wirklich, aber der Ort des Programms kann beeinflussen das Verhalten, aber nicht in der Art, wie Sie denken würden.

Wenn Sie ein Programm ausführen, richtet Windows eine Umgebung ein, in der es ausgeführt wird (ich meine in Bezug auf Speicher, Adressierung usw., nicht nur Umgebungsvariablen). Diese Umgebung hängt vom Inhalt der ausführbaren Datei ab (32-Bit- und 64-Bit-Programme unterscheiden sich intern). Wenn Sie ein 32-Bit-Programm auf einem 64-Bit-System ausführen, wird es in dem 32-Bit-Subsystem ausgeführt, das eine 32-Bit-Umgebung emuliert. Es wird genannt WoW64 (WoW64 steht für Windows unter Windows 64-Bit) und ist ähnlich wie 16-Bit-Anwendungen in XP mit dem NTVDM.

Wenn Sie ein Programm mit oder ohne Administratorrechte ausführen, wirkt sich dies auf die Ausführung aus, aber auf den Speicherort sollte nicht beeinflussen (obwohl es einige Beispiele von Standortabhängigkeit gibt, wie einige Treiber zum Beispiel).

(Ich benutze einen anderen Computer, so dass ich mich nicht auf meine Browsergeschichte verlassen kann, um meine Schritte zurückzuverfolgen, sondern neulich während der Beantwortung diese SU-Frage Ich landete bei diese SO Frage was mich dazu gebracht hat Google PROZESSOR_ARCHITEW6432welche zu führen diese SO Frage und dieser Microsoft Blogeintrag.)

Irgendwo auf dem Weg las ich einen StackOverflow-Post darüber, wie die Umgebungsvariable ist %processor_architecutre%  Je nachdem, von wo aus Sie die Eingabeaufforderung ausführen, ergeben sich unterschiedliche Ergebnisse (Ich werde versuchen, das genaue Zitat zu finden).

Es stellte sich heraus, dass die Antwort darauf zurückzuführen war, ob die 32-Bit- oder 64-Bit-Version der Eingabeaufforderung ausgeführt wurde (d. H. Von System32\ oder SysWoW64\). Mit anderen Worten, während der Ort scheint beeinflussen das Verhalten des Programms, es ist nur, weil es verschiedene Versionen des Programms gibt, nicht weil Windows den Ordner auf eine besondere Weise behandelt.

Dies ist sinnvoll, da der Inhalt der ausführbaren Datei angibt, ob es sich um 32-Bit- oder 64-Bit-Dateien handelt, sodass Sie sowohl eine 32-Bit- als auch eine 64-Bit-Kopie desselben Programms (z. B. foobar32.exe und foobar64.exe) in demselben Ordner und wenn Sie sie ausführen, werden sie korrekt geladen (die 64-Bit-Version wird nativ ausgeführt und die 32-Bit-Version wird in der WoW64-Emulationsschicht ausgeführt).

Mit FreePascal können Sie sowohl DOS- als auch Windows-Versionen installieren und sie befinden sich im selben Ordner: %programfiles%\FreePascal. Es verwaltet die verschiedenen Architekturen, indem es ausführbare Dateien speichert (.exe, .sys, .dll, .ovrusw.) in separaten Ordnern und Freigeben von Ressourcendateien wie Bilder, Quelldateien usw.) Es gibt keinen technischen Grund, warum dies nicht auch für 32- und 64-Bit-Versionen eines Programms möglich ist. Wie David sagte, ist es einfacher für den Programmierer, wenn sie getrennt gehalten werden (d. H. Variablen verwenden, damit es so aussieht, als ob es nur einen Satz von Dateien usw. gibt).


14
2018-06-27 19:23



Rache nach unten stimmen! Muahahaha! Seufzer - Synetech
Down-Stimme seltsam: \. BTW gut erklären +1. - avirk


Ein weiterer Grund ist, dass die meisten Programme Umgebungsvariablen wie% PROGRAMFILES% verwenden, um auf die Installation ihres Programms zu zeigen. Für 64-Bit-Programme geht es an den normalen Ort. Bei 32-Bit-Programmen wird es auf das neue umgeleitet Program Files (x86) Mappe.

Zumindest mit den neuen .Net-Elementen in Visual Studio haben sie jetzt die Variable App.Local, die den gesamten Bedarf dafür eliminiert.


11
2018-06-27 17:36



Das erklärt es nicht. Wer verwendet genau die Umgebungsvariable und warum würde es interessieren, ob ein Programm 32-Bit oder 64-Bit ist? - Synetech
@Synetech - Der Autor von Programmen verwendet die Umgebungsvariable. Was den Grund dafür angeht, ist wegen der Verweise auf dlls. Sie können eine 32-Bit-DLL nicht innerhalb eines 64-Bit-Prozesses laden und umgekehrt. - Ramhound
Und wie %programfiles%, %programfiles(x86)%, oder %programw6432% dort einen Unterschied machen? Alle gemeinsam genutzten DLLs werden in das einzelne WinSxS-Verzeichnis geschrieben, und alle nicht gemeinsam genutzten DLLs befinden sich direkt in der ausführbaren Datei. Das wäre nur wichtig, wenn Sie aus irgendeinem Grund sowohl 32-Bit- als auch 64-Bit-Versionen desselben Programms installiert haben, und selbst dann würden Sie die 32-Bit-DLLs mit der 32-Bit-Programmdatei und der 64-Bit-DLL beibehalten die ausführbare 64-Bit-Datei. Sie können das so machen: %programfiles%\CoolApp\bin\32 und% programfiles% \ CoolApp \ bin \ 64`, warum die separaten Ordner der obersten Ebene? - Synetech
@Synetech Sicher es tut; % programfiles% gibt es schon eine Weile. Wenn Sie ein 32-Bit-Programm auf einem 64-Bit-Computer installieren, würde das Vorhandensein eines Orts zu Problemen für diese 32-Bit-App führen. WoW kann% programfile% jedoch auf die (x86) -Version für 32-Bit-Anwendungen und die Nicht-x86-Version für 64 umleiten. - Andy
Ich denke, die Leute wären nicht so verwirrt, wenn es keine implizite Neuausrichtung gäbe - kommradHomer


Microsofts Lösung für diesen Übergang von 32-Bit zu 64-Bit bestand darin, Legacy-Unterstützung für die meisten 32-Bit-Anwendungen hinzuzufügen. Mit anderen Worten, die meisten 32-Bit-Anwendungen funktionieren in der 64-Bit-Betriebsumgebung. Beachten Sie, dass andere Betriebssysteme, die mit einer 64-Bit-Architektur arbeiten, keine 32-Bit-Anwendungen laden oder ausführen können.

Um den Übergang zu erleichtern, hat Microsoft festgelegt, dass alle 32-Bit-Anwendungen standardmäßig in den Ordner "Programme" (x86) geladen werden sollten, anstatt mit echten 64-Bit-Anwendungen im normalen Ordner "Programme" gemischt zu werden.

Quelle 

"Was würde schiefgehen, wenn ich irgendwie den Umleitungsmechanismus umgehen würde und alles gezwungen hätte, in das echte C: \ Programme \ zu installieren?" 

Nichts. Die zwei Programmverzeichnisse sind nur für die Organisation, oder um Programme, die zwei Versionen eine 32-Bit- und 64-Bit-Version getrennt haben, wie Internet Explorer. Aber Sie können ein 32-Bit-Programm in "Programme" und ein 64-Bit-Programm in "Programme x86" installieren und nichts wird passieren, das Programm wird gleich laufen.

Wiki sagt:

Einige Anwendungsinstaller lehnen Bereiche innerhalb des Pfads des Installationspfads ab. Für 32-Bit-Systeme lautet der Kurzname für den Ordner Programme Progra ~ 1. Für 64-Bit-Systeme lautet der Kurzname für den 64-Bit-Ordner "Programme" Progra ~ 1 (wie bei 32-Bit-Systemen); während der Kurzname für den 32-Bit-Ordner Programme (x86) jetzt ist Progra ~ 2.


8
2018-06-28 16:28



Hehe. Netter Artikel. Die Kommentare zu diesem Artikel klingen genau wie die hier. Schlimmer noch, dieser Artikel war vor mehr als zwei Jahren, was nur zeigt, dass diese Frage nicht neu ist und wenn sie immer noch nicht autoritativ beantwortet werden kann, dann wird es wohl nie passieren (es sei denn jemand aus dem Windows-Team läutet). Naja, ich nehme an, wir sollten alle aufhören, uns Sorgen zu machen und lernen, die Bombe zu lieben, äh, ich meine damit zu leben. +1 Um den Artikel aufzuzeigen und zu zeigen, dass diese Frage schon so lange existiert. - Synetech
@Synetech danke! Ja, die Idee hinter dem Artikel Link ist der gleiche wie du hast. Das ist eine sehr alte Zeitfrage, aber IDK, warum die Leute es noch nicht bekommen haben. Allerdings sollte die MS eine KB oder Dokumentation für dieses Problem schreiben :) - avirk
Ja, das sollten sie, vor allem, weil nicht nur Entwickler fragen, sondern auch normale Anwender sich darüber wundern. Leider ist die Dokumentation von Microsoft nicht oft zu gut. - Synetech
@Synetech Yup! Die MS-Dokumentation ist die meiste Zeit kaputt. Aber ja, sie haben auch gute Artikel geschrieben und ich bin mir ziemlich sicher, dass sie zählbar sind;) - avirk


Der Grund liegt darin, ein Upgrade für ein 64-Bit-Programm für Entwickler zu erleichtern. Sie müssen keinen benutzerdefinierten Code schreiben, um beim Kompilieren im 32-Bit-Modus und in einem anderen Verzeichnis beim Kompilieren im 64-Bit-Modus nach dem Programm in einem Verzeichnis zu suchen. sie überprüfen nur C:\Program Files, und wenn im 32-Bit-Modus ausgeführt wird, wird dies automatisch in geändert C:\Program Files (x86) von 64-Bit-Windows. In ähnlicher Weise sind die Registrierungseinträge zwischen 32-Bit- und 64-Bit-Programmen isoliert.

Dies verhindert Konflikte von unwissenden Entwicklern, die ihren Kompilierungsmodus einfach auf 64-Bit ändern, ohne sich Gedanken darüber zu machen, und verhindert eine enorme Menge an Arbeit für Entwickler, die Benutzer sowohl 32- als auch 64-Bit-Versionen installieren möchten Software gleichzeitig.


Aber warum sollte irgendein Programm beide Versionen gleichzeitig installieren lassen wollen? Ein Beispiel: Photoshop und IE haben Erweiterungen, die native .dlls sind. Sie können nicht 32- und 64-Bit-Code im selben Prozess mischen, daher kann ein Add-On für die 32-Bit-Version nicht mit der 64-Bit-Version verwendet werden und umgekehrt. Also, Photoshop / IE haben um zu erlauben, dass beide Versionen installiert werden, oder riskieren, ihre riesige Basis existierender Addons zu zerstören.


6
2018-06-27 18:48



+1 Sie haben zumindest die Frage beantwortet, warum durchschnittliche Benutzer beide Versionen haben. - Synetech


Programme, die unter "Programme (x86)" ausgeführt werden, verwenden die WOW64 Subsystem (Windows 32-Bit unter Windows 64-Bit ist eine Reihe von Treibern und APIs, die zum Ausführen von x32-Anwendungen über ein x64-Architektursystem vorgesehen sind):

Das WoW64-Subsystem umfasst eine leichte Kompatibilitätsschicht, die   hat ähnliche Schnittstellen für alle 64-Bit-Versionen von Windows. Es zielt darauf ab   Erstellen Sie eine 32-Bit-Umgebung, die die erforderlichen Schnittstellen bereitstellt   Führen Sie unmodifizierte 32-Bit-Windows-Anwendungen auf einem 64-Bit-System aus.   Technisch ist WoW64 mit drei Dynamic-Link-Bibliotheken implementiert   (DLLs):

  • Wow64.dll, die Kernschnittstelle zum Windows NT-Kernel, der zwischen 32-Bit- und 64-Bit-Aufrufen einschließlich Zeiger und Aufruf übersetzt   Stapelmanipulationen
  • Wow64win.dll, die die entsprechenden Einstiegspunkte für 32-Bit-Anwendungen bereitstellt
  • Wow64cpu.dll, die dafür sorgt, dass der Prozessor vom 32-Bit- auf den 64-Bit-Modus umgeschaltet wird

64-Bit-System muss 32-Bit-Anwendungen "emulieren", das ist der Grund, warum Windows zwei Programme-Ordner "trennen" muss.


5
2018-06-27 17:32



Aber warum muss es in verschiedene Ordner gelegt werden? Windows ist bereits in der Lage, die Architektur einer ausführbaren Datei zu bestimmen, indem es den PE-Header betrachtet. Warum kann beim Laden der ausführbaren Datei nicht die entsprechende Umgebung geladen werden? - Synetech
Ich denke, es ist einfach eine Entscheidung von Microsoft, den Benutzern einfach zu zeigen, welche Architektur sie von zwei Programmversionen haben wollen, wenn sie ein Programm öffnen. Ich meine, wenn es diese zwei Ordner nicht gäbe und wenn es für die Benutzer transparent wäre (wenn es automatisch wechselt), würden sie nicht wissen, ob sie eine 32 oder 64 Bit App ausführen, sie würden nicht wissen, welches Programm geöffnet werden soll wenn auf 64 Bits läuft .. - Diogo
Die 64-Bit-Version von IE hat den Ruf, fürchterlich zu sein. - Samuel Edwin Ward
MS empfiehlt die Verwendung von office32, es sei denn, Sie arbeiten mit Datasets, die groß genug sind, um Speicherbeschränkungen zu überschreiten. Ich glaube, dass binäre Addons neu kompiliert werden müssen, um mit office64 zu arbeiten; in Verbindung mit dem Verzicht auf Vorteile in normalen Anwendungsfällen steht hinter der Entscheidung. - Dan Neely
Ich denke, Sie werden feststellen, dass ein 64-Bit-Programm, das explizit in den Ordner Programme (x86) installiert wird, einwandfrei funktioniert (und in den meisten Fällen auch umgekehrt). Windows verwendet den Speicherort des Ordners nicht, um zu bestimmen, wie die ausführbare Datei behandelt wird. - Harry Johnston