\nA colleague was investigating a problem with a third party\napplication and found an unusual window class name:\nL”整瑳整瑳”.\nHe remarked,\n“This looks quite odd and could be some problem with the application.”\n<\/p>\n
\nThe string is nonsense in Chinese,\nbut I immediately recognized what was up.\n<\/p>\n
\nHere’s a hint:\nRewrite the string as\n<\/p>\n
\nL”\\x6574″ L”\\x7473″ L”\\x6574″ L”\\x7473″\n<\/p><\/blockquote>\n
\nStill don’t see it?\nHow about looking at the byte sequence,\nremembering that Windows uses UTF-16LE.\n<\/p>\n
\n0x74 0x65 0x73 0x74 0x74 0x65 0x73 0x74\n<\/p><\/blockquote>\n
\nOkay, maybe you don’t have your ASCII table memorized.\n<\/p>\n
\n\n
\n 0x74<\/td>\n 0x65<\/td>\n 0x73<\/td>\n 0x74<\/td>\n 0x74<\/td>\n 0x65<\/td>\n 0x73<\/td>\n 0x74<\/td>\n<\/tr>\n \n t<\/td>\n e<\/td>\n s<\/td>\n t<\/td>\n t<\/td>\n e<\/td>\n s<\/td>\n t<\/td>\n<\/tr>\n<\/table>\n<\/blockquote>\n \nThat’s right, the application took the ASCII string\n“testtest” and just treated it as a Unicode string\nwithout actually converting it to Unicode.\nWhen the compiler complained “Cannot convert char * to wchar_t *”\nthey just stuck a cast to make the compiler shut up.\n<\/p>\n
\n\/\/ Code in italics is wrong\nWNDCLASSW wc;\nwc.lpszClassName = (LPWSTR)\"testtest\";<\/i>\n<\/pre>\n\nThey were lucky that the compiler happened to put\ntwo<\/i> null bytes at the end of the “testtest” string.\n<\/p>\n
\nBonus psychic powers<\/b>: Actually, I have a theory\nas to how this happened that doesn’t involve maliciousness.\n(This is generally a good mindset to maintain,\nsince most of the time, when people cause a problem,\nit’s not willful; it’s accidental.)\nConsider a library with the following interface header file:\n<\/p>\n
\n\/\/ mylib.h\n#ifdef __cplusplus\nextern \"C\" {\n#endif\nBOOL RegisterWindowClass(LPCTSTR pszClassName);\n#ifdef __cplusplus\n}; \/\/ extern \"C\"\n#endif\n<\/pre>\n\nSomebody uses this header file like this:\n<\/p>\n
\n#include <mylib.h>\nBOOL Initialize()\n{\n return RegisterWindowClass(TEXT(\"testtest\"));\n}\n<\/pre>\n\nSo far so good.\n<\/p>\n
\nMeanwhile, the library implementation goes like this:\n<\/p>\n
\n#define UNICODE\n#define _UNICODE\n#include <mylib.h>\nLRESULT CALLBACK StandardWndProc(HWND, UINT, WPARAM, LPARAM);\nBOOL RegisterWindowClass(LPCTSTR pszClassName)\n{\n WNDCLASS wc = { 0, StandardWndProc, 0, 0, g_hInstance,\n LoadIcon(IDI_APPLICATION),\n LoadCursor(IDC_ARROW),\n (HBRUSH)(COLOR_WINDOW + 1),\n NULL, pszClassName);\n return RegisterClass(&wc);\n}\n<\/pre>\n\nThe two files both compile successfully, and they even link together.\nUnfortunately, one of them was compiled with Unicode disabled,\nand the other was compiled with Unicode enabled.\nSince the header file uses
LPCTSTR<\/code>,\nthe actual declaration ofRegisterWindowClass<\/code>\nchanges<\/i> depending on whether the code that includes\nthe header file is compiled as Unicode or ANSI.\n<\/p>\n\nResult: If one file is compiled as ANSI and the other is\ncompiled as Unicode, then one will pass an ANSI string,\nwhich the other will receive and treat as Unicode.\n<\/p>\n
\nThis is why functions in Windows which are dependent on\nwhether the caller is compiled as ANSI or Unicode\nare really two functions, one with the A suffix (for ANSI)\nand another with the W suffix (for Wnicode?), and the\ngeneric name is really a macro that forwards to one or the\nother.\nIt prevents
TCHAR<\/code>s from sneaking past the compiler\nand ending up being interpreted differently by the two sides.<\/p>\n","protected":false},"excerpt":{"rendered":"A colleague was investigating a problem with a third party application and found an unusual window class name: L”整瑳整瑳”. He remarked, “This looks quite odd and could be some problem with the application.” The string is nonsense in Chinese, but I immediately recognized what was up. Here’s a hint: Rewrite the string as L”\\x6574″ L”\\x7473″ […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-7983","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
A colleague was investigating a problem with a third party application and found an unusual window class name: L”整瑳整瑳”. He remarked, “This looks quite odd and could be some problem with the application.” The string is nonsense in Chinese, but I immediately recognized what was up. Here’s a hint: Rewrite the string as L”\\x6574″ L”\\x7473″ […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/7983","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=7983"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/7983\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=7983"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=7983"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=7983"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}