[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 1f6163: Handle UTF16 logName and serviceName

[GitHub]

  Branch: refs/heads/WIN64_UNICODE
  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
  Commit: 1f616371ff559224ad6200d1a1109e6c1a5007b3
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1f616371ff559224ad6200d1a1109e6c1a5007b3
  Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
  Date:   2018-12-31 (Mon, 31 Dec 2018)

  Changed paths:
    M platforms/win32/vm/sqWin32Main.c
    M platforms/win32/vm/sqWin32Service.c

  Log Message:
  -----------
  Handle UTF16 logName and serviceName

These are the last two obstacles that generate compiler warnings with -DUNICODE
No compiler warning does not mean that UNICODE is OK and ready to go.
It means that we have at least eliminated all the trivial TCHAR*/char*/WCHAR* mismatch (and there were a bunch of them!!!)
Also the code is like a battlefield with lot of different ad hoc recipes, that would deserve more uniform approach (refactoring)
But small steps!

To reach the current stage, we have to overhaul printCommandLine()
It can't answer a TCHAR* when sqMain expects a char*argv[]...
So, like what is done in WinMain thru getCommandLineW, we first produce a Wide command line, then convert to UTF8.
There is currently no provision for conversion failure: I don't know how to report and exit when the VM is ran as a service.

Note that command line parsing is then working the other way around: some of the arguments are converted back to UTF16.
I call this style tricotage coding: une maille à l'endroit, une maille à l'envers.
Maybe a deeper change will be to WCHAR* all the way down, but let's differ this decision. Small steps!

Note that another source of problems is RegQueryValueExW.
When we query a WCHAR* string, it is not necessarily NULL terminated.
But every answer is handled as raw un-interpretd-bytes (char *), whose byte length is answered in dwSize.
That's not the WCHAR character length! So buffer[dwSize] = 0 is not the right thing:

- if buffer is declared WVCHAR*, this would write the NULL well beyond the real string length (and eventually overrun the buffer);
- if buffer is declared char*, this would not guaranty a terminating NULL WCHAR (we need 2 zero bytes to make a NULL WCHAR).

Usage of this function will require a careful review, the price of low level API...

Also note that we seem to compile with flag -DNO_SERVICE right now. Why?
I have not enough knowledge in this area and lack tests/examples.
In that conditions, it's not easy to test the modifications! Any help will be greatly appreciated.
The good part is that It won't break current VM usage...
You know what I think of dead-code, but half alive Frankenstein code scares me as well ;)



      **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.