News Windows unter Linux: Wine 10 setzt auf Wayland

Randnotiz schrieb:
Da wirst Du etwas experimentieren müssen, eventuell auch das passende Telefon für kaufen.

Ich würde mit dem Wissen, dass bald Desktop Linux mit Android 16 einfach eingerichtet werden kann und 3D Beschleunigung auch funktioniert, eher darauf warten, ansonsten, wie ich es jedem empfehle, statt der 1200€ Smartphones auf Vertrag, lieber ein SteamDeck oder eine Switch kaufen.
Ich brauche das Phone für mich und plane ein Tab zu holen.
Aber die Samsungs haben eben auch den Snapdragon 3 oder besser, die ich möchte.

Unterwegs spiele ich nur WoW. Dafür brauche ich kein Steamdeck, sondern nen 12"+ Display :-)

Auf Vertrag ist da auch nichts :-)
 
flatline1 schrieb:
Hatte ich auch immer gehofft.
Leider weiß ich nicht mehr woher ich den Denkanstoß hatte, denn so schön open source auch ist, hat es den nachteil das "jeder" sich seinen eigenen Kernel zusammenstellen kann.
Dadurch ist es wohl unmöglich zu schaffen das etwas nicht manipuliert werden kann, bzw. man alles umgehen /überbrücken kann.

Das einzige was wohl dagegen helfen würde wenn es einen unveränderlichen "anti cheat kernel" geben würde, nur könnte der dann nicht open source sein also eigentlich kein Linux Kernel mehr.
Deshalb ist meiner Meinung nach das beste Anticheat, eines welches auf dem Server läuft.
Also das der Input verifiziert wird, damit keine übernatürlichen Bewegungen möglich sind.
Und damit man z.B. Gegner nicht durch Wände sehen kann: das die Position von diesen erst übermittelt wird wenn man sie (fast) sehen kann. Bzw. ist es auch möglich, das der Server zusätzliche Positionen von fiktiven Gegnern sendet, welche man nicht sehen kann um potentielle Cheater zu verwirren, welche dann 20 statt 5 Gegner durch Wände sehen.

Problem ist nur, dass sowas teilweise extrem aufwendig zu implementieren ist.
 
@Kaito Kariheddo:

Da ich vermute, dass die meisten das nicht wissen, solltest du wegen der etwas merkwürdigen Versionierung von Wine vielleicht immer dazuschreiben, dass die .0er Versionen die Stable sind.

Alle Nachkommastellen sind Developer-Versionen, so dass Wine 10.1 praktisch die erste öffentliche Beta von Wine 11 sein wird.

Falls die Stable aktualisiert wird, wird es 10.0.1 - Wine 9.0 wurde z. B. nicht aktualisiert, vorletztes Jahr ging es dagegen bis Wine 8.0.2: https://www.winehq.org/news/25
 
  • Gefällt mir
Reaktionen: ILoveShooter132, Deinorius, BrollyLSSJ und 4 andere
Es muss nicht immer x86 sein – ARM64 mit Wine 10

Viel Arbeit an Wine 10 ist auch in die Umsetzung der ARM64-Architektur geflossen. Dabei wird der Wine-Code selbst nativ ausgeführt, während die nötige x86-Emulation von Drittsoftware über ein Interface erfolgt.

Ich fänds lustig, wenn in Zukunft x86 Windows Programme unter Linux on Arm besser laufen, als unter Windows on Arm selbst. 😁

Und wer weiß, vielleicht wird das bei MS zweifelhafter SW Qualität, sogar der Fall werden. 😁
 
Hmm, mal schauen ob ich am WE zeit finde das mit Lutris und meinen Spiele zu testen.

Vor allem mit meinen ollen Dingern wie Afterlife und co. wird das interessant.😉😁
 
Man kann noch nichtmal sagen alte Spiele funktionieren besser als neue. Es kommt wirklich drauf an welche Schnittstellen sie benutzen.
 
  • Gefällt mir
Reaktionen: SeBi1896
riloka schrieb:
Man kann noch nichtmal sagen alte Spiele funktionieren besser als neue.
Unterschreibe ich aufgrund meiner Erfahrung mit Battlefield 2 neulich mal so.

Hab das ganze auch nur mit Hilfe eines Lutris-Skripts installiert bekommen und dann musste ich noch schauen, dass es einen Community-Masterserver gibt, welcher funktioniert.

Musste dafür die bf2.exe per Hexeditor bearbeiten, so dass alles, was zu Gamespy will, zu Openspy stattdessen wandert.

Soweit so gut, das ist auch alles so gegeben, abseits von Lutris, wenn man unter Windows 10 oder 11 selbst das Spiel noch zocken möchte.

Aber Proton-GE, welches dafür verwendet wurde, schmiert dabei dann auch ab, wenn ich mit einem Server verbinde.

Na ja, war ein nettes Experiment, ziehe ich mir im Zweifel halt eine KVM auf.
 
Sehr schön. Auch danke an @Caramon2 für die Erläuterungen der Wine Benummerung. Die war mir z.B. nicht bewusst.
 
  • Gefällt mir
Reaktionen: pseudopseudonym, Caramon2 und Alexander2
flatline1 schrieb:
Leider weiß ich nicht mehr woher ich den Denkanstoß hatte, denn so schön open source auch ist, hat es den nachteil das "jeder" sich seinen eigenen Kernel zusammenstellen kann.
Dadurch ist es wohl unmöglich zu schaffen das etwas nicht manipuliert werden kann, bzw. man alles umgehen /überbrücken kann.
Da muss man nicht immer der Propaganda der Firmen die da mit der Brechstange versuchen ihre Probleme anderen auf zu drücken.

Man muss einfach ein Stück weit Cheating akzeptieren da führt kein Weg dran vorbei, nur ein Polizeistaat kann das verhindern:
https://www.tomshardware.com/monito...eat-at-league-of-legends-looks-great-doing-it

Man kann das dann in Esports Events in so Kabinen überprüfen das nicht gecheatet wird mit eigenen pcs, der User darf nur seine Maus und Tastatur anschließen und fertig, wenns um Geld geht.

Bei Fahrradfahrern nehmen wir das auch hin, da gibts auch kein Körperimplantat das Alarm schlägt wenn irgendwelche Drogen zu sich genommen werden.

Man kann immer noch auf Server Side bestimmte Verhalten beobachten, das ist nur aufwändiger aber daran kommt keiner vorbei.

Zu guter letzt wird es wohl auch Microsoft in Zukunft zumindest eventuell auch nimmer erlauben in ihr OS Rootkits zu installieren.

https://www.notebookcheck.net/Micro...ld-kill-kernel-level-anti-cheat.888345.0.html

Von daher wenn Kernel Rootkits und man sollte die Dinger beim Namen nennen denn das sind sie, zwingend ist für Firmen Spiele an zu bieten ohne das sie unspielbar werden weil sie zu faul sind Serverseitig das zu kontrollieren oder sie es außerhalb der Kernel nicht implementieren wollen was ja auch viele viele Jahre sehr erfolgreich gemacht wurde mit Punkbuster z.B. dann können sie bald auch Windows nimmer unterstützen.

Letztlich kommt noch ein weiterer Aspekt dazu ein Steam und Steamos kann sehr wohl die integrität zumindest eines SteamOS Systems kontrollieren, die Kontrollmöglichkeiten kann man natürlich auch umgehen mit tools oder die Biblioteken die ein Grünes Licht Signalisieren obwohl was falsch ist, aber diese Umgehung kann man dann wieder abprüfen und dann hat man das ganz normale Wettrüsten...

Letztlich ists auch ne demokratisierung von Cheats nicht nur Leute die sich die teuren Cheating-monitore kaufen können dürfen cheaten sondern alle.

Manche "cheats" finde ich btw auch ethisch vertretbar, wenn man nicht sich Vorteile gegenüber anderen Spielern verschafft sondern z.B. ein Game das auf Grinding ausgelegt ist mit nem Bot befarmt, das geht dann in die Richtung von Raubkopien nur mit dem Unterschied das die Unterstellung das man ohne diesen Bot Geld aus gegeben hätte um Booster zu kaufen noch spekulativer. Wer so motiviert ist Geld zu sparen das er Stunden lang einen Bot einrichtet hat wohl eine starke motivation nichts aus zu geben, die chance das der ohne das dann Geld aus gibt ist gering.

Hab das vor vielen Jahren mal gemacht in so nem MMORPG nen Bot durch die Gegend laufen lassen um Zeug zu farmen und mobs zu looten, leider ist der aus irgend einem Grund dann mal gegen ne Wand gelaufen stur und wurde dann nachgefragt von nem admin und als keine Antwort kahm glaub ne Woche gesperrt, folge war hab dann aufgehört zu spielen, nun mag ich eh kein Geld ausgegeben haben, aber es gibt auch Netzwerkeffekte wenn die Welt lehrer ist ist sie auch für Bezahlkunden uninteressanter... und eventuell verleitet man auch noch nen Freund mit zu spielen in nem anderen MMORPG wo ich davor gespielt hab war das so das ein Kumpel der mit mir dort auch gespielt hat dann auch Geld aus gegeben hat.

Wie auch immer werd zu ausufernd, mein Punkt ist, wartet einfach mal 1-2 Jahre dann ist das Problem wohl auch gegessen weil Microsoft hier das selbe wie Windows machen wird und die ganzen Spienner ausm Kernel verbannen wird und den zu schließt weil deren verhalten das verrückte ist nicht das von Linux.

Die ganzen ausfälle mit Crowdstrike führen auch auf solche Kernel-rootkits zurück und das wird wohl auch der Grund sein warum das MS beenden wird:

https://www.theverge.com/2024/7/26/24206719/microsoft-windows-changes-crowdstrike-kernel-driver

Btw hatte ich fast mehr Spass am Bot einrichten als am Game selbst, so ist ja auch mal Simcity unter anderem entstanden Entwickler merkten das ihr Leveleditor mehr spass machte als das Spiel zu spielen... wahrscheinlich gibts das auch bald als Spiel wie richtige und benutze ich einen Bot. Ich mein so Hackerspiele und ähnliches gibt es ja eh schon haufenweise.
 
Zuletzt bearbeitet:
Alexander2 schrieb:
Das hast du wohl auch nicht mitbekommen. vielleciht haben viele auch einfach auf viele Klicks gehoff tbei so einer Meldung .. ist ja klar, das es die gibt.
Bullshit, nirgends hat MS gesagt das sie definitiv Anti cheat nicht ausschließen sehr wohl aber das sie den Zugang zum Kernel deutlich beschränken wollen.

Oder zeig mir die Meldung wo MS commited hat das sie Anticheat nie ausschließen werden oder wegen mir auch nur für Zeitraum der mehr als 1-2 Jahre ist?

Das sind also 2 verschiedene Interpretation oder Meinungen nicht deine die Wahrheit die andere Fake news.

Nur weil sie es nicht übers Knie gebrochen haben und sofort durch gezogen haben. Ist es sicher das sie das tun? nein, aber in beide Richtungen es zeigt zumindest das es keine vernünftige Lösung ist selbst wenn MS entscheiden sollte das sie diesen Zwielichtigen Firmen teilweise auch aus China rootkits in den Kernel installieren lassen wollen, ist es damit definitiv eine idiotische Idee, wegen irgendwelchen Dattelnden Kindern die Computersicherheit komplett über bord zu werfen.

Dann wird das nicht das letzte Crowdstrike gewesen sein, selbst Gesetzlich frag ich mich wie lange die amerikanische Politik noch zu schaut wie diese oft Chinesischen Firmen noch Rootkits in Amerikanischen IT installieren dürfen... mal abwarten...
 
Es ist nichtmal sicher, dass Microsoft überhaupt den Kernel zumachen oder beschränken wird. Es sollen bzw. werden nur zusätzliche Optionen im User Mode bereitgestellt (werden), damit man nicht mehr in den Kernel Mode muss.

Warum ich denke, dass das nicht passiert, habe ich hier in dem Posting schonmal erklärt:
https://www.computerbase.de/forum/t...rbeiten-zusammen.2211746/page-6#post-29822843

Wir wissen im Endeffekt gar nichts, nur die Anbieter der Sicherheitssoftware, die mit Microsoft gesprochen haben, werden wissen, was kann und sein wird.
Zumal Microsoft sich mit der Schließung des Kernels auch sich selber ins Fleisch schneiden würde, denn der Defender müsste dann ebenfalls wieder aus dem Kernel in den User Mode wandern.

Da wurde einfach wieder viel reininterpretiert von den Medien und entsprechend Clickbait betrieben (auf den ich leider auch reingefallen bin).
 
  • Gefällt mir
Reaktionen: Alexander2
mike78sbg schrieb:
Ich fänds lustig, wenn in Zukunft x86 Windows Programme unter Linux on Arm besser laufen, als unter Windows on Arm selbst. 😁
Weshalb in Zukunft? Das ist doch schon lange so.

Z. B. habe ich früher MS Works 4.0 (gabs zum HP DeskJet) sehr gerne genutzt, da es keine Zusammenstellung mehrerer Programme war, sondern ein einziges Programm, dass alles kann: Dadurch konnte man auch gleich nach dem ersten Start (der auch deutlich schneller als von MSO war) nahezu sofort zwischen Textverarbeitung und Tabellenkalkulation wechseln (z. B. um eine Tabellenkalkulation in einem Dokument zu erstellen), statt (auf damaligen Rechnern) ewig lange darauf zu warten, dass Excel nachgeladen wurde und vielleicht einen Programmabsturz zu riskieren (Win98).

Dann kam Win XP und MS Works wurde unbenutzbar, wie übrigens auch MSO '97! - Microsoft war wie gewohnt nicht mal zu sich selbst kompatibel. - Wenigstens sind die konsequent…

Vorletztes Jahr habe ich aus einer Laune heraus nach MS Works gesucht und sogar eine Version mit freiem Key gefunden: Geladen, installiert, gestartet: Läuft! - Einfach so, als wäre es das normalste auf der Welt. Was es für Linux offenbar auch ist.

Das ist nur ein Beispiel von vielen.

Absurd, mit was für Problemen sich viele (ausdrücklich nicht alle!) Windows-Nutzer alles herumärgern, aber gleichzeitig lästern, Linux wäre kompliziert. - Im Verdrängen und sich schön reden, sind die offenbar Spitzenklasse. Anders kann ich mir das nicht erklären.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Caramon2 schrieb:
Dann kam Win XP und MS Works wurde unbenutzbar, wie übrigens auch MSO '97! - Microsoft war wie gewohnt nicht mal zu sich selbst kompatibel.
Du weißt aber schon, dass WinXP auf dem NT-Zweig basiert?
Der Consumer-Zweig hatte mit WinME sein Millennium & war dann tot.
 
Tanzmusikus schrieb:
Oder meinst Du speziell Battle.Net?
Speziell nur beim B.Net Client. In Spielen selbst war bisher nichts zu merken, dass eine der beiden Varianten "besser" ist als die andere.
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Caramon2 schrieb:
Weshalb in Zukunft? Das ist doch schon lange so.
Ich red aber von ARM CPUs, nicht von x86.

Da gabs bisher keine Möglichkeit von x86 auf ARM Cous unter Linux auszuführen. Bis jetzt, wie es scheint.
 
Tanzmusikus schrieb:
Du weißt aber schon, dass WinXP auf dem NT-Zweig basiert?
Der Consumer-Zweig hatte mit WinME sein Millennium & war dann tot.
Was hat in dem Zusammenhang das eine mit dem anderen zu tun? Andere Programme laufen doch auch auf beiden Zweigen.

mike78sbg schrieb:
Ich red aber von ARM CPUs, nicht von x86.

Da gabs bisher keine Möglichkeit von x86 auf ARM Cous unter Linux auszuführen. Bis jetzt, wie es scheint.
Ach so hattest du das gemeint. Damit habe ich mich mangels Bedarf noch nicht beschäftigt.

Btw:

Die in den Wine-Einstellungen eingestellte Windows-Version ist übrigens eher kosmetisch. - Z. B. nutze ich manchmal noch XMedia-Recode, was mindestens Windows 7 braucht, aber offenbar nicht auf die Windows-Version prüft, sondern ob die benötigten Funktionen bereitgestellt werden: Sogar wenn ich Wine auf "Windows 2" einstelle, startet XMR und lässt sich uneingeschränkt nutzen.

Das ist wie beim Identifikationsstring des Browsers: Z. B. dass man Vivaldi auf "Google-Chrome" einstellen, weil dann weniger Seiten Probleme machen.
Ergänzung ()

Alexander2 schrieb:
Damit kann man zumindest auf ein eigenes Scripten verzichten :D
Aber das scripten selbst kann ja auch spaß machen das umzusetzen. vorallem dann die Kiste sich selbst melden zu lassen am Ende.
Wenn ich es selbst mache, weiß ich wenigstens dass es so funktioniert, wie ich es möchte. - Oder wenn nicht, kann ich es korrigieren und habe wieder etwas gelernt.

Btrfs habe ich eine Weile als normales Dateisystem genutzt (also ohne diesen @-Kram, der Fehler provoziert, weil man im laufenden System nichts davon sieht: Wenn man das beim Wiederherstellen "im Eifer des Gefächts" nicht beachtet, zerschießt man sich das System) und auch keine Snapshots/Subvolumes, weil sich die nicht als solche sichern lassen: Nach der Wiederherstellung sind das normale Verzeichnisse.

Deshalb nitze ich Hardlinks: Die funktionieren mit jedem geläufigen Dateisysten (einschließlich NTFS) und Tools wie rsync oder tar hat keine Probleme Hardlinks als solche zu sichern und wiederherzustellen.

Spontaneous schrieb:
Solange wie die Gamingleistung in Linux einfach nicht stimmt gegenüber Windows, bleiben die Benutzer bei Windows.
Ich verstehe nicht, weshalb ein OS alles können muss: Ich würde auf meinem Produktivsystem, mit wichtigen und sensiblen Daten überhaupt keine Spiele mit ihren Anti-Cheat-Rootkits usw. haben wollen!
 
Zuletzt bearbeitet:
Alexander2 schrieb:
Ist das tatsächlich so? das ne CPU Emulation/VM für arm ganz neu ist?
Also mir wärs bisher nicht bekannt, dass man Windows Code unter Linux direkt auf ARM ausgeführt werden kann.

Und im Endeffekt macht Wine ja nix anderes. Windows-API-Aufrufe werden in Echtzeit zu entsprechenden POSIX-Aufrufen übersetzt.
Nun kommt noch eine zusätzliche Übersetzung (Emulation) von x86 auf ARM CPUs dazu, laut dem Artikel.
Viel Arbeit an Wine 10 ist auch in die Umsetzung der ARM64-Architektur geflossen.Dabei wird der Wine-Code selbst nativ ausgeführt, während die nötige x86-Emulation von Drittsoftware über ein Interface erfolgt.

Falls es das schon in irgendeiner Form gibt, würde mich interessieren obs dazu mehr Infos gibt. Ich kenne jedenfalls nichts.
 
  • Gefällt mir
Reaktionen: floTTes
Hier wird angedeutet, dass es nicht ganz neu ist, das dort "verbessert" steht:
https://www.linux-magazin.de/news/wine-10-0-verbessert-arm-und-direct3d-unterstuetzung/

Hier ist der momentane Stand von Wine10 zu sehen:
https://gitlab.winehq.org/wine/wine/-/wikis/ARM64

Als Emulator wird FEX empfohlen.


Man könnte mal nach den bereits vorhanden Linux-Distros mit ARM-Support schauen, ob dort WINE 9.x für Windows/x86-Programme nutzbar ist. Dies wäre dann ein Indiz, dass es früher auch schon mit "Wine4Arm" ging.
 
So 4 Jahre schienen zumindest 2 der Projekte da zu sein. ab wann die Benutzbar waren kann ich nciht beurteilen. Jetzt laufen sogar Spiele
(FEX Box64 Box86)
 
Zurück
Oben