[OpenSmalltalk/opensmalltalk-vm] 92c1b2: Handle both an ASCII (UTF8) and a WIDE (UTF16) ver...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[OpenSmalltalk/opensmalltalk-vm] 92c1b2: Handle both an ASCII (UTF8) and a WIDE (UTF16) ver...

Eliot Miranda-3
 
  Branch: refs/heads/WIN64_UNICODE
  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
  Commit: 92c1b26589db8deea97b8cc7659ecc8b6aef8983
      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/92c1b26589db8deea97b8cc7659ecc8b6aef8983
  Author: Nicolas Cellier <[hidden email]>
  Date:   2018-12-29 (Sat, 29 Dec 2018)

  Changed paths:
    M platforms/win32/vm/sqWin32.h
    M platforms/win32/vm/sqWin32Main.c
    M platforms/win32/vm/sqWin32Prefs.c
    M platforms/win32/vm/sqWin32Service.c
    M platforms/win32/vm/sqWin32Window.c

  Log Message:
  -----------
  Handle both an ASCII (UTF8) and a WIDE (UTF16) version of image/vm name/path

Note:
the Microsoft windows API mostly uses the W version (for enabling internationalized image name/path)
the image uses UTF8 encoded bytes string for communication with the VM (this is best for compatibility with Unix/Mac)
The idea here is that the implementation maintains both versions of the UTF8 and UTF16 path/name

The appropriate macro returning a TCHAR * are also provided.
This is in order to support the generic version using TCHAR, which are normally used to ease transition to UNICODE.

Note about string length:
No effort has been made so far to support long path names for image and VM.
The path is limited to MAX_PATH in UTF16.
UTF8 can eventually consume more characters than UTF16 (not necessarily more bytes).
Thus, the ASCII version has been made longer (MAX_PATH_UTF8) in order to avoid an even more restrictive limit.



      **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.
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSmalltalk/opensmalltalk-vm] 92c1b2: Handle both an ASCII (UTF8) and a WIDE (UTF16) ver...

alistairgrant
 
Hi Nicolas,

On Sat, 29 Dec 2018 at 22:58, GitHub <[hidden email]> wrote:
>
>   Log Message:
>   -----------
>   Handle both an ASCII (UTF8) and a WIDE (UTF16) version of image/vm name/path

This is the same issue I've dealt with recently in FileAttributesPlugin.

What I did there was to create a structure that holds both the VM
(UTF-8) encoded version and the platform specific encoded version
(WCHAR for Windows) and use accessor routines that make sure the two
are kept in sync:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/plugins/FileAttributesPlugin/faSupport.h
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/plugins/FileAttributesPlugin/faSupport.c

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/win32/plugins/FileAttributesPlugin/faSupport.h
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/win32/plugins/FileAttributesPlugin/faSupport.c

I doubt that this code is generally useful because of the way it
allows for a directory to be set and then a file name to be added to
the path, but the concept may be useful.

Cheers,
Alistair