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/Cygwinhttps://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
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/QemuUserEmulationhttp://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.
