Ist auch schon seit längerer Zeit behoben. https://github.com/wine-mirror/wine/com ... 532ee038ef Also bitte die Wine-Version aktualisieren.
Testbericht unter Linux
- Bernhard K.
- Beiträge: 167
- Registriert: 23.06.2020 22:29:41
- Aktuelle Projekte: Uni
- Wohnort: VzG 5900, Km 9,4
- Kontaktdaten:
Re: Testbericht unter Linux
- Johannes
- Beiträge: 3218
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
Stimmt, danke. Die Wine-Version war schon aktuell, ich prüfe nur nicht routinemäßig, ob alle Patches noch notwendig sind
- Carsten Hölscher
- Administrator
- Beiträge: 33548
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: Testbericht unter Linux
Frage am Rande: Könnte man Zusi auch unter Android zum Laufen bringen?
Carsten
Carsten
- Johannes
- Beiträge: 3218
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
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.
- Bernhard K.
- Beiträge: 167
- Registriert: 23.06.2020 22:29:41
- Aktuelle Projekte: Uni
- Wohnort: VzG 5900, Km 9,4
- Kontaktdaten:
Re: Testbericht unter Linux
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.Carsten Hölscher hat geschrieben: ↑10.01.2022 18:59:29 Frage am Rande: Könnte man Zusi auch unter Android zum Laufen bringen?
- Christian Gründler
- Beiträge: 2213
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
Re: Testbericht unter Linux
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):
Ä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?
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"
Leider habe ich das nicht schon früher versucht, insofern keinen Vergleich zu älteren Versionen.
Hat jemand eine Idee?
- Johannes
- Beiträge: 3218
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
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).
- Christian Gründler
- Beiträge: 2213
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
Re: Testbericht unter Linux
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
- Johannes
- Beiträge: 3218
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
Verifizieren kannst du meine Vermutung mit "WINEDEBUG=+file wine ZusiSim.exe". Da sollte eine kontinuierliche Ausgabe mit "0024:trace:file:FindNextFileW" o.ä. kommen.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.
- Bernhard K.
- Beiträge: 167
- Registriert: 23.06.2020 22:29:41
- Aktuelle Projekte: Uni
- Wohnort: VzG 5900, Km 9,4
- Kontaktdaten:
Re: Testbericht unter Linux
Ü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. )
Re: Testbericht unter Linux
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.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
- Christian Gründler
- Beiträge: 2213
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
Re: Testbericht unter Linux
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.
- Johannes
- Beiträge: 3218
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: Testbericht unter Linux
Ein realistischerea Vergleich wäre im Routes-Ordner „wine cmd“ und dann „dir /s /b "*.st3"“. Aber auch das ist bei mir viel schneller.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.
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.
- Christian Gründler
- Beiträge: 2213
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
Re: Testbericht unter Linux
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.
- Christian Gründler
- Beiträge: 2213
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
Re: Testbericht unter Linux
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.
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.
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.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.
- Bernhard K.
- Beiträge: 167
- Registriert: 23.06.2020 22:29:41
- Aktuelle Projekte: Uni
- Wohnort: VzG 5900, Km 9,4
- Kontaktdaten:
Re: Testbericht unter Linux
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.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.
Ich kann das Problem bei mir nicht reproduzieren, Zusi hängt, aber nicht die ganze Oberfläche.
So sieht das dann aus ^.
Kopieren reicht 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.
Re: Testbericht unter Linux
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.
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.
- Christian Gründler
- Beiträge: 2213
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
Re: Testbericht unter Linux
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.
- Christian Gründler
- Beiträge: 2213
- Registriert: 04.10.2003 13:27:48
- Wohnort: Brühl (Baden)
Re: Testbericht unter Linux
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.
Bleibt natürliich die Frage, warum die native gdiplus micross.ttf nicht findet; der Pfad stimmt jedenfalls mit dem von Flo Zille genannten überein.
- Bernhard K.
- Beiträge: 167
- Registriert: 23.06.2020 22:29:41
- Aktuelle Projekte: Uni
- Wohnort: VzG 5900, Km 9,4
- Kontaktdaten:
Re: Testbericht unter Linux
Naja die Wine Gdiplus Dll mit den massiven Performanceproblemen ist jetzt auch nicht so schlecht.