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

USB-Kabeljau schrieb:
Kann mir echt mal einer erklären, wo dieser Hass herkommt?
Ich nutze Discord lieber als Teamspeak, würde aber nie auf die Idee kommen, das Programm hier madig zu machen.

Wieso müssen manche Leute aus allem einen Krieg machen?
Vielleicht liegts daran, dass man ständig zu Discord gedrängt wird, obwohl man es nicht nutzen möchte, was wiederum frustrierend sein kann
Das ist jedenfalls ein Unterschied, in der Vergleichssituation, welche du beschreibst.
 
USB-Kabeljau schrieb:
Naja. Ich war auch schon mal genervt, weil ich dann doch wieder TS3 installieren musste.
Ist doch garnicht vergleichbar, weil die Ausnahme
 
Gibt es eigentlich eine Korrelation zwischen Discordnutzern und "Gegnern" von Whatsapp, Facebook, Google et al.?
 
KitKat::new() schrieb:
Ist doch garnicht vergleichbar, weil die Ausnahme
In meinen Kreisen (ü30-ü60) ist die Nutzung von TS, Mumble, Ventrilo und Konsorten die Ausnahme 🤷‍♂️ ebenso die Ablehnung von Discord. Das ist wie mit SMS und Whatsapp. Beides reicht zur simplen Kommunikation.

Ist ein sehr subjektives Thema.
 
Akkulaus schrieb:
und Ram verbrauch auch echt enorm. Da kommt TS mit paar MB locker aus.
Wofür hab ich das Zeug im Rechner wenn es nicht benutz werden soll.
Die Zeiten in denen man mit seinen 128MB Ram haushalten musste sind ja nun schon länger vorbei.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: supergundel, Cool Master und ComputerJunge
david91x schrieb:
Dann sag sag den Leuten sie sollen:
1. Lauter sprechen
2. Mikrofon Einstellung höher drehen
3. Den Treiber richtig einstellen
4. Perma Senden anmachen
5. Voice Verbesserer aus. (Dafür gibts doch die Optionen zum ausstellen)
6. Bilde nen eigenen Server (sei es auch temporär) und erhöhe die Bitrate der Voice-Channels. Die ist standardmäßig unten, genau wie in DMs, Mit Nitro gehen die meine ich sogar noch höher und schlagen dann sogar euer geliebtes Teamspeak. - Bleibt insgesamt immer noch günstiger als irgendwas eigener Server.
Oder:
1. Teamspeak nutzen.
Fertig. Es kann so einfach sein. 😜

Ontopic: Bin gespannt wie sich der Store so entwickeln wird. Das mögliche App-Angebot erweitert sich durch Win32-Apps natürlich enorm. Potenzial ist da, mal sehen was Microsoft draus macht.
 
CrucialValue schrieb:
Datenschutz.

Ich wette die meisten die hier nach Datenschutz schreien benutzen wohlmoeglich Facebook, Instagram und/oder ......
Und das hast du jetzt einfach mal so geraten? Was hat das eine mit dem andern zu tun?

Klassischer Fall von Whataboutism wenn einem die Argumente ausgehen.

Discord hat viele Funktionen die nützlich sind, Datenschutz ist aber halt ein reisen Negativpunkt. Den kann man auch nicht wegdiskutieren. Wenn man damit kein Problem hat ist man bei Discord doch auch gut aufgehoben.
 
  • Gefällt mir
Reaktionen: Miuwa, Zorror und Der Lord
Der Lord schrieb:
Das mögliche App-Angebot erweitert sich durch Win32-Apps natürlich enorm.
... nochmal:
KitKat::new() schrieb:
Der Unterschied jetzt ist, dass man in den Store direkt Setups reinpacken kann, statt dass Entwickler ein msix Paket erstellen mussten.
 
Ändert nichts an meinem Fazit: Mehr Möglichkeiten für Entwickler dort Anwendungen unterzubringen sorgt letztendlich für eine größere Anwendungsauswahl im Store. Daher begrüßenswert, wenn der Store dadurch mehr Nutzer erreichen wird. Aber wie das Angebot genutzt wird, wird sich erst zeigen müssen.
 
  • Gefällt mir
Reaktionen: Sdfendor, chartmix und KitKat::new()
Yuuri schrieb:
Ein immenser Vorteil von Windows. Ich kann auch heute noch das originale UT aus dem Jahre 1999 von CD installieren und es läuft, höchstwahrscheinlich auch auf Windows 11. E
Yuuri schrieb:
Da hast du aber wunderbar komplett den Kontext entstellt! Gratulation! Du solltest bei der Bild arbeiten! Und gleich mal nen Schwanzvergleich mit eingebaut! So will man Diskussionen führen!
Man kann unter Linux/Wine einige alte Spiele starten, die auf Windows 10 nicht mehr laufen dank Kopierschutz. SafeDisc/SecuROM sei als Stichwort genannt. Somit ist dein Argument hinfällig.
 
  • Gefällt mir
Reaktionen: Cool Master
chithanh schrieb:
Somit ist dein Argument hinfällig.
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 und warum Microsoft auf 64 Bit only setzen, sowie jeglichen 32 Bit Support streichen sollte und was das überhaupt mit 30+ Jahre aufrecht erhaltener ABI- und API-Stabilität zu tun hat... Nebenbei hat UT 99 mit dem 436er Patch überhaupt keine Copy Protection mehr. "Somit ist dein Argument hinfällig."

Das Plus von @Cool Master auf deinen Beitrag verdeutlicht mir zusätzlich, dass er gar nichts weiter zum Thema zu sagen hat, wenn er bereits Offtopic upvotet.

Ich merk schon, um das eigentliche Thema der Diskussion ("Warum sollte Windows 32 Bit API Support streichen") kann man nicht reden, weil sowieso nichts mehr von euch kommt, ja nicht ein einziger rationaler Grund in die Diskussion gebracht wurde.
 
Zuletzt bearbeitet:
0x8100 schrieb:
32bit x86 code wird auf x86-64 cpu nicht emuliert, der läuft nativ.
Das ist nicht korrekt. Windows x64 führt x86 durch WOW64 aus (Windows 32-bit on Windows 64-bit), seit XP ist das so, keine native Ausführung (https://en.wikipedia.org/wiki/WoW64).

mae1cum77 schrieb:
Leider sieht es so aus, daß bei nicht-UWP Anwendungen der Ersteller anwendungsintern eine Updatefunktion bereitstellen muß. Automatische Updates via Store unterstützen nur UWP Apps.

Reichlich inkonsistent.

Vielleicht sollte man hier nochmal klarstellen, dass das neue an den Win32 Anwendungen im Windows 11 Store ist, dass die Anwendungen nicht extra verpackt werden müssen. Bisher war es bereits möglich UWP Apps und Win32 Apps in den Store zu stellen, man musste sie aber für den Store speziell verpacken (mit Manifest in einem speziellen Format). Hat man das gemacht, kann man beide Varianten auch über den Store updaten.
Die neue Möglichkeit ohne "spezielle Verpackung" Win32 Anwendungen einzustellen, ermöglicht es nicht, Funktionen wie automatische Updates via Store zu nutzen!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mae1cum77
Sdfendor schrieb:
Das ist nicht korrekt. Windows x64 führt x86 durch WOW64 aus (Windows 32-bit on Windows 64-bit), seit XP ist das so, keine native Ausführung (https://en.wikipedia.org/wiki/WoW64).
natürlich ist das korrekt. der 32bit x86 code läuft genauso unmodifiziert und nativ auf 32bit x86 cpus wie auf x86-64 cpus. das ist ja gerade der vorteil von amd64. intels 64bit ansatz auf itanium musste für x86 binaries wirklich emulieren und war daher langsam.

dass ein 64bit os interfaces bereitstellen muss, damit ein 32bit programm mit dem 64bit os sprechen kann (WoW64), ist eine andere sache. diese interfaces gibt es natürlich ebenso auf einem 32bit os, niemand lässt programme ohne os laufen (ausnahmen: bootloader- und kernel-entwickler)
 
Zuletzt bearbeitet:
0x8100 schrieb:
natürlich ist das korrekt. der 32bit x86 code läuft genauso unmodifiziert auf 32bit x86 cpus wie auf x86-64 cpus. das ist ja gerade der vorteil von amd64. intels 64bit ansatz auf itanium musste für x86 binaries wirklich emulieren und war daher langsam.

dass ein 64bit os interfaces bereitstellen muss, damit ein 32bit programm mit dem 64bit os sprechen kann (WoW64), ist eine andere sache. diese interfaces gibt es natürlich ebenso auf einem 32bit os, niemand lässt programme ohne os laufen (ausnahmen: bootloader- und kernel-entwickler)
Es findet eine Emulation statt, genau wie bei WSL (Version 1 da Version 2 quasi virtualisiert mit Hyper-V) eine Emulation stattfindet. Dass sich x86 und x64 dabei nicht sehr unterscheiden, ist für die Emulation ein großer Vorteil (und die Geschwindigkeit zwischen nativem Windows 32 und WOW64 nahezu identisch). Microsoft selber spricht auch von Emulationen, wurde in diversen //BUILD Vorträgen zu WSL (v1) und der Technik dahinter so gesagt. Die x86 Anwendungen, die auf Itanium Windows 64 ausgeführt worden sind, mussten afaik auch nicht modifiziert werden. um ausgeführt zu werden. Gleichwohl müssen ELF Binaries heute auch nicht angepasst werden, um grundlegend in der WSL ausgeführt zu werden (Das neue Android Subsystem wird vermutlich den WSL 2 Ansatz gehen).

https://docs.microsoft.com/de-de/wi...64-implementation-details?redirectedfrom=MSDN
hier: "Wow64.dll stellt die Kernemulationsinfrastruktur und die Thunks für die Ntoskrnl.exe Einstiegspunktfunktionen zur Verfügung." ist Teil jeder WOW64 Implementierung, während Itanium und ARM64 Versionen von Windows 64 weitere Binaries für die x86 Softwareemulation beinhalten. Das weißt auch auf die allgegenwertige Emulation in allen Windows 64 hin.
 
Zuletzt bearbeitet:
es wird nichts emuliert. emulation wäre das ausführen von z.b. arm-binaries auf x86. auch wsl emuliert nichts, da es immer noch x86 binaries sind, die nur andere interfaces erwarten. da wsl nicht emuliert, kannst du z.b. nicht ein arm binaries ausführen bzw. unter hyperv kein anderes os ausser für x86 starten.

qemu kann andere architekturen emulieren, mit damit einhergehenden performanceeinbußen.
 
0x8100 schrieb:
es wird nichts emuliert. emulation wäre das ausführen von z.b. arm-binaries auf x86. auch wsl emuliert nichts, da es immer noch x86 binaries sind, die nur andere interfaces erwarten.
Du kannst das weiter wiederholen, das Dokument von Microsoft widerspricht dir. Ist aber auch nicht weiter wild, war ja nur am Rande relevant für dieses Thema.

EDIT: Hier nochmal schwarz auf weiß von Microsoft: https://docs.microsoft.com/en-US/wi...nning-32-bit-applications?redirectedfrom=MSDN

"WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows."
 
Zuletzt bearbeitet:
Sdfendor schrieb:
Microsoft selber spricht auch von Emulationen, wurde in diversen //BUILD Vorträgen zu WSL (v1) und der Technik dahinter so gesagt.
zeigst du mal so einen Vortrag, bitte?
 
nur weil ms von emulation spricht, macht es die sache nicht richtiger. bei x86 auf x86-64 werden die aufrufe nur zwischen den beiden 32- und 64-bit modi übersetzt (translation). sie müssen eben nicht emuliert werden. das muss nur bei unterschiedlichen prozessor-architekturen gemacht werden.
 
KitKat::new() schrieb:
zeigst du mal so einen Vortrag, bitte?
Eine kurze Suche auf Youtube ergab bei Microsoft Developer leider nichts erhellendes, nur zur Architekturvorstellung von WSL2. Ich denke die Videos existieren da nicht mehr oder ich suche falsch. Da WSL Release 2017 war, nehme ich an BUILD 2017 oder 2018 wird das gewesen sein. Viel mehr als die Informationen, die bereits in den Infos zu WOW64 hier stehen, wurde dort aber auch nicht gesagt. Nur dass sie das Subsystem Prinzip von WOW64 benutzen, um WSL umzusetzen (damals noch nicht v1 da es nur diese gab).

Ergänzung ()

0x8100 schrieb:
nur weil ms von emulation spricht, macht es die sache nicht richtiger.
Damit ist wohl alles gesagt zum Thema, die Leute wissen es eben besser als Microsoft.
 
Zuletzt bearbeitet:
Zurück
Oben