This also means the Solaris port will be unmaintained, unless the fbc developers continue working on it.
https://illumos.topicbox.com/groups/dis ... his-system
I divorced with OpenIndiana
-
- Posts: 215
- Joined: Dec 14, 2013 0:43
Re: I divorced with OpenIndiana
https://twitter.com/OpenIndiana/status/ ... 9562814466UPDATE: ICU version 66.1
This update is ABI-incompatible , make sure to recompile any local application against the new libraries.
Re: I divorced with OpenIndiana
FreeBASIC does not depend on libICU in any way.
Re: I divorced with OpenIndiana
I left because of the stupid memory model of that OS, nothing to do with the thing you mentioned. I always on the latest update of OpenIndiana Hipster.fatman2021 wrote:https://twitter.com/OpenIndiana/status/ ... 9562814466UPDATE: ICU version 66.1
This update is ABI-incompatible , make sure to recompile any local application against the new libraries.
Re: I divorced with OpenIndiana
I found the same thing when building FBC, too. So how does FBC deal with unicode support?caseih wrote:FreeBASIC does not depend on libICU in any way.
The only things I found so far are:
viewtopic.php?f=8&t=26856
viewtopic.php?f=8&t=29169
Re: I divorced with OpenIndiana
The compiler source code itself directly decodes UTF-8, 16, and 32 encodings when processing a source code file. The runtime itself only deals with ANSI or wide characters in memory. A WSTRING is 4-bytes per character on Linux, 2 bytes per character on Windows. Technically it's UTF-16 on Windows, but I don't think the runtime library has any concept of things like surrogate pairs. As near as I can tell the runtime library has zero support for unicode encoding and decoding, for example when reading and writing data to a file. FB does ship with a utility .bi file that implements UTF-8 encoding and decoding. But generally, speaking, FB has very little intrinsic understanding and support for unicode, much like other classic languages. At least compared to Unicode-native languages like Go, Python, etc.