<p>Hi Tobias, about LoadLibraryA, I see nothing in MSDN suggesting that these ASCII versions will be deprecated.<br>
<a href="https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-loadlibrarya" rel="nofollow">https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-loadlibrarya</a></p>
<p>The purpose of using W variants is to enable usage of internationalized strings, like in window titles, file names, etc... But when we have a simple explicit ASCII string like "advapi32.dll", using the W variant brings nothing.</p>
<p>About windowTitle, I can explain more: if you look at <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/476f70605a0352dd7528d251f7403e9233716cdb/platforms/win32/vm/sqWin32Window.c">https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/476f70605a0352dd7528d251f7403e9233716cdb/platforms/win32/vm/sqWin32Window.c</a></p>
<p>you'll see this: <code>if(*windowTitle) sprintf(titleString, "%s", windowTitle);</code> we first copy the <code>char *windowTitle</code> to the <code>char *titleString</code>. It obviously cannot be UTF16 at this stage, otherwise the copy would be shorten at first ASCII character.</p>
<p>Then <code>titleString</code> is interpreted as UTF8, converted to UTF16 before being displayed as title, line 773:</p>
<pre><code>MultiByteToWideChar(CP_UTF8, 0, titleString, -1, wideTitle, MAX_PATH+20);
SetWindowTextW(stWindow, wideTitle);
</code></pre>
<p>This was before I change anything. Also we have this function:</p>
<pre><code>char *ioGetWindowLabel(void) {
  return windowTitle;
}
</code></pre>
<p>I think it is for the purpose of communicating the title back to the image. For communicating with the image, we wish using UTF8, so the minimal and simplest change was to just declare <code>windowTitle</code> as char * (which it is now because we can't use -DUNICODE yet), and align the squeak.ini preference to read in UTF16 and convert back to UTF8. You are right, I messed up this part (because I currently compile with <code>-DUNICODE</code> for the purpose of discovering the flaws, when I should rather compile with AND without this option). I will issue another commit and use <code>GetPrivateProfileStringW</code> unconditionnally, which is a lot simpler.</p>
<p>In fact, most of the time, we have to communicate the strings with the image, and for that, we will need to perform UTF8-UTF16 conversions, so compiling with <code>-DUNICODE</code> is not enough and not really a goal per se. Using the generic versions and generic TCHAR *string has only a value if we want to maintain both an ASCII version and a Wide version. But as you said, the ASCII version does not have much interest now, so we could as well directly use W version where we think we need them, or for making the code a bit more uniform (polishing). If it adds un-necessary complexity, I would say just stick to the A version.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/329#issuecomment-450425978">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AhLyWwpnYv98K2MDnZkxgRLfFd6L_6Xqks5u9oWHgaJpZM4ZkCQ-">mute the thread</a>.<img src="https://github.com/notifications/beacon/AhLyW9BFp6Eiab-cL5txNkyhN3S5NXoxks5u9oWHgaJpZM4ZkCQ-.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/OpenSmalltalk/opensmalltalk-vm","title":"OpenSmalltalk/opensmalltalk-vm","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/OpenSmalltalk/opensmalltalk-vm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@nicolas-cellier-aka-nice in #329: Hi Tobias, about LoadLibraryA, I see nothing in MSDN suggesting that these ASCII versions will be deprecated.\r\nhttps://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-loadlibrarya\r\n\r\nThe purpose of using W variants is to enable usage of internationalized strings, like in window titles, file names, etc... But when we have a simple explicit ASCII string like \"advapi32.dll\", using the W variant brings nothing.\r\n\r\nAbout windowTitle, I can explain more: if you look at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/476f70605a0352dd7528d251f7403e9233716cdb/platforms/win32/vm/sqWin32Window.c\r\n\r\nyou'll see this: `if(*windowTitle) sprintf(titleString, \"%s\", windowTitle);` we first copy the `char *windowTitle` to the `char *titleString`. It obviously cannot be UTF16 at this stage, otherwise the copy would be shorten at first ASCII character.\r\n\r\nThen `titleString` is interpreted as UTF8, converted to UTF16 before being displayed as title, line 773:\r\n\r\n    MultiByteToWideChar(CP_UTF8, 0, titleString, -1, wideTitle, MAX_PATH+20);\r\n    SetWindowTextW(stWindow, wideTitle);\r\n\r\nThis was before I change anything. Also we have this function:\r\n\r\n    char *ioGetWindowLabel(void) {\r\n      return windowTitle;\r\n    }\r\n\r\nI think it is for the purpose of communicating the title back to the image. For communicating with the image, we wish using UTF8, so the minimal and simplest change was to just declare `windowTitle` as char * (which it is now because we can't use -DUNICODE yet), and align the squeak.ini preference to read in UTF16 and convert back to UTF8. You are right, I messed up this part (because I currently compile with `-DUNICODE` for the purpose of discovering the flaws, when I should rather compile with AND without this option). I will issue another commit and use `GetPrivateProfileStringW` unconditionnally, which is a lot simpler.\r\n\r\nIn fact, most of the time, we have to communicate the strings with the image, and for that, we will need to perform UTF8-UTF16 conversions, so compiling with `-DUNICODE` is not enough and not really a goal per se. Using the generic versions and generic TCHAR *string has only a value if we want to maintain both an ASCII version and a Wide version. But as you said, the ASCII version does not have much interest now, so we could as well directly use W version where we think we need them, or for making the code a bit more uniform (polishing). If it adds un-necessary complexity, I would say just stick to the A version."}],"action":{"name":"View Pull Request","url":"https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/329#issuecomment-450425978"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/329#issuecomment-450425978",
"url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/329#issuecomment-450425978",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>