Testbericht unter Linux

[derCherusker]

Wine egal, ob frisch installiert oder geupdated, immer diese Fehlermeldung. Bei Nobara, Garuda und Manjaro. Bald geht der Rechner durchs geschlossene Fenster, dann erstmal anderes Hobby...
Ich habe wine 8.17. Ich weiss nicht wie ich 8.19 installiere. Muss warscheinlich mein system upgraden. Das versuche ich morgen mal. Jetzt installiere ich erstmal versuchsweise die 32bit Version. Dann lädt das Ding halt etwas länger. Hauptsache es ruckelt nicht... und wenn dann versuche ich die Installation morgen vom geupgradeten Nobara. Da müsste ja 8.19 drin sein. Nobara hat übrigens wine-staging... Hab auchjmal die wine-devel version probiert, damit ich das neuste kriege. Wie kann ich unter wine denn wine-proton auswählen?? Wäre vielleicht auch ne Lösung.

[derCherusker]

Muss ich die alten dotnet Versionen wie 3.0 vom Stick vielleicht auch installieren? Mir schwant eine riesen Dummheit.... Ich dachte bis jetzt 6.0 vom Webinstaller reicht...

[derCherusker]

Vielleich tut mir jemand den riesen Gefallen und macht mir eine Schritt für Schritt Liste, was ich nach einer wieder mal neuen Nobara Installation machen soll. Wie, was mit wine, was ich wann installieren soll. Also nicht wie ich den Webinstaller starte, das weiss ich. Habe ich ja schon mehr als 10 mal gemacht. Ich hab mich fast totgesucht im Netz. Wie erstelle und benutze ich denn ein Präfix für Wine? Das erschliesst sich mir noch nicht. Jedenfalls nicht ohne Winetricks. Das möchte ich nicht haben, wenn es geht. So wenig Software wie nötig!
Ich kriege schon schlechte Laune wenn ich meinen Rechner nur sehe. Sonst klappt doch auch alles. Auch mit Workaround hier und da, aber es klappt! Witcher3, Enderal, Nehrim, GTA x-Y, Rise of the Tomb Raider, Skyrim, Oblivion, Fallout x-Y. Alles läuft. Allerdings unter Steam. Habe leider die Stick Version. Ich war da damals so scharf drauf... bin es immer noch. Unter Windoof null Problemo. Wie kann ich zum Beispiel so installieren, das er wine mit Proton nimmt?
Vielleicht hab ich auch die falsche Distru für Zusi... wer hat denn gute Erfahrungen mit welcher? Dann installiere ich mir n zweites Linux dazu... eins wo gleich die richtige wine Version dabei ist. Aber warum brauche ich denn 8.19? Zusi läuft doch schon ein paar wine Versionen länger auf Linux... bei anderen jedenfalls.
Naja vielleicht klappts ja mit nem anderen Linux. Das benutz ich dann nur für Zusi.
Ich hab Nobara 38 mit KDE. Basiert auf Fedora! Was würdet ihr empfehlen? Wo ist das richtige wine sofort dabei? Ein Linux welches ich aufsetze, Update, Zusi installieren und ZD, und dann Zusi 64 starte. Muss ich nur dotnet 6.0 aus dem zusi0001 Ordner installieren oder dann auch erstmal die alten vom Stick? Brauche ich die directX Redistrutables auch? Weil der Installer danach nicht fragt.

Wenn ich ZD unter wine starte kommt jetzt folgendes:

02c:fixme:winediag:LdrInitializeThunk wine-staging 8.17 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0114:fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime"): stub
0114:fixme:advapi:ReportEventW (CAFE4242,0x0001,0x0000,0x000003ff,00000000,0x0001,0x00000000,005FFE20,00000000): stub
0114:err:eventlog:ReportEventW L"Description: A .NET application failed.\n"
0114:err:eventlog:ReportEventW L"Application: ZusiDisplay.exe\n"
0114:err:eventlog:ReportEventW L"Path: C:\\Program Files (x86)\\Zusi3\\_Tools\\ZusiDisplay\\ZusiDisplay.exe\n"
0114:err:eventlog:ReportEventW L"Message: Failed to load the dll from [Z:\\usr\\lib64\\dotnet\\host\\fxr\\6.0.23\\hostfxr.dll], HRESULT: 0x800700C1\n"
0114:err:eventlog:ReportEventW L"The library hostfxr.dll was found, but loading it from Z:\\usr\\lib64\\dotnet\\host\\fxr\\6.0.23\\hostfxr.dll failed\n"
0114:err:eventlog:ReportEventW L" - Installing .NET prerequisites might help resolve this problem.\n"
0114:err:eventlog:ReportEventW L" https://go.microsoft.com/fwlink/?linkid=798306\n"
0114:err:eventlog:ReportEventW L"\n"
0114:fixme:advapi:DeregisterEventSource (CAFE4242) stub

[Flo Zille]

Ohje, wenn die Stimmung schon so leidet, wäre vielleicht einfach zwischendurch ein Windows-Boot zu empfehlen, dort läuft Zusi ja. So hab ich es jedenfalls immer gemacht, wenn beim Basteln an Wine Frust aufkam, und manche Fehler wollten sich wirklich erst nach vielen Wochen finden lassen.

Ich hab jetzt den Verdacht, dass es bei dir einfach an der alten wine-devel Version liegt. Erst ab wine 8.19 können 64-Bit-dotnet-6-Programme fehlerfrei ausgeführt werden. Davor war das nur mit wine-staging und Proton möglich, weil bis wine 8.18 noch dieser Bug in wine vorhanden war – und alle Leute, die hier 64 Bit-ZusiDisplay mit Wine genutzt haben, werden das wohl mittels wine-staging oder Proton oder einer wine-Version ab 8.19 getan haben. Es kann sein, dass mit der alten Version auch der dotnet-Installer nicht richtig funktioniert, weiß nicht mehr genau. Proton-Wine lässt sich glaub ich sinnvoll nur mit Steam nutzen, es gäbe höchstens noch inoffizielle Veröffentlichungen irgendwelcher Leute, die so ähnlich sein sollen wie das wine in Proton. Aber das erscheint mir eher unnötig.

Zu deinen anderen Fragen: Ein Wine-Präfix ist einfach das Verzeichnis, in dem Wine z.B. die Inhalte des Laufwerks "C:\" für die genutzten Windows-Programme speichert. Befindet sich normalerweise unter in deinem homedir unter ~/.wine/. Man kann aber per Start mit "WINEPREFIX=/anderer/pfad/zum/prefix/ wine programm.exe" einen anderen Präfix-Pfad festlegen (muss man dann aber bei jedem Start von wine wieder neu angeben). Wine legt automatisch einen neuen Präfix an, wenn keiner an der erwarteten Stelle existiert. Wenn man den Verdacht hat, dass der Präfix irgendwie verbastelt ist, kann man ihn also einfach löschen oder per WINEPREFIX-Umgebungsvariable einen neuen festlegen und den alten erstmal "ruhen lassen". Wenn man in dem Präfix mit einem Windows-Programm aber z.B. was unter C:\ installiert oder abgespeichert hatte (auch savegames usw.) ist das dann natürlich weg.

Distro dürfte relativ egal sein. Wichtig ist eben die wine-Version. Ich nutze Ubuntu (short-term-support versionen), weil ich das schon seit 17 Jahren so mache (ist aber nicht unbedingt empfehlenswert, ich werfe inzwischen immer snapd raus und besorge mir Firefox aus anderen Quellen, denn snapd führt zu langsamen Programmstarts). Wie dem auch sei, es gibt hier offizielle aktuelle Wine-Versionen (und auch aktuelle Wine-Staging-Versionen) per Repository für Ubuntu (und offenbar Mint), Debian und Fedora. Eine davon wäre vielleicht gut, damit du diese Quellen nutzen kannst. Aber vielleicht gibt es ja auch eine Möglichkeit, für Nobara eine aktuelle wine-Version zu erhalten, das wäre dann auch ein guter Ansatz.

Es ist eben so, dass Zusi im Vergleich zu anderen Spielen doch deutlich mehr "Betriebssystemfunktionen" nutzt. Also es wird nicht nur DirectX und ein wenig Sound und Joystick gemacht und das wars. Mit ZusiDisplay zusammen hat man z.B. ein richtiges Client/Server-System, und dann auch noch teilweise mit Named Pipes, teilweise mit TCP. Und Zusi geht teilweise auch doch stärker an die Grenzen des Systems als andere Spiele, z.B. ist es wohl eher unüblich, dass so viele DirectSound-Soundpuffer gleichzeitig abgespielt werden wie in Zusi (einer pro Schienenfahrzeug mit Sound – auch stehende Schienenfahrzeuge – in der Nähe der Kamera, was in Güterbahnhöfen extrem dreistellig werden kann – und unter wine bis vor ein paar Jahren eben das ganze Spiel zum kompletten Einfrieren gebracht hat, und vorher schon zum zunehmendem Ruckeln und echt mieser Performance) oder scheinen auch andere Spiele üblicherweise nicht so viele Drawcalls pro Frame bzw. in kurzer zeitlicher Abfolge wie Zusi in manchen Gegenden zu nutzen, was dann in Kombination mit dxvk und einem unscheinbaren Bug in der Vulkan-Implementierung für AMD in Mesa zu "verschwindenden" Objekten geführt hat. Und dazu kommt noch, dass keine weitverbreitete Engine von der Stange genutzt wird, sondern alles selbst gebaut ist – und das eben manchmal auf etwas andere Art, die dann noch nie jemand in wine getestet hatte. Also so gesehen ist Zusi eben ein ziemlich ungewöhnliches Spiel und daher ist es kein Wunder, dass es immer mal wieder wine-Probleme gibt.

Edit: Falls du dotnet ursprünglich mit wine-devel 8.17 installiert hast, wird die Installation evtl. nicht richtig funktioniert haben und es nutzt jetzt auch nichts mehr, ZD mit wine-staging zu starten. Vielleicht mal den dotnet-Installer in einem "frischen" Präfix (also WINEPREFIX anders setzen) mit wine-staging ausführen und dann ebenfalls mit diesem neuen Präfix ZD versuchen zu starten.
Noch ein Edit: Dein dotnet versucht ja offenbar auch diese hostfxr.dll von Z:\, also von deinem Linux-Dateisystem unter /usr/lib64/dotnet, zu laden. Das erscheint mir etwas seltsam. Diese Dateien habe ich gar nicht, aber möglicherweise bietet Microsoft inzwischen die Installation von dotnet unter Linux an, da war doch mal was? Selbst wenn, ist es wohl nicht so gedacht, dass das windows-dotnet versucht, dlls aus dem Linux-dotnet zu laden.

[mitropam]

Sehr interessant, danke für die ausführlichen Erläuterungen.
Da habe ich ja Glück gehabt, dass ich bei der Installation damals wine-staging gewählt habe. Dieser Hinweis wäre vielleicht für den einen oder anderen etwas früher schon hilfreich gewesen. Nagut, bei mir läuft Zusi jedenfalls derzeit gut (mit wine-8.20 staging).

[derCherusker]

Von mir auch erstmal ein grosses Danke, das wahr sehr Ausführlich erklärt!

Ich habe jetzt rausbekommen, wie ich ne aktuelle Version installiere. Habe das über Fish gemacht(besser als Bash, mit automatischen Textvorschlägen und in Farbe und bunt ;-) ) Danach ht er auch im grafischen Update 8.20 Staging installiert. Vorher unter Terminal hatte ich schon auf 8.19 geupdated. Dann habe ich unter root/dotnet erstmal alles gelöscht. Habe mich vorher davon überzeugt, das es alles erstellt wurde als ich von Zusi dotnet versucht habe zu installieren. Meine Steamspiele laufen jedenfalls noch, auch ohne dotnet neu holen zu wollen .
Jetzt noch ein Systemupdate, ein A,E,I paffen..., "O paffte die Raupe", und dann hoffentlich morgen früh gute Nachrichten.

Update: Er hat nach dem Hochfahren artig ein neues dotnet in den Ordner geschieben. Gutes Zeichen. 6.0.24. Jetzt den Webinstaller starten und dann die dotnet Sachen. Mach ich die vorm eigentlichen zusi installieren oder danach? Da mich der Installer davor fragt, mal davor. Vom Installer kann ichs ja nicht installieren, da macht er einfach ein neues Fenster auf. Das muss ich überspringen.

Wenn das wieder nicht klappt, wie stelle ich denn um, das er sich die dotnet Dateien aus dem richtigen Verzeichnis holt, nicht von Z:? Ja, dotnet kann man einfach von Microsoft runterladen und installieren. Hab aber wie gesagt mal alles aus dem lib64 Ordner runtergeschmissen.

[derCherusker]

Und wieder die gleiche Scheiße. Ich gewöhne mich langsam an dieses Fenster. Vielleicht lad ichs ja mal zum Essen ein.
Dotnet wäre nicht installiert. Warum zeigt das gottverdammte Ding denn auf Z: und nicht irgendwo hin, wo die blöde Dotnetscheiße ist?
Das ist der einzige Grund warum nix läuft. Zusi hatte schon ohne dotnet funktioniert, mit der scheiß Abfrage. Ohne Zugdatenfenster, es läuft wie geschmiert. Warum i mmer Z:???? Warum legt das Dingens nich das dahin wo es hin soll?

[dave@hal9000 ZusiDisplay]$ wine ZusiDisplay.64.exe
002c:fixme:winediag:loader_init wine-staging 8.20 is a testing version containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0088:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0114:fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime"): stub
0114:fixme:advapi:ReportEventW (00000000CAFE4242,0x0001,0x0000,0x000003ff,0000000000000000,0x0001,0x00000000,00007FFFFE27FDD0,0000000000000000): stub
0114:err:eventlog:ReportEventW L"Description: A .NET application failed.\n"
0114:err:eventlog:ReportEventW L"Application: ZusiDisplay.64.exe\n"
0114:err:eventlog:ReportEventW L"Path: C:\\Program Files\\Zusi3\\_Tools\\ZusiDisplay\\ZusiDisplay.64.exe\n"
0114:err:eventlog:ReportEventW L"Message: A fatal error occurred, the required library hostfxr.dll could not be found in [Z:\\usr\\lib64\\dotnet\\host\\fxr\\6.0.24]\n"
0114:err:eventlog:ReportEventW L"\n"
0114:fixme:advapi:DeregisterEventSource (00000000CAFE4242) stub
[dave@hal9000 ZusiDisplay]$

[derCherusker]

So. Fenito la musica! Hab mir grad einen win10 Key geholt. Warum vorher nicht? Weil ich nicht wusste wie günstig einer sein kann.
Deswegen ist das Thema für mich ad acta. Ich installiere jetzt Windoof. Nur für Zusi. Linux benutze ich weiter. Da bin ich mitlerweile um einiges Fitter. Des weiteren mag ich den Umgang mehr. Man lernt viel und kann FAST alles problemlos irgendwann, irgendwie einstellen. Hat auch ne kreativere Atmosphäre. Naja es gibt unzählig viele Vorzüge. Toll das dafür so viele kreative Köpfe rauchen. Und dann nur für ne Aufwandsentschädigung. Find ich allgemein ne gute Sache. Is ja hier bei Zusi ähnlich. Hier wird auch sehr Geduldig geholfen, auch wenn der Häuptling manchmal etwas harsch ist. Gibt aber auch wesentlich schlimmere Charakterzüge als Direktheit.

[Wasabi9495]

Hab seit dem letzten Zusi Update das Problem, dass bei mir bei Fahrzeugen mit Displaz Anzeigen, das MTD und EBuLa Bordgerät schwarz bleibt, das MFD hingegen bleibt hingegen gewohnt funktionsfähig.

dotnetcoredesktop3 und gdiplus sind installiert. Hat jmd. zufällig den gleichen Fehler?

[F. Schn.]

ZusiDisplay wie der Buchfahrplan verwenden .Net 6.0. .Net Core ist für Zusi inzwischen Obsolett. (Aber k.A. ob das darauf eine Auswirkung hat.)

[Flo Zille]

Hab seit dem letzten Zusi Update das Problem, dass bei mir bei Fahrzeugen mit Displaz Anzeigen, das MTD und EBuLa Bordgerät schwarz bleibt, das MFD hingegen bleibt hingegen gewohnt funktionsfähig.

Ja, ich hatte ein ähnliches Problem gestern beim 423 (S-Bahn von Au(Sieg) nach Siegburg/Bonn) und dem 648 (82953_82356 im "Hildesheim-Hameln 2020"-Fahrplan). Das EBuLa blieb schwarz, MTD hat aber funktioniert (das Display links mit FIS etc. ist doch das MTD?).

Ich nutze Proton 8, wenn ich mich richtig erinnere auch ohne irgendwelche Änderungen. Also nur "bei Zusi mitgeliefertes dotnet" und die bei Proton mitgelieferte gdiplus von wine. Bin aber nicht mehr 100% sicher ob ich nicht doch mal irgendwas gebastelt hatte. Ich werde mal die ZusiDisplay-Logs aktivieren und sehen, ob da irgendwas erhellendes drin steht.

Edit: So richtig aufschlussreich ist es nicht. In der buchfahrplan-Logdatei sieht alles in Ordnung aus, glaube ich:

2024-02-23 08:05:47.9527|INFO|EBuLaTools.Utils|Logging wurde aktiviert! ZD-Version:3.5.21
2024-02-23 08:05:50.9365|INFO|MMI.MVB.MVB|Verbinde mit Server (127.0.0.1:41801)...
2024-02-23 08:05:51.1658|INFO|MMI.MVB.MVB|Connected to server
2024-02-23 08:05:51.1863|INFO|EBuLaTools.PipeHelper|SetupTexturePipe. Texturübertragung via TCP
2024-02-23 08:05:51.1910|INFO|EBuLaTools.PipeHelper|Starte PipeHelper Timer
2024-02-23 08:05:51.1964|INFO|MMI.MVB.MVB|Verbindung mit Server hergestellt!
2024-02-23 08:05:51.1964|INFO|EBuLaTools.PipeHelper|RenderLoop() -> Started

Im vermutlich relevanten Teil des master-Logs findet sich immerhin ein Fehler, vielleicht sollten wir mal unter Windows schauen, ob der dort auch auftritt oder ob das nicht vorkommen sollte:

2024-02-23 08:06:00.3885|INFO|SuperNetwork.SuperNetwork|ACK_HELLO korrekt empfagen
2024-02-23 08:06:00.3951|INFO|SuperNetwork.SuperNetwork|SendRequestToZusi3() [826 bytes] -> Pipe
2024-02-23 08:06:00.3962|INFO|SuperNetwork.SuperNetwork|SendRequestToZusi3() -> Pipe -> ok
2024-02-23 08:06:00.6729|INFO|SuperNetwork.SuperNetwork|ACK_NEEDED_DATA korrekt empfangen
2024-02-23 08:06:01.0001|INFO|MMI.EBuLa.EBuLaController|Saving 'Buchfahrplan' with given root path: C:\users\Public\Documents\Zusi3Steam\_Tools\ZusiDisplay
2024-02-23 08:06:01.0093|INFO|MMI.EBuLa.EBuLaController|Existing 'Buchfahrplan'-Path: C:\users\Public\Documents\Zusi3Steam\_Tools\ZusiDisplay\buchfahrplaene\S32332_32349.timetable.xml
2024-02-23 08:06:01.0178|INFO|MMI.EBuLa.EBuLaController|'Buchfahrplan' written!
2024-02-23 08:06:01.0686|ERROR|SuperNetwork.SuperNetwork|Leeres Paket soll intern verteilt werden mit ID '990007'
at System.Environment.get_StackTrace()
at SuperNetwork.SuperNetwork.EnqueueNewPackage(Int32 id, Byte[] buffer, Boolean updateTime)
at SuperNetwork.SuperNetwork.EnqueueNewPackage(Int32 id, Byte[] buffer)
at SuperNetwork.SuperNetwork.HandleZusi3TcpFahrpultNode(Zusi3TcpNode node, Zusi3TcpNode rootNode)
at SuperNetwork.SuperNetwork.HandleZusi3TcpNode(Zusi3TcpNode node)
at SuperNetwork.SuperNetwork.ReadZusi3(Socket s, NamedPipeClientStream p)
at SuperNetwork.SuperNetwork.<SendHelloToZusi>b__86_0()
at System.Threading.Thread.StartHelper.Callback(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.Thread.StartCallback()
2024-02-23 08:06:01.0845|INFO|SuperNetwork.SuperNetwork|Empfange PipeConfig-Paket für LM: ZD_EBuLa(381x236)
2024-02-23 08:06:01.0845|INFO|SuperNetwork.SuperNetwork|Empfange PipeConfig-Paket für LM: ZD_MTD(360x231)
2024-02-23 08:06:01.0866|INFO|MMI.MVBDevice.ZSG|PipeConfigPackage: ZD_EBuLa 381x236 WithoutBackground
2024-02-23 08:06:01.0866|INFO|MMI.MVBDevice.ZSG|PipeConfigPackage: ZD_MTD 360x231 WithoutBackground
2024-02-23 08:06:01.0904|INFO|EBuLaTools.PipeHelper|Pipe Daten für Melder ZD_EBuLa
2024-02-23 08:06:01.0904|INFO|EBuLaTools.PipeHelper|Pipe Daten für Melder ZD_MTD
2024-02-23 08:06:01.0904|INFO|EBuLaTools.PipeHelper|Setze Fenstergröße für PipeMode auf 360x231
2024-02-23 08:06:01.0904|INFO|EBuLaTools.PipeHelper|Setze Texturgröße für PipeMode auf 512x256

Könnte sich um das gleiche Problem handeln, das bisher nur bei manchen ICEs aufgetreten ist. Ganz gelegentlich hatten glaube ich auch Windows-Nutzer über dunkle Displays geklagt, das könnte aber natürlich auch andere Ursachen haben (Firewallsoftware oder Virenschutz oder so).

[F. Schn.]

ZusiDisplay wie der Buchfahrplan verwenden .Net 6.0. .Net Core ist für Zusi inzwischen Obsolett. (Aber k.A. ob das darauf eine Auswirkung hat.)

Vielleicht noch mal Ping an Johannes, weil bei dir steht noch .Net Core auf der Startseite, und der Buchfahrplan 2006 wird noch anders als alle anderen Buchfahpläne behandelt, obwohl das seit Zusi 3.5 ja nicht mehr der Fall ist.

[Johannes]

Da wäre ich für Umformulierungs-Vorschläge dankbar.

[F. Schn.]

In wie fern? Also in der Theorie sollte sowohl ZusiDisplay als auch alle Buchfahrpläne "gdiplus" benötigen, vielleicht "corefonts" und .Net 6. Im Winetricks-Abschnitt ist da nur von 2006er-DLL die Rede und unter "Bekannte Probleme" steht "dotnetcoredesktop3", und weiter unten steht "Buchfahrplan-DLL ist Version 1.3.0.0"; die Voraussetzungen sind seit DLL-Version 3.x aber ganz andere (seit 3.5 .Net 6). Vermutlich würde es also Sinn machen, alle 3 betroffenen "bekannte Probleme" Abschnitte zu archivieren und den "Winetricks"-Abschnitt entsprechend upzudaten. Die Frage wäre auch, wie man .Net 6 installiert. Laut Google einfach die zwei EXEs installieren. Aber ich habe ich weiß ehrlich gesagt bei all dem nicht, wie es da in der Praxis aussieht.

[Flo Zille]

Man kann in Steam jetzt Proton 9.0 (Beta) auswählen.

Verbesserungen, die mir aufgefallen sind: Dopplereffekt funktioniert jetzt, was Begegnungen mit anderen fahrenden Zügen natürlich gleich besser klingen lässt. Und im "Datei Öffnen"-Dialog, den Zusi nutzt, ist jetzt ein "nach oben"-Pfeil zur Navigation in das übergeordnete Verzeichnis statt nur eines "nach links"-Pfeils für "vorheriges Verzeichnis", was die Sache im Vergleich zum Dialog aus alten Wine-Versionen in manchen Situationen sehr viel angenehmer macht.

Gefühlt ist möglicherweise durch den neuen Dopplereffekt die Audiosache etwas weniger performant geworden. An manchen Stellen schien mir der Ton manchmal kurze Aussetzer zu haben (buffer underrun), vielleicht ist es mir aber bisher auch nur nie aufgefallen. Gefühlt sind auch die gelegentlichen Ruckler "länger" geworden, was meinen Verdacht bestärkt, dass diese (auch) durch das Hinzufügen und/oder Entfernen von Audiobuffern zur DirectSound-Ausgabe entstehen, was bei Überlastung des Sound-Mixer-Threads in Wine ggf. zu Rucklern im gesamten Programm führen kann. Vor einigen Jahren führte das damals noch stärkere Problem sogar noch dazu, dass sich Zusi unter Wine komplett aufgehängt hat. Dazu gibt es hier im Wine-Bugtracker schon eine lange Diskussion seit über 10 Jahren, bisher ohne ganz zufriedenstellendes Ergebnis.

[Flo Zille]

Hab seit dem letzten Zusi Update das Problem, dass bei mir bei Fahrzeugen mit Displaz Anzeigen, das MTD und EBuLa Bordgerät schwarz bleibt, das MFD hingegen bleibt hingegen gewohnt funktionsfähig.

Auch hier noch der Hinweis, dass das mit Wine 9.4 (erscheint wohl nächsten Freitag) hoffentlich wieder funktioniert. Jedenfalls funktioniert es, wenn ich die jetzt in 9.4 enthaltene Änderung auf wine-proton anwende und die entstehenden DLL-Dateien in meine Proton 9-Installation kopiere. ZusiDisplay benötigt jetzt eine Funktion, die es bisher in Wine noch nicht gab.

[chaotium]

Nun Ich habe eine Frage, ich hab hier ein Macbook Pro Mit M2 Chip mit einer VM für Windows Arm. Wäre es möglich seitens Carsten Zusi eine Windows Arm Unterstützung einzubauen?

[Iarnród]

Auch hier noch der Hinweis, dass das mit Wine 9.4 (erscheint wohl nächsten Freitag) hoffentlich wieder funktioniert. Jedenfalls funktioniert es, wenn ich die jetzt in 9.4 enthaltene Änderung auf wine-proton anwende und die entstehenden DLL-Dateien in meine Proton 9-Installation kopiere. ZusiDisplay benötigt jetzt eine Funktion, die es bisher in Wine noch nicht gab.

Die eingebauten Anzeigen funktionieren wieder mit der neuen Wine-Version. Allerdings habe ich immer noch Probleme mit dem FIS.

Tschüss
Iarnrod

[F. Schn.]

Siehe ZusiDisplay-Forum, allgemeiner Bug auch unter Windows.