Delphi’s NextGen compiler (Android, IOS) removed support for UTF8String, AnsiString and RawByteString. But if you look into System.pas you see that those types are still there but Embarcadero makes them inaccessible from outside of System.pas by prefixing them with an underscore that the compiler converts to the at-sign. And you can’t write “@UTF8String” as it is not a valid identifier.
By patching DCU files it is possible to make those hidden types accessible. And guess what, the compiler generates correct code for the “unsupported” strings.
The unit System.ByteStrings reintroduces:
- ShortString
- AnsiString
- AnsiChar
- PAnsiChar
- PPAnsiChar
- UTF8String
- PUTF8String
- RawByteString
- PRawByteString
Usage:
Add the System.ByteStrings.dcu’s path to the compiler’s search path and add the unit to your uses clauses.
There is no *.PAS file because the DCU is patched with a hex editor to get access to the hidden types.
| Name | IDE Version | File | Size | Downloads | Added |
|---|---|---|---|---|---|
| System.ByteStrings | XE5 RTM/UP1 only | XE5ByteStrings.7z | 2.45 KB | 1578 times | 2013-10-23 |
| System.ByteStrings | XE5 UP2 only | XE5Up2ByteStrings.7z | 2.85 KB | 1504 times | 2013-12-20 |
| System.ByteStrings | XE6 | XE6ByteStrings.7z | 2.89 KB | 1337 times | 2014-04-16 |
| System.ByteStrings | XE7 | XE7ByteStrings.7z | 2.89 KB | 1667 times | 2015-01-20 |
| System.ByteStrings | XE8 | XE8ByteStrings.7z | 3.69 KB | 1724 times | 2015-04-16 |
| System.ByteStrings | 10 Seattle | D10ByteStrings.7z | 3.67 KB | 1906 times | 2015-09-01 |
| System.ByteStrings | 10.1 Berlin | D101ByteStrings.7z | 3.72 KB | 2376 times | 2016-05-31 |
Hi Andy, this was so extremely lightning fast, thank you very much!
There wasn’t much work to do: Change the BDS directory in the build script from “15.0” to “16.0”. Start build.bat.
Was there a good reason that these types were removed by EMBT? Will this patch cause any incompatibilities anywhere else?
The reason was “we have too many String types and new customers can get confused”. There are no incompatiblities. The RTL and compiler still have full support for Byte-Strings but they were disabled by making it impossible to declare variables.
But you should only use those types if you really need them (backward compatibility). It is always better to use “string” if you can because there may come a time when EMBT completely removes the Byte-String functionality. New code should always use “string” or TBytes+TEncoding.
This is a bad decision to remove ByteStrings. No reason to do this.
They are reducing the cross-platform compatibility of Delphi code. Now desktop libraries will have to be forced to use Unicode strings if they want to stay compatible with mobile applications.
Plus ByteStrings are a very useful feature. Lots of processing is done on bytes (e.g. protocols) that don’t involve UI.
Pingback: Unofficial ByteStrings Patch To Enable AnsiString Support In Delphi XE8 Firemonkey On Android And IOS | Delphi XE5 XE6 XE7 XE8 Firemonkey, Delphi Android, Delphi IOS
The dcu for the platform iOSDevice64 is missing. Can you provide a fix?
Regards
CTB
The XE8 download is now updated to include the iosDevice64 folder and the iosDevice folder was renamed to iosDevice32.
Pingback: Delphi XE8 things I learned from the first week of G+ reading « The Wiert Corner – irregular stream of stuff
Pingback: Delphi AnsiString in Android App - Seite 3 - Delphi-PRAXiS
Pingback: Delphi XE8/C++Builder XE8に対応済みのコンポーネントやツール - 山本隆の開発日誌