The full code is of course somewhat longer but I am essentially following this C/C++ code to set up the console: https://github.com/OneLoneCoder/videos/blob/master/olcConsoleGameEngine.h
Now this works fine with ASCII characters, however it appears that characters wrap around once you hit 256.
#ifndef UNICODE #error Please enable UNICODE for your compiler! VS: Project Properties -> General -> \ Character Set -> Use Unicode. Thanks! - Javidx9 #endif
That would make perfect sense if WriteConsoleOutput() maps to WriteConsoleOutputA() instead of to WriteConsoleOutputW(). Which is likely the case given that FreePascal still uses Ansi strings and Ansi RTL/Win32 functions by default.
That means the C/C++ code requires WriteConsoleOutput() to map to WriteConsoleOutputW(), not to WriteConsoleOutputA(). So, in your code, just call WriteConsoleOutputW() directly, then it should write your UnicodeChar values as expected.
That would make perfect sense if WriteConsoleOutput() maps to WriteConsoleOutputA() instead of to WriteConsoleOutputW(). Which is likely the case given that FreePascal still uses Ansi strings and Ansi RTL/Win32 functions by default.
No, it won't. Stop spreading such nonsense. >:( It depends on whether the Windows unit is compiled with FPC_OS_UNICODE is set or not. Aside from that changing the mode would not affect a compiled unit as modes and modeswitches are specific to the units its used in (and those passed on the command line only apply to those that are compiled)I tested it! It is not nonsense. Although I might have used a full unicode version, that's true. I might also have the sourcecode in the path anyway.
(that latter is not true, the core RTL uses W functions since 3.0, and most functions are overloaded ansistring/unicodestring, things like \\?\ escapes therefore also work)Things like \\?\ works well in ANSI and Unicode. Internal "A" functions simply converts strings to Unicode and then calls "W" functions.
Things like \\?\ works well in ANSI and Unicode.
Internal "A" functions simply converts strings to Unicode and then calls "W" functions.
Do not understand the logic. I can also say that some APIs do not work in old Windows, some only on servers. I'm talking about the \\?\., which work in ANSI as well. Of course, if there is no function, then there is nothing to perform.Things like \\?\ works well in ANSI and Unicode.Not always. Some APIs support them only in the Unicode versions and not in the ANSI versions.
I'm talking about the \\?\., which work in ANSI as well. Of course, if there is no function, then there is nothing to perform.
Prepending "\\?\" to a path only works in Unicode functions, and even then only the functions that are documented to support it. Whether or not the corresponding ANSI functions pass such a path string to their Unicode counterparts is handled on a per-function basic, and there are ANSI functions that do not do this.No! For example from https://docs.microsoft.com/en-us/windows/desktop/LearnWin32/working-with-strings (https://docs.microsoft.com/en-us/windows/desktop/LearnWin32/working-with-strings) "Internally, the ANSI version translates the string to Unicode".