- Welcome to Pelles C forum.
Pelles C forum
News:
Download Pelles C here: http://www.pellesc.se
Recent posts
#71
Tips & tricks / Re: UTF-8 multilanguage consol...
Last post by TimoVJL - September 18, 2026, 12:14:50 PMWindows 7 have Consolas font, but version 5.? and Windows 1x have version 7 font family.
Less interest to console, albeit file / folder names can have many kind of chars.
Less interest to console, albeit file / folder names can have many kind of chars.
#72
Tips & tricks / Re: UTF-8 multilanguage consol...
Last post by Michele - September 18, 2026, 09:26:00 AMTimovjl you successfully changed the codepage to UTF-8, in fact many characters are correctly displayed.
I agree that now the problem is the console font that doesn't contains the full set.
A known font known to render all charset is 'Consolas', try changing the face font with:
If still doesn't it confirms that the fonts in your OS version are limited.
You said that on a Win10/11 system it works?
I agree that now the problem is the console font that doesn't contains the full set.
A known font known to render all charset is 'Consolas', try changing the face font with:
Code Select
BOOL SetConsoleFontToConsolas(void)
{
HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
if (hConsole == INVALID_HANDLE_VALUE) return FALSE;
CONSOLE_FONT_INFOEX cfi;
cfi.cbSize = sizeof(CONSOLE_FONT_INFOEX);
// Get the current font info first to preserve defaults
if (!GetCurrentConsoleFontEx(hConsole, FALSE, &cfi))
{
return FALSE;
}
// Set font properties
cfi.dwFontSize.X = 0; // Width (0 lets Windows calculate based on height)
cfi.dwFontSize.Y = 16; // Height (Font size in points/pixels)
cfi.FontFamily = FF_DONTCARE;
cfi.FontWeight = FW_NORMAL;
// Specify a TrueType font that supports UTF-8 Unicode characters
// Common choices: L"Cascadia Code", L"Consolas", L"Lucida Console"
wcscpy_s(cfi.FaceName, LF_FACESIZE, L"Consolas");
// Apply the new font
return SetCurrentConsoleFontEx(hConsole, FALSE, &cfi);
}If still doesn't it confirms that the fonts in your OS version are limited.
You said that on a Win10/11 system it works?
#73
Tips & tricks / Re: UTF-8 multilanguage consol...
Last post by TimoVJL - September 18, 2026, 09:03:07 AMWindows 7 x64 EN console.
Less fonts than Windows 1x versions.
Less fonts than Windows 1x versions.
#74
Tips & tricks / Re: UTF-8 multilanguage consol...
Last post by Michele - September 17, 2026, 10:06:40 PMHello Vortex, I imagine that the problem is the OS version.
I will not add mine, just report what Gemini says:
I will not add mine, just report what Gemini says:
QuoteThe functions SetConsoleOutputCP and SetConsoleCP along with the CP_UTF8 code page constant (code page 65001) have been supported since Windows 2000.
However, the minimal OS version depends on what you are trying to achieve:
Basic Function Support (API availability): Windows 2000 or later. Calling SetConsoleOutputCP(65001) is supported on all Windows NT-based OS versions starting from 2000, as well as Windows XP, Vista, 7, 8, and 10.
Functional UTF-8 Console Rendering: Windows 10 Version 1903 (Build 18362) or later.
Why the distinction matters:
While the functions exist on older OS versions, UTF-8 support inside cmd.exe on legacy releases (Windows 7/8/early Win 10) was notoriously buggy:
Legacy Bugs: On older versions like Windows 7, setting the console to code page 65001 frequently broke C runtime output routines (printf), caused character truncation, or crashed batch scripts.
Font Rendering: Legacy consoles couldn't render multi-byte UTF-8 sequences properly unless using specific TrueType fonts.
Full ConPTY Overhaul: Microsoft fully overhauled the Windows Console infrastructure in Windows 10 version 1903 (Build 18362)—the exact same release that introduced manifest-based UTF-8 ACP support—making UTF-8 output reliable and stable in the terminal.
#75
Tips & tricks / Re: UTF-8 multilanguage consol...
Last post by Vortex - September 17, 2026, 10:01:22 PMHi Michele,
Thanks for your code. Testing your executable on my Windows 7 Sp1 64-bit, I get a lot of garbled characters, probably a limitation of Windows 7.
Thanks for your code. Testing your executable on my Windows 7 Sp1 64-bit, I get a lot of garbled characters, probably a limitation of Windows 7.
#76
Tips & tricks / UTF-8 with windows mixed ANSI/...
Last post by Michele - September 17, 2026, 09:52:41 PMThis other example shows how to use the manifest to change the process codepage for a window program.
When we change the process codepage to UTF-8 the ANSI version of many (warning not all!) windows messages automatically translates from process codepage to internal UTF-16 (unicode) format.
Winapi explicitly allows the mixed use of ANSI and WIDE messages providing behind the scenes the translation from between the process codepage and unicode. This means that you can create an ANSI window/control and send to it wide messages or the reverse, and also means that you are free to create a unicode or ansi application as you like and use which encoding you prefer.
But if your codepage doesn't cover the whole range of alphabets, i.e. if you use a typical latin western 1252 encoding, supplying an utf8 string will produce garbage output.
The trick is to set the process codepage to UTF-8 using the specific manifest command, but this feature has benn introduced starting from Windows 10 Version 1903 (Build 18362), and will be silently ignored in previous versions. The manifest code is:
The idea was born creating a program based on sqlite3 that is UTF-8 based.
If your system does'nt supports the process codepage change you can use the standar conversion functions:
When we change the process codepage to UTF-8 the ANSI version of many (warning not all!) windows messages automatically translates from process codepage to internal UTF-16 (unicode) format.
Winapi explicitly allows the mixed use of ANSI and WIDE messages providing behind the scenes the translation from between the process codepage and unicode. This means that you can create an ANSI window/control and send to it wide messages or the reverse, and also means that you are free to create a unicode or ansi application as you like and use which encoding you prefer.
But if your codepage doesn't cover the whole range of alphabets, i.e. if you use a typical latin western 1252 encoding, supplying an utf8 string will produce garbage output.
The trick is to set the process codepage to UTF-8 using the specific manifest command, but this feature has benn introduced starting from Windows 10 Version 1903 (Build 18362), and will be silently ignored in previous versions. The manifest code is:
Code Select
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
</windowsSettings>
</application>
The attached sample demonstrate how it works. You can test it in both versions ANSI and WIDECHAR, just change the '#if 1' to '#if 0' to compile in ANSI mode.The idea was born creating a program based on sqlite3 that is UTF-8 based.
If your system does'nt supports the process codepage change you can use the standar conversion functions:
Code Select
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
// 1. UTF-8 (multibyte char*) -> UTF-16 (wchar_t*)
wchar_t* Utf8ToUtf16(const char* utf8_str) {
if (!utf8_str) return NULL;
// Get required buffer size in wchar_t elements (including null-terminator)
int size_needed = MultiByteToWideChar(CP_UTF8, 0, utf8_str, -1, NULL, 0);
if (size_needed == 0) return NULL;
wchar_t* wstr = (wchar_t*)malloc(size_needed * sizeof(wchar_t));
if (!wstr) return NULL;
// Perform conversion
MultiByteToWideChar(CP_UTF8, 0, utf8_str, -1, wstr, size_needed);
return wstr; // Caller must free()
}
// 2. UTF-16 (wchar_t*) -> UTF-8 (multibyte char*)
char* Utf16ToUtf8(const wchar_t* wstr) {
if (!wstr) return NULL;
// Get required buffer size in bytes (including null-terminator)
int size_needed = WideCharToMultiByte(CP_UTF8, 0, wstr, -1, NULL, 0, NULL, NULL);
if (size_needed == 0) return NULL;
char* utf8_str = (char*)malloc(size_needed);
if (!utf8_str) return NULL;
// Perform conversion
WideCharToMultiByte(CP_UTF8, 0, wstr, -1, utf8_str, size_needed, NULL, NULL);
return utf8_str; // Caller must free()
}
#77
Tips & tricks / UTF-8 multilanguage console pr...
Last post by Michele - September 17, 2026, 08:38:58 PMSomewhere on this forum there was a discussion about how to print multilanguage strings on console output.
The small attached sample shows the code that use the console codepage set functions using the UTF-8 encoding that is, at least for me, a very powerful option because while allows the multilanguage text let you use the simple and efficient ansi text functions (strcpy, ctrcat, strcmp, ...).
The small attached sample shows the code that use the console codepage set functions using the UTF-8 encoding that is, at least for me, a very powerful option because while allows the multilanguage text let you use the simple and efficient ansi text functions (strcpy, ctrcat, strcmp, ...).
#78
Add-ins / Re: Add-Ins
Last post by TimoVJL - September 17, 2026, 04:45:37 PMWhen someone want to see compiled C-code in assembler, easist way is to use Add-In, that show podump.exe output from object file in poide Output window in easy way.
The poide have over 50 Add-Ins with source code, so lot of code for everyone to study.
https://forum.pellesc.de/index.php?msg=29747
The poide have over 50 Add-Ins with source code, so lot of code for everyone to study.
https://forum.pellesc.de/index.php?msg=29747
#79
Add-ins / Re: Add-Ins
Last post by John Z - September 14, 2026, 09:55:47 PMDefinitely agree with you Timo ! The ability to do Add-In's is exceptional. User feature requests are where I started to develop Add-In's from requests for simple button on the toolbar to Linecounter+ to Copy Mode and Hint. You are the king of the Add-In's in my book.
Many might not know that a few revision back Pelle significantly enhanced the Add-In's capability for the Debug mode. Seems like a lot of potential there.
John Z
Many might not know that a few revision back Pelle significantly enhanced the Add-In's capability for the Debug mode. Seems like a lot of potential there.
John Z
#80
Bug reports / warning #2131 fires on defined...
Last post by KEL26 - September 12, 2026, 08:18:54 PMSubject: warning #2131 fires on defined shifts, and on expressions with no shift
Pelles C 14.50, Windows x64 and x86. At every optimisation level, and never
without one, the compiler reports undefined behaviour that is not present.
Minimal case, no headers needed:
Compiled with:
gives, one for each function:
Two things about that.
FIRST, the shift in pack_a is not undefined. in[1] & 0x0f is subject to the
usual arithmetic conversions, so the left operand of << has type int, with a
value of at most 15. Shifting it by 8 is fully defined.
SECOND, pack_b contains no shift operator at all. The multiplication by 256
is being rewritten as a shift, and the message then describes the rewritten
form as though it were what was written.
Remove the /O switch and both warnings disappear, on both targets, which is
what places this in an optimisation stage rather than the front end.
WHAT IS AND IS NOT AFFECTED
Sixteen one-line cases were compiled in twenty-four configurations: four
optimisation settings, two targets, three warning levels. The same six lines
warn in every configuration that has a /O switch, and none warns without one.
the same right-hand side, assigned to unsigned char warns
... to signed char warns
... to unsigned short, short, int, unsigned silent
the multiplication form, to unsigned char warns
the multiplication form, to unsigned short silent
shift by 7, to unsigned char silent
shift by 9, to unsigned char warns, "by 9 bits"
So the destination width decides it, and the shift count is being compared
against 8 rather than against the width of int.
The message also mis-spells the type for a signed char destination:
THE GENERATED CODE IS CORRECT
This is a diagnostic matter only. The same computation was run over all
65,536 input pairs under four Pelles C builds -- no /O, -Ot, -Os, -Ox -- and
under a second C compiler. All five produced identical checksums, 8355840 for
the 8-bit destination and 134184960 for the 16-bit one. Nothing is
miscompiled.
WHY IT IS WORTH FIXING
That expression is the ordinary way to unpack two 12-bit samples from three
bytes, and it appears verbatim in a widely used image library, inside a block
guarded by a run-time test for 12-bit precision. A build kept deliberately
clean gains a warning that says "undefined" about code that has none.
The condition being detected does look like a real one: the shifted bits are
lost in the narrowing conversion. The compiler already has #2215, "possible
loss of data or unexpected result", and emits it elsewhere in the same build.
Reporting these sites as #2215 would say something true.
A self-contained reproducer, the sixteen-case file, the value comparison and
a script that regenerates every figure above are attached.
Pelles C 14.50, Windows x64 and x86. At every optimisation level, and never
without one, the compiler reports undefined behaviour that is not present.
Minimal case, no headers needed:
Code Select
typedef unsigned char u8;
void pack_a(const u8 *in, u8 *out)
{
out[0] = (u8)(((in[1] & 0x0f) << 8) | in[2]);
}
void pack_b(const u8 *in, u8 *out)
{
out[0] = (u8)((((int)in[1]) & 0x0f) * 256 | in[2]);
}
Compiled with:
Code Select
pocc -Tx64-coff -std:C17 -Ze -Zx -Go -Ot -W1 -c d006_minimal.c
gives, one for each function:
Code Select
warning #2131: Shifting an 'unsigned char' by 8 bits is undefined.
Two things about that.
FIRST, the shift in pack_a is not undefined. in[1] & 0x0f is subject to the
usual arithmetic conversions, so the left operand of << has type int, with a
value of at most 15. Shifting it by 8 is fully defined.
SECOND, pack_b contains no shift operator at all. The multiplication by 256
is being rewritten as a shift, and the message then describes the rewritten
form as though it were what was written.
Remove the /O switch and both warnings disappear, on both targets, which is
what places this in an optimisation stage rather than the front end.
WHAT IS AND IS NOT AFFECTED
Sixteen one-line cases were compiled in twenty-four configurations: four
optimisation settings, two targets, three warning levels. The same six lines
warn in every configuration that has a /O switch, and none warns without one.
the same right-hand side, assigned to unsigned char warns
... to signed char warns
... to unsigned short, short, int, unsigned silent
the multiplication form, to unsigned char warns
the multiplication form, to unsigned short silent
shift by 7, to unsigned char silent
shift by 9, to unsigned char warns, "by 9 bits"
So the destination width decides it, and the shift count is being compared
against 8 rather than against the width of int.
The message also mis-spells the type for a signed char destination:
Code Select
warning #2131: Shifting an 'char' by 8 bits is undefined.
THE GENERATED CODE IS CORRECT
This is a diagnostic matter only. The same computation was run over all
65,536 input pairs under four Pelles C builds -- no /O, -Ot, -Os, -Ox -- and
under a second C compiler. All five produced identical checksums, 8355840 for
the 8-bit destination and 134184960 for the 16-bit one. Nothing is
miscompiled.
WHY IT IS WORTH FIXING
That expression is the ordinary way to unpack two 12-bit samples from three
bytes, and it appears verbatim in a widely used image library, inside a block
guarded by a run-time test for 12-bit precision. A build kept deliberately
clean gains a warning that says "undefined" about code that has none.
The condition being detected does look like a real one: the shifted bits are
lost in the narrowing conversion. The compiler already has #2215, "possible
loss of data or unexpected result", and emits it elsewhere in the same build.
Reporting these sites as #2215 would say something true.
A self-contained reproducer, the sixteen-case file, the value comparison and
a script that regenerates every figure above are attached.