Kompatibilität von C/C++-Programmen
-
Der aus dem Westen ... schrieb:
wxSkip schrieb:
Was er hat? Recht hat er!
Mag sein, aber ich habe eine völlig korrekte Frage gestellt. Ich habe das Recht, nicht alles zu wissen, aber ich sehe es als Pflicht an, möglichst viel zu lernen. Und wenn mir bestimmte Medien bestimmte Konzepte nicht erklären können, fragt man besser nach ... bevorzugt bei Leuten, die sich mit der Materie besser auskennen. Dafür existiert doch dieses Forum, was?
Das war keine Kritik an dir. Ich wollte nur bestätigen, dass es Leute gibt, die die Bezeichung C/C++ kritisieren, vielleicht zu Recht, wenngleich es etwas pingelig ist. In deinem Fall meinst du natürlich eher C und C++ als eine Mischung aus C und C++, daher wäre Kritik hier weniger angebracht.
-
Dieser Thread hat FAQ-Potential als ein Beispiel für "Wie stelle ich meine Anfängerfragen richtig?". Zum Thema:
Der aus dem Westen ... schrieb:
Definieren moderne Prozessoren unterschiedlicher Hersteller den gleichen Befehlssatz (oder binden zumindest die neusten Befehle in ihre Entwicklungen ein)? Worauf muss ich achten, wenn ich will, dass meine Programme auch auf fremden Maschienen laufen?
Ich bleibe im Beispiel auch bei x86 Prozessoren. Die Befehlssätze sind der gemeinsame Nenner und die Prozessoren deshalb kompatibel, wie es schon gesagt wurde, allerdings gibt es auch noch Befehlssatzerweiterungen, die herstellerspezifisch sein können. Als Paradebeispiel sei hier SSE und 3DNow! erwähnt. Dort liest es sich:
Da SSE eine der ersten SIMD-Erweiterungen der x86-Architektur ist und bereits im Jahr 1999 auf den Markt kam, besitzen eigentlich alle x86-CPUs der letzten Jahre SSE.
Da 3DNow! eine der ersten Erweiterungen der x86-Architektur ist, besitzen viele CPUs (außer von Intel) der letzten Jahre 3DNow!.
Solche Erweiterungen kommen immer mal wieder hinzu, deren Verwendung könnte dein Programm ggf. inkompatibel mit älteren Prozessoren machen. Moderne Compiler optimieren Code und machen sich dabei auch solche Erweiterungen zunutze. Obwohl es in der Praxis wenig relevant sein wird, weil du die Erweiterungen möglicherweise gar nicht benutzt und sie andernfalls ja doch fast überall unterstützt werden, kann ein Blick ins Compilerhandbuch nicht schaden, für VC++ wäre z.B. hier die richtige Anlaufstelle: MSDN: /arch (Minimum CPU Architecture) und MSDN: Compiler Intrinsics.
-
Der aus dem Westen ... schrieb:
und ein x86-Programm läuft zwar auf einem x86- und einem x64-Prozessor (andere Architekturen können folgen), aber nicht auf einem 16-Bit-Prozessor.
Das ist nicht korrekt.
Der 8086 ist ein 16 Bit Prozessor, das gleiche gilt für den 8088, 80186 und 80286.
Und alle älteren DOS Programme sind 16 Bit Programme, deswegen laufen sie auch auf einem 8086 und heutigen x64 Rechnern.
-
Musterknabe schrieb:
Dieser Thread hat FAQ-Potential als ein Beispiel für "Wie stelle ich meine Anfängerfragen richtig?".
So mies?
Musterknabe schrieb:
...
Danke dafür.
Korrektor schrieb:
Das ist nicht korrekt.
Der 8086 ist ein 16 Bit Prozessor, das gleiche gilt für den 8088, 80186 und 80286.
Und alle älteren DOS Programme sind 16 Bit Programme, deswegen laufen sie auch auf einem 8086 und heutigen x64 Rechnern.Klar. Deshalb laufen auch 16-Bit-Spiele, die ich auf Windows 7 64 Bit starten will, prinzipiell nicht. Stattdessen (wenn ich das jetzt richtig im Kopf habe - ist schon eine Weile eher, dass ich eine Rohinstallation versucht und nicht die DOSBox verwendet habe) kommt eine Fehlermeldung, dass wohl eine falsche Version der Anwendung verwendet und ich mal nachfragen sollte, ob beim Hersteller eine x86- oder x64-Version der Anwendung zu bekommen sei - ein klares Zeichen dafür, dass dem wohl nicht so ist.
Ich erinnere mich, dass einmal gesagt wurde, dass unter Windows XP (32 und 64 Bit) ein 16-Bit-Prozessor emuliert wird, wenn 16-Bit-Anwendungen gestartet werden. Ich habe einmal nach dem Aufrüsten meiner Maschine (GIGABYTE-Mainboard, x64-Architektur und Windows 7 64 Bit) gemerkt, dass meine 16-Bit-Anwendungen nicht mehr lauffähig sind. Und das, obwohl ich einen AMD64-Prozessor verwende, der laut diesem Artikel Kompatibilität mit 16-Bit-Software gewährleisten soll.
Außerdem rede ich hier von etwas ganz anderem. 64-Bit-Programme kann man kaum auf einem 16-Bit-Prozessor ausführen, noch nicht einmal auf einem 32-Bit-Prozessor. Wie denn auch - ein 64-Bit-Programm verweißt auf Register, die x86er nicht kennen.
Nur in einem kann ich dir zustimmen: der Bezeichner x86 ist von mir irreführend gewählt - schließlich waren die ersten x86er 16-Bit-Prozessoren, bevor dann 85 die ersten x86er eine 32-Bit-Architektur aufwiesen.
-
Der aus dem Westen ... schrieb:
Klar. Deshalb laufen auch 16-Bit-Spiele, die ich auf Windows 7 64 Bit starten will, prinzipiell nicht.
Das Problem sitzt offenbar vor dem Bildschirm.
Wenn du zu doof bist um auf deinem 64 Bit Prozessor für deine 16 Bit DOS Anwendungen DOS zu benutzen, dann bist du schlichtweg selber schuld.
Bei mir laufen alle 16 Bit DOS Anwendungen auf meinem 64 Bit Prozessor unter DOS.
Stattdessen (wenn ich das jetzt richtig im Kopf habe - ist schon eine Weile eher, dass ich eine Rohinstallation versucht und nicht die DOSBox verwendet habe) kommt eine Fehlermeldung, dass wohl eine falsche Version der Anwendung verwendet und ich mal nachfragen sollte, ob beim Hersteller eine x86- oder x64-Version der Anwendung zu bekommen sei
Die 16 Bit MS-DOS Anwendung ist eine x86 Version der Anwendung!
Daher sag ich es nochmal, das Problem sitzt definitiv VOR dem Bildschirm.
Ich erinnere mich, dass einmal gesagt wurde, dass unter Windows XP (32 und 64 Bit) ein 16-Bit-Prozessor emuliert wird, wenn 16-Bit-Anwendungen gestartet werden. Ich habe einmal nach dem Aufrüsten meiner Maschine (GIGABYTE-Mainboard, x64-Architektur und Windows 7 64 Bit) gemerkt, dass meine 16-Bit-Anwendungen nicht mehr lauffähig sind. Und das, obwohl ich einen AMD64-Prozessor verwende, der laut diesem Artikel Kompatibilität mit 16-Bit-Software gewährleisten soll.
Wenn du eine Anwendung auf dem falschen Betriebssystem startest, die für MS DOS geschrieben wurde, dann bist du schlichtweg schon wieder selber schuld.
Also, damit du das auch kapierst:
Fakt ist, daß auch ein 64 Bit x86 Rechner eine 16 Bit MS DOS Anwendung ausführen kann, solange der Rechner noch BIOS besitzt. Bei Macs müßte es also bestenfalls Softwareseitig nachgeschoben werden.Außerdem rede ich hier von etwas ganz anderem. 64-Bit-Programme kann man kaum auf einem 16-Bit-Prozessor ausführen, noch nicht einmal auf einem 32-Bit-Prozessor.
Das habe ich auch nicht behauptet.
Ich schrieb, daß man 16 Bit x86 Programme auf einem 64 Bit x86 Prozessor ausführen kann.Nur in einem kann ich dir zustimmen:
Du bist mir nicht gewachsen und kannst keine qualiativen Aussagen treffen, deswegen würde ich sagen, daß du nichtmal stimmberechtigt sein solltest.
-
sicher, aber nicht 100% - Stichwörter Neha1em xe0n und das gute alte A2O Gate.
-
Der aus dem Westen ... schrieb:
Musterknabe schrieb:
Dieser Thread hat FAQ-Potential als ein Beispiel für "Wie stelle ich meine Anfängerfragen richtig?".
So mies?
Nein, dein Thread ist die Antwort auf die Frage.
-
Der aus dem Westen ... schrieb:
Ich habe einmal nach dem Aufrüsten meiner Maschine (GIGABYTE-Mainboard, x64-Architektur und Windows 7 64 Bit) gemerkt, dass meine 16-Bit-Anwendungen nicht mehr lauffähig sind. Und das, obwohl ich einen AMD64-Prozessor verwende, der laut diesem Artikel Kompatibilität mit 16-Bit-Software gewährleisten soll.
Das liegt an Windows, nicht an der CPU.
Die CPU kann schon noch 16 bittiges Zeug ausführen, bloss haben sie unter Windows den Support dafür rausgenommen.
Offiziell weil es "nicht geht", weil man die CPU nicht ohne Weiteres vom 64 Bit Mode in den V86 Mode schalten kann.
Mag sein dass das die Dinge etwas verkompliziert, aber möglich ist es trotzdem. VMware/VirtualBox/... machen es ja auch.
Soll heissen: installier VMware/VirtualBox/..., und du kannst auf deinem 64 Bit PC mit Windows 7 64 als Host wunderbar DOS in einer VM laufen lassen, und da drin diverse 16 Bit Programme.
-
Der aus dem Westen ... schrieb:
Worauf muss ich achten, wenn ich will, dass meine Programme auch auf fremden Maschienen laufen?
Halte dich an Standards.
Wenn du z.B. für deine Zielplattformen jeweils einen ANSI-C Compiler besitzt, dann schreibe ANSI-C konformen Quellcode und du bist maximal portabel.
Der Haken beginnt dort, wo du Plattform-Spezifiken verwenden willst, die evtl. andere Standard-Compiler nicht unterstützen eben weil diese Spezifiken ( z.B. Cursorsteuerungen in einem Konsolenfenster,... ) nicht im Standard definiert werden.
Auch sind (natürlicherweise) maximal plattformunabhängige Programme/Quellcodes meist nicht auch maximal schnell, dafür bieten sich dann plattformabhängige Compiler an (z.B. Intel,...).
-
Korrektor schrieb:
Das Problem sitzt offenbar vor dem Bildschirm.
Wenn du zu doof bist um auf deinem 64 Bit Prozessor für deine 16 Bit DOS Anwendungen DOS zu benutzen, dann bist du schlichtweg selber schuld.
Bei mir laufen alle 16 Bit DOS Anwendungen auf meinem 64 Bit Prozessor unter DOS.
Kann es sein, dass du mich prinzipiell für blöder hälst, als ich bin?
Ich kenne den Unterschied zwischen DOS und Windows, Himmel noch mal. Ich bin noch mit MS-DOS und Windows 3.11 aufgewachsen ... und glaub mir, ich versuche nicht, alte DOS-Anwendungen auf Windows laufen zu lassen, das wird nicht funktionieren, aber soweit war ich auch schon. Deshalb benutze ich ja die DOSBox.
Mein Beispiel bezog sich auf Command & Conquer, welches in zwei Versionen auf meiner CD vorliegt: DOS und Windows. Ich habe also versucht, die Windows-Installation zu starten, aber leider scheint es hierbei ein Problem zu geben, da nachdem der Install Shield Wizard 100% seines Ladebalkens erreicht hat, dieser einfach mit Fehlermeldung (allerdings ohne Inhalt!) abstürtzt. "Rohinstallation" ist mein Terminus für das Programm, dass ich verwendet habe, um es doch installieren zu können (denn die vorhergehensweise war ein bisschen komplex, da mit Rohdaten rumhantiert wurde) - installieren, wohlgemerkt, nicht spielen, das ist aus mir unerfindlichen Gründen nicht möglich (siehe die Fehlermeldung einige Posts zuvor).
Korrektor schrieb:
Die 16 Bit MS-DOS Anwendung ist eine x86 Version der Anwendung!
Daher sag ich es nochmal, das Problem sitzt definitiv VOR dem Bildschirm.
Fragt sich nur, vor welchem ... abgesehen davon, dass ich auch nach mehrmaligem Durchlesen deines Satzes nicht mal einen Deut schlauer bin als zuvor, habe ich nicht explizit geschrieben, dass ich versuche, eine DOS-Anwendungen unter Windows laufen zu lassen, sondern nur, dass ich es einmal für Windows auf Windows und einmal für DOS auf der DOSBox gestartet habe - und nur beim zweiten hat's geklappt.
Korrektor schrieb:
Also, damit du das auch kapierst:
Fakt ist, daß auch ein 64 Bit x86 Rechner eine 16 Bit MS DOS Anwendung ausführen kann, solange der Rechner noch BIOS besitzt. Bei Macs müßte es also bestenfalls Softwareseitig nachgeschoben werden.Windows offenbar nicht, und darum geht's mir.
Korrektor schrieb:
Du bist mir nicht gewachsen und kannst keine qualiativen Aussagen treffen, deswegen würde ich sagen, daß du nichtmal stimmberechtigt sein solltest.
Zumindest bin ich in der Lage zu lesen, was keine Selbstverständlichkeit ist - immerhin scheint es trotz der Schulbildung in diesem Land immer noch Analphabeten, dies's nicht können, und Leute, dies's nicht verstehen, zu geben. Zudem lässt die Aussage "Du bist mir nicht gewachsen" entweder auf einen Narzisten ("Ich bin der Tollste, alle anderen sind mir nicht gewachsen!") oder auf ein zu kleines Ego schließen, dessen Person dies zu kompensieren versucht, schließen.
hustbaer schrieb:
Das liegt an Windows, nicht an der CPU.
Die CPU kann schon noch 16 bittiges Zeug ausführen, bloss haben sie unter Windows den Support dafür rausgenommen.
Offiziell weil es "nicht geht", weil man die CPU nicht ohne Weiteres vom 64 Bit Mode in den V86 Mode schalten kann.
Mag sein dass das die Dinge etwas verkompliziert, aber möglich ist es trotzdem. VMware/VirtualBox/... machen es ja auch.
Soll heissen: installier VMware/VirtualBox/..., und du kannst auf deinem 64 Bit PC mit Windows 7 64 als Host wunderbar DOS in einer VM laufen lassen, und da drin diverse 16 Bit Programme.Danke, eine solche Antwort hilft mir wirklich weiter.
Wutz schrieb:
Halte dich an Standards.
Wenn du z.B. für deine Zielplattformen jeweils einen ANSI-C Compiler besitzt, dann schreibe ANSI-C konformen Quellcode und du bist maximal portabel.
Der Haken beginnt dort, wo du Plattform-Spezifiken verwenden willst, die evtl. andere Standard-Compiler nicht unterstützen eben weil diese Spezifiken ( z.B. Cursorsteuerungen in einem Konsolenfenster,... ) nicht im Standard definiert werden.
Auch sind (natürlicherweise) maximal plattformunabhängige Programme/Quellcodes meist nicht auch maximal schnell, dafür bieten sich dann plattformabhängige Compiler an (z.B. Intel,...).Zunächst: ich habe C/C++ geschrieben, weil ich es für beide Sprachen wissen wollte. Ich schreibe oft in beiden Sprachen und habe schon einige böse Dinge in C gesehen, die nicht standart waren ... wie zum Beispiel eine Form der Parameterdeklaration, die ich bis dato noch nie gesehen habe, oder dass Schleifenvariablen auch ausserhalb der Schleife benutzt werden können.
Was die Plattform angeht: ich kann in einem Programm also die STL und Container verwenden, wie ich lustig bin, und es wird funktionieren (auch, um das Beispiel bezubehalten, auf meiner Uhr oder der Waschmaschine), aber sobald ich einen nicht universell einsetzbaren Interupt (oder, um bei C/C++ zu bleiben, eine Funktion, die einen Interupt verwendet) verwende, gibt's Probleme, stimmt's?
-
Der aus dem Westen ... schrieb:
Was die Plattform angeht: ich kann in einem Programm also die STL und Container verwenden, wie ich lustig bin, und es wird funktionieren (auch, um das Beispiel bezubehalten, auf meiner Uhr oder der Waschmaschine), aber sobald ich einen nicht universell einsetzbaren Interupt (oder, um bei C/C++ zu bleiben, eine Funktion, die einen Interupt verwendet) verwende, gibt's Probleme, stimmt's?
Du kannst die Container, STL usw. verwenden wenn du das Programm für die neue Plattform (Hardware + Betriebssystem...) neu übersetzt und beide Compiler standardkonform sind. Sobald du Bilbiotheken benutzt, die plattfomrspezifisch sind (z.B. WinAPI-Funktionen für Interrups oder weiß der Geier was es da gibt), ist das nicht mehr der Fall. Es gibt allerdings Bibliotheken, die für ähnliche Dinge auf verschiedenen Zielplattformen eine einheitliche Schnittstelle liefern, beispielsweise boost.thread für die Threading-Mechanismen unter Windows und unixoiden Systemen.
Auch bei Dingen, die aus dem Standard kommen, ist nicht immer gleiches Verhalten garantiert, auch wenn die Compiler standardkonform sind - der Standard benutzt an diversen Stellen die Phrase "implementation defined", was heißt, dass jeder Compiler selbst bestimmen kann, wie das Verhalten an der Stelle ist.
