News Windows 11 setzt auf Win32: TeamSpeak 5 ist im Microsoft Store erhältlich

[Yuuri]

Damit ist wohl alles gesagt zum Thema, die Leute wissen es eben besser als Microsoft.

Wende dir Wissen zur Thematik selbst an und hör auf dir Rosinen rauszupicken ohne zu wissen was sie bedeuten. Dann müsste man dir auch nicht das Wort "Emulation" in diesem Kontext erklären...

@0x8100 hat das schon korrekt erklärt.

 

[Sdfendor]

Wende dir Wissen zur Thematik selbst an und hör auf dir Rosinen rauszupicken ohne zu wissen was sie bedeuten. Dann müsste man dir auch nicht das Wort "Emulation" in diesem Kontext erklären...

@0x8100 hat das schon korrekt erklärt.

Ja whatever - lass aber vielleicht deine Kindergarten Vorwürfe über Unwissenheit und dergleichen. Ihr wollt dogmatisch den Begriff Emulation ausdifferenzieren und nur auf Architekturebene gelten lassen, von mir aus, tut euch keinen Zwang an. Dann mach ich das auch mit der Aussage "der läuft nativ" von @0x8100 in dem ersten Beitrag, auf den ich antwortete (bezogen auf x86 Windows Anwendungen). Das ist selbst dann nicht der Fall, wenn es sich nur um eine Translation handelt (https://i.stack.imgur.com/BaOo6.png).
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.
Microsoft wird Gründe haben, es ebenfalls Emulation zu nennen. Aber die zählen ja - wie gehört - nicht 🤷‍♂️.

 

[ComputerJunge]

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.

In dem von Dir zitierten Wikipedia-Artikel steht doch auch explizit, dass es unter x86-64 eben keine Adaptierung der System-Calls gibt, sondern "nur" der Ausführungsmode der CPU geschaltet wird.

 

[chithanh]

Wenn das nur irgendwie Thema gewesen wäre. Ich frag mich was "Wine, alte Spiele starten, Kopierschutz, SafeDisc, SecuROM" mit "überfälligem 32 Bit Support und überfälliger Win32 API" zu tun hat

Keine Ahnung wer dir ins Frühstück geschissen hat dass du dir so eine abfällige Ausdrucksweise zugelegt hast. Ich habe lediglich ein Gegenbeispiel für deinen behaupteten "immensen Vorteil von Windows" genannt.
Die APIs die SafeDisc und SecuROM genutzt haben waren anscheinend nicht stabil genug. Wine hingegen unterstützt sie noch immer.

 

[Yuuri]

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.

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.

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.

Ich habe lediglich ein Gegenbeispiel für deinen behaupteten "immensen Vorteil von Windows" genannt.

Dein "Gegenbeispiel" ist ein komplett anderes Thema.

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.

• https://www.computerbase.de/2015-09/microsoft-update-deaktiviert-safedisc-unter-windows-vista-bis-8/
• https://support.microsoft.com/en-us...r-8-2015-6a1e4fc4-0821-79d4-d25c-02728a6fdf30

Ü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.

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.

 

[chithanh]

SafeDisc und SecuROM werden mittels Drittanbieter-Treiber (secdrv.sys) umgesetzt.

Na und? Microsoft liefert schon seit langem Windows mit Drittanbietertechnologien aus. Ob es nun von Microsoft direkt stammt oder nicht macht für die Frage "Ist die Software die das benutzt mit der neuen Windows-Version kompatibel oder nicht?" keinen Unterschied.

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.

Wine unterstützt den Kopierschutz, es ist kein Crack. Die Kommunikation zwischen DRM-Treiber und CD-Laufwerk wird durchgereicht.
https://wiki.winehq.org/Copy_Protection
https://www.winehq.org/pipermail/wine-users/2002-April/007910.html

 

[h00bi]

Dazu kann ich den ganzen bunten trendigen Kiddie Kram nicht leiden.

Zocke mit 3 anderen "Technik-Noobs", die kommen mit Discord besser klar als mit Teamspeak, vor allem wenn man mal was postet, wie Videos oder Bilder.

Beschreibt die Unterschiede zu 100%
Voice: TS > Discord
mehr als Voice: Discord > TS