Can I just ask a simple question, please?
Why have the recent releases been classed as ALPHAs and not BETAs?
Are they expected by RITlabs to be less stable?
Thank you for the good question!
We are using the following the following designations, from least to most stable: alpha, beta, gamma (didn’t actually use gamma so far).
We have made changes that made the program very unstable, and it even didn’t run on some processors. The summary of changes in the alpha series is the following:
1. Updated HTML editor component. For the HTML editor, we are using TRichView from trichivew.com. Previously, we were using TRichView 14.5.2, released on 21 May 2013, and we were introducing our own fixes into it. In the open-source community it would have said “TRichView 14.5.2 fork”. In May 2017 we took TRichView 16.15.1, released on 27 March 2017 and implemented it into The Bat!. To do that, we have analysed the differences that we have included into the “TRichView 14.5.2 fork” between 23 May 2013 and 27 March 2017. In future, we plan to always stay on the latest version of TRichView. We will be always getting latest version of TRichView and include it into The Bat!, when the latest version of TRichView come out. What are the most notable changes of TRichView 16.15.1 since TRichView 14.5.2? Not necessarily yet all the new features of TRichView are implemented in The Bat. Here is the list (taken from the http://www.trichview.com/
• text formatting:
o the components render bi-directional text and “exotic” scripts reliably, due to use of Uniscribe library;
o justify” alignment and custom character spacing now can be applied to bi-directional text;
o new paragraph alignment type: “distribute” ; distributed paragraphs are similar to justified paragraphs, but space is added between all characters, not between words; this type of alignment is common for Far East languages http://www.trichview.com/shots/alignment-distribute.png
o customized alignment for the last line of justified and distributed paragraphs;
o special options for vertical text in table cells (automatic application of vertical fonts and switching column order from right-to-left to left-to-right) http://www.trichview.com/shots/traditional-mongolian.png
• visual improvements:
o the users can define a customized degree of transparency for backgrounds of paragraphs, tables, table cells, text boxes;
o user interface is compatible with high-DPI display modes.
2. Improved memory manager. The source code of it is available at https://github.com/maximmasiutin/FastMM4 This is a fork of the latest version of FastMM4 by Pierre le Riche. What we have added to the fork:
• if the CPU supports Enhanced REP MOVSB/STOSB (ERMS), use this feature for faster memory copy or large memory blocks (under 32 bit or 64-bit);
• if the CPU supports AVX or AVX2, use the 32-byte (256 bit) YMM registers for faster memory copy;
• memory copy is secure - all XMM/YMM registers used to copy memory are cleared by vxorps/vpxor, so the leftovers of the copied memory are not exposed in the XMM/YMM registers;
• properly handle AVX-SSE transitions to not incur the transition penalties, only call vzeroupper under AVX1, but not under AVX2 since it slows down subsequent SSE code under Kaby Lake;
• 32-bit version checks whether the CPU supports MMX, to run on very old CPUs or in environments where MMX is disabled; in this case FPU is used to copy data.3. Memory fill base function (FillChar) for 64-bit is improved; used one from Delphi 10.2, bugs fixed, ERMS handing improved, added support for AVX/AVX2. It turned out to be the fastest implementation of memory fill I’ve seen so far. See https://stackoverflow.com/questions/4395…624111#44624111 and https://stackoverflow.com/questions/4395…-release-target for more information. Todo: support for AVX-512 in the memory fill.
4. Memory move/copy base function (Move) for 64-bit is written from scratch. Uses EMRS/SSE/AVX/AVX2 – whatever is available. It is many times faster than the standard one that came with Delphi 10.2. Didn’t have other implementations to compare. Todo: support for AVX-512 in the memory copy/move.
TODO: various changes to increase stability, fix bugs, improve performance. One area is to utilize multiple cores whenever possible; for example, for data compression, etc.
All these changes are major and inherently unstable. That’s why we’ve called that version Alpha.
--
Maxim Masiutin
Director
Ritlabs, SRL
Bei mir ist in dieser Version das Programm-Icon nicht mehr vollständig dargestellt. Der untere und rechte Rand sind abgeschnitten (Windows 7).
[-] (#0000876) Modal dialog boxes with modal window frame have an icon that overlaps text on Windows XP computers
Bei mir ist in dieser Version das Programm-Icon nicht mehr vollständig dargestellt. Der untere und rechte Rand sind abgeschnitten (Windows 7).
Ich kann unter 7 bestätigen, dass Icons jetzt abgeschnitten sind. Wahrscheinlich sieht's in allen Windows-Versionen genauso aus.
Im BT-Eintrag #0000876 sind Screenshots vorhanden, wie das unter XP aussah. Wahrscheinlich aber auch nur, wenn man die klassische Ansicht gewählt hat. Ich konnte das allerdings mit der klassischen Ansicht unter 7 nicht nachvollziehen. Also muss das ein XP-only Bug gewesen sein. Jedenfalls hat man jetzt in vielen Dialogen Icons ganz entfernt (z.B. Benutzereinstellungen) und in den übrigen abgeschnitten bzw. ersetzt (sieht nämlich auch nach einer niedrigeren Bildauflösung aus), damit sie wohl die Überschriften nicht verdecken.
Ich habe im BT etwas dazu geschrieben. Mal sehen, was passiert.
[-] Fixed html editor dialog translations
Folgende Bugs sind jetzt beseitigt:
Die entsprechenden Dialoge sind jetzt also alle komplett auf Deutsch, wenn man die deutsche Sprache eingestellt hat.
Ich habe im BT etwas dazu geschrieben. Mal sehen, was passiert.
Max meint im BT, dass Delphi nicht zwischen großen und kleinen Icons differenziert. Daher haben die TB!-Entwickler früher geänderte Delphi-Dateien verwendet, was wohl u.a. zu dem in #0000876 beschriebenen Problem unter WinXP geführt hat. Jetzt haben sie wieder auf Standard umgestellt und das führt dazu, dass obwohl in der EXE-Datei auch kleine 16x16 Icons enthalten sind, für die Titelleisten herunterskalierte große 48x48 Icons verwendet werden. Ich habe im BT einen Screenshot mit ein paar Beispielen angehängt. Es betrifft also nicht nur die Titelleiste des Hauptfensters, sondern auch z.B. des Adressbuches, des Suchdialogs und des Terminplaners.
Max hat dazu bereits im Stack Overflow (das ist eine Art Board für Programmierer) gepostet, da das ein Delphi-Problem ist, und im Übrigen empfohlen, im Ritlabs BT einen neuen Eintrag zu erstellen. Meiner Bitte, die Änderungen rückgängig zu machen, will er wohl nicht entsprechen. Es wird also bei den herunterskalierten Icons so lange bleiben, bis eine Lösung gefunden ist.
