Forum: PC Hard- und Software Windows mit Linux-Kernel? Realistisch?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von zulu (Gast)


Bewertung
1 lesenswert
nicht lesenswert

von Anarchist (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Der Unterbau spielt doch heute überhaupt keine Rolle mehr.
Mit einer Weiterentwicklung dessen kann man keinen Blumentopf mehr 
gewinnen.
Was zählt ist einzig und allein die Oberfläche.

Also bei der Hardware das Gehäusedesign - Apple hat das schon früh 
herausgefunden.
Bei der Software hippe Oberflächen mit wischen usw.

Von daher - wenn man beim Unterbau auf kostenlos verfügbare Systeme 
zurückgreift und seine Ressourcen für die Oberflächenentwicklung 
verwendet ist das nur folgerichtig.

von OliTV (Gast)


Bewertung
0 lesenswert
nicht lesenswert
zulu schrieb:
> Windows mit Linux-Kernel? Realistisch oder Phantasterei?

Das finde ich gar nicht so weit her geholt.
Ein Grund könnte sein, Windows auch auf anderen Plattformen laufen zu 
lassen.
So z.B. auf ARM Prozessoren, genau hier tut sich Windows schwer, auch 
wenn es auf dem Windows Phone schon recht Gut funktioniert hat.

von Nick M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
zulu schrieb:
> Realistisch oder Phantasterei?

Jedenfalls irre innovativ.
Apple macht das erst seit 2000 mit Darwin (auch ein UNIX).

von ACDC (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
zulu schrieb:
> Windows mit Linux-Kernel? Realistisch oder Phantasterei?

Was ist ein Kernel?

Also:
Wenn Windwos genau so funktioniert wie immer....

Dann ist mir der Kern egal...

von zulu (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Anarchist schrieb:
> Was zählt ist einzig und allein die Oberfläche.

Diesbezüglich ist die Windows-Usability ziemlich schlecht. Viele 
Grundfunktionen fehlen oder lassen sich nur sehr umständlich einstellen. 
Man nenne da nur mouse-over-aktivität bei sich überlappenden Fenstern. 
Bei Linux kann man immerhin die GUI einfach austauschen.

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
zulu schrieb:
> Windows mit Linux-Kernel? Realistisch oder Phantasterei?

Technisch denkbar, mit WINE & Co. laufen Windows-Binaries ja schon 
länger unter Linux, und zwar nicht als Emulation, sondern als (relativ) 
kompatible API-Nachbildung.

Aber die Firmenpolitik wird wohl erstmal weiter Windows 10 verfolgen, 
denn nicht nur "Cloud"-Kram ist in Mode, sondern auch das Einsammeln von 
Daten.

Nick M. schrieb:
> Jedenfalls irre innovativ.
> Apple macht das erst seit 2000 mit Darwin (auch ein UNIX).

Was macht Apple seit 2000 Innovatives?

Windows auf einem Unix-Kernel? Nö.
GUI auf einem Unix-Kernel? Ja, war aber da schon ein alter Hut.
MacOS-9-Anwendungen auf einem Unix-Kernel? Naja, als Emulation und von 
vornherein nicht für die Ewigkeit gedacht.

Aber mir wollte auch schon ein Apple-Lemming erzählen, dass Apple der 
erste Anbieter von 64-Bit-Workstations gewesen wäre.

von c-hater (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
OliTV schrieb:

> Ein Grund könnte sein, Windows auch auf anderen Plattformen laufen zu
> lassen.
> So z.B. auf ARM Prozessoren, genau hier tut sich Windows schwer, auch
> wenn es auf dem Windows Phone schon recht Gut funktioniert hat.

Unsinn.

Windows (insbesondere der Kernel, aber auch das allermeiste von dem, was 
Windows ansonsten ausmacht) läuft auf ARM völlig problemlos. Wenn es 
(auch) für ARM kompiliert wurde, was im Fall von Windows Phone passiert 
ist.

Was nicht läuft, sind halt Windows-Anwendungen, die nicht auf ARM 
portiert sind und die nicht über den Store vertrieben wurden.

Deswegen ist Windows Phone baden gegangen. Die User wollten genau diese 
Anwendungen und nicht den Scheiß, der den Weg in den Store gefunden 
hat...

von PhilCol (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Deswegen ist Windows Phone baden gegangen. Die User wollten genau diese
> Anwendungen und nicht den Scheiß, der den Weg in den Store gefunden
> hat...

Ach ja!
Und Android oder iOS sind nicht auf den jeweiligen Store angewiesen?

Eine i386, AMD64 Anwendung kann nicht einfach neu kompiliert werden und 
Gut ist es.

von UnLinx (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
zulu schrieb:
> Anarchist schrieb:
>> Was zählt ist einzig und allein die Oberfläche.
>
> Diesbezüglich ist die Windows-Usability ziemlich schlecht. Viele
> Grundfunktionen fehlen oder lassen sich nur sehr umständlich einstellen.
> Man nenne da nur mouse-over-aktivität bei sich überlappenden Fenstern.
> Bei Linux kann man immerhin die GUI einfach austauschen.

Linux hat kein GUI. Linux, richtig GNU/Linux ist der Kernel. 11!!ölf 
UJnd der regelt sowas

von UnLinx (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
PhilCol schrieb:
> c-hater schrieb:
>> Deswegen ist Windows Phone baden gegangen. Die User wollten genau diese
>> Anwendungen und nicht den Scheiß, der den Weg in den Store gefunden
>> hat...
>
> Ach ja!
> Und Android oder iOS sind nicht auf den jeweiligen Store angewiesen?
>
> Eine i386, AMD64 Anwendung kann nicht einfach neu kompiliert werden und
> Gut ist es.

Android ist auf keinen Store angewieses. iOS auch nicht nach Jailbreak.

Nur weil Du etwas für eine Architekturs/OS kompilieren kannst, läuft es 
nicht unbedingt auch darauf. Weil Du es nihct installieren kannst, siehe 
apple

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Anarchist schrieb:
> Der Unterbau spielt doch heute überhaupt keine Rolle mehr.

Mein Profiler ist anderer Meinung.

von wie soll das gehen? (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Warum eigentlich Linux? Warum nicht xyz-BSD?

Die BSD-Lizenz wäre doch besser für sie.  wie soll das sonst mit der 
GPL-Lizenz funktionieren? Werden sie  ihren Quelcode zu allen 
Anwendungen veröffentlichen? (rethorische Frage)

Mac benutzt ja auch BSD.

von 🐧 DPA 🐧 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
wie soll das gehen? schrieb:
> wie soll das sonst mit der
> GPL-Lizenz funktionieren? Werden sie  ihren Quelcode zu allen
> Anwendungen veröffentlichen? (rethorische Frage)

Userspace Anwendungen sind vom Copyleft der GPL des Linux kernel codes 
ausgenommen.

von Xy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wie soll das gehen? schrieb:
> Warum eigentlich Linux? Warum nicht xyz-BSD?
>
> Die BSD-Lizenz wäre doch besser für sie.  wie soll das sonst mit der
> GPL-Lizenz funktionieren? Werden sie  ihren Quelcode zu allen
> Anwendungen veröffentlichen? (rethorische Frage)

Wie macht das google? Android basiert ja auch auf Linux.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Xy schrieb:
> Android basiert ja auch auf Linux.

https://source.android.com/

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
OliTV schrieb:
> zulu schrieb:
>> Windows mit Linux-Kernel? Realistisch oder Phantasterei?
>
> Das finde ich gar nicht so weit her geholt.
> Ein Grund könnte sein, Windows auch auf anderen Plattformen laufen zu
> lassen.
> So z.B. auf ARM Prozessoren, genau hier tut sich Windows schwer, auch
> wenn es auf dem Windows Phone schon recht Gut funktioniert hat.

Der Windows NT Kernel tut sich hier gar nicht schwer, da der schon immer 
auf andere Plattformen portierbar war.

Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft.
Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM 
Prozessoren. Deswegen gibt's auch in Zukunft keinen Grund, Windows auf 
ARM laufen zu lassen, MS tut das ja jetzt schon mit Windows RT und Co, 
aber mangels Software führt das zu nichts.

Die Windowssoftwarewelt verlangt nach x86 CPUs und x86 Emulationen auf 
fremden Architekturen sind langsam.

von Johannes M. (johannesm)


Bewertung
0 lesenswert
nicht lesenswert

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Wenn das NTFS schneller würde, dann würde mir das schon reichen. Selbst 
das WSL kompiliert um Faktoren schneller, das ist schon signifikant. Auf 
welchem Prozessor ist eigentlich egal.

von Maxe (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Nano schrieb:
> Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft.
> Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM
> Prozessoren.
Das OS koennte ja einen Recompiler/Reassembler bereitstellen, der die 
386er Binaries auf die entsprechende Plattform uebersetzt. Apple macht 
das wohl bei ihren neuen PCs mit "eigener" Architektur.

Fuer ARM-Linux (oder RISC-V-Linux) waere das eigentlich auch 
interessant.

von Maxe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sorry, das Thema war ja von Johannes im Link angesprochen.

von Matthias F. (atarist)


Bewertung
0 lesenswert
nicht lesenswert
Gab es nicht bereits so um 2001 den Versuch, ein LINDOWS auf Basis von 
WINE zu entwickeln? Hat sich m.W. im Sande verlaufen.

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Maxe schrieb:
> Fuer ARM-Linux (oder RISC-V-Linux) waere das eigentlich auch
> interessant.

Gibt es längst, qemu-user, läuft recht gut, aber nicht besonders 
schnell.

Unter debian, einfach:
1
apt-get install qemu-user-static

Damit kann man dann von einem arm64, riscv64, powerpc, amd64, etc. 
rechner aus arm64, riscv64, powerpc, amd64, etc. Anwendungen ausführen. 
Alles ausser statische binaries sind damit aber etwas umständlich. 
Richtig nützlich wird's aber erst zusammen mit dem restlichen Userspace. 
z.B.
1
debootstrap --arch=arm64 buster buster_amd64
2
chroot buster_amd64
Und schon ist man in einer amd64 Umgebung. Funktioniert eigentlich alles 
einwandfrei.

Wenn debian ihr Multiarch auf binaries ausweiten würde, und nicht nur 
für libraries, bräuchte man das chroot nicht mehr. Obwohl, eigentlich 
müsste das in den meisten fällen reichen, habs aber noch nicht 
ausprobiert.

Ein aktuelles qemu-user+wine geht damit im moment leider gerade nicht 
mehr so rund wie auch schon, aber das wird schon wieder.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Wenn das NTFS schneller würde, dann würde mir das schon reichen.

NTFS war immer schon schlimm. So schlimm, daß mittlerweile sogar 
Microsoft das anerkennt^Hen muß. WSL kann mittlerweile auch richtige 
Filesysteme. Fefe sieht das als Anhaltspunkt, daß Windows demnächst nur 
noch ein Emulations-Layer über dem Linux Kernel sein wird:

https://blog.fefe.de/?ts=a19f3925

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Johannes M. schrieb:
> Dann können wir gespannt sein, was hier bei rauskommt

Neu daran ist die Emulation von 64-Bit x86 Code. Die für 32-Bit x86 Code 
gibt es längst und wird z.B. beim Microsoft Surface Pro X eingesetzt.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Nick M. schrieb:
> zulu schrieb:
>> Windows mit Linux-Kernel? Realistisch oder Phantasterei?
>
> Jedenfalls irre innovativ.
> Apple macht das erst seit 2000 mit Darwin (auch ein UNIX).

Apple nutzt den Linux-Kernel?

Hmmm schrieb:
> Aber die Firmenpolitik wird wohl erstmal weiter Windows 10 verfolgen,
> denn nicht nur "Cloud"-Kram ist in Mode, sondern auch das Einsammeln von
> Daten.

Das hat ja nichts mit dem Kernel zu tun. Nutzerdaten sammeln könnten sie 
auf einem Linux-Kernel genauso gut wie auf einem Windows-Kernel.

UnLinx schrieb:
> Linux hat kein GUI. Linux, richtig GNU/Linux ist der Kernel.

Nein, "GNU/Linux" ist nicht der Kernel. Der Kernel heißt nur Linux®. 
"GNU/Linux" ist die Bezeichnung, die Richard Stallman gerne für das 
komplette Betriebssystem hätte, weil typische Linux-basierte 
Betriebssysteme viele Komponenten enthalten, die von seinem GNU-System 
kommen. Denn ursprünglich wollte er ein Betriebssystem namens GNU 
rausbringen. Der Kernel hat noch gefehlt, und gerade da kam Linus 
Torvalds mit seinem Linux-Kernel um die Ecke, und der wurde verwendet. 
Sehr zum Ärger von Stallman wurde das Betriebssystem dann 
umgangssprachlich nicht als GNU, sondern als Linux bekannt. Stallman 
möchte da einfach sein "GNU" im Namen haben. Allerdings gibt es im 
System noch sehr viele Komponenten, die weder Teil des GNU-Projekts, 
noch von Linux sind, die man dann auch allen nennen müsste, um 
konsequent zu sein. Und dann wäre der Name für das Betriebssystem sehr 
sehr sehr lang.

🐧 DPA 🐧 schrieb:
> wie soll das gehen? schrieb:
>> wie soll das sonst mit der
>> GPL-Lizenz funktionieren? Werden sie  ihren Quelcode zu allen
>> Anwendungen veröffentlichen? (rethorische Frage)
>
> Userspace Anwendungen sind vom Copyleft der GPL des Linux kernel codes
> ausgenommen.

Interessanter könnte es bei Treibern werden. Die dürfen zwar auch als 
closed-Source geschrieben werden, aber es gibt gewisse Einschränkungen.

Nano schrieb:
>> So z.B. auf ARM Prozessoren, genau hier tut sich Windows schwer, auch
>> wenn es auf dem Windows Phone schon recht Gut funktioniert hat.
>
> Der Windows NT Kernel tut sich hier gar nicht schwer, da der schon immer
> auf andere Plattformen portierbar war.

Ja. Viele wissen wohl nicht mehr, dass Windows NT auch z.B. mal auf DEC 
Alpha (welches schon Anfang der 90er eine reine 64-Bit-Architektur war), 
MIPS und PowerPC lief.

> Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft.
> Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM
> Prozessoren. Deswegen gibt's auch in Zukunft keinen Grund, Windows auf
> ARM laufen zu lassen, MS tut das ja jetzt schon mit Windows RT und Co,
> aber mangels Software führt das zu nichts.

Nur warum tut Microsoft nichts dagegen? Sie könnten doch wie Apple 
früher ihren Compiler/Linker so auslegen, dass er im Executable einfach 
den Code für beide Architekturen ablegt und je nach System den passenden 
Code lädt. Bei Apple heißt das "universal binary".
https://de.wikipedia.org/wiki/Universal_Binary

Johannes S. schrieb:
> Wenn das NTFS schneller würde, dann würde mir das schon reichen. Selbst
> das WSL kompiliert um Faktoren schneller, das ist schon signifikant. Auf
> welchem Prozessor ist eigentlich egal.

Liegt das tatsächlich an NTFS? Ich könnte mir auch vorstellen, dass es 
am fehlenden fork() und generell an der extrem langsamen Art liegt, wie 
Windows Prozesse startet.

Axel S. schrieb:
> NTFS war immer schon schlimm. So schlimm, daß mittlerweile sogar
> Microsoft das anerkennt^Hen muß. WSL kann mittlerweile auch richtige
> Filesysteme.

Wie sieht es mit Netzwerk aus? Da ist Windows auch nicht gerade flott 
unterwegs. Funktioniert das mit WSL auch besser?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Liegt das tatsächlich an NTFS? Ich könnte mir auch vorstellen, dass es
> am fehlenden fork() und generell an der extrem langsamen Art liegt, wie
> Windows Prozesse startet.

hier ist z.B. ein Benchmark:
https://vxlabs.com/2019/12/06/wsl2-io-measurements/

Beim  gcc fällt es eben auch extrem auf. Ich denke nicht das da viele 
Prozesse gestartet werden (wenn nicht gerade zigfach parallel kompiliert 
wird) und wirklich die File I/O reinhauen.

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> 🐧 DPA 🐧 schrieb:
>> wie soll das gehen? schrieb:
>>> wie soll das sonst mit der
>>> GPL-Lizenz funktionieren? Werden sie  ihren Quelcode zu allen
>>> Anwendungen veröffentlichen? (rethorische Frage)
>>
>> Userspace Anwendungen sind vom Copyleft der GPL des Linux kernel codes
>> ausgenommen.
>
> Interessanter könnte es bei Treibern werden. Die dürfen zwar auch als
> closed-Source geschrieben werden, aber es gibt gewisse Einschränkungen.

Ja, die GPL exports bei kernel Modulen sind sehr fragwürdig / 
umstritten. Nicht wenige sind der Meinung, dass die Nutzung von kernel 
Symbolen in nicht GPL kernel Modulen generell nicht zulässig sei. Ich 
persönlich glaube auch, dass Thorvalds Idee mit den GPL exports, um auch 
nicht GPL Module die nicht GPL exports brauchen zu ermöglichen, um dinge 
wie Nvidias proprietäre Treiber und Oracles inkompatibel lizenziertes 
ZFS offtree zu ermöglichen, gigantischer (il)legaler Bullshit ist.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Ich
> persönlich glaube auch, dass Thorvalds Idee mit den GPL exports, um auch
> nicht GPL Module die nicht GPL exports brauchen zu ermöglichen, um dinge
> wie Nvidias proprietäre Treiber und Oracles inkompatibel lizenziertes
> ZFS offtree zu ermöglichen, gigantischer (il)legaler Bullshit ist.

Hmm, ich dachte, der Kernel-Teil der Nvidia-Treiber sei der Einfachheit 
halber auch GPL (die ganze Magie findet ja eh im X-Treiber, also im 
Userspace statt). Aber anscheinend stehen die Module, die zu dem 
Kernel-Treiber gehören, sogar unter verschiedenen Lizenzen:
1
kwayk@tardis:/usr/src/nvidia-440.100$ grep LICENSE -r *
2
nvidia/nv-frontend.c:#if defined(MODULE_LICENSE)
3
nvidia/nv-frontend.c:MODULE_LICENSE("NVIDIA");
4
nvidia-drm/nvidia-drm-linux.c:#if defined(MODULE_LICENSE)
5
nvidia-drm/nvidia-drm-linux.c:  MODULE_LICENSE("MIT");
6
nvidia-modeset/nvidia-modeset-linux.c:#if defined(MODULE_LICENSE)
7
nvidia-modeset/nvidia-modeset-linux.c:  MODULE_LICENSE("NVIDIA");
8
nvidia-uvm/uvm8.c:MODULE_LICENSE("Dual MIT/GPL");

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Maxe schrieb:
> Nano schrieb:
>> Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft.
>> Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM
>> Prozessoren.
> Das OS koennte ja einen Recompiler/Reassembler bereitstellen, der die
> 386er Binaries auf die entsprechende Plattform uebersetzt.

Selbst wenn das technisch halbwegs sauber funktionieren würde, wäre es 
rechtlich nicht erlaubt. Das Urheberrecht verbietet meist das 
Dissassmeblieren für den nicht bestimmungsgemäßen Gebrauch.
Und die bestimmungsgemäße Plattform ist eben ein x86 Rechner.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Nano schrieb:
>> Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft.
>> Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM
>> Prozessoren. Deswegen gibt's auch in Zukunft keinen Grund, Windows auf
>> ARM laufen zu lassen, MS tut das ja jetzt schon mit Windows RT und Co,
>> aber mangels Software führt das zu nichts.
>
> Nur warum tut Microsoft nichts dagegen? Sie könnten doch wie Apple
> früher ihren Compiler/Linker so auslegen, dass er im Executable einfach
> den Code für beide Architekturen ablegt und je nach System den passenden
> Code lädt. Bei Apple heißt das "universal binary".
> https://de.wikipedia.org/wiki/Universal_Binary

Microsoft tut dagegen schon was. Das nennt sich .NET und die neue App 
Infrastruktur. Damit sind die Anwendungen dank .NET Laufzeitumgebung wie 
Java ohne Neucompilierung gut auf Windowssystemen, die alle benötigten 
zusätzlichen Libs haben, portabel.
Daran haben die schon die letzten > 15 Jahre gearbeitet.

Nur kriegst du die nativen gewachsenen C und C++ Anwendungen so nicht 
auf Windows für ARM.
Universal Binaries haben den Nachteil, dass sie mehr Platz brauchen und 
den braucht Windows schon dafür, weil sie anders als bei Linux, gleich 
mehrere Versionen der gleichen Bibliothek zwecks Binärkompatibilität auf 
Anwendungsebene mitliefern. Das ist der Grund, warum unter Windows für 
gewöhnlich eine über 20 Jahre alte 32 Bit Anwendung noch auf einem 
aktuellen Windows läuft.

Klar für Neuentwicklungen könnte man das so machen. Die Entwickler 
könnten auch zwei verschiedene Plattformen bedienen und ihren C und C++ 
Code jeweils für die entsprechende Plattform compilieren.
Aber da die Nutzer Zuhause noch eine riesen Sammlung an Bestandssoftware 
haben, kaufen die trotzdem bevorzugt x86 Prozessoren. Das führt dazu, 
dass der Markt für Win auf ARM klein bleibt und weil das so ist, macht 
sich kein Entwickler die Mühe, auch noch ARM als Plattform zu supporten.
Deswegen versucht Microsoft das in dem es einfach die Laufzeitumgebung 
abstrahiert. .NET Anwendungen sollten daher überall laufen und wenn die 
Verbreitung dann irgendwann groß genug ist, könnte man den Schwenk zu 
ARM dann forcieren.

Im Prinzip arbeitet man ja daran. Aber für die alten nativen Anwendungen 
muss man trotzdem einen x86 Emulator bereitstellen. Auch das macht man, 
nur sind die eben grottenlangsam.
Bis die schnell genug sind, vergehen noch ein paar Rechnergenerationen.

Tja und dann gibt's da noch die immer neuen nativen C++ Anwendungen, die 
viel Performance schlucken und daher immer höchstens erst 20 Jahre 
später in der Emulation halbwegs akzeptabel laufen.

Wir werden also noch eine ganze Weile mit Windows auf x86 bleiben.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Selbst wenn das technisch halbwegs sauber funktionieren würde, wäre es
> rechtlich nicht erlaubt. Das Urheberrecht verbietet meist das
> Dissassmeblieren für den nicht bestimmungsgemäßen Gebrauch.
> Und die bestimmungsgemäße Plattform ist eben ein x86 Rechner.

Hast du dafür irgendwelche Referenzen? Ich habe das noch nie gehört und 
halte das für Unfug.

Es gibt ein Haufen Software, die Bytecode in irgendwelchen anderen 
Bytecode übersetzt, z.B. qemu oder vmware, wenn sie andere Plattformen 
emulieren, Wine wenn es D3D Shader auf OpenGL umbaut, oder 
Spielekonsolen-Emulatoren wie Dolphin, der PPC-Bytecode in X86-Bytecode 
JITed. Man hört von gelegentlich rechtlichen Problemen bei diesen 
Projekten, da geht es aber immer um rechtmäßigen Erwerb und Vertrieb der 
Original-Binaries, nicht um die Emulation an sich.

Beitrag #6429793 wurde vom Autor gelöscht.
von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Binary translation ist ein alter Hut. Nur die Vorstellung, das wäre als 
Rückübersetzung in Quellcode und anschliessende Neuübersetzung zu 
verstehen, die ist daneben.

Umgekehrt gab es das auch schon, also ARM zu x86 Umsetzung: Android 
Handys mit Intel Prozessor nutzten "Houdini", wenn ihnen nativer ARM 
Code zugemutet wurde.

: Bearbeitet durch User
von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Nano schrieb:
>> Selbst wenn das technisch halbwegs sauber funktionieren würde, wäre es
>> rechtlich nicht erlaubt. Das Urheberrecht verbietet meist das
>> Dissassmeblieren für den nicht bestimmungsgemäßen Gebrauch.
>> Und die bestimmungsgemäße Plattform ist eben ein x86 Rechner.
>
> Hast du dafür irgendwelche Referenzen? Ich habe das noch nie gehört und
> halte das für Unfug.

Du scheinst wohl das UrHG nie gelesen zu haben:

§ 69c Zustimmungsbedürftige Handlungen
§ 69d Ausnahmen von den zustimmungsbedürftigen Handlungen
und
§ 69e Dekompilierung


> Es gibt ein Haufen Software, die Bytecode in irgendwelchen anderen
> Bytecode übersetzt, z.B. qemu oder vmware, wenn sie andere Plattformen
> emulieren, Wine wenn es D3D Shader auf OpenGL umbaut, oder
> Spielekonsolen-Emulatoren wie Dolphin, der PPC-Bytecode in X86-Bytecode
> JITed. Man hört von gelegentlich rechtlichen Problemen bei diesen
> Projekten, da geht es aber immer um rechtmäßigen Erwerb und Vertrieb der
> Original-Binaries, nicht um die Emulation an sich.

Hier geht es auch nicht um Emulation, sondern Maxe will die Programme 
dissassemblieren und dann daraus für die neue Architektur wieder native 
Programme erstellen.
Das ist weit mehr, als nur eine Emulation.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
(prx) A. K. schrieb:
> Binary translation ist ein alter Hut. Nur die Vorstellung, das
> wäre als
> Rückübersetzung in Quellcode und anschliessende Neuübersetzung zu
> verstehen, die ist daneben.

So ist es. Das ist das nächste Problem.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Du scheinst wohl das UrHG nie gelesen zu haben:
>
> § 69c Zustimmungsbedürftige Handlungen
> § 69d Ausnahmen von den zustimmungsbedürftigen Handlungen
> und
> § 69e Dekompilierung

Dekompilierung ist nicht Emulation oder Bytecode-Translation oder JIT 
Recompilation. Dekompilierung ist, wenn ich versuche, aus dem Bytecode 
wieder C++ zu machen. Davon redet hier keiner.

Darüber hinaus gibt sich der von dir genannte Text doch jede erdenkliche 
Mühe, das Verbot "zum Zweck der Interopabilität" genau eben nicht 
auszusprechen, und genau um diesen Zweck geht es doch hier 
offensichtlich.

-> Ich halte das immer noch für Nonsens.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Hier geht es auch nicht um Emulation, sondern Maxe will die Programme
> dissassemblieren und dann daraus für die neue Architektur wieder native
> Programme erstellen.
> Das ist weit mehr, als nur eine Emulation.

Die Liste von Beispielen, die du von mir im Satz drüber zitiert hat, hat 
dafür doch sogar auch eines: Dolphin JIT-ed die PPC-Instruktionen in 
natives x86 während der Ausführung.

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
Mikroprogrammierte Prozessoren sind auch illegal, weil sie während der
Programmausführung ohne Zutun des Benutzers Maschinencode in Mikrocode
umsetzen.

Jetzt muss ich mich mit dem Tippen auf meinem PC mit Intel-Prozessor
aber beeilen, hinter mir hämmert schon die Polizei gegen die Tür ...

;-)

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Hmmm schrieb:
>> Aber die Firmenpolitik wird wohl erstmal weiter Windows 10 verfolgen,
>> denn nicht nur "Cloud"-Kram ist in Mode, sondern auch das Einsammeln von
>> Daten.
>
> Das hat ja nichts mit dem Kernel zu tun. Nutzerdaten sammeln könnten sie
> auf einem Linux-Kernel genauso gut wie auf einem Windows-Kernel.

Ich bezog mich auf die Aussage, dass man wegen der höheren Bedeutung des 
Azure-"Cloud"-Zeugs evtl. die Entwicklungskosten von Windows reduzieren 
will.

Mit Windows 10 gibt es bereits ein fertiges Produkt, das ein 
Kaufargument liefert (weitestgehend kompatibel zu bestehenden 
Anwendungen, dürfte bei etwas auf Linux-Basis schlechter aussehen), sich 
in die tolle moderne "Cloud"-Welt integriert (sammelt Daten) und wohl 
auch deshalb immer noch halb verschenkt wird (Aktivierung mit 
Windows-7-Seriennummer).

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Nano schrieb:
>> Du scheinst wohl das UrHG nie gelesen zu haben:
>>
>> § 69c Zustimmungsbedürftige Handlungen
>> § 69d Ausnahmen von den zustimmungsbedürftigen Handlungen
>> und
>> § 69e Dekompilierung
>
> Dekompilierung ist nicht Emulation oder Bytecode-Translation oder JIT
> Recompilation. Dekompilierung ist, wenn ich versuche, aus dem Bytecode
> wieder C++ zu machen. Davon redet hier keiner.

Doch, genau das hat Maxe gemeint.
Lies sein Kommentar auf das ich oben geantwortet habe.

Er schrieb:

Maxe schrieb:
> Nano schrieb:
>> Das Problem ist das Ökosystem, das auf x86 Prozessoren läuft.
>> Man kriegt nämlich keine neuen Binaries von Windowsanwendungen für ARM
>> Prozessoren.
> Das OS koennte ja einen Recompiler/Reassembler bereitstellen, der die
> 386er Binaries auf die entsprechende Plattform uebersetzt.

Maxe möchte also x86 Binärcode dissassemblieren und dann aus dem 
lesbaren x86 Assemblercode irgendwie ARM Binärcode erstellen oder eben 
über den Umweg über C Code und daraus dann aus dem C Code zurück zu ARM 
Assembler und dann ARM Binärcode.

Es ist also genau anders herum, die Emulation und Bytecode-Translation 
oder JIT Recompilation, waren hier nie gemeint. Die sind gar nicht das 
Thema.
Das hast erst du selber aufgemacht, weil du Maxe nicht verstanden hast.


> Darüber hinaus gibt sich der von dir genannte Text doch jede erdenkliche
> Mühe, das Verbot "zum Zweck der Interopabilität" genau eben *nicht*
> auszusprechen, und genau um diesen Zweck geht es doch hier
> offensichtlich.

Bei Interopabilität geht es darum, dass du bspw. eine Schnittstelle wie 
das SMB Protokoll erforschen kannst, damit du eine eigene 
Implementierung schreiben kannst.
D.h. du nimmst die Windowsbinaries, dekompilierst sie um das SMB 
Protokoll und dessen Funktionsweise zu erforschen und dann 
implementierst du, wie es die Samba Entwickler gemacht haben, einen 
eigene SMB Implementierung.

Das deckt aber nicht ab, dass du ein bestehendes x86 Binary nimmst, 
dieses dissassemblierst, den Code an arm anpasst und dann daraus ein 
natives arm Binary machst.
Das deckt das Urheberrecht nämlich nicht ab, dafür bräuchtest du die 
Zustimmung des Rechteinhabers bzw. darf nur er selber das machen.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Nano schrieb:
>> Hier geht es auch nicht um Emulation, sondern Maxe will die Programme
>> dissassemblieren und dann daraus für die neue Architektur wieder native
>> Programme erstellen.
>> Das ist weit mehr, als nur eine Emulation.
>
> Die Liste von Beispielen, die du von mir im Satz drüber zitiert hat, hat
> dafür doch sogar auch eines: Dolphin JIT-ed die PPC-Instruktionen in
> natives x86 während der Ausführung.

Das ist aber nicht bleibend, sondern eben nur zur Laufzeit.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Maxe möchte also x86 Binärcode dissassemblieren und dann aus dem
> lesbaren x86 Assemblercode irgendwie ARM Binärcode erstellen oder eben
> über den Umweg über C Code und daraus dann aus dem C Code zurück zu ARM
> Assembler und dann ARM Binärcode.

Jo, aber das ist doch im Verständnis des normal denkenden Menschein 
keine "Dekompilierung"! Eine Dekompilierung ist etwas, wo das Ergebnis 
eine Hochsprache ist. Ist es hier nicht, das Ergebnis ist anderer 
Bytecode. Das ist Bytecode-Translation, was soll das sonst sein?

Selbst wenn dazu zwischendrin eine C-Repräsentation erzeugt werden 
sollte (was ich ziemlich kurios fände und nicht glaube), ist das ein 
Implementierungsdetail, was rechtlich vermutlich nicht von Belang ist, 
da im Zweifel eh keiner versteht was das bedeutet. Die Intention 
hingegen ist ganz klar nicht den Code zu dekompilieren, sondern ihn auf 
einer anderen Plattform auszuführen.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Nano schrieb:
>> Maxe möchte also x86 Binärcode dissassemblieren und dann aus dem
>> lesbaren x86 Assemblercode irgendwie ARM Binärcode erstellen oder eben
>> über den Umweg über C Code und daraus dann aus dem C Code zurück zu ARM
>> Assembler und dann ARM Binärcode.
>
> Jo, aber das ist doch im Verständnis des normal denkenden Menschein
> keine "Dekompilierung"! Eine Dekompilierung ist etwas, wo das Ergebnis
> eine Hochsprache ist. Ist es hier nicht, das Ergebnis ist anderer
> Bytecode. Das ist Bytecode-Translation, was soll das sonst sein?

Nun, Maxe hat aus dem Kontext ja erkennen lassen, was er möchte, auch 
wenn sein Begriff Dekompilierung sicher falsch gewählt war, aber als 
Antworter irgnoriert man das und geht darauf ein, was er aus dem Kontext 
eigentlich wissen will. Deswegen sagte ich ja auch dissassemblieren.

Was er aus dem Kontext definitiv nicht meinte, war die Emulation von x86 
Code, wie du es meinst. So viel ist klar.


> Selbst wenn dazu zwischendrin eine C-Repräsentation erzeugt werden
> sollte (was ich ziemlich kurios fände und nicht glaube), ist das ein
> Implementierungsdetail, was rechtlich vermutlich nicht von Belang ist,
> da im Zweifel eh keiner versteht was das bedeutet.

Rechtlich interessant ist eigentlich nur, ob du die Daten umbearbeitest 
und neue daraus machst.
Und da schon die Konvertierung eines PNG Bildes ins JPG Format eine 
Umkodierung verlangt und rechtlich ohne Zustimmung des Rechteinhabers 
nicht erlaubt ist, ja, kaum zu glauben, ist aber juristisch so, wird das 
bei der Konvertierung von x86 Code in ARM Code erst Recht nicht möglich 
sein.


> Die Intention
> hingegen ist ganz klar nicht den Code zu dekompilieren, sondern ihn auf
> einer anderen Plattform auszuführen.

Nein, die Intention ist native Binares zu erhalten. Das geht auch aus 
dem Kontext hervor, da ich vor seinem Kommentar ja schon auf die 
langsame Emulation hingewiesen habe und er dann deswegen native Binaries 
ins Spiel brachte um die Langsamkeit zu umgehen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.