News Windows 10 on ARM: Keine Emulation von x86-64-Bit-Anwendungen

[Herdware]

Ich nehme an, Windows 10 on ARM ist nicht unbedingt als Konkurrenz für Android gedacht. (Da ist Windows Phone/Mobile ja schon gescheitert.) ChromeOS schon eher.

Windows 10 on ARM soll wohl PC-ähnliche Geräte mit ARM statt x86 bedienen. Was das angeht, gibt es bisher auch mit Linux nicht allzu viel am Markt. Von "Bastel"-Geräten (nicht abfällig gemeint) ala Raspberry Pi abgesehen.

Windows 10 on ARM wäre also weniger Konkurrenz zu "Linux on ARM", sondern Konkurrenz zu "x86 under Windows".

Microsoft hat schon immer versucht, alternative CPU-Architekturen im PC-Markt zu unterstützen und sich so ein zweites Standbein neben x86 zu schaffen. (NT gab es neben x86/x64 und jetzt ARM auch für MIPS, Alpha, Power PC und Itanium.) Auch ein Monopolist wie Microsoft ist nicht gerne abhängig vom Monopol anderer (Intel).
"Wintel" war nie eine Liebesbeziehung, sondern eher eine Zweckgemeinschaft, bei der sich beide Seiten immer wieder gerne nach anderen Partnern umgeschaut haben.

 

[Wadenbeisser]

Dazu ist Qualcomm auch noch eine Partnerschaft mit AMD eingegangen und es wird die Geräte mit AMD APU+ Qualcomm Modem geben.
Soll heißen sogar Qualcomm weiß dass sie ohne X86 kerne gegen Intel abstinken und bekommen so wenigstens noch ihre Modems in die Geräte!

Öhm, warum? AMD hatte vor nicht allso langer Zeit auch schon an einem ARM Server Chip gearbeitet.

 

[valnar77]

Ich kann es nur immer wieder widerholen. Dieser Emulationsquatsch ist Mist. Vor allem Wenn entwickler wieder etwas neu kompilieren müssen.
Sie hätten AMD beauftragen sollen, den ARM/x86(-64) Kombichip, welche für Server geplant war, als Custom-SOC für Mobile weiter zu einwickeln. 8ARM Kerne nach dem BIG-little Prinzip und 1-2 etwas beschnittene Zen-kerne bei 1,xGhz incl SMT.
Ja, ich weiß, hätte hätte, Fahrradkette.
Vor allem hätte man dann keine Patentprobleme mehr. Wobei ein Patent doch eh nur für x Jahre gültig ist. Wann gab es den Ur-8086? 1978 und der 80386 1985. Beides schon über 30 Jahre her.

OT: Meiner Meinung nach sollten Patente eh nur einen viel kürzeren Zeitraum gültig sein. Vorschlag: nach 5 Jahren wenn die Entwicklungskosten um einen Faktor X eingespielt worden sind, wenn nicht halt länger. So ein FairUse Prinzip nach einer gewissen Zeit.

 

[Terrier]

ich habe zwar keine Ahnung worüber Ihr hier diskutiert.
Aber wenn es interessiert.
https://www.drwindows.de/news/asus-novago-mit-windows-10-on-arm-fuer-99-euro-mit-lte-vertrag-bei-11
https://www.drwindows.de/news/windows-10-on-arm-64-bit-unterstuetzung-in-arbeit

 

[GrooveXT]

Ich kann es nur immer wieder widerholen. Dieser Emulationsquatsch ist Mist. Vor allem Wenn entwickler wieder etwas neu kompilieren müssen.
Sie hätten AMD beauftragen sollen, den ARM/x86(-64) Kombichip, welche für Server geplant war, als Custom-SOC für Mobile weiter zu einwickeln. 8ARM Kerne nach dem BIG-little Prinzip und 1-2 etwas beschnittene Zen-kerne bei 1,xGhz incl SMT.

Der Weg auf/mit ARM ist der Richtige. Alle beklagen sich hier das MS ja ein Monopol hat, aber das Intel quasi das Gleiche hat wird dabei völlig ignoriert. Ich fände es super wenn zukünftig Anwendungen und Spiele gleichermaßen auf X86 als auch ARM laufen würde. Was für eine Gerätvielfalt da entstehen würde, wenn jeder Hersteller seine Chips entwickeln könnte...hammer. Würde wir auf Kombi-Chips setzen hätten wir keins der Probleme gelöst. Entwickler haben weiterhin keine Not für ARM zu entwickeln und es geben nach wie vor nur zwei Player im CPU Markt oder wenn Intel nicht mitzieht nur einen.

Aber MS macht leider den gleiche Fehler wie bei RT und Windows Mobile. Sie sind zu spät und wollen in einen Markt der schon mit starken Playern ausgestattet ist. Schließlich kämpft man nicht nur gegen Android/ChromeOS sondern auch gegen iOS. Der App-Pool auf diesem Plattformen hat schon über eine Dekade Vorsprung.
Außerdem haben wir hier wieder das Henne-Ei Problem. Ohne passenden Software kauft keiner die Devices, ohne Devices entwickelt keiner die Software. Zudem gibt es genug alternativen mit ausgwachsenem Ökosystem. Die schmale x86 Emulation ist eine kleine, leicht verrottete Karotte die den Absatz ankurbeln soll. Na immerhin haben sie im dritten Anlauf das grundsätzliche Problem verstanden.

Sinnvoller wäre es aber wenn MS hingehen würde und seine Patte nutzt um die Entwickler zu animieren ihre Software auf ARM anzupassen. Sollen sie halt Adobe ein paar Mille hinlegen damit die gesamte Suite ARM kompatibel wird. Einfach mal quer durch den Anwendungsmarkt jedem Anbieter der Relevanz im Windows-Ökosystem hat ein bisschen Asche in die Hand drücken. Dazu noch die Garantie das man nicht in 4 Jahren die Schüppe rausholt und Win10 auf ARM wieder ganz tief verbuddelt. Auch mal ne Durststrecke überwinden. Anders wird das nun mal nichts. Ich habe immer das Gefühl das MS einfach ne Technologie hinstellt sich umdreht, weggeht, nach ein paar Jahren zurückkommt und sich wundert das daraus nichts geworden ist.

Und diesen 64-Bit compiler können sie sich knicken. Kaum eine Anwendung kommt ohne 3rd Party Libs daher und wenn nicht jede einzelne davon vorher übersetzt wurde, hilft auch der Druck auf die Compilertaste nichts. Ganz zu schweigen davon das sicherlich noch eine Million andere Probleme auftreten werden. Wäre das erstemal das bei MS irgendwas einfach so klappen würde. Never ever.

 

[chithanh]

https://www.drwindows.de/news/asus-novago-mit-windows-10-on-arm-fuer-99-euro-mit-lte-vertrag-bei-11

99€? Das kommt ja dem Preis nahe, den das Surface RT zuletzt gekostet hat (ohne Vertrag)

Ich kann es nur immer wieder widerholen. Dieser Emulationsquatsch ist Mist. Vor allem Wenn entwickler wieder etwas neu kompilieren müssen.

"Emulation" und "neu kompilieren müssen" schließt sich gegenseitig aus.
Außerdem nutzt Windows soweit ersichtlich keine Emulation sondern Binary Translation (vergleichbar zu DEC FX!32 was vor zwei Jahrzehnten x86-Code auf Alpha unter Windows NT lauffähig gemacht hat).

Für UWP-Anwendungen wird übrigens nur MSIL in den Store hochgeladen, letzterer kümmert sich dann um die Kompilation für die jeweilige Zielarchitektur.

 

[calluna]

@GrooveXT

Man kann gegen Intel und x86 sagen was man will... diese Kontinuität in der Abwärtskompatibilität ist schon einzigartig und hat Vor- und Nachteile.

Ich fände es super wenn zukünftig Anwendungen und Spiele gleichermaßen auf X86 als auch ARM laufen würde.

Das ist je nach Anwendung - denn nicht für jede Problemstellung ist das sinnvoll - kein Problem, wenn als Grundlage Node.js, Python, NET Core etc. verwendet wird.

Vor allem hätte man dann keine Patentprobleme mehr. Wobei ein Patent doch eh nur für x Jahre gültig ist. Wann gab es den Ur-8086? 1978 und der 80386 1985. Beides schon über 30 Jahre her.

So gut wie niemand kompiliert heute noch ein Programm für x86.

Der Standard ist x86_64 und mindestens SSE2, selbst wenn noch x86 verwendet wird. Und wenn du dich einmal etwas mit Assembler Programmierung befasst, dann wirst du auch sofort die Unterschiede zwischen x86 und x86_64 erkennen. Und auf die zusätzlichen Befehlssätze kann man nicht wirklich verzichten. Also ich komme nicht mehr ohne AVX 1 und 2 aus. Aber natürlich ist das je nach Anwendung unterschiedlich.

 

[Kristatos]

Das wird Apple denen schon vormachen, wie das geht mit der Emulation

 

[noxon]

Somit ist das System jetzt schon eine Todgeburt und dem gleichen Schicksal wie bereits sämtliche Windows Mobile-Versionen zuvor geweiht.

Sinn und Zweck des ARM Systems ist es nicht x86 Anwendungen auszuführen.
Der Emulator und der Compiler sind nette Features, die den Entwicklern dabei helfen können ihre Anwendungen zu portieren, aber mehr soll das auch nicht darstellen.

Microsofts einzige Aufgabe ist es den Entwicklern ein Betriebssystem für ARM Systeme zur Verfügung zu stellen. Die entsprechende native ARM Software müssen dann von den Entwicklern geschrieben werden.
Das Betriebssystem hat nicht die Aufgabe x86 Anwendungen auf ARM Systmen auszuführen. Das führt die ganze Nutzung von ARM Prozessoren ad absurdum.

 

[GrooveXT]

Man kann gegen Intel und x86 sagen was man will... diese Kontinuität in der Abwärtskompatibilität ist schon einzigartig und hat Vor- und Nachteile.

Naja das ist aber nichts Intels Verdienst. Intel hätte liebend gerne die Architektur gewechselt. Siehe die Itaniums. Das Problem dabei ist nur das Gleiche wie bei ARM, man muss die Leute zum Umstieg bewegen. Den X86 hat man nur mitgenommen weil man sich damit ein einzigartiges Monopol geschaffen hat. Hätten man x86 einfach eingestampft, wäre MS schon viel früher zum Architekturwechsel gezwungen gewesen und ob es dann nochmal Intel als Alleinherrscher geworden wäre...ich wage es zu bezweifeln.
Ansonsten wäre x86 schon längst tot.

Das ist je nach Anwendung - denn nicht für jede Problemstellung ist das sinnvoll - kein Problem, wenn als Grundlage Node.js, Python, NET Core etc. verwendet wird.

Naja das sind nette Alternativen für einfach Programme. Aber wenn es um echte Desktopanwendungen und nicht bloß um ein Frontend für Webservices geht kannst du damit leider nicht viel reißen. Und das ist ja das Ziel von Win 10 on ARM. Falls nicht können sie es gleich wieder einstampfen.

 

[xexex]

Das wird Apple denen schon vormachen, wie das geht mit der Emulation

Apple wird da gar nichts vormachen. Sie werden schlichtweg den App Store zur Pflicht erklären und behaupten sie hätten die Computerwelt neu erfunden.

 

[valnar77]

Wenn es nur eine Übersetzung ist (ähnlich wie Vulkan>Metall auf MacOS) kann man damit ja noch leben. Entschuldigt wenn ich einige Sachen nur laienhaft wiedergegeben hab, bin halt kein Entwickler ;-)

@GrooveXT
Dir ist schon klar dass AMD auch x86 Lizensiert hat, und x86-64 sogar entwickelt hat. Die Lizenz von VIA wurde ja ungültig nach der NV-Übernahme AFAIK.
Natürlich besitzt Intel derzeit den größten Marktanteil im Notebook und Desktop-Segment.
Selbst wann MS/Quallcomm "nur" von ARM nach x86 übersetzten vereinfach ausgedrückt, kann mich mir kaum vorstellen dass die Leistung an die eines Kombiprozessors heran kommt.

Mein Gedanke zum Kombiprozessor war eher folgender:
Ich stelle mir das so vor, dass der Kernel mit allem drum und dran auf ARM laufen, und sobald eine x86 Anwendung gestartet wird, werden die x86 Kerne aus dem DeepSleep geholt.
So als Laienhaft ausgedrückt.

 

[calluna]

@valnar77

Für welches Problem soll das die Lösung sein?

Wenn eine Software nicht von bestimmten Bibliotheken abhängig ist, die an ein bestimmtes Betriebssystem gebunden sind, welches nur für einen bestimmten CPU-Befehlssatz erhältlich ist... dann sollte es auch möglich sein die Software für verschiedene Systeme anbieten zu können.

Vielleicht bin ich gerade zu beschränkt, um mir abseits von Nischen einen sinnvollen Einsatz so einer Misch-CPU vorstellen zu können.

PS: x86... x86-64... das sind eher Interfaces als tatsächliche CPU-Architekturen.

@GrooveXT

Das stimmt, es ist nicht Intels verdienst. Ich hätte schreiben sollen... man kann gegen x86 sagen was man will... die Abwärtskompatibilität hat Vor- und Nachteile. Ich finde es jedenfalls interessant, dass sich die eigentliche Architektur von x86 CPUs gravierend ändern kann, um neuen Anforderungen gerecht zu werden, wie etwa mit TLX und AVX512... aber dennoch die Software der letzten 30 Jahre lauffähig ist.

 

[valnar77]

Dass man performant sämtliche x86 Anwendungen (samt etwaiger Erweiterungen) auf einem ARM-basiertem System ausführen kann. Damit hätte man die Vorteile aus beiden "Welten" vereint. So ein SoC in ein Surface-Phone und man hätte einen echten Desktop-Ersatz. Aber vielleicht bin ich auch auf dem Holzweg und deren x86 on ARM Lösung funktioniert einwandfrei. Werde ich ja sehen, wenn ich mal so ein Gerät zur Verfügung habe und versuche ein älteres x-beliebiges Programm dort auszuführen, was nicht speziell angepasst ist. Halt eine klassische Win32 bzw. bald dann auch AMD64 Anwendung. Wenn das nicht geht, dann habt ihr den Vorteil meiner Idee.

 

[joshy337]

Die Ironie ist, wie ich bereits schon sagte, dass (ältere) Programme mit reinem i386 Code
besser auf 'nem 386DX-40 mit ET4000-Graphik unter Windows 95, Windows 98 oder gar Windows 3.1 mit Win32s laufen, anstatt auf der NT-Schiene (zu der auch Windows 10 noch gehört).

Auch alte Spiele-Klassiker sind davon betroffen, da Windows 10 nicht mehr vollends kompatibel
mit Komponenten wie WinG, Direct3D 7 (als Fallback mit HW-Beschleunigung für D3D3, D3D5, D3D6, D3D7-Titel),
DirectMusic oder DirectDraw im Allgemeinen ist. Da nützt auch die angepriesene DirectX 9-Unterstützung nichts. Wer sich erinnert: DXDiag aus Win XP unterstützte/testete folgende APIs auf Beschleunigung: DirectX 7, 8, 9.

Die Emulation von Win32-x86 ist wirklich nettgemeint, nur predigt MS eben seit Jahren das Programmieren von 64-Bit bzw. x64.
Abgesehen von 7zip und anderen, "sauber" programmierten Anwendungen (kleine Freeware Tools, Open Source-Projekte), laufen aktuelle Programme nicht mehr so ohne weiteres ohne SIMDs.

PS: Den Begriff Übergangslösung sollte man nur verwenden, wenn es ein konkretes Datum zu dessen Ende gibt.
Andernfalls wird aus dieser Übergangslösung eine Dauerlösung.

 

[Sinnfrei]

Und warum sollte irgendjemand dieses System einsetzen wollen? Offensichtlich bietet es keinen echten Mehrwert gegenüber einem Android.

 

[Hayda Ministral]

Damit es ein Erfolg wird, muss MS sich nur auf seine alten Stärken besinnen: Jede Software auf jeder Hardware,

Ich stimme Dir zu. MS aber offenbar nicht, denn es wird eben nicht jede Software sondern nur eine Teilmenge auf WOA laufen.

Zur Frage wie wichtig die Teilmenge ist die nicht läuft fällt mir der uralte Witz ein der da lautet "Wieviele Mikrosoft-Ingeneure braucht man um eine kaputte Glühbirne zu wechseln?"
Antwort: "Keinen einzigen. Mikrosoft erklärt einfach die Dunkelheit zum Industriestandard."

MS hat eine kaputte Glühbirne, ein Windows das nur einen Teil der Windows-Anwendungen ausführen kann. Statt den Fehler zu fixen erklärt MS einfach dass die nicht laufenden Anwendungen ja gar nicht benötigt werden. Ich hoffe, dass die Hardware-Hersteller schlauer sind als bei den vorigen Debakeln und diesesmal den Kunden wenigstens Linux-Unterstützung mit an die Hand geben. Ein Laptop mit potenter ARM-CPU und mit Linux-Treibern würde mir schon gefallen.

 

[joshy337]

Damit es ein Erfolg wird, muss MS sich nur auf seine alten Stärken besinnen: Jede Software auf jeder Hardware,

Ich stimme Dir zu. MS aber offenbar nicht, denn es wird eben nicht jede Software sondern nur eine Teilmenge auf WOA laufen.

Zur Frage wie wichtig die Teilmenge ist die nicht läuft fällt mir der uralte Witz ein der da lautet "Wieviele Mikrosoft-Ingeneure braucht man um eine kaputte Glühbirne zu wechseln?"
Antwort: "Keinen einzigen. Mikrosoft erklärt einfach die Dunkelheit zum Industriestandard."

MS hat eine kaputte Glühbirne, ein Windows das nur einen Teil der Windows-Anwendungen ausführen kann. Statt den Fehler zu fixen erklärt MS einfach dass die nicht laufenden Anwendungen ja gar nicht benötigt werden. Ich hoffe, dass die Hardware-Hersteller schlauer sind als bei den vorigen Debakeln und diesesmal den Kunden wenigstens Linux-Unterstützung mit an die Hand geben. Ein Laptop mit potenter ARM-CPU und mit Linux-Treibern würde mir schon gefallen.

Da stimme ich euch beiden zu. Generationen von Menschen sind mit Windows aufgewachsen,
und erwarten, dass die Programme aus der Kindheit/Jugend/Ausbildungszeit laufen.
(Ja, mir läuft bei dem Gedanken auch ein eiskalter Schauer über den Rücken.)

Der Wegfall des 16-Bit Teilsystems unter Windows x64 war schon ein schwerer Brocken.
Noch heute fragen Anwender im Web, warum manche Programme unter dem normalen Windows (x64)
denn nicht laufen.

Meist kommen dann so saublöde Antworten wie z.B. "das geht nicht, weil Windows XY kein DOS mehr hat.",
"da fehlt Command.com. Ziehs dir und kopiers nach C:" Oder "nimm DOSBox, dann läufts".
Letzteres is zumindest zum Teil richtig, da Windows 3.1 darin laufen kann.

So, und nun erklären wir solchen verzweifelten Menschen zusätzlich, dass diese modernen 64-Bit Programme
ihres 64-Bit Windows auf dem hypermodernen Windows 10 on ARM Gerät nun plötzlich nichtmehr laufen,
man aber die altbekannten -aber nicht zu alten- 32-Bit Programme nutzen kann.
Vorausgesetzt, dass diese semi-alten Anwendungen nur den ur-uralten i386 Befehlsatz brauchen.

Wird schwierig. Nicht weil diese Menschen einfache Gemüter haben (-Ausnahmen bestätigen die Regeln.- ),
sondern weils aus Anwendersicht einfach keinen Sinn ergiebt.

Windows Store hin- oder her, normale 0815 Programme auf CD/DVD-ROM aus Magazinen oder Büchern
die man im Kaufhaus oder der Bibliothek bekommt, oder ab und an unterm Weihnachtsbaum liegen,
sind derzeit nun mal keine Metro-Apps, sondern Win32- (Win64 stark zunehmend), bestenfalls .NET-Anwendungen.

Für viele könnte der Umstieg auf Linux/BSD weniger verwirrend sein,
als die zig inkompatiblen Versionen von Windows im Kopf zu behalten.


Manchmal frage ich mich: Hätte MS vor 10 Jahren die x86-Versionen von Windows konsequent aufgegeben,
WoW16 behalten und zusätzlich Bytecode für Win32/64-Anwendungen als Alternative zu x86/x64-Code eingeführt
(Visual Studio 95 mit P-Code lässt grüßen), wie würde die Windows-Welt nun wohl aussehen ?

Edit: Oder anders - Warum erlaubt MS keine FAT-Binaries (bzw. Universal-Binaries), wie es Apple damals tat ? Würde Visual Studio ab dato bei Win64-Anwendungen standardmäßig einfach PE Binaries mit x64+ARM Code generieren, hätte ARM 'ne echte Chance auf dem Desktop (das x64-Patenttheater wäre vom Tisch) und Anwender könnten sich entspannen. Metro und .NET könnten ja
weiterhin nebenbei coexistieren.

 

[xexex]

Edit: Oder anders - Warum erlaubt MS keine FAT-Binaries (bzw. Universal-Binaries), wie es Apple damals tat ? Würde Visual Studio ab dato bei Win64-Anwendungen standardmäßig einfach PE Binaries mit x64+ARM Code generieren, hätte ARM 'ne echte Chance auf dem Desktop (das x64-Patenttheater wäre vom Tisch) und Anwender könnten sich entspannen. Metro und .NET könnten ja weiterhin nebenbei coexistieren.

Genau das ist mit den Store Apps gegeben und eine App funktioniert, wenn sie entsprechend kompiliert wurde, sowohl auf x86, x64 als auch ARM Geräten.

Apple hat "damals" die Binaries auch nur eine Zeitlang unterstützt und hat den Support später fallen lassen, bei Microsoft wird aber nun das Fass aufgemacht.

Vermutlich wird aus diesem Grund, Apple ihren Store schneller im macOS fest verankern, als es bei Microsoft der Fall sein wird, obwohl Microsoft diesen Weg nun seit mehreren Jahren anvisiert. Bei Apple bejubelt man dann in 5 Jahren die einfache Softwareinstallation als "Innovation" im Desktopsegment und bei Microsoft wird behauptet man bräuchte weiterhin Unterstützung für 20 Jahre alte Software. Dabei läuft heutzutage nicht ein 10 Jahre altes Programm aus der vor Intel Ära auf einem aktuellen macOS und niemanden stört es.

Im Jahr 2020 ist Apple dann von Intel weg und unterstützt vermutlich nur noch Store Apps und in Microsoft Lager krallen sich noch immer Leute an ihrem steinalten Windows 7 fest. So verschieden können nun mal die Welten sein.

EDIT:
@joshy337 Lustig wie du Apple als ein positives Beispiel für Kompatibilität aufführst obwohl sie mit der Umstellung von System 7 auf X und Motorola auf Intel bereits in vergleichbar kurzer Zeit zwei mal jegliche Kompatibilität zu alter Software abgeschnitten haben und bald einen neuen harten Schnitt planen.

Im Vergleich dazu ist die Langzeitkompatibilität unter Windows ein Traum und so weit fernab jeder Konkurrenz. Auch unter Linux würdest du heute ein 10 Jahre altes Programm kaum noch zum laufen bekommen und der Mobilmarkt und Stores gab es zu diesem Zeitpunkt nicht einmal.

 

[joshy337]

EDIT:@joshy337 Lustig wie du Apple als ein positives Beispiel für Kompatibilität aufführst obwohl sie mit der Umstellung von System 7 auf X und Motorola auf Intel bereits in vergleichbar kurzer Zeit zwei mal jegliche Kompatibilität zu alter Software abgeschnitten haben und bald einen neuen harten Schnitt planen.

Ich verstehe nicht, was daran so lustig ist bzw. warum das Beispiel besser negativ sein sollte.
Das MacOS der PowerPC-Plattform enthielt einen eigenen m68k-Emulator und konnte Anwendungen ausführen,
die bis in die frühen 80er zurückgingen. Wenn man Classic als Teil von Tiger 10.4.x mit einbezieht,
war die Untersützung von Motorola-Anwendungen über 20 Jahre lang gegeben (1984-2007).
Bei PowerPC-Anwendung (für OS X) wurden von ~2001 bis Mitte 2011 unterstützt (bis zum Ende von 10.6.x Snow Leopard).
FAT-/Universal-Binaries in beiden Fällen nicht mitgerechnet.

Im Vergleich dazu ist die Langzeitkompatibilität unter Windows ein Traum und so weit fernab jeder Konkurrenz.

Muss sie auch sein, ansonsten ist Windows wertlos.

Auch unter Linux würdest du heute ein 10 Jahre altes Programm kaum noch zum laufen bekommen und der Mobilmarkt und Stores gab es zu diesem Zeitpunkt nicht einmal.

Stimmt. Selbst wenn es laufen würde (ABI-Kompatibeliität vorhanden), würden die benötigten Bibliotheken fehlen.
*nix hat da seine ganz eigene DLL-Hell. Diese Programme erwarten immer eine ganz bestimmte Version einer Bibilothek. Wenn die der Distri fehlt, dann Gute Nacht. Dann wird das Neukompilieren einfacher,
als die alte Lib auf das System zu bekommen. Zum Store: Ist im Prinzip auch nur ein Paketmanager mit optionalem DRM und Bezahlfunktion.