Mit Emulatoren hat das auch nichts mehr zu tun. Der Programmcode wird nicht mehr Emuliert.
Deswegen habe ich auch noch Komma Wrapper Komma etc. dazu geschrieben. Ich weiß das das kein Emulator ist, ich weiß auch das WINE ausgeschrieben sogar "Wine is not an emulator" heisst.
Er wird vor dem Programmstart in den nativen Code der neuen CPU codiert, komplett. Erst dann wird das neue erstellte Programm laufen gelassen. Das klappt so gut, das es keine Nachteile in der Geschwindigkeit gibt.
Dann braucht die Zielplatform eigentlich keinen Kompatibilitätslayer mehr, denn dann könnte man das ja einmalig für die jeweilige Zielplatform codieren lassen und der Zielplatform dann gleich das gerade passend konvertierte Binary zur Verfügung stellen.
Man kann sich das wie Java Code vorstellen. Dieser wird auch einmal für eine virtuelle CPU compiliert und läuft dann auf jeder CPU, egal welche Architektur.
Bei Java war das aber von Anfang so vorgesehen, das der Binärcode eben platformunabhängig sein soll, die Zielplatform dafür dann aber eben eine Laufzeitumgebung braucht um dieses Binary überhaupt ausführen zu können.
Quasi das Mittelding zwischen Interpreter und Kompiler. Aber von Anfang an im Konzept so vorgesehen.
Ich denke die Zukunft wird die Windows-API sein und diese dann auf jedem System zu "emulieren".
Ich hoffe nicht.
Platformunabhängigkeit gerne, aber nicht auf einer zugemüllten, veralteten Legacy-API aufbauend.
Das schöne daran ist, der Softwareentwickler muss seine Software nicht mehr für 3 Plattformen entwickeln und testen, sondern nur noch für eine. Die Software läuft dann auf den anderen Plattformen dank der "Emulation". Firmen wie Steam kümmern sich um die perfekte "emulation" und Updaten die "Emulatoren". Ein Win/Win für alle.
Was genau hast du an "Ich bin selbst Softwareentwickler und habe schon Multiplatformentwicklung machen dürfen" nicht verstanden?
Man muss/sollte übrigens trotzdem noch auf den Zielplatformen testen. Wie ich oben schon geschrieben habe, hat Id-Software sogar gesagt, das sie das explizit tun. Es gibt auch immernoch Spiele (und andere Software), die unter Linux mit Proton nicht so sauber läuft wie unter Windows. Von irgendwelchen nebensächlichen Glitches, bis hin zu Abstürzen.
Es ist nicht nur so, das eine andere CPU-Architektur anderen Binärcode braucht, alleine schon die komplette Systemumgebung kann abweichen. Unter Linux gibts z.B. keine Laufwerksbuchstaben. Somit funktioniert schon sowas simples wie einfach nur eine Datei öffnen wie es Windows tut unter Linux eben nicht. Da sorgt erst Wine dafür. Und das nervt mich sogar mit Steam ein wenig, weil deswegen es für jedes Spiel eine separate virtuelle Umgebung anlegt. Und dann kannste immer ewig Ordner durchsuchen, bis du den findest, der auch zu dem Spiel gehört, wo man gerade was ändern will.
Das ich den Win/Win nachvollziehen kann, habe ich eben ja geschrieben, nur das da eigentlich noch /Loss hinten angehängt gehört. Es machts dem Softwareentwickler leichter, es machts dem Anwender leichter, es verbessert die Verfügbarkeit von Software, aber man bindet sich eben auch einen riesigen Legacy-Klotz ans Bein und durch diverse Softwarelayer wird das Gesamtsystem auch wieder komplexer.
Das ganze ist ein Henne-Ei-Problem... wenn es das nicht wäre, hätte man mit Java schon seit wieviel... 30? Jahren die entsprechende Lösung an der Hand gehabt. Und damit meine ich nicht die Sprache ansich, sondern die Funktionsweise der kompletten Umgebung.
