Sdfendor schrieb:
Ja whatever - lass aber vielleicht deine Kindergarten Vorwürfe über Unwissenheit und dergleichen.
Wenn dir mehrfach gesagt und mit Argumenten erklärt wird, dass das keine Emulation ist und du es jedes Mal ignorierst und weiterhin auf deiner Meinung beharrst und keine weiteren Punkte darlegst, die deine Interpretation unterstützen... Sorry.
Sdfendor schrieb:
Diese Übersetzung der System Calls - sei es bei WOW64 oder WSL oder sonstwas - reichen mir dennoch aus. um von Software Emulation zu sprechen, in Abgrenzung zu einer nativen Ausführung einer x86 Win Anwendung oder einem ELF Binary.
Wenn du danach gehen willst, ist
alles eine Emulation. Denn jedes Interface und somit jede einzelne Abstraktion ist damit nicht mehr "nativ". Das klappt aber nicht, denn schließlich will man Kompatibilität und Interoperabilität herstellen. Das geht mit "nativ" nicht.
Und nur weil eine DLL dazwischenliegt, die die Calls entsprechend nur an ne andere Stelle leitet, läuft der Code selbst dennoch nativ und nicht emuliert. Emuliert wird, wenn ich das SNES nachbilden will. Emuliert wird aber nicht, wenn ich 32 Bit Code auf ner 64 Bit CPU ausführe, da übliche amd64 CPUs weiterhin x86/IA-32 beherrschen - nativ. Und selbst heutige OS arbeiten nicht mehr "nativ", da der direkte Zugriff auf die Hardware wo immer möglich unterbunden wird.
Das hat dir
@0x8100 mehrfach erklärt.
Und nur weil Windows seine APIs über Indirection durch verschiedene Subsysteme der Kompatibilität wegen leitet, wird 1 + 2 deshalb trotzdem nativ auf der CPU in x86/IA-32 berechnet, ohne dass dort irgendwas emuliert werden muss.
Das hat dir
@0x8100 auch erklärt, dass der Code unmodifiziert läuft.
Aber alle Erklärungen hast du gewissentlich ignoriert und beharrst auf deiner Meinung, dass 32 Bit Code auf 64 Bit Windows emuliert wird, weil das Wort "emulation"
einmal vorkommt. Zumal wie üblich "emulation" mehrere Bedeutungen besitzt.
Vielleicht tritt das Wort "emulation" dort auf, weil
hier u.a. auch vom IA-64/ARM -> x86 Emulator gesprochen wird. Genau das wäre eine Emulation, da sich ARM oder IA-64 nicht auf x86 mappen lassen. Das hat aber nichts mit dem ursprünglichem x86/IA-32 Code auf x86-64 Hardware zu tun.
chithanh schrieb:
Keine Ahnung wer dir ins Frühstück geschissen hat dass du dir so eine abfällige Ausdrucksweise zugelegt hast.
Du. Weil du dich in eine Diskussion einklinkst, von der du anscheinend keinen Schimmer hast und irgendwas erzählst, was nichts mit dem Thema zu tun hat.
Und dein großspuriges "Somit ist dein Argument hinfällig".
Danke für die Anteilnahme.
chithanh schrieb:
Ich habe lediglich ein Gegenbeispiel für deinen behaupteten "immensen Vorteil von Windows" genannt.
Dein "Gegenbeispiel" ist ein
komplett anderes Thema.
chithanh schrieb:
Die APIs die SafeDisc und SecuROM genutzt haben waren anscheinend nicht stabil genug.
SafeDisc und SecuROM werden mittels Drittanbieter-Treiber (
secdrv.sys
) umgesetzt. Diese werden seit Jahrzehnten nicht mehr gewartet und weisen entsprechende Lücken auf. Deshalb kam irgendwann der Cut und sie wurden im
Auslieferungszustand von Windows entfernt.
Übrigens kannst du den Treiber auch gern manuell wieder installieren und aktivieren - dann läuft alles wie eh und je. Ein fehlender Treiber hat aber nichts mit der Abwärtskompatibilität des Systems selbst zu tun.
Was das Thema Rechtemanagement allgemein betrifft... Ich denke darüber muss man sich nicht unterhalten.
chithanh schrieb:
Wine hingegen unterstützt sie noch immer.
Ja, indem sie (wie üblich bei Wine) irgendwas vorgaukeln. Zu den eigentlichen Treibern wird dort kein einziger Aufruf stattfinden. Gleiches Ergebnis wie bei der Nutzung eines Cracks. Mich würde interessieren wie der Einsatz von Cracks nach
dem Urteil gewertet werden kann.