Notiz Spielen unter Linux: Wine 6.0 ist fertig

@Grumpy Ich weiß schon was das ist. Wie willst du jemanden erkennen der schlichtweg verheimlicht, dass er Windows Code gesehen hat? Verhalten frei nach zu bauen oder Verhalten nachzubauen mit dem Wissen des Quellcodes ist an sich nichts anderes, es ist im ersten Fall nur deutlich schwieriger und, und da wird es für Wine wichtig, selbstverständlich wesentlich einfacher in rechtliche Probleme zu geraten, weil angeblich kopiert wurde. Da wird eben einfach direkt ein Riegel vorgeschoben.
 
@DaysShadow Ich frage mich gerade was der Sinn dieser Diskussion ist?! Jemand fragte ob es nicht einfach möglich ist den geleakten Windows XP Quellcode für die Entwicklung von Wine zu verwenden. Wine hat diesbezüglich klare Regeln aufgestellt die das verwenden dieses Quellcodes verbieten (und sogar noch weiter geht). Möchtest du mit mir nun einen Regelbruch diskutieren? Wie gesagt, Wine ist da sehr klar. Die ganzen Jahre lang hat Wine nur Verhalten nachgebaut ohne den Quellcode zu benutzen (Außer öffentliche APIs, was ja erlaubt ist). Das ist auch der Grund warum es ewig dauert Wine in einen Status zu bekommen, der eine stabile Plattform bietet. Mir fehlt da jetzt wirklich der Sinn der Diskussion. Es ist bereits alles gesagt. Die Regeln sind klar und die Ausgangsfrage ist auch klar mit Nein beantwortet.
 
  • Gefällt mir
Reaktionen: ###Zaunpfahl###
Grumpy schrieb:
Wenn du möchtest, dass Wine Klagen am Hals hat und eventuell am Ende das Projekt ganz einstellen muss, dann würde ich mit deiner Empfehlung fortfahren.

Nur weil etwas (illegal) geleaked ist, heißt das noch laaaange nicht dass man es einfach benutzen darf. Das sollte eigentlich jedem klar sein. Wine benutzt eben keinen Windows Quellcode und es ist in den contributions-Regeln absolut verboten diese zu verwenden außer es ist ausdrücklich von Microsoft erlaubt.

Siehe dazu: Wine Developer FAQ



Zumal ich mir sicher bin, dass der Quellcode sowieso nur beginnt bei der Entwicklung hilft.
Es geht ja nicht darum, dass sie den Code 1zu1 übernehmen, sondern sich von diesem "inspirieren" lassen.
Sind die Funktionen umgeschrieben und von der Struktur her anders aufgebaut, wird es rechtlich alles andere als einfach sein da etwas jemandem nachzuweisen.
"Wine Pro" als Closed Source Edition wäre doch auch mal ne Idee, so ganz am Rande *hust.

PS: 'Mit Verwendung' war meinerseits auch eher "Unter Beachtung des MS Codes" als Hilfe gemeint, wie von DaysShadow auch richtig verstanden. Von Copy-Paste war doch nie die Rede, lol. Das ist jedem auch so klar.
 
Zuletzt bearbeitet:
###Zaunpfahl### schrieb:
Ein konservativeres Manjaro würde ich mir noch wünschen. Das wär geil.
Ich habe nur Erfahrung mit wine da ich Adventure Spieler bin und daher vor allem directx9 benötige. Aber das einzige System bei dem wine einfach so funktioniert war bei mir Opensuse leaf. Das wäre also so ein Manjaro. Allerdings steht hinter Suse die deutsche Wirtschaft und die brauchen keine Lücken in ihren Systemen und es ist viel mehr als doppelt so sicher wie jedes andere Linux und das ist keine Übertreibung.

Allerdings benötigt man immer mal wieder eine besondere dll von winetricks für die spiele, die man hier nahsehen kann:
https://appdb.winehq.org/objectManager.php?sClass=application&sTitle=Browse Applications&sOrderBy=appName&bAscending=true

und opensuse installiert bereits sein eigenes mono, also bricht man das was wine bei erststart installieren will ab.

Und mal zu valve, also wine schaffte seit langem directx 9 komplett und directx 10 und 11 bereits teilweise. Und erst als wine so weit und klar war das wine bald alles schaffen kann war valve bereit proton zu machen.
 
Zuletzt bearbeitet:
Rejin schrieb:
Es geht ja nicht darum, dass sie den Code 1zu1 übernehmen, sondern sich von diesem "inspirieren" lassen.
Sind die Funktionen umgeschrieben und von der Struktur her anders aufgebaut, wird es rechtlich alles andere als einfach sein da etwas jemandem nachzuweisen.
"Wine Pro" als Closed Source Edition wäre doch auch mal ne Idee, so ganz am Rande *hust.

PS: 'Mit Verwendung' war meinerseits auch eher "Unter Beachtung des MS Codes" als Hilfe gemeint, wie von DaysShadow auch richtig verstanden. Von Copy-Paste war doch nie die Rede, lol. Das ist jedem auch so klar.
Und wie genau willst du das mit der Regel
Some people cannot contribute to Wine because of potential copyright violation. This would be anyone who has seen Microsoft Windows source code (stolen, under an NDA, disassembled, or otherwise).
in Einklang bringen? Auch "Inspirieren lassen" ist nicht erlaubt. Nochmal: "[...] This would be anyone who has seen Microsoft Windows source code (stolen, under an NDA, disassembled, or otherwise) [...]". Ich weiß nicht wie das noch klarer formuliert werden kann ...
 
AlBas schrieb:
Allerdings steht hinter Suse die deutsche Wirtschaft und die brauchen keine Lücken in ihren Systemen und es ist viel mehr als doppelt so sicher wie jedes andere Linux und das ist keine Übertreibung.
Die Sicherheit hat wohl niemand nachgefragt.. oder? Wenn du das sagst dann ist das bestimmt so... 😅

Ja OpenSuse ist schon nicht schlecht, aber da hatte ich auch Probleme mit btrfs ob das an irgendwie doch an der Hardware lag kann ich nicht zu 100% ausschließen, ka was da schief lief.
OpenSuse setzt aber auf RPM was ein großes Manko damals zu mindestens war, da es für Anwender auf jedenfall viel weniger Pakete gibt / gab.
Erst als ich zu Manjaro gewechselt bin und der Nvidia Treiber noch schlechter war wie jetzt hab ich Intel / Nvidia richtig hinbekommen ohne Handstand.
Bezüglich den ganzen Laptop zum laufen zu bekommen war Manjaro einfach viel besser als OpenSuse und Software auch.
Ich glaube das da eher MXLinux in die Richtung geht. Werde ich irgendwann mal ausprobieren und mit Debian 11 als unterlage sollte das Ding dann auch mit 3 Jahre alter Hardware gut zurechtkommen.
Wobei ich Linux bedingt eh bald komplett auf AMD wechseln wollte, aber USB4 braucht wohl noch ne weile... das brauch ich für mein Thunderbolt3 Dock....
 
###Zaunpfahl### schrieb:
ch auch Probleme mit btrfs
das ist eigentlich unmöglich, das von suse seit jahren optimierte btrfs läuft ohne fehler wie ext2, also nicht so wie ext4. In anderen Systemen läuft es allerdings angeblich nicht so gut, möglicherweise hattest du es ja dort und dachtest es wäre opensuse gewesen, weil man dort btrfs seit Jahren als Standart nimmt?

Ausser natürlich du hattest eben einen Hardwarefehler denn im gegensatz zu den anderen systemen wird bei btrfs nicht einfach über die ersten noch korrigierbaren lesefehler hinweggegangen, so das man normalerweise nicht pötzlich mit defekten Daten dasteht und rechtzeitig auf eine neue Platte umsteigen kann.
 
Zuletzt bearbeitet:
@Grumpy Naja meint eben einfach mal gucken weil es eh schwierig wird nachzuweisen das jemand geguckt hat.

@Rejin
So einfach ist das am Ende aber vermutlich nicht. Wenn dann aber jemand fragt "wie haben Sie das denn so Reverse Engeneeren können?" und man dann ins stottern kommt hat man ein Problem.
Ich weiß es nicht! aber außerdem könnte ich mir vorstellen das die bei Wine wenn sie etwas reverse engineering jeden Schritt dokumentieren sodass Ihnen niemand was vorwerfen kann.

Das einzige was ich mir vorstellen könnte, das man evtl. mal reinguckt wenn man beim revers engineering nicht weiterkommt. Was nicht erlaubt aber sehr schwer nachweisbar wäre.

Aber wie schon gesagt ist das eigentlich eine sinnlose Diskussion. Wir wissen es nicht und hoffen es auch nie erfahren zu werden :).
Ergänzung ()

@AlBas war wahrscheinlich nicht böse gemeint. Aber nicht zu wissen was für ne Distro ich installiert habe... das empfinde ich schon ein wenig beleidigend :heul:

Es war 100% OpenSuse Leap mit btrfs und ich hab auch snapper benutzt. Ich weiß nicht mehr wie es genau war aber es startete nicht mehr und mit ein paar Kommandos hab ich dann btrfs anscheinend noch verschlimmbessert. Bin mir aber ziemlich sicher das ich nichts komisches gemacht habe. Ich bastel normalerweise nicht rum wenn alles läuft und wieso sollte ich an btrfs rumbasteln, das wichtigste für mich ist am Ende das das Ding läuft und Daten speichert.
Ergänzung ()

@AlBas Bist du eigentlich Mitarbeiter bei OpenSuse oder wieso ist es anscheinend das beste der Welt? Woher weißt du denn das es "unmöglich" ist und so dermaßen "sicher"? Hat das auch Hintergründe oder ist das einfach nur deine Meinung?
 
Zuletzt bearbeitet:
@Grumpy
Deiner Fußnote nach zu beurteilen scheinst du ein großer Freund von Juristik zu sein. Derartige Basics in Sachen Mediengesetze sollten jedermann allg. bekannt sein. Ich hoffe du gehörst nicht zu jenen, der seine eigenen Mitschüler bei dem Lehrer verpetzte, nachdem du diese beim spicken bemerkt hast.. ;)
Nichts anderes wäre es nämlich, wenn man sich am Original orientiert, dabei jedoch seine eigene Lösung entwickelt. Dennoch hast du vermutlich ja recht.

@###Zaunpfahl###
Ich glaube rechtlich gesehen bist du keinem eine Antwort schuldig. Gesetzlich muss deine Schuld bewiesen werden. Nachzuweisen, dass jemand sich etwas angeschaut hat was er nicht sehen sollte ist bereits als Gedanke der absolute Hohn. Niemand wird das jemals können. Der gute Geist hat dir die Lösung im Schlaf zugeflüstert. Du hast rumprobiert und bist zufällig auf die einzig wahre Lösung gekommen, welche zwar nicht 1zu1 mit der von MS übereinstimmt, jedoch "scheinbar" genauso funktioniert. Bist selber völlig überrascht wie es dir so gut gelingen konnte. Versuche mal das Gegenteil zu beweisen.

Eine 1zu1 Kopie wird einem ja so und so nicht gelingen, weil unter Linux zwangsläufig andere Bibliotheken verwendet werden. Ob sinnlos oder nicht, wäre doch einfach mal interessant zu erfahren ob es so theoretisch möglich wäre.

Die Unity-Engine wurde z.B. plötzlich auch grafisch deutlich aufgewertet, kurze Zeit später nachdem UE4 als OpenSource freigegeben wurde. Zufall? - Vielleicht.

Einfach mal die künftigen Computerspiele durchgehend auf Vulkan umstellen, exklusiv auf Linux deployen und schon wird sich Microsoft wünschen es gebe jemanden der den proprietären DirectX Mist auf Linux portiert.
 
Wine ist ne geile Sache.
Aber ich finde es extrem umständlich, dass man für bestimmte Software Winetricks-Addon braucht und zwar verschiedene, die sich auch gegenseitig behindern können.
Wieso macht Wine es den Usern nicht einfacher bestimmte Programme mit bestimmten Winetricks zu starten?

Wegen dieser Problematik braucht man so Sachen wie PlayOnLinux, Lutris oder Proton.
Wieso kann man das nicht schon einbauen? Das würde es einfacher machen.
 
Es sieht so aus als wären das MS Komponenten die in Wine noch nicht ausreichend nachgebaut wurden und deswegen heruntergeladen und installliert werden.
Da würde ich sagen: Es muss sich wie immer ein Programmierer finden der sich dessen annimmt, wie bei allen anderen fehlenden und fehlerhaften Funktionen auch.
 
Ich bin zwar kein Programmierer, aber ich denke dlls sind Brücken zwischen zwei Befehlen und sind somit eben nicht anders als original schaffbar. Sie lenken von einem Aufruf auf den anderen um. Das weiss ich allerdings nicht, muss aber so sein da es sonst längst anders nachgebildet würde.
 
AlBas schrieb:
Ich bin zwar kein Programmierer, aber ich denke dlls sind Brücken zwischen zwei Befehlen und sind somit eben nicht anders als original schaffbar. Sie lenken von einem Aufruf auf den anderen um. Das weiss ich allerdings nicht, muss aber so sein da es sonst längst anders nachgebildet würde.
Eine DLL ist keine Brücke zwischen irgendwelchen Befehlen sondern eine Bibliothek mit einer Ansammlung von Funktionen welche von dem Programm zur Laufzeit, dynamisch, abgerufen werden können.
Mit Headern als Funktionsdeklarationen (interfaces) und den Source-Dateien selbst.
Je komplexer die Funktionalität des Programms (und Windows ist sehr komplex) desto mehr Variationen gibt es um diese Funktionalität nachzubilden.
Reverse engineering macht genau das. Die Nachbildung muss zum Original deterministisch ablaufen. Tut sie dies nicht, läuft das Programm fehlerhaft oder stürzt komplett ab. Deshalb führt Wine auch eigene Kompatibilitätslisten zu einzelnen Programmen und Spielen.

Allein für ein Programm zum Auffinden eines Pixels mit einer bestimmten Farbe in einem Bild hätte ich schon 10 vers. Lösungen parat, welche zwar unterschiedlich zu implementiert wären, jedoch immer dasselbe Ergebnis liefern würden.
Kurzum: Wenn du genau weißt, wie ein Programm funktioniert, kannst du eine eigenständige und 100% kompatible Nachbildung gewährleisten.
 
  • Gefällt mir
Reaktionen: Deinorius, MicroStream, Tanzmusikus und eine weitere Person
Die dlls müssen aber eine so kurze und knappe varrierung zwischen ein und ausgang sein, daß man um das selbe ergebnis zu erreichen eben doch nur nachbauen könnte. Ausser man würde es monströs verändern mit viel mehr arbeitsschritten um von hinten ans Auge zu kommen. Sonst hätte man die dll funktionalität stück für stück in wine eingebaut.
 
@AlBas Du schreibst doch, dass du keine Ahnung vom Programmieren hast. @Rejin hat dir erklärt was eine DLL ist. Was du schreibst ist schlichtweg Unsinn, also hör doch bitte auf mit irgendwelchen Mutmaßungen und lies dich bei Bedarf in die Thematik ein.

Die Aufgabe beim Nachbau der DLLs besteht darin die Funktionen darin zu (er)kennen sowie deren Eingaben und Ausgaben. Kennt man Ein- und Ausgabe Paare kann man, potenziell, den Code dazu schreiben und dabei ist es für das Ziel vollkommen egal wie kurz oder lang dieser Code wird. Dem Programm das diese DLL nutzt ist es nämlich vollkommen egal was in der nachgebauten Funktion genau passiert, solange bei einer bestimmten Eingabe das zurück kommt was erwartet wird oder etwas womit das Programm umgehen kann. Ist das nicht der Fall gibt es Fehler, was dafür sorgt, dass etwas z.B. in Wine nicht funktioniert. Das passiert selbst unter Windows, wenn nicht zu einander passende Versionen verwendet werden (Programm erwartet Version X, DLL liegt aber in Version Y vor).
 
Also fakt ist wine integriert nicht die dlls obwohl es wine schafft riesige Aufrufmengen in linux aufrufe umzuwandeln. das muss ja an was anderem als das es noch nicht getan wurde liegen, sondern das dlls sehr knapper code sind, den man einfach nicht ohne massive effizienzverluste anders programmieren kann. Man kann eben nicht Aufrufe von fremd in linux wandeln sondern muss mit der Abfolge die diese dlls vorgeben handeln das sollte es bedeuten als ich schrieb das sie einen aufruf in einen anderen wandeln.

Man könnte es auch anders sagen, das ist ein microsoft Programm das man nur mit effizienzverlusten anders programmieren könnte da nur äusserst knappe Programmabläufe und damit varianzmöglichkeiten innerhalb der dlls vorhanden sind.
 
Hallo! Weiß zufällig jemand, ob es was neues zur Windows 2.x Kompatibilität gibt?

Vor einer Weile las ich was von der Integration von DOSBox, wodurch auch DOS-Programme unterstützt werden sollten. Dadurch gab es aber dann Probleme mit der Erkennung von alten NE Headern (Windows 1.x/2.x) oder so ähnlich.

Im Web habe ich aber nix dazu gefunden. :(
 
Rejin schrieb:
Ob der Leak von dem Windows XP source code dazu beitragen könnte Wine entsprechend zu verbessern..?
:)
Nein, die Entwickler werden einen Teufel tun, sich den Code auch nur anzugucken.
Wenn die dadurch auf zu ähnlichen Code kommen (schwierig, ne eigene Lösung beim "Nachprogrammieren" zu finden wenn man das Original kennt), wird Wine mit Pech erstmal wieder komplett auf Eis gelegt und alles gegengecheckt wegen Copyright.
Also nein, Codeleaks sind sogar schädlich für Projekte wie Wine.
 
Zurück
Oben