Ist in Vista 64 geschriebener Code auf 32-Bit-Betriebssystemen kompatibel?

Question

Wir bekommen neue Entwicklungsmaschinen und steigen auf Vista 64 Ultimate um, um von unserem 8-GB-RAM zu profitieren.Unser Manager möchte, dass wir die gesamte Entwicklung in virtuellen 32-Bit-Maschinen durchführen, um sicherzustellen, dass es keine Probleme gibt, wenn unser Code in die Produktion übergeht.

Gibt es eine Möglichkeit zu garantieren, dass die resultierenden Programme auf 32-Bit-Betriebssystemen funktionieren?Es macht mir nichts aus, virtuelle Maschinen zu verwenden, aber mir gefällt nicht, wie sie einen dazu zwingen, wieder in eine „Einzelmonitor“-Ansicht zu wechseln.Ich verschiebe meine VS-Symbolleisten gerne auf meinen anderen Monitor.

BEARBEITEN:Wir verwenden Visual Studio 2005 und 2008, VB.NET und/oder C#

BEARBEITEN:Mit Harpreets Antwort, das sind die Schritte, die ich verwendet habe, um meine Visual Studio-IDE so einzustellen, dass sie x86/32bit kompiliert:

1. Klicken Sie auf „Erstellen“ und öffnen Sie den Konfigurationsmanager
2. Wählen Sie die Dropdown-Liste „Aktive Lösungsplattform“ aus
3. Wählen Sie x86 aus, wenn es in der Liste enthalten ist, und fahren Sie mit Schritt 5 fort, wenn nicht, wählen Sie <New...>
4. Wählen Sie im Dialogfeld „Neue Lösungsplattform“ x86 aus und klicken Sie auf „OK“.
5. Stellen Sie sicher, dass die ausgewählte Plattform für alle Ihre Projekte x86 ist
6. Klicken Sie auf Schließen.

Genießen.

Danke, Keith

Answer 1

Ich entwickle auf 64-Bit-Rechnern für 32-Bit-Windows.Es ist kein Problem.Um konservativ vorzugehen, sollten Sie sicherstellen, dass Ihre Projekte im x86-Modus kompiliert werden.Sie sollten jedes Projekt in der Lösung durchgehen und dies noch einmal überprüfen.Sie könnten auch die AnyCPU-Einstellung verwenden, aber das ist etwas riskanter, da sie auf Ihrem Entwicklungscomputer anders läuft als auf einem 32-Bit-Computer.Natürlich möchten Sie den 64-Bit-Modus vermeiden.

Die Probleme, auf die ich gestoßen bin, sind Treiber, die nicht funktionieren, wenn die App für 64 Bit kompiliert ist (explizit 64 Bit oder AnyCPU, kompiliert und ausgeführt unter 64 Bit Windows).Diese Probleme können vollständig vermieden werden, wenn man bei der x86-Kompilierung bleibt.Das sollte alle Fehler auf Ihren Entwicklungsmaschinen aufdecken.

Idealerweise könnten Sie eine Build- und Testumgebung einrichten, die häufig auf einem 32-Bit-Computer ausgeführt werden kann.Das sollte Ihr Management beruhigen und es Ihnen ermöglichen, die VM als Ihren Desktop zu vermeiden.

Answer 2

Solange Sie Ihre ausführbaren Dateien als 32-Bit kompilieren, laufen sie sowohl auf 32-Bit- als auch auf 64-Bit-Windows-Rechnern (garantiert).Die Verwendung von 64-Entwicklermaschinen hat den Vorteil, dass Sie mit dem Testen Ihres Codes mit der 64-Bit-Kompilierung beginnen können (um nach Dingen wie Zeigern zu suchen, die in 32-Bit-Ganzzahlen umgewandelt wurden), wodurch der Übergang zu 64-Bit in Zukunft einfacher wird (falls Ihr Unternehmen dies wünscht). um eine 64-Bit-Version zu erstellen).

Answer 3

Das Kompilieren für ein 64-Bit-Betriebssystem ist eine Option im Compiler.Sie können durchaus aus Vista 64 Bit in eine 32-Bit-Exe kompilieren.Wenn Sie die App ausführen, können Sie im TaskManager sehen, dass neben dem Prozess ein „*32“ steht...das bedeutet, dass es sich um 32bit handelt ;)

Ich glaube, Ihre Manager brauchen mehr Aufklärung darüber, was 64-Bit-Betriebssysteme wirklich bedeuten :)

Answer 4

Keine Antwort auf Ihre Frage, aber möglicherweise eine Lösung für Ihr Problem:VirtualBox (und wahrscheinlich auch andere) unterstützt den Modus „Nahtlose Integration“, der Ihnen lediglich eine zweite Startleiste bietet und Sie Fenster frei verschieben lässt.

Außerdem, und dies ist eine Antwort auf Ihre Frage, hängt es von Ihren Kompilierungseinstellungen ab.Sie können für verschiedene Umgebungen kompilieren und mit Visual Studio können Sie 32-Bit-Programme perfekt auf einem 64-Bit-System kompilieren.Ich kann Ihnen nicht sagen, wie, aber ich bin sicher, dass ein Visual Studio-Guru Ihnen helfen könnte.

Answer 5

Wir entwickeln eine 32-Bit-Anwendung mit VS 2005 (bald 2008) und haben gerade einige neue Maschinen mit XP Pro x64 oder Vista Business 64-Bit gekauft, damit wir den zusätzlichen RAM nutzen können, während wir uns das kurz ansehen Möglichkeit einer 64-Bit-Portierung, wenn dies kommerziell erforderlich wird.Wir hatten dabei keine Probleme, abgesehen von der Optimierung einiger Skripte in unserer Entwicklungsumgebung usw.

Diejenigen Entwickler, die nicht in diesen Upgrade-Zyklus einbezogen wurden, verwenden immer noch 32-Bit-Maschinen, sodass diese Probleme bekommen sollten, wenn die Unit-Tests und die Anwendungstestsuite selbstverständlich vor einem Check-in ausgeführt werden.

Was wir auch tun, ist sicherzustellen, dass wir über eine Reihe von „Test-Build“-Maschinen verfügen, die aus „typischen“ Konfigurationen (XP/Vista, 2/4/8 Kerne usw.) bestehen, die Check-In-Sets erstellen und testen - Wir haben verschiedene Testsuiten für Stabilität, Leistung usw.- bevor sie dem eigentlichen Integrationsbereich hinzugefügt werden.Auch hier sind bei der Ausführung einer 32-Bit-Anwendung, die auf einem 64-Bit-Betriebssystem basiert, keine Probleme aufgetreten.

Wie andere bereits gesagt haben, erwarte ich jedenfalls kein Problem, da es der Compiler ist, der den entsprechenden Code für das Zielbetriebssystem generiert, unabhängig davon, auf welchem ​​Betriebssystem der Compiler tatsächlich ausgeführt wird.

Answer 6

Ja, wie Adam sagte.Es gibt 3 Optionen:MSIL (Standard), x64 und x86.Sie können auf x64 abzielen und es werden DLLs speziell für 64-Bit-Systeme generiert, oder Sie können x86 verwenden, das auf 32-Bit und 64-Bit läuft, aber die gleichen Einschränkungen hat wie 32-Bit auf einem 64-Bit-System.

MSIL lässt grundsätzlich zu, dass der JITer die plattformspezifische Anweisung ausgibt (mit einer leichten Leistungseinbuße im Vergleich zu einem nativen Image).

BEARBEITEN:Keine Sprache, also spreche ich von .net-Framework-Sprachen wie vb.net und c#, C++ ist ein ganz anderes Tier.

Answer 7

Habe das heute gefunden:

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

x64-Entwicklung mit .NET

Anfang des Jahres habe ich auf ein 64-Bit-Betriebssystem umgestellt – genauer gesagt auf Vista Ultimate x64.Im Großen und Ganzen verlief dieser Vorgang relativ schmerzlos, es gab jedoch ein paar Probleme auf dem Weg (hauptsächlich x64-kompatible Treiber, aber das ist nicht der Punkt dieser Diskussion).

In der Welt der x64-Entwicklung gab es einige schwierige Punkte, die ich hier kurz skizzieren möchte.Diese Liste wird wahrscheinlich noch länger werden, also erwarten Sie zukünftige Beiträge zu diesem Thema.

In der wunderbaren Welt der .NET-Entwicklung können Anwendungen und Assemblys für verschiedene Plattformen kompiliert werden.Standardmäßig werden Anwendungen und Assemblys in Visual Studio als beliebige CPU kompiliert.In diesem Szenario lädt die CLR die Assembly als das Standardziel für den Computer, auf dem sie ausgeführt wird.Wenn Sie beispielsweise eine ausführbare Datei auf einem x64-Computer ausführen, wird diese als 64-Bit-Prozess ausgeführt.

Visual Studio bietet außerdem drei spezifische Plattformziele:x86, x64 und Itanium (IA-64).Wenn Sie eine ausführbare Datei als bestimmtes Ziel erstellen, wird sie als Prozess dieses Typs geladen.Beispielsweise wird eine auf x86 ausgerichtete ausführbare Datei, die auf einem x64-Computer ausgeführt wird, als 32-Bit-Prozess unter Verwendung der 32-Bit-CLR- und WOW64-Schicht ausgeführt.Wenn Assemblys zur Laufzeit geladen werden, können sie nur von einem Prozess geladen werden, wenn ihr Ziel mit dem des Hosting-Prozesses übereinstimmt oder sie als „Beliebige CPU“ kompiliert sind.Wenn beispielsweise x64 als Ziel für eine Assembly festgelegt wurde, kann diese nur von einem x64-Prozess geladen werden.

Dies kam bei mir in einigen Szenarien zum Tragen:

• XNA – XNA ist nur als Satz von 32-Bit-Assemblys verfügbar.Daher muss beim Verweisen auf die XNA-Assemblys die ausführbare Datei/Assembly, die sie verwendet, auf die x86-Plattform ausgerichtet sein.Wenn es als x64 (oder als beliebige CPU und Ausführung auf einem 64-Bit-Computer) vorgesehen ist, wird beim Versuch, die XNA-Assemblys zu laden, ein Fehler ausgegeben.

• Microsoft Robotics Studio – Der XInputGamepadService verwendet intern XNA, um mit dem Xbox 360-Controller zu kommunizieren.Siehe oben.

• Managed DirectX – Obwohl dies bereits veraltet ist und durch XNA ersetzt wird, hat es immer noch seine Verwendungsmöglichkeiten.Die Assemblys sind nicht für ein bestimmtes Ziel markiert, ich hatte jedoch Probleme mit Speicherausnahmen, insbesondere mit der Microsoft.DirectX.AudioVideoPlayback-Assembly.

• Phidgets – Je nachdem, welche Bibliothek Sie herunterladen und wann, kann sie als reine 32-Bit-Bibliothek markiert sein oder auch nicht.Die aktuelle Version (08.11.07) ist als solche gekennzeichnet und erfordert daher einen 32-Bit-Prozess zum Hosten.Der einfachste Weg, um festzustellen, ob eine ausführbare Datei oder Assembly auf eine bestimmte Plattform ausgerichtet ist, ist die Verwendung der Anwendung corflags.Um dies zu verwenden, öffnen Sie eine Visual Studio-Eingabeaufforderung in Ihrem Startmenü und führen Sie sie für die Assembly aus, die Sie überprüfen möchten.

Der einfachste Weg, um festzustellen, ob eine ausführbare Datei oder Assembly auf eine bestimmte Plattform ausgerichtet ist, ist die Verwendung der Anwendung corflags.Um dies zu verwenden, öffnen Sie eine Visual Studio-Eingabeaufforderung in Ihrem Startmenü und führen Sie sie für die Assembly aus, die Sie überprüfen möchten.