Mit wine 9.0 laufen TB 10 und 11, und TB 8 kann sich wieder erfolgreich nach Updates erkundigen.
Allerdings ist bei dem wine-Paket der Distro, die ich verwende der neue WoW64-Modus noch nicht aktiviert. Würde aber wohl auch keinen Unterschied machen, da ich kein TB 32bit verwende.
Bei mir startet weder The Bat v10.4.x noch v10.5.x mit wine v8.17 oder neuer. Ich bleibe daher vorerst auf v8.16. Wäre zwar eigentlich egal bei mir, da ich sowieso noch The Bat v8 nutze, aber um v10 zu testen ist es so halt doch besser. Und wer will schon eine defekte wine-Version nutzen...?
Wine hat in der Vergangenheit schon öfter mal Versionsreihen gehabt, mit denen ein oder mehrere Programme ganz oder teilweise nicht mehr liefen.
Z.B. funktionierte die Update-Suche von The Bat v8 mit wine von ca. v7.20 bis v8.10 nicht.
Im Übrigen hat eine Mitarbeiterin vom The Bat Support letztes Jahr mal so nebenbei erwähnt, daß sie überlegen, eine Plattform-unabhängige Version zu machen. Würde sich natürlich anbieten, wo sie sowieso schon CEF integriert haben. Sieht dann aber vermutlich dann auch entsprechend aus... Es gibt ja inzwischen ziemlich viel Software, die auf CEF aufgebaut ist.
Außerdem wurde der neue HTML-Editor noch in der v9.3.3.2 Alpha implementiert. Der Fehler wurde aber erst in v9.3.3.6 Alpha (endgültig) behoben. Damit bestand er zunächst auch im neuen HTML-Editor.
Wie schon geschrieben:
Nun habe ich doch noch v9.3.4 gefunden. Die ist perfekt: Hat nicht den neuen Editor, der in der Testversion v9.3.3.6 implementiert ist und in der der Fehler wohl nicht auftritt.
In v9.3.4 tritt er aber auf. D.h. wie vermutet wurde der Fehler im MicroEd nicht behoben.
Allerdings müßte ich noch z.B. v9.3.3.2 testen (die erste Version mit dem neuen Editor, aber angeblich noch mit dem Fehler), um meine Vermutung belegen zu können, daß der Fehler im neuen Editor gar nicht aufgetreten ist.
Zur Verdeutlichung:
v9.3.3.2: Fehler angeblich vorhanden, mit neuem html Editor (s.u. zu Fehlermeldung 1639) <---- Diese Version hätte ich gerne zum Testen.
v9.3.3.6: Fehler angeblich behoben, mit neuem html Editor
v9.3.4: Wie 9.3.3.6, aber ohne neuen html Editor <----- In dieser Version sollte deiner Theorie nach der Fehler nicht mehr auftauchen. Der Fehler ist aber noch vorhanden.
Es gibt eine Möglichkeit, die den Fehler "an den alten html Editor bindet" ohne in ihm selbst zu sein: Der Fehler konnte im "übergeordneten Editor" (den ich deiner Beschreibung entnehme) nicht behoben werden, weil der untergeordnete, alte html Editor das nicht zugelassen hat. Das würde ebenso erklären, warum der Fehler nach der ersten Behebung in v8 kurz darauf wieder eingeführt und danach (in v8, und nach meiner Theorie auch in v9 im / mit dem alten html Editor) nie behoben wurde, weil er nicht behoben werden konnte, weil sonst etwas anderes nicht mehr funktioniert hätte. Andernfalls wäre es ein leichtes gewesen, das Vorgehen bei der ersten Fehlerbehebung einfach noch einmal zu wiederholen. Einen Fehler zu finden, der schon einmal aufgetreten ist und der behoben wurde sollte wohl deutlich einfacher sein, als einen neuen, bisher nie aufgetretenen zu finden (d.h. seine Ursache im Code) und beheben.
Daher auch:
Leider kann man die alten Versionen kaum noch herunterladen
... alles im Kontext von v9, d.h. um die Versionen herum, in denen der Fehler noch vorhanden oder nicht mehr vorhanden sein sollte.
Von daher würde es mir natürlich etwas nützen (da von v8 in diesem Zusammenhang ("alte Versionen herunterladen") nie die Rede war)...
Und seit v10.2 hat man jetzt auch den alten HTML-Editor als Alternative wieder. Damit hat man jetzt den alten Nur-Text-Editor (MicroEd) und auch den alten HTML-Editor (RichText Editor).
Das changelog auf der Webseite besagt dazu:
New features
Ich entnehme dem nicht, daß es sich dabei um den (- unveränderten - Code des) alten html Editor(s) handelt.
Du hättest mal die neuste Version zumindest antesten sollen.
Zu welchem Zweck genau?
Generell angetestet habe ich sie ja. Nur nichts gespeichert, um nicht meine Datenbank(en) ggf. für v8 unlesbar zu machen. Ein Duplizieren der Datenbank war mir für die jeweils rel. kurzen Tests (bei denen ich auf andere Dinge geachtet habe, da der Fehler ja seit v9.3.3.6 angeblich nicht mehr auftritt) zu aufwändig.
Der Fehler ist ja in v10 nie aufgetreten. Wobei: Wenn es schon in v8 und v9 "niemandem" aufgefallen ist, wäre es auch in v10 "niemandem" aufgefallen, wenn er vorhanden gewesen wäre. Jedenfalls habe ich außer den beiden erwähnten Fehlermeldungen keine weiteren gefunden.
Bis auf 1639, die aber quasi eine neu eingetragene Kopie der 1366 ist, nur unter "HTML editor" einsortiert statt unter "MicroEd text editor".
Interessanterweise steht dort als Bemerkung:
Irrelevant since v9.3.3.3 with the new HTML editor.
Wobei die Einträge in den Fehlermeldungen jetzt auch nicht die absolute Wahrheit darstellen müssen.
Aber diese Bemerkung (auch wenn hier von v9.3.3.3 die Rede ist, laut Beta-Mailgruppe der neue html Editor aber in v9.3.3.2 eingeführt wurde) würde ja dafür sprechen, daß die angebliche "Behebung" des Fehlers in v9.3.3.6 nicht durch tatsächliche Fehleranalyse und Codeänderung zustande kam, sondern automatisch (und "zufällig") lediglich durch Umstellen auf einen neuen html Editor.
Man kann Hinweise für beide Theorien finden und wird ja nach persönlicher Tendenz diejenigen für die nicht-bevorzugte Theorie eher ignorieren.
Deshalb: Die v9.3.3.2 wäre ein optimales Testsubjekt, weil sie angeblich den Fehler noch enthält, aber schon den neuen Editor mitbringt. (s.o.)
Leider ist es aber keine finale Version, weshalb sie außerhalb der Ritlabs-Server noch unwahrscheinlicher aufzufinden sein wird als finale Versionen, die auch nicht mehr für jede Version (so einfach) zu finden sind. Und Ritlabs löscht "sogar" veraltete finale Versionen, so daß auch Mitarbeiter keine Kopie mehr auftreiben können. Da wird es bei einer alpha/beta Version leider noch weniger wahrscheinlich sein. 
Die v9.3.4 habe ich ja bereits getestet. Die hat noch den Fehler, von dem man zwar annehmen sollte, daß er, wenn er nichts mit dem html Editor zu tun hat, in dieser Version behoben sein sollte, aber diese Version könnte auch von einer Version vor v9.3.3.6 (in der der Fehler angeblich behoben wurde) abstammen. Solange ich das nicht ausschließen kann (auch wenn es in der Beta-Gruppe heißt "So, version 9.3.4 is very much like to 9.3.3.6, but without new HTML editor."), kann v9.3.4 keinen abschließenden Beweis für meine Theorie erbringen. v9.3.3.2 könnte das sehr wahrscheinlich schon (für oder gegen meine Theorie).
Wie auch immer.
Eine Gegenfrage. Welche Bildschirmauflösung hast du in der VM?
Die gleiche wie auf dem nativen System.
Auf der Ritlab-Webseite sind die changelogs ja etwas lückenhaft, weil nicht jede (Zwischen-) Version aufgeführt ist.
Ich bin trotzdem nach diesen gegangen:
New features
Von daher meine Meinung, daß der Fehler (im ursprünglichen Editor) nie behoben wurde, da ein neuer Editor implementiert wurde (in dem der Fehler ggf. gar nicht aufgetreten ist, aber das dann als "Fehler behoben" verkauft wurde).
In den Fehlermeldungen (1366) ist vermerkt, daß der Fehler erstmals in ~v8.0.14.2 (2017) aufgetreten ist und in v8.0.14.3 behoben wurde - oder auch erst in v8.2.8.5. Beide Versionen werden im selben Vorgang angegeben.
Dann ist der Fehler (1538) wieder in ~v8.5.8.3 (2018) aufgetreten und angeblich in v9.3.3.4 (2021) behoben worden. Letztere Version taucht nicht einmal in der Beta-Mailgruppe auf. Vielleicht ist es nur eine interne Version - oder ein Tippfehler (statt 9.3.3.2 oder 9.3.3.6).
Jedenfalls wollte ich nicht nur wegen dieses Fehlers eine neue Version kaufen müssen - zumal er ja schon mal behoben worden war.
Hier noch ein Hinweis darauf, daß der Editor neu aufgesetzt wurde und der Fehler im ursprünglichen Editor (MicroEd) nie behoben wurde:
Where is MicroEd? (The Bat 9.4.1)
- Where is MicroEd? (The Bat 9.4.1)
- It is gone.
Leider kann man die alten Versionen kaum noch herunterladen - und ich behalte auch nicht jede Version. Ich würde meine Behauptungen gerne testen können... 
(s.u.)
Hier eine Bestätigung, daß in v9.3.3.6 ein neuer Editor implementiert ist:
Zitat von Stefan Tanurkov via TBBETA
While we are working on new HTML editor, we've prepared an update to the official release with recent changes to other parts. So, version 9.3.4 is very much like to 9.3.3.6, but without new HTML editor.
Nun habe ich doch noch v9.3.4 gefunden. Die ist perfekt: Hat nicht den neuen Editor, der in der Testversion v9.3.3.6 implementiert ist und in der der Fehler wohl nicht auftritt.
In v9.3.4 tritt er aber auf. D.h. wie vermutet wurde der Fehler im MicroEd nicht behoben.
Allerdings müßte ich noch z.B. v9.3.3.2 testen (die erste Version mit dem neuen Editor, aber angeblich noch mit dem Fehler), um meine Vermutung belegen zu können, daß der Fehler im neuen Editor gar nicht aufgetreten ist.
Ein Hinweis darauf, warum der Fehler für den neuen Editor als "behoben" aufgeführt sein könnte.
Re: 9.3.3.3 - tracking issues in BT
an idea for the bugtracker: To make tracking issues clearer, can we have a new category for New HTML editor?
Or better: close all bugs for the current category "HTML-Editor" since the old editor is gone in 9.3.3.3 and its bugs went along with it.
Same for the bugs of category "Windows Editor".
Die Fehlermeldungen für alten und neuen Editor landeten in der selben Kategorie, so daß man Fehler, die im neuen nicht auftreten ggf. einfach auf "behoben" gesetzt hat, um etwas aufzuräumen und nur noch Fehler die den neuen Editor betreffen "offen" zu haben.
Es ist halt auch eine Frage, ob und wie viel Code sie vom alten in den neuen Editor übernommen haben.
Aber das ist alles sowieso nur Theorie und zum Spaß, weil v10 ja aktuell ist und diese nie etwas anderes als den neuen Editor hatte.
Strg+S für was, Nachricht speichern? Man kann ja seit langem die Shortcuts selbst vergeben und ändern.
Nachricht speichern klappt hier jedenfalls über diese Tastenkombi in v8.8.9 64bit problemlos.
Mhhh. Hatte ich vorhin extra noch einmal getestet. Wenn ich damit speichere und dann die Nachricht schließen will, fragt er nach, ob ich speichern will.
Vielleicht hätte ich es anders formulieren sollen: Strg+S funktioniert zwar zum Speichern, er fragt aber trotzdem noch einmal nach Speichern, wenn man das Editor-Fenster schließen möchte.
Nun habe ich noch einmal getestet: Noch genauer müßte es heißen: Der Fehler tritt auf, wenn man in den Nachricht-Teil etwas schreibt. Wenn man nur eine Email-Adresse und / oder den Betreff ausfüllt / ändert (und dann per Strg+S speichert), fragt er beim Schließen nicht nach.
Vielleicht kommt aber auch schon v11 im nächsten Jahr.
Ich hoffe mal, es dauert wieder 2 Jahre+ bis zur nächsten Hauptversion...
Wenn du bei der v8 bleibst, dann aktualisiere sie wenigstens auf die letzte v8.8.9, die auf der offiziellen Webseite noch vorhanden ist.
V8.5.4 ist die letzte tolerierbare Version für mich, da danach Strg+S nicht mehr funktioniert. Sie wollten es nicht mehr reparieren (der Fehler war vorher schon mal eingeschleust und später wieder behoben worden). Ich tippe auf schlechten Code, den sie für neue Funktionen brauchten und ihnen nur die Wahl zwischen den neuen Funktionen oder der Behebung des Fehlers gelassen hat. Jedenfalls wurde die Fehlermeldung nach mehrmaligen Nachhaken dann auf "won't be fixed" gesetzt.
Den Thread dazu findet man unter "BYE out-of-sync data before server greeting". Du hast dort übrigens auch gepostet. Das Problem hatte jeder TB!-Nutzer, da GMX & Co. plötzlich nicht mehr über TLS funktionierten. StartTLS ging noch.
Danke für die Erinnerung!
Der Ritlabs-Support meint, daß eine (1) weitere Meldung dieser Art vorliegt (CEF-basierter Viewer ignoriert ClearType-Einstellung). Da bezweifle ich mal stark, daß Ritlabs daran etwas ändern kann.
Im Übrigen bin ich der "VM vs nativ"-Vermutung mal nachgegangen. Für mich wenig überraschend gibt es keinen Unterschied zwischen W7 VM und W7 nativ. Wohl aber zwischen W7 und W10 (VM, habe ich nie nativ installiert). Auf W10 ist es weniger "schlimm".
Das die leichte Unschärfe (im Vergleich zu nur-text) nicht jeden stört ist in sofern nicht unbedingt überraschend, da es ja auch Nutzer gibt, die ClearType nutzen... Und dann fällt es vermutlich gar nicht auf bzw. gibt es ggf. keinen Unterschied.
Ich kann ja mal eine v10-Lizenz nehmen für den Fall, daß v8 irgendwann nicht mehr kompatibel mit den Anforderungen meiner Email-Anbieter ist. Und vielleicht finde ich noch eine Möglichkeit, die Darstellungsprobleme unter wine zu reduzieren (z.B. eine weniger "empfindliche" Schriftart), so daß ich v10 schon vorher nutzen möchte....
Vielen Dank für die Rückmeldungen.
Da ich "glücklicherweise" alle Mailanbieter, die (laut Ritlabs changelogs) auf OAuth setzen aus anderen Gründen gar nicht erst nutze, ist das jetzt mal kein Upgrade-Grund für mich.
Die Probleme mit UI im Januar sind mir nicht mehr im Detail in Erinnerung, daher kann ich nicht sagen, ob mein TB davon betroffen war oder nur ein anderes Programm, das ich zur Spam-Entfernung verwende.
Leider haben sich heute bei meinen Alternativen-Tests (Claws Mail, Mail-Funktion in Vivaldi) herausgestellt, daß sie bei genauerer Betrachtung nicht als Alternative taugen...
Andere Clients hatte ich schon im Vorfeld vor Wochen mal ausgeschlossen. Die Vivaldi-"Idee" kam mir erst heute in den Sinn. Und auch gleich wieder verworfen, da man keine Emails importieren (oder exportieren) kann.
Zur Not besorge ich mir halt eine v10-Lizenz und steige um, wenn v8 nicht mehr mag (oder darf)...
Da ich noch aus diversen Gründen v8.5.2 nutze, heute aber die Rabatt-Aktion endet, bin ich mal sämtliche changelog-Einträge auf der Ritlabs-Webseite durchgegangen, um zu sehen, ob sich ggf. ein Upgrade doch lohnt (trotz hässlicherem GUI).
Da waren ja doch einige TLS-Updates, v.a. noch in v8 und v9, die irgendwann eventuell mal relevant werden könnten in dem Sinne, daß Email-Anbieter sie zur Voraussetzung machen (wie es ja in diesem Jahr mit TLS 1.2 u.a. bei der Strato-Familie der Fall war).
Daher habe ich wieder mal v10 getestet, um zu sehen, ob ich damit arbeiten könnte.
Leider mußte ich feststellen, daß der html-Betrachter für die Email-Anzeige relative unscharfe Schriften anzeigt, sowohl unter wine als auch unter Windows (7, VM), wenn auch in unterschiedlicher Weise. Unter Windows ist Cleartype deaktiviert, welches aber auf die Textanzeige im html-Betrachter sowieso keinen Einfluß zu haben scheint, wie Wechseln zwischen Aktivierung und Deaktivierung zeigt.
Unter wine kommt noch hinzu, daß die Anzeige Sekunden braucht, z.B. beim Wechsel von einer Email zu einer anderen. Da kann dann zwar TB nichts dafür, ist aber für mich dann doch ein Punkt auf der Negativ-Liste was einen möglichen Wechsel anbelangt.
Aber die unscharfe Textanzeige (im Vergleich zum (alten) html-Betrachter von v8 und zur nur-Text-Anzeige) ist schon ein Grund, nicht zu wechseln. Es sei denn, es gibt eine Möglichkeit, das abzustellen. Immerhin kann ich mir nicht vorstellen, daß andere Nutzer eine solche Textanzeige tolerieren würden.
Allerdings konnte ich auch keine "Beschwerden" in Form von Foreneinträgen bzw. Einträgen im bugtracker finden, was mir dann auch wieder komisch vorkommt.
Daher wäre ich für Tips oder Hinweise was eine unscharfe Textanzeige im html-Betrachter anbelangt dankbar.
Zufällig gesehen, daß die Preise momentan (3.-9.10.2022) reduziert sind und deshalb mal geschaut warum...
Der Angebot zum Tag des Lehrers: 25% Rabatt auf The Bat!
Der Angebot zum Tag des Lehrers: 25% Rabatt auf The Bat!
Da stelle ich mir die Frage, ob die zum Black Friday noch mehr Rabatt geben (in der Vergangenheit z.B. 40%). Immerhin sind die Preise für ein Upgrade mit 25% schon tiefer als 2020 (The Bat! Black Friday Sale: 40% discount)... Das liegt aber auch daran, daß die Upgrade-Preise im Vergleich zum Vollpreis günstiger sind als 2020.
Die wine-Versionen 7.3-7.5 haben etliche Probleme für diverse Programme verursacht, seit v7.6 scheinen diese behoben und bislang keine neuen (oder alten wieder) eingeführt worden sein.
Da The Bat! nach v8.5.4 einen nervigen Fehler beim Editor wieder eingeführt hatte (bei dem das Speichern mit Strg+S einfach ignoriert wurde und beim Schließen des Fensters trotzdem nach Speichern gefragt wurde) und weil ich grundsätzlich nur alle 2 Versionen eine neue Lizenz von The Bat! kaufe, habe ich v9 nie wirklich in Betracht gezogen.
Der oben genannte Fehler wurde auch in v9 vermutlich nie wirklich behoben, sondern verschwand nur durch die Neuimplementierung des Editors, wenn ich das richtig verfolgt habe.
Nun ist v10 erschienen und eigentlich wäre das ein Kandidat für mich - weshalb ich diese Version (v10.0.3), aber auch v9.5.1, getestet habe.
Dankenswerterweise gibt es von v10 ja auch eine NAU-Version mit herkömmlicher Ordnerstruktur - weshalb das Testen, insbesondere mit Entpacken statt Installieren, nicht anders ist als mit Versionen vor v10.
Für mich als v8-Nutzer sieht v10 auf den ersten Blick nicht anders aus als v9 - die Icons gefallen mir nicht wirklich, insbesondere das "Konto-Icon" und die Tatsache, daß das "Plus" zum Aufklappen der Ordner durch diesen "Winkel" ersetzt wurde. Dank Resource Hacker kann man zwar das in v10 neue Tray-Icon durch das bis v9 einheitliche ersetzen, bei den Icons der Programm-Oberfläche muß ich noch mal testen - beim ersten Versuch hat das noch nicht geklappt. Es ist wirklich schade, daß es keine skins (wie z.B. bei IrfanView) für TB gibt. Das würde den Nutzer ermächtigen, nicht jeden Designanfall der Programmierer mitmachen zu müssen - und die Upgrade-Entscheidung erleichtern.
v10 scheint unter wine nicht anders zu laufen als v9. Seit Einführen des neuen Email-Editors, bzw. dessen neuen HTML-Modus, muß TB mind. im Windows-Modus "Vista" gestartet werden, andernfalls bleibt der Editor leer, selbst vorgegebene Texte bleiben unsichtbar. Dies ist das deutlichste Zeichen für den neuen Editor. Etwas störend ist, daß die Schrift im HTML-Modus cleartype-mäßig leicht unscharf ist, was aber unter Windows bei ausgeschaltetem cleartype vermutlich gar nicht erst auffällt.
Das neue Adressbuch passt designmäßig nicht wirklich zu TB, das dürfte aber wohl der Code-Grundlage geschuldet sein, auf der es basiert. Es wäre nicht verwunderlich, wenn irgendwann das gesamte Programm in diesem Gewand daherkommt.
Wenn man auf die Nicht-Email-Funktionen keinen Wert legt, dürfte v10 für v9-Nutzer vermutlich keinen Mehrwert bzw. keine große Veränderung bringen.
Und da v8 bislang noch neu genug ist, so daß die darin enthaltenen Standards noch funktionieren, sehe ich momentan noch keinen Drang, auf v9 oder v10 umzusteigen - allenfalls der aktuelle 50%-Rabatt für die Upgrade-Lizenz, die allerdings auch gut 50% teurer ist als die letzte, wäre ein Anreiz.
Vielleicht ist es aber nun doch mal an der Zeit, native Linux-Email-Lösungen testen...
Ja, geht wieder! (v8.5.2)
Danke für den Hinweis!
Ergebnis eines weiteren Tests:
Um zu überprüfen, ob das erfolglose Installieren von 64bit TB unter wine 64bit auf die v9 beschränkt ist, habe ich v8.5.2 installiert - erfolgreich. Dann v8.8.9, erfolgreich.
Und zum Gegentest dann noch v9.1.16. Diesmal ebenfalls erfolgreich.
Es scheint mir also auf meinem System eher die noch nicht ganz stabile 64bit Version von wine zu sein, die beim ersten Versuch den Abbruch der Installation von TB v9.1.16 64bit verursacht hat.
So. Endlich habe ich Dank eines anderen Nutzers eine Kompilierungsvorlage für wine64 für das Linux, das ich nutze, gefunden und konnte nach stundenlangem Kompilieren und etwas try and error endlich TB 64bit zum Laufen bringen.
Das gilt auch für die aktuelle v9.1.16. Allerdings gilt das nur für das "Laufen". Installieren ging nicht - der Prozess bricht kurz nach dem scheinbaren Beginn der eigentlichen Installation ab. Ob das dem allgemeinen, hier vorgebrachten Problem entspricht, kann ich nicht sagen. Für mich ist das allerdings weniger tragisch, da ich Programminstaller, soweit möglich, entpacke und die Programme "portable", ggf. mit entsprechender Anpassung der registry, ausführe.
So könnte ich also auch v9.1.16 64bit ausführen. Da ich allerdings keine Lizenz dafür habe, bleibe ich bei der für mich letzten brauchbaren Version 8.5.2 (da ich den Installer für die 8.5.4 bei Erscheinen einer Nachfolgerversion mit nachher festgestelltem wieder eingeführtem Bug voreilig gelöscht und bisher noch nicht wieder als 64bit Version zum Download gefunden habe).
Vielen Dank für den Hinweis.
Allerdings alles schon probiert. Mehrfach.
Es scheint ein Void-Problem bzw. ein Problem des wine 64bit-Paketes von/für Void zu sein. Es gibt v.a. in den letzten Monaten vermehrt Beschwerden bzw. "Aufforderungen" im reddit-Kanal von Void dazu, das win 64bit-Problem zu lösen. Ich scheine also nicht der einzige mit diesem Problem zu sein.
Daher auch der (dezente) Hinweis auf das funktionierende Ubuntu...
Auch PlayOnLinux ist mir nicht unbekannt. Ich hoffe allerdings trotzdem vorerst auf eine "interne" Lösung. So dringlich bin ich dann auch wieder nicht auf wine 64bit angewiesen, daß ich nicht noch etwas warten kann bevor ich ein.
Ich habe es bisher nicht geschafft, wine 64bit auf Void/Trident zum Laufen zu bringen. Hatte erst nach meinem letzten Post realisiert, daß es doch ein 64bit-Problem (von wine) ist.
Daher konnte ich bisher auch noch keine Rückmeldung zu TB 64bit auf wine 64bit abliefern...
Man kann zwar 64bit-wine (v4.2.1) auf Void selbst kompilieren, aber dann wird kein wine-server und anderes gefunden. Wenn man dann noch 32bit-wine (ebenfalls 4.2.1) installiert, beschwert sich das System, daß 64bit nicht funktionieren kann, weil .wine 32 bit sei - obwohl ich andere Pfade für 32bit und 64bit-Architektur konfiguriert habe...
Kann natürlich auch Anwenderfehler sein. Auf einem Ubuntu-System, wo 64bit wine "nativ" (von ubuntu repos?) verfügar ist, gibt es diese Probleme allerdings nicht - nicht einmal mit der "nicht-nativen" Version 5.4 (von winehq-Repos).
Yep, das ist das Projekt. Allerdings ist es quasi nur eine benutzer-freundliche Distro von Void Linux, also DE und ein paar andere default-Zusätze, insbesondere zfs-on-root. Auf der Github-Seite von Project Trident findet man lediglich die Dinge, die Trident zusätzlich zu Void mitbringt.
Für verfügbare Pakete daher hier schauen:
https://voidlinux.org/packages/
Hinweis: Für die verschiedenen Architekturen gibt es jeweils eine glibc (nicht bezeichnet) und eine musl-Variante. Wobei es für die musl-Variante i.d.R. weniger Pakete gibt. Fehlende / zusätzliche Pakete lassen sich ggf. selbst kompilieren aus der Quelle.
Die Wiki-Seite (https://wiki.voidlinux.org/Main_Page) ist sehr hilfreich bei allen Fragen. Ich als quasi-Newbie konnte mein Testsystem (Void-Installation ohne DM und DE) damals mit wenigen zusätzlichen Websuchen allein mit der Wiki-Seite komplett zu einem GUI-System mit LightDM und xfce ausbauen.
Aber es ist halt ein kleines Projekt, sodaß nicht alles, was man von Ubuntu/Debian und anderen großen gewohnt ist, unbedingt funktioniert.
Für alteingesessene Linux-Nutzer dürfte das Void-Package-System (xbps) eine gewisse Umstellung bedeuten. Ist aber alles in Wiki gut dokumentiert.
Habe mal testweise TB v9.1.6 (32bit) installiert. Ging ohne Probleme.
Wine 5.3 (32bit), Void Linux mit zfs on root (= Project Trident), kernel v5.4.25_1, xfce. Leider gibt's kein 64bit wine in den regulären repos von Void, sonst würde ich das nutzen. Sollte aber für TB-Tests keinen Unterschied machen.
Als erstes ein Dankeschön an den zuständigen Admin für die Freischaltung. Ich wußte gar nicht, daß ich mich nicht schon vor Jahren, als ich vom Netscape Communicator umsteigen mußte und dankbarerweise TB (steht natürlich (!) für The Bat!, nicht für Thunderbird :-)) gefunden habe...
Ich muß gestehen, daß ich nicht den gesamten Thread durchgelesen habe. Viele scheinen ja schon grundsätzlich das Problem zu haben, TB zu installieren bzw. zu starten.
Ich wollte zunächst einmal mitteilen, daß bei mir TB 8.5.4 mit wine 5.3 (auf Void Linux (via Project Trident)) weitgehend funktioniert.
Ich muß allerdings hinzufügen, daß ich TB schon unter W7 seit einigen Jahren nicht mehr installiert habe, sondern den Installer entpackt und das Programm so quasi "portable" benutzt habe. Ja, TB, nicht TB Voyager! Und beim Umstieg auf Linux vor ca. 1 Wochen habe ich einfach den Ordner "mitgenommen" und die reg-Einträge importiert und angepasst.
Bisher sind mir zwei Dinge aufgefallen, die nicht oder zumindest nicht richtig funktionieren, was allerdings auch an der grundsätzlichen Konzeption von wine liegen kann.
1. Ich kann keine Anhänge auf den Desktop verschieben, sondern muß das Kontextmenü verwenden.
2. Der Maileditor (MicroEd) ignoriert den (bzw. beherrscht keinen) Zeilenumbruch. Der schreibt einfach über den Fenster- und ggf. Bildschirmrand hinaus.
Während ersteres eine Unannehmlichkeit ist, ist das zweite schon unfassbar lästig - und es betrifft auch den Zitatbereich.
In der Mailansicht des Hauptfenster bzw. im extra Mail-Lese-Fenster (per Doppelklick geöffnetes Fenster für Mails, die nicht im Editor geöffnet werden (sich nicht im Ausgangsordner befinden) funktioniert der Zeilenumbruch hingegen.
Nach einigem Testen mit der Registry habe ich eben herausgefunden, wo der Bug (2.) begraben liegt:
Es ist der Eintrag HKEY_CURRENT_USER\Software\RIT\The Bat!\Editor\"Format"=dword:
Sobald dieser einen anderen Wert als 0 (Null) hat, funktioniert der automatische Zeilenumbruch nicht mehr
Dieser Eintrag entspricht der Einstellung über das Menü: Optionen -> Benutzereinstellungen -> Betrachter | Editor -> Standard-Text-Editor. Wenn dort etwas anderes als "Nur-Text (Micro-Ed) - MicroStar-kompatibel" eingestellt ist, funktioniert der automatische Zeilenumbruch nicht.
Das dürfte dann wohl ein wine-Problem sein.
Bei dieser Testerei habe ich außerdem festgestellt, daß sich die v8.5.4 (32bit) problemlos auf wine 5.3 installieren läßt.
Die v8.5.4 benutze ich übrigens, weil Ritlab es bis heute nicht geschafft hat, den Bug 1639 zu beheben. Und das, obwohl sie den Bug früher schon einmal eingeführt und auf meinen Hinweis hin wieder behoben hatten.
