- Welcome to PlanetSquires Forums.
PlanetSquires Forums
"It’s not a bug; it’s an undocumented feature" - Anonymous
Recent posts
#11
PlanetSquires Software / Re: Tiko - beta tests
Last post by Paul Squires - August 06, 2026, 08:24:33 PMThanks José,
As I feared, the larger font and spacing was too much. The OK, CANCEL don't fit on the dialog based on your display.
As I feared, the larger font and spacing was too much. The OK, CANCEL don't fit on the dialog based on your display.
#12
PlanetSquires Software / Re: Tiko - beta tests
Last post by José Roca - August 06, 2026, 05:30:58 PMQuote@José Roca if you have tried this beta then I would be interested to know if the dialog and font sizes are okay on your computer/laptop.
No. I guess there are "Ok" and "Cancel" buttons, but they aren't visible.
#13
PlanetSquires Software / Re: Tiko - beta tests
Last post by hajubu - August 06, 2026, 04:46:45 PMThanks, Paul.
Yes , I had edited the "OWL" for all the necessary entries manually.
therefore the results are the same , as what you did with the adapted defines and surrogates
Therefore my observation , said before, can be also confirmed with your edition.
a) The CLef-symbols IS NOT visualized in TIKO Editor : OWL is Visible as it should
b) FBC log text does not display the UNICODE symbols (by nature).
c) TODO/NOTES show a equivalent of the OWL in Black & White only
b.r. Hans
P.S: I'll try to understand the reason behind - then I'll will be back.
Yes , I had edited the "OWL" for all the necessary entries manually.
therefore the results are the same , as what you did with the adapted defines and surrogates
Therefore my observation , said before, can be also confirmed with your edition.
a) The CLef-symbols IS NOT visualized in TIKO Editor : OWL is Visible as it should
b) FBC log text does not display the UNICODE symbols (by nature).
c) TODO/NOTES show a equivalent of the OWL in Black & White only
b.r. Hans
P.S: I'll try to understand the reason behind - then I'll will be back.
#14
PlanetSquires Software / Re: Tiko - beta tests
Last post by Paul Squires - August 06, 2026, 04:04:37 PMThe problem is not the compiler, but rather the test code itself. The #DEFINE set at the top of the code has hardcoded values later in the test suite based on that value. Changing that value from a clef to an owl did not (obviously) change the hardcoded HI/LO values later in the test.
Use the attached test code file (in the zip) until I can update the Github repository.
Use the attached test code file (in the zip) until I can update the Github repository.
#15
PlanetSquires Software / Re: Tiko - beta tests
Last post by Paul Squires - August 06, 2026, 03:48:24 PMThe OWL produces the following error output:
USTRING usage showcase
FAIL m[1] is the HIGH surrogate got= 55358 want= 55348
FAIL m[2] is the LOW surrogate got= 56713 want= 56606
FAIL units recombine to U+1D11E got= 129417 want= 119070
142 checks, 3 failed
I'll post a fix/explanation as soon as I can.
USTRING usage showcase
FAIL m[1] is the HIGH surrogate got= 55358 want= 55348
FAIL m[2] is the LOW surrogate got= 56713 want= 56606
FAIL units recombine to U+1D11E got= 129417 want= 119070
142 checks, 3 failed
I'll post a fix/explanation as soon as I can.
#16
PlanetSquires Software / Re: Tiko - beta tests
Last post by hajubu - August 06, 2026, 03:10:39 PMthanks , Paul
I'm trying a little the USTRING, but I'm struggling withe visualization.
The character used in the showcase "ustring_usage_test_owl.bas" U+1D11E is not visible in TIKO.
The emoji OWL can be visualized as it show below.
I added/changes from the Musical Clef values to the values for OWL. )inclusive for the surrogate pair (hi,lo)
All 146 test running fine for both , but not the visibility for the clef.
Also the compiler log files do not show the symbol, which may by nature of the fbc.
Your TODO/NOTES TAB Panels show the OWL with the emoji for the black & white symbols.
The Musical Clef sees , do not have an equivilant (?).
b.r. Hans
I'm trying a little the USTRING, but I'm struggling withe visualization.
The character used in the showcase "ustring_usage_test_owl.bas" U+1D11E is not visible in TIKO.
The emoji OWL can be visualized as it show below.
I added/changes from the Musical Clef values to the values for OWL. )inclusive for the surrogate pair (hi,lo)
All 146 test running fine for both , but not the visibility for the clef.
Also the compiler log files do not show the symbol, which may by nature of the fbc.
Your TODO/NOTES TAB Panels show the OWL with the emoji for the black & white symbols.
The Musical Clef sees , do not have an equivilant (?).
b.r. Hans
Code Select
'#define ASTRAL wchr(&h1D11E) '' surrogates( hi:0xD834, lo:0xDD1E ) i.e. |𝄞| U+1D11E MUSICAL SYMBOL G CLEF)
'#define ASTRAL wchr(&h1F989) '' surrogates ( hi:0xD83E, lo:0xDD89 ) i.e. |🦉| U+1F989 OWL
#17
PlanetSquires Software / Re: Tiko - beta tests
Last post by Paul Squires - August 06, 2026, 09:11:28 AMHi Hans,
I tried doing so myself and the new toolchain did not show up under the list of available toolchains. Turns out there was a bug in the new PsListTree control that scrolled the first item off the top of the list (which happened to be that new toolchain). it's fixed now but not in the development branch because I am doing other major work off a feature sub-branch from development that I don't want to disturb.
To make things easier for you, I have attached the new tiko.exe with the fix included.
Just add the whole \fbc-win folder from the USTRING repo to the \toolchains folder off of Tiko. I renamed my new toolchain to fbc-win-USTRING so that I would know for sure what that toolchain does.
I tried doing so myself and the new toolchain did not show up under the list of available toolchains. Turns out there was a bug in the new PsListTree control that scrolled the first item off the top of the list (which happened to be that new toolchain). it's fixed now but not in the development branch because I am doing other major work off a feature sub-branch from development that I don't want to disturb.
To make things easier for you, I have attached the new tiko.exe with the fix included.
Just add the whole \fbc-win folder from the USTRING repo to the \toolchains folder off of Tiko. I renamed my new toolchain to fbc-win-USTRING so that I would know for sure what that toolchain does.
#18
PlanetSquires Software / Re: Tiko - beta tests
Last post by hajubu - August 06, 2026, 08:47:49 AMHi, just tried the new "UString" with fbc-win (1.20?) under the Toolchains within Tiko-beta.
How can we add the additional compiler with the help of the Settings options (Ctrl + ,).
I do know to add them manually in the settings.ini ( that worked).
Testing this with Tiko132 - it does offer to set the alternatives with the options (Shift + F7) as it find the new folder under the "Toolchains" by itself.
It would be a great support you could check the possibilities.
Thanks Hans (Hajubu)
How can we add the additional compiler with the help of the Settings options (Ctrl + ,).
I do know to add them manually in the settings.ini ( that worked).
Testing this with Tiko132 - it does offer to set the alternatives with the options (Shift + F7) as it find the new folder under the "Toolchains" by itself.
It would be a great support you could check the possibilities.
Thanks Hans (Hajubu)
#19
PlanetSquires Software / USTRING data type (built into ...
Last post by Paul Squires - August 06, 2026, 06:55:22 AMUSTRING: Universal String
A dynamic UTF-16 string type for FreeBASIC (Win/Linux, 32/64 bit)
Information and source found at the github repository: https://github.com/PaulSquires/USTRING
Full compiled FBC compiler toolchains for 32/64 Windows and Linux are included in the repository.
\fbc-win
\fbc-linux
USTRING is true intrinsic type, not a library.
USTRING is not a UDT, a class, a macro, or a header you #include. It is a data type inside the compiler, registered exactly the way ZSTRING and WSTRING are.
It replaces the need to use José's DWSTRING class in the AfxNova library.
The FB 1.20.0 source was directly modified so that USTRING becomes the 4th string data type in FB (along with STRING, ZSTRING, and WSTRING).
USTRING passes all FBC tests. To see the string in action, take a look at the ustring_usage_test.bas file located in the \tests subfolder. It showcases USTRING used every way the FB language allows. Every construct is checked, not just compiled, so it doubles as documentation you can trust.
Covered: every declaration form, dynamic and fixed, arrays (static, dynamic, multi-dimensional, initialised), UDTs, inheritance and virtual methods, properties, operator overloads, every parameter mode (BYVAL / BYREF / BYREF AS CONST, dynamic and fixed), pointers, and every return form (BYVAL, BYREF, fixed-length).
I hope to introduce USTRING to the FB maintainers for inclusion into the core FB compiler. It solves one of the most longstanding omissions in the FB core language - a dynamic unicode enabled string data type.
The core engine
Three things: a descriptor, an allocator, and hand-rolled primitives.
The pieces that matter:
ushort vs. extending wstring
WSTRING has two problems, and they're independent:
(1) it can't grow;
(2) its element width varies by platform — 2 bytes on Windows, 4 on Linux, 1 on DOS.
Extending WSTRING to be dynamic fixes (1) and leaves (2) — and (2) is the one that actually corrupts things. You'd end up with a dynamic string that's still UTF-16 on one target and UTF-32 on another: same source, different bytes on disk, different offsets, different LEN. It would also be a breaking change to a type whose sizeof and ABI programs already depend on.
So the element is uint16_t explicitly, never wchar_t — with a compile-time assert enforcing it. That's what makes the representation identical everywhere.
The subtle part is the no-libc rule, and it's the reason for spelling it uint16_t rather than "wchar_t where it happens to be 16 bits". On Windows they are the same width, so wcslen, wcsstr, towlower would link and appear to work perfectly. Using them there and hand-rolled code elsewhere is exactly how two platforms drift apart — which is the failure this type exists to remove. Same reasoning drove using a generated case table instead of towupper, and a fixed UTF-8 conversion instead of the C locale.
Why UTF-16 internally, not UTF-8
Deliberate trade:
Note this only concerns the in-memory form. Files are UTF-8 regardless, and STRING ↔ USTRING is UTF-8 on every target — so the UTF-16 choice never leaks into anything portable.
NEXT UP: Generics
Once Generics become a core FB language feature, it will be easy to have:
(1) Iterator protocol
(2) For Each: for each x in c
(3) Containers: Vector, Dictionary, Set, List
A dynamic UTF-16 string type for FreeBASIC (Win/Linux, 32/64 bit)
Information and source found at the github repository: https://github.com/PaulSquires/USTRING
Full compiled FBC compiler toolchains for 32/64 Windows and Linux are included in the repository.
\fbc-win
\fbc-linux
USTRING is true intrinsic type, not a library.
USTRING is not a UDT, a class, a macro, or a header you #include. It is a data type inside the compiler, registered exactly the way ZSTRING and WSTRING are.
It replaces the need to use José's DWSTRING class in the AfxNova library.
The FB 1.20.0 source was directly modified so that USTRING becomes the 4th string data type in FB (along with STRING, ZSTRING, and WSTRING).
USTRING passes all FBC tests. To see the string in action, take a look at the ustring_usage_test.bas file located in the \tests subfolder. It showcases USTRING used every way the FB language allows. Every construct is checked, not just compiled, so it doubles as documentation you can trust.
Covered: every declaration form, dynamic and fixed, arrays (static, dynamic, multi-dimensional, initialised), UDTs, inheritance and virtual methods, properties, operator overloads, every parameter mode (BYVAL / BYREF / BYREF AS CONST, dynamic and fixed), pointers, and every return form (BYVAL, BYREF, fixed-length).
I hope to introduce USTRING to the FB maintainers for inclusion into the core FB compiler. It solves one of the most longstanding omissions in the FB core language - a dynamic unicode enabled string data type.
The core engine
Three things: a descriptor, an allocator, and hand-rolled primitives.
Code Select
typedef struct _FBUSTRING {
FB_UCHAR *data; /* uint16_t, on every target */
ssize_t len; /* CODE UNITS, not bytes */
ssize_t size; /* allocated units, excl. terminator */
} FBUSTRING;
12 bytes on 32-bit, 24 on 64-bit — asserted at compile time against what symb-data.bas hardcodes, because if those disagree every ustring variable is the wrong size on the stack.The pieces that matter:
- Length is authoritative, the terminator is a courtesy. Every operation uses len, so embedded NULs survive and LEN is O(1). That's also why appending is O(1) amortised while WSTRING's is O(n²) — no walk to find the end.
- Size-discriminator ABI. Every entry point takes a (ptr, size) pair: -1 = var-len descriptor, size & FB_STRISFIXED = USTRING * N, 0 = raw units. Same scheme FBSTRING uses, so one function body serves all three forms.
- Temp-descriptor pool — 256 slots, identified by pointer range, with the temp flag in len's sign bit. Plus descriptor stealing, which is what keeps a = b + c + d linear instead of allocating per term.
- Geometric growth — (units + 15) & ~15 then +12.5% headroom (ustr_core.c:77).
- No libc wide functions. All primitives hand-written in ustr_prim.c.
ushort vs. extending wstring
WSTRING has two problems, and they're independent:
(1) it can't grow;
(2) its element width varies by platform — 2 bytes on Windows, 4 on Linux, 1 on DOS.
Extending WSTRING to be dynamic fixes (1) and leaves (2) — and (2) is the one that actually corrupts things. You'd end up with a dynamic string that's still UTF-16 on one target and UTF-32 on another: same source, different bytes on disk, different offsets, different LEN. It would also be a breaking change to a type whose sizeof and ABI programs already depend on.
So the element is uint16_t explicitly, never wchar_t — with a compile-time assert enforcing it. That's what makes the representation identical everywhere.
The subtle part is the no-libc rule, and it's the reason for spelling it uint16_t rather than "wchar_t where it happens to be 16 bits". On Windows they are the same width, so wcslen, wcsstr, towlower would link and appear to work perfectly. Using them there and hand-rolled code elsewhere is exactly how two platforms drift apart — which is the failure this type exists to remove. Same reasoning drove using a generated case table instead of towupper, and a fixed UTF-8 conversion instead of the C locale.
Why UTF-16 internally, not UTF-8
Deliberate trade:
- Bought: O(1) LEN and []; free Win32 ...W interop (a pointer reinterpret, no copy); semantics familiar from WSTRING-on-Windows.
- Paid: 2 bytes per character even for ASCII, and a surrogate pair counts as 2 for LEN — so MID can split one, exactly as on a WSTRING.
Note this only concerns the in-memory form. Files are UTF-8 regardless, and STRING ↔ USTRING is UTF-8 on every target — so the UTF-16 choice never leaks into anything portable.
NEXT UP: Generics
Once Generics become a core FB language feature, it will be easy to have:
(1) Iterator protocol
(2) For Each: for each x in c
(3) Containers: Vector, Dictionary, Set, List
#20
PlanetSquires Software / Re: Tiko - beta tests
Last post by Paul Squires - August 06, 2026, 05:33:21 AMExcellent, thanks Hans, appreciate it 