Profile pic

Marek Knápek, marekknapek@programming.dev

Instance: programming.dev
Joined: 2 years ago
Posts: 1
Comments: 4

Level 33 C++ sourcerer. https://about.me/marek.knapek

RSS feed

Posts and Comments by Marek Knápek, marekknapek@programming.dev


The main language of the app was English. The user could change it to German, French, Russian, Chinese, Spanish, etc. But sometimes the translation was not complete. Sometimes some plug-in was not translated. We used string IDs to identify various texts. Sometimes the ID pointed to the translated text, sometimes not, thus English version of that text was used instead.

Also I reported the bug in the visual style to Microsoft. They refused to fix it and said something like “don’t do that”.


Win32 MFC desktop application, should be able to run continuously unsupervised for days or weeks. When I log in via RDP it crashed. Yes, just in that moment. In the end I figured it out.

MFC supports multiple visual styles, such as classic Windows, few Office versions and few more. We used feature for loading (possibly translated) strings (resource) from various DLLs. First from a currently active plug-in DLL, if the string was not there, then from a sub-system DLL, if it was not there then from main EXE. Plus there was some logic about translation and fallback to English in case of missing or not up-to-date translation. The cause was in one of the MFC visual styles, it changed a global variable related to that string loading thing for a short duration of time, then changed it back. It was only in one of the styles and there was no need to change it, the code could just load the value and use it as a parameter to a function that needed it. Our code in a different thread failed to load a string and threw an exception. Cross a COM interface boundary. Every COM method is decorated by a bunch of macros our senior engineer didn’t understand and was not willing to learn. One of the macros was noexcept. Thus an exception being thrown cross an noexcept boundary crashed our app.


No! One code point could be encoded by up to 4 UTF-8 code units, not glyph. Glyphs do not map to code points one to one. One glyph could be encoded by more than one code point (and each code point could be encoded by more than one code unit). Code points are Unicode thing, code units are Unicode encoding thing, glyphs are font+Unicode thing. For example the glyph á might be single code point or two code points. Single code point because this is common letter in some languages, and was used in computers before Unicode was invented, two code points because this might be the base letter a followed by an diacritic combining mark. Not all diacritic letters have single code point variant. Also emojis, they are single glyph but multiple code points, for example skin tone modifier for various faces emojis, or male+female characters combined into single glyph forming a family glyph. Also country flags are single glyph, but multiple code points. Unicode is BIG, there are A LOT of stuff in it. For example sorting based on users language, conversion to upper/lower case is also not trivial (google the turkish i).


RSS feed

Posts by Marek Knápek, marekknapek@programming.dev

Comments by Marek Knápek, marekknapek@programming.dev


The main language of the app was English. The user could change it to German, French, Russian, Chinese, Spanish, etc. But sometimes the translation was not complete. Sometimes some plug-in was not translated. We used string IDs to identify various texts. Sometimes the ID pointed to the translated text, sometimes not, thus English version of that text was used instead.

Also I reported the bug in the visual style to Microsoft. They refused to fix it and said something like “don’t do that”.


Win32 MFC desktop application, should be able to run continuously unsupervised for days or weeks. When I log in via RDP it crashed. Yes, just in that moment. In the end I figured it out.

MFC supports multiple visual styles, such as classic Windows, few Office versions and few more. We used feature for loading (possibly translated) strings (resource) from various DLLs. First from a currently active plug-in DLL, if the string was not there, then from a sub-system DLL, if it was not there then from main EXE. Plus there was some logic about translation and fallback to English in case of missing or not up-to-date translation. The cause was in one of the MFC visual styles, it changed a global variable related to that string loading thing for a short duration of time, then changed it back. It was only in one of the styles and there was no need to change it, the code could just load the value and use it as a parameter to a function that needed it. Our code in a different thread failed to load a string and threw an exception. Cross a COM interface boundary. Every COM method is decorated by a bunch of macros our senior engineer didn’t understand and was not willing to learn. One of the macros was noexcept. Thus an exception being thrown cross an noexcept boundary crashed our app.


No! One code point could be encoded by up to 4 UTF-8 code units, not glyph. Glyphs do not map to code points one to one. One glyph could be encoded by more than one code point (and each code point could be encoded by more than one code unit). Code points are Unicode thing, code units are Unicode encoding thing, glyphs are font+Unicode thing. For example the glyph á might be single code point or two code points. Single code point because this is common letter in some languages, and was used in computers before Unicode was invented, two code points because this might be the base letter a followed by an diacritic combining mark. Not all diacritic letters have single code point variant. Also emojis, they are single glyph but multiple code points, for example skin tone modifier for various faces emojis, or male+female characters combined into single glyph forming a family glyph. Also country flags are single glyph, but multiple code points. Unicode is BIG, there are A LOT of stuff in it. For example sorting based on users language, conversion to upper/lower case is also not trivial (google the turkish i).