Zusi-Forum

Verfasst: **01.01.2022 20:15:58**

Johannes hat geschrieben: ↑01.01.2022 20:00:54 Das Problem habe ich bei mir auch. Grund ist, dass tief in libxml2 bei der Initialisierung ein Floating-Point-Fehler auftritt

Ist auch schon seit längerer Zeit behoben. https://github.com/wine-mirror/wine/com ... 532ee038ef Also bitte die Wine-Version aktualisieren.

Verfasst: **01.01.2022 20:41:34**

Stimmt, danke. Die Wine-Version war schon aktuell, ich prüfe nur nicht routinemäßig, ob alle Patches noch notwendig sind

Verfasst: **10.01.2022 18:59:29**

Frage am Rande: Könnte man Zusi auch unter Android zum Laufen bringen?

Carsten

Verfasst: **10.01.2022 19:10:55**

Es gibt Wine für Android: https://dl.winehq.org/wine-builds/android/. Mit einem x86-basierten Gerät dürfte man bessere Chancen haben als auf ARM. In einem kurzen Test auf meinem Lenovo-Yoga-Tablet (x86) wollte Wine allerdings nicht starten, sodass ich nicht weiter testen konnte.

Verfasst: **10.01.2022 20:00:43**

Carsten Hölscher hat geschrieben: ↑10.01.2022 18:59:29 Frage am Rande: Könnte man Zusi auch unter Android zum Laufen bringen?

Also mit einem 0815 Smartphone wirds aufgrund der Architektur nicht gehen und x86 Android ist (meiner Ansicht nach) nicht wirklich sinnvoll nutzbar. Funktionieren könnte es dort jedoch.

Verfasst: **19.01.2022 16:43:45**

Heute habe ich erstmalig versucht, einen eigenen Fahrplan zu erstellen (Zusi und Wine sind auf dem aktuellen Stand). Das sieht dann so aus (zweimal getestet):

Das Programm klappert etwa zwei Minuten auf der Festplatte rum, aber es geht nicht weiter. Wines standard error (nur das Ende):

Code: Alles auswählen

fixme:msctf:InputProcessorProfileMgr_GetActiveProfile (118BAE70)->({34745c63-b2f0-4784-8b67-5e12c8701a31} 0031C194)
011c:fixme:file:NtLockFile I/O completion on lock not implemented yet
011c:fixme:ieframe:BrowserService_GetTravelLog 00BD3A50 0031C5D0
011c:fixme:ieframe:ClientSite_GetContainer (00B8C860)->(0031C6CC)
011c:fixme:ieframe:ClientSite_GetContainer (00B8C860)->(0031D7FC)
011c:fixme:ieframe:DocHostUIHandler_GetDropTarget (00B8C860)
011c:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {a3da04e0-57d7-482a-a1c1-61da5f95bacb}
011c:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {917b96b1-ecad-4dab-a760-8d49027748ae}
011c:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {26d1e091-0ae7-4f49-a554-4214445c505c}
011c:fixme:ieframe:PropertyNotifySink_OnChanged unimplemented dispid 1005
011c:fixme:mshtml:nsChannel_GetContentLength (118C30B8)->(0031DFB0)
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-Regular.ttf"
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-Bold.ttf"
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-ExtraLight.ttf"
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-Black.ttf"
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-Light.ttf"
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-SemiBold.ttf"
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-Thin.ttf"
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-ExtraBold.ttf"
021c:fixme:font:find_matching_face Untranslated charset 255
021c:fixme:font:get_nearest_charset returning DEFAULT_CHARSET face->fs.fsCsb[0] = 00000000 file = L"\\??\\Z:\\usr\\share\\fonts\\truetype\\noto\\NotoKufiArabic-Medium.ttf"

Ärgerlich ist, dass mein Rechner dann weder auf Tastatureingaben noch auf Mausklicks reagiert, nur der Mauszeiger beweg sich noch. Nicht mal der Reset-Knopf funktioniert; Abbruch geht nur durch Ausschalten der Stromversorgung

.

Leider habe ich das nicht schon früher versucht, insofern keinen Vergleich zu älteren Versionen.

Hat jemand eine Idee?

Verfasst: **19.01.2022 16:48:36**

Christian Gründler hat geschrieben: ↑19.01.2022 16:43:45Hat jemand eine Idee?

Ja, Zusi durchsucht auf der Suche nach Streckenmodulen das gesamte Routes-Verzeichnis. Es ginge viel schneller, wenn es die Verzeichnisse nur bis zu einer Tiefe von 3 besuchen würde, um die genormte Dateistruktur gemäß Doku 4.2.1.3 abzubilden.

Workaround: Warten oder den Fahrplan ohne Assistent erzeugen (dafür "Fahrplan bearbeiten" statt "Neuen Fahrplan erstellen" wählen).

Verfasst: **19.01.2022 16:59:24**

Johannes hat geschrieben: ↑19.01.2022 16:48:36 Ja, Zusi durchsucht auf der Suche nach Streckenmodulen das gesamte Routes-Verzeichnis.

Hallo Johannes,

Du bis ja schneller als der Notfallmanager

! An diese Erklärung habe ich natürlich gedacht, aber da nach einiger Aktivität auf der Festplatte die Lampe nicht mehr geflackert hat habe ich Stillstand angenommen. Diese Blockade des gesamten Rechners sollte trotzdem nicht sein; tatsächlich habe ich so etwas unter Linux noch nie erlebt.

Dann werde ich mal diesen anderen Weg ausprobieren.

Danke und herzliche Grüße

Christian

Verfasst: **19.01.2022 17:05:34**

Christian Gründler hat geschrieben: ↑19.01.2022 16:59:24Du bis ja schneller als der Notfallmanager ! An diese Erklärung habe ich natürlich gedacht, aber da nach einiger Aktivität auf der Festplatte die Lampe nicht mehr geflackert hat habe ich Stillstand angenommen.

Verifizieren kannst du meine Vermutung mit "WINEDEBUG=+file wine ZusiSim.exe". Da sollte eine kontinuierliche Ausgabe mit "0024:trace:file:FindNextFileW" o.ä. kommen.

Verfasst: **19.01.2022 17:51:56**

Übrigens, so Logs mit nur "fixme" Meldungen sind meistens nicht zielführend. Das gilt besonders bei grundlegenden Dingen wie Dateiaufrufe. ( Soll kein übrigens kein Angriff sein, sondern eher zeigen, wie schwierig das teilweise sein kann so einen Fehler in Wine zu finden.

)

Verfasst: **19.01.2022 23:42:55**

Also bei mir unter Windows braucht dieser Dialog auch unheimlich ewig und Zusi friert für mehrere Minuten ein. Das wäre also nicht zwingend ein Hinweis auf eine Linux-Besonderheit.

Verfasst: **20.01.2022 06:51:10**

F. Schn. hat geschrieben: ↑19.01.2022 23:42:55 Also bei mir unter Windows braucht dieser Dialog auch unheimlich ewig und Zusi friert für mehrere Minuten ein.

Bei mir friert halt der ganze Rechner ein

. Generell ist natürlich die Frage, warum das so lange dauert und was Zusi da genau macht. Mit Linux-Bordmitteln bekomme ich eine Liste sämtlicher .st3-Dateien in _ZusiData als Pfadnamen in einer Sekunde.

Verfasst: **20.01.2022 08:38:47**

Christian Gründler hat geschrieben: ↑20.01.2022 06:51:10Mit Linux-Bordmitteln bekomme ich eine Liste sämtlicher .st3-Dateien in _ZusiData als Pfadnamen in einer Sekunde.

Ein realistischerea Vergleich wäre im Routes-Ordner „wine cmd“ und dann „dir /s /b "*.st3"“. Aber auch das ist bei mir viel schneller.

Was auffällt: Zusi gibt als Suchmaske für FindFirstFile "*.*" an und filtert dann vermutlich intern. Wine gibt als Suchmaske "*.st3" an, damit werden unpassende Dateinamen gar nicht erst zurückgegeben.

Verfasst: **20.01.2022 08:58:55**

Johannes hat geschrieben: ↑20.01.2022 08:38:47 Ein realistischerea Vergleich wäre im Routes-Ordner „wine cmd“ und dann „dir /s /b "*.st3"“.

Daran hatte ich nicht gedacht, und diese cmd-Kommandos habe längst vergessen. Eben habe ich nach Deinem Verfahren getestet: das braucht bei mir keine 2 Sekunden.

Verfasst: **20.01.2022 10:20:32**

Zum Thema ZusiDisplay:

Vorgestern habe ich Wine aktualisiert, und da Zusi gut lief dann auch Zusi. Bei ZusiDisplay bin ich sicherheitshalber nur bis 3.4.7. gegangen. Alles einwandfrei.

Gestern habe ich leichtsinnigerweise auch ZusiDisplay auf den aktuellen Stand gebracht und bekomme seitdem die Fehlermeldung, dass "Microsoft Sans Serif" nicht gefunden wird. Diese Datei liegt allerdings seit Ende Dezember im windows\Fonts-Ordner, und bisher ging das ja.

Und jetzt wirds komisch: Natürlich habe ich von ZusiDisplay 3.4.7 eine Sicherungskopie gemacht, aber wenn ich diese als ZusiDisplay wiederherstelle kommt der Fehler trotzdem. Die Verwaltung erkennt mein rekonstruiertes ZusiDisplay.exe als Version 3.4.7.0 an, also sollte das wohl richtig sein.

EDIT meint (am 22.1.): Zusi aus alter Datensicherung zurückgeholt und aktualisiert. ZusiDislplay ist jetzt bei mirt die letzte 3.3er Version, alles andere ist aktuell – funktioniert. Eine neure Version von ZusiDisplay hat wieder den gleichen Fehler geliefert (also nochmal von vorn

). Äußerst merkwürdig ist halt, dass die 3.4.7. bei mir schon mal lief.

Bernhard K. hat geschrieben:Ganz wichtig, sonst geht's gar nicht: Man muss manuell irgendwo die Schriftart micross.ttf (Microsoft Sans Serif) herholen und in C:\Windows\Fonts packen.

Packen = Reinkopieren? Oder braucht es eine Installation? Möglicherweise stimmt der Ort auch nicht, denn ich habe diesen Ordner für micross.ttf neu anlegen müssen.

Verfasst: **22.01.2022 17:33:56**

Christian Gründler hat geschrieben: ↑20.01.2022 06:51:10 Generell ist natürlich die Frage, warum das so lange dauert und was Zusi da genau macht. Mit Linux-Bordmitteln bekomme ich eine Liste sämtlicher .st3-Dateien in _ZusiData als Pfadnamen in einer Sekunde.

Na ja, auch wenn das nur Dateiaufrufe sind, muss ja Wine trotzdem das Windows Verhalten simulieren und kann das nicht direkt zu Linux durchschleifen. Jedoch dürfe es keinesfalls den ganzen Rechner einfrieren.
Ich kann das Problem bei mir nicht reproduzieren, Zusi hängt, aber nicht die ganze Oberfläche.

So sieht das dann aus ^.

Christian Gründler hat geschrieben: ↑20.01.2022 10:20:32 Packen = Reinkopieren? Oder braucht es eine Installation? Möglicherweise stimmt der Ort auch nicht, denn ich habe diesen Ordner für micross.ttf neu anlegen müssen.

Kopieren reicht aus.

Verfasst: **22.01.2022 18:18:59**

Christian, wahrscheinlich hast du den falschen Ordner erwischt. Denn C:\windows\Fonts müsste eigentlich in jedem Wine-Präfix schon existieren (jedenfalls wird er bei mir direkt angelegt, wenn ich ein neues Präfix erstellen lasse).

Der Standard-Prefix ist /home/nutzername/.wine/ (und dann weiter drive_c/windows/Fonts, wo die ttf-Datei rein muss). Je nach dem, wie du Zusi unter wine startest, kann auch ein anderer Prefix per WINEPREFIX=/pfad/ als Umgebungsvariable angegeben sein, z.B. in einem Startskript.

Verfasst: **22.01.2022 19:34:49**

Flo Zille hat geschrieben: ↑22.01.2022 18:18:59 Christian, wahrscheinlich hast du den falschen Ordner erwischt.

Nee, das ist schon richtig bei mir. Eben noch mal kontrolliert: der Fonts-Ordner (Pfad wie von Dir angegeben) wurde am 2.11. beim Erzeugen des Wine-Prefix angelegt und am 26.12. von mir mit micross.ttf befüllt. Ich hatte das also falsch in Erinnerung und habe ihn offensichtlich doch nicht händisch angelegt (ein emeritierter Papst würde bei seiner ursprünglichen Behauptung bleiben), war aber definitiv überrascht, dass der Ordner leer war.

Verfasst: **23.01.2022 09:04:49**

Jeder IT-Berater kennt es, dass User unerklärliche Fehler melden und dabei betonen: "Ich habe doch garnichts gemacht"

. Ich muss gestehen, dass ich die native gdiplus erst vor ein paar Tagen installiert und vor dem weiteren Update von ZusiDisplay nicht getestet habe

. Wenn ich die dll-Überschreibung auf builtin ändere, funktioniert es wieder. Mit ZusiDisplay hat dieses "unerklärliche" Phänomen also garnix zu tun.

Bleibt natürliich die Frage, warum die native gdiplus micross.ttf nicht findet; der Pfad stimmt jedenfalls mit dem von Flo Zille genannten überein.

Verfasst: **23.01.2022 12:06:50**

Naja die Wine Gdiplus Dll mit den massiven Performanceproblemen ist jetzt auch nicht so schlecht.

Zusi-Forum

Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux

Re: Testbericht unter Linux