Wie die Überschrift schon erahnen läßt wie speziell muß/ kann ich mein Programm compilieren. Also ich arbeite auf einem Intel/Ubuntu System. Wenn ich mit gcc mein C Programm compiliere muß ich es z.b. für ein Arm/Ubuntu System neu compilieren. Wenn ich nun mein Programm auf möglichst vielen Prozessoren laufen lassen will könnte ich es natürlich mittels Cross Compiler für jede OS/Prozessor kombination neu kompilieren. Ich vermute mal stark dass ich für jedes OS eine Version kompilieren muß. Aber wenn ich z.B. ein Windows Programm anschaue bekomme ich nicht x exe-files für jeden Prozessortyp. Wohingegen ich in Linux scheinbar spezieller sein muss/kann da die Packages speziel auf Prozessor und Version abgestimmt sind bzw ich den source code mittells make/gcc für meinen Prozessor compilieren muss/kann. Die Frage ist nur rein informativ etwas was ich mich schon länger gefragt habe. Ich habe deshalb kein konkretes Beispielprogramm was ich anführen könnte. Aber wäre toll wenn jemand etwas auch nur zu teilen meiner Frage sagen könnte
Die prozessorfamilie muss binärkompatibel sein, also den selben instructioncode verstehen. Bei pc os sind das alle intel/ amd orozessoren mit x86 oder IA32 und ähnlicher prozessorarchtektur. Ferner muss die benutzte API und die gelinkte runtime zum OS passen https://de.m.wikipedia.org/wiki/Cygwin https://de.m.wikipedia.org/wiki/IA-32
Ich habe auch Cross-Compiler für Arm unter Windows. Da bekommt man dann auch für jede Architektur ein eigenes Exe. Das heisst dann nicht Exe sondern (z.B. bei meinem NXP-Cross Compiler) .bin . Ist also letztendlich das gleiche unter Windows. Unter Linux kann man sich mit file anschauen, für welche Architektur ei Executable ist: file xx_message xx_message: ELF 32-bit LSB executable, ARM, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x972eae9e79e0dbe06bd64628c7bcb191bbfea088, stripped Das Kommando wurde auf einem X86 Linux ausgeführt, das Executable ist allerdings für arm/32.
Felix schrieb: > Aber wenn ich z.B. ein Windows Programm anschaue > bekomme ich nicht x exe-files für jeden Prozessortyp Windows ist gröstenteils auch nur auf x86 und amd64 benutzbar. Es gibt zwar noch arm, aber dort die meisten Anwendungen nicht. x86 ist mit amd64 kompatibel. Eine exe Datei ist eigentlich eine art Archivdatei. Der Programmcode ist immer nur für eine Architektur. Ob eine exe mehrere Programcodes für unterschiedliche Architekturen beinhalten kann, weiss ich nicht, meistens sind diese aber für eine bestimmte Architektur, man denke an all die Programme, die eine 64-bit und eine 32-bit Version anbieten. Es fällt nur nicht so auf, weil Windows sowieso nur auf sehr wenigen CPU Architekturen funktioniert. Ich glaube MS wollte das Problem bei arm mal lösen, indem sie eine amd64 Emulationsschicht ins OS einbauen, aber ich weiss nicht was daraus geworden ist. Ich frage mich, ob man in arm Windows amd64 Anwendungen laufen lassen könnte, indem man im WSL wine für amd64 mit Qemu User Emulation laufen lässt?
Daniel A. schrieb: > Ich frage mich, ob man in arm Windows amd64 Anwendungen laufen lassen > könnte, indem man im WSL wine für amd64 mit Qemu User Emulation laufen > lässt? WSL gibt es nur für AMD64 Architekturen, weil er die Linux binaries direkt auf dem Hostprozessor ausführt (und dann Kernel Aufrufe auf den Windows-Kernel umleiten). Vermutlich würde WSL auch auf ARM laufen (wenn MS das implementiert), dann müssten aber auch ARM binaries für Linux benutzt werden. Gruß Jan B
Felix schrieb: > Aber wenn ich z.B. ein Windows Programm anschaue > bekomme ich nicht x exe-files für jeden Prozessortyp. Da können aber verschiedene Programmme oder Programmteile für verschiedene Prozessoren drinstecken, denn auch X86 ist nicht gleich X86. 32/64 Bit-Versionen sind sowieso getrennt Denn zwischen einem 386 und einem aktuellen Intel-Prozessor liegen schon Welten. All das, was der neue mehr kann, lässt sich nur mit passend kompilierten Programmen auch nutzen. Oliver
:
Bearbeitet durch User
Gewöhn' dich dran, so ist die Welt. Es geht nicht nur um Op-Codes für den spezifischen Prozessor, sondern auch um Bibliotheken und Linking-Strategien (static/ dynamic). Ist schon ein Unterschied, auf Windows in eine .DLL zu fassen, als unter Linux vom Kernel gerufen zu werden (oder in eine .so zu greifen). Und selbst wenn du kein einziges #include hast, bleibt es immer dem Compiler überlassen, wie etwa Gleitkommaarithmetik oder Speicherallokation vorgenommen wird. Das kannst du sogar mit dem Füllhorn an Compiler-Paramtern steuern. Und noch ein Tipp: jeder Compiler hat seine Eigenheiten UND es unterscheidet sich sogar von Compiler-Version zu Compiler-Version.
Jan B. schrieb: > Daniel A. schrieb: >> Ich frage mich, ob man in arm Windows amd64 Anwendungen laufen lassen >> könnte, indem man im WSL wine für amd64 mit Qemu User Emulation laufen >> lässt? > > WSL gibt es nur für AMD64 Architekturen. Oh, das wusste ich noch garnicht. > Vermutlich würde WSL auch auf ARM laufen (wenn > MS das implementiert), dann müssten aber auch ARM binaries für Linux > benutzt werden. Da käme dann eben die Qemu User Emulation ins spiel. Qemu User Emulation ist eine unvollständige Emulation. Statt das gesammte System zu emulieren, werden nur die Anwendungen darauf emuliert, wodurch man Anwendungen anderer Architekturen auf seinem System starten kann, wie wenn diese nativ wären. Ich habe das aber noch nie ausprobiert, und das gibt es nur für Linux: https://wiki.debian.org/QemuUserEmulation http://nairobi-embedded.org/qemu_usermode.html
Oder meinst Du etwa so einen "Zwischencode" wie bei Java oder .Net ? Da wird nicht gleich in etwas Ausführbares übersetzt, sondern in einen Code, den weder der Programmierer noch der Prozessor versteht, welcher dann, wenn der Benutzer das Programm startet, durch ein weiteres Programm (Laufzeitumgebung) interpretiert wird. Dadurch ist es möglich durch Austausch des Compilers verschiedene Sprachen zu unterstützen und durch Austausch der Laufzeitumgebung verschiedene Architekturen.
Nee nee ich meine schon in C. Klar in höheren Programmiersprachen ist dass dann immer Prozessor unspezifischer. Aber ich hatte mich nur gefragt weil ja die Variationsmöglichkeiten riesig sind gegen die man sein Programm kompilieren, optimieren und testen muss. Mit der Zeit nimmt ja auch die Anzahl der Prozessoren zu. > Da können aber verschiedene Programmme oder Programmteile für > verschiedene Prozessoren drinstecken, Klar die Binaries können natürlich dann für verschiedene Prozessoren sein. Dann wird natürlich auch die Größe des Programms immer größer.
Daniel A. schrieb: > Felix schrieb: >> Aber wenn ich z.B. ein Windows Programm anschaue >> bekomme ich nicht x exe-files für jeden Prozessortyp > > Windows ist gröstenteils auch nur noch > auf x86 und amd64 benutzbar. NT gab's für x86, Alpha, MIPS, PowerPC und später eine Zeit lang für Itanium (afair Server 2003 bis 2008), aktuell gibt es neben Windows 10 Mobile (und dessen Vorgänger Windows Phone 8/8.1) wieder WinOnARM > Es gibt > zwar noch arm, aber dort die meisten Anwendungen nicht. Die könnte es geben, wenn es 1. MS gewollt hätte 2. wenn die ganzen Anwendungen sauber programmiert wären und 3. wenn die Anwendungen entsprechend überarbeitet oder neu entwickelt worden wären 1). Beim aktuellen Ableger/Wiederaufguss von Windows On ARM gibt's einen dynamischen Übersetzer, der zur Laufzeit x86 in ARM übersetzt und cached. Unter NT gab's für die DEC Alphas FX!32, um x86 ausführen zu können und etwas anders gearbeitet hat https://en.wikipedia.org/wiki/FX!32 1) "Native code for Windows Phone 8" https://msdn.microsoft.com/en-us/library/windows/apps/jj681687(v=vs.105).aspx > Eine exe Datei ist eigentlich eine art Archivdatei. > Der Programmcode ist immer nur für eine Architektur. Ob eine exe mehrere > Programcodes für unterschiedliche Architekturen beinhalten kann, weiss > ich nicht, meistens sind diese aber für eine bestimmte Architektur, man > denke an all die Programme, die eine 64-bit und eine 32-bit Version > anbieten. Hat sich anscheinend nicht durchgesetzt. Sog. Fat Binaries gibt's nur auf dem Mac und Amiga, für ELF gibt's anscheinend die Erweiterung FatELF, die mir aber bislang noch nicht begegnet ist. https://en.wikipedia.org/wiki/Comparison_of_executable_file_formats > Ich frage mich, > ob man in arm Windows amd64 Anwendungen laufen lassen könnte, indem man > im WSL wine für amd64 mit Qemu User Emulation laufen lässt? Qemu läuft auch ohne WSL, emulieren ohne Hardwareunterstützung will man eh nur sehr selten
Felix schrieb: > Nee nee ich meine schon in C. Klar in höheren Programmiersprachen ist > dass dann immer Prozessor unspezifischer. Aber ich hatte mich nur > gefragt weil ja die Variationsmöglichkeiten riesig sind gegen die man > sein Programm kompilieren, optimieren und testen muss. Mit der Zeit > nimmt ja auch die Anzahl der Prozessoren zu. Weshalb Microsoft/DotNet wie auch Google/Android Techniken verwenden, die den abschliessenden Schritt der Übersetzung von Programmen in Binärcode der Zielmaschine auf die Zielmaschine selbst verlagern. In beiden Systemen werden Programme in einem Zwischenformat ausgeliefert und erst auf der Zielmaschine weiter übersetzt. Erlebt man in Windows nach Updates von DotNet im Form längerer CPU-Aktivität eines Prozesses mscorsw.exe.
Felix schrieb: > Aber wenn ich z.B. ein Windows Programm anschaue > bekomme ich nicht x exe-files für jeden Prozessortyp. Was aber zur Folge haben kann, dass das Programm nur einen Grundbefehlsatz von anno dunnemal verwendet, Befehlserweiterungen also nicht nutzt. Oder zur Laufzeit abhängig vom konkreten Prozessor verschiedene Codevarianten verwendet. Letzteres bleibt für den Anwender aber unsichtbar. > Wohingegen ich in > Linux scheinbar spezieller sein muss/kann da die Packages speziel auf > Prozessor und Version abgestimmt Windows gibt es in der Breite für 2 Architekturen, 32-Bit x86 und 64-bit x64 (aka x86-64 oder amd64). Exoten wie IA64 und je nach Laune vom Microsoft auch ARM sind Randerscheinungen. Abgesehen davon definiert Microsoft alleine, was Windows ist. Linux gibts für alle CPUs auf die es drauf passt. Wobei auch nicht jeder ARM gleich ist, weil es innerhalb der ARM Prozessoren verschiedene Byteorder, Floatingpoint-Unit etc gibt. Dann gibts zwar gewisse Library-Konventionen, aber oft benötigt man dennoch verschiedene Binaries oder zumindest Packages für verschiedene Distributionen. Nicht alles was für die Debian-Familie gebaut wird, ist auch in Redhat- oder Suse-Systemen einsetzbar, selbst bei gleicher CPU. Ein Weg, das Problem zu lösen, ist Software-Distribution in Quellcode. Es gibt Tools, die bei der Installation einer Software das System auf seine Eigenheiten abklopft und damit für den Compiler vorbereitet. Der Entwickler kann natürlich nicht alle testen, das tun die Anwender. Einige fluchen dann, wenn das Ding beim "make" Fehler auswirft. Je nach Skill und Problem behebt er es dann selbst, informiert den Entwickler/Maintainer oder schmeisst es in den Müll. Kommerzielle nicht quelloffene Software für Linux ist deshalb mitunter auf nur eine oder wenige Plattformen eingeschränkt. D.h. das gibts dann beispielsweise nur für Redhat.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.