[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 627bc5: Use the eventually true UNICODE imageNameT if -DUN...
GitHub
noreply at github.com
Sun Dec 30 23:38:19 UTC 2018
Branch: refs/heads/WIN64_UNICODE
Home: https://github.com/OpenSmalltalk/opensmalltalk-vm
Commit: 627bc5e39c3e718de09ddc0293997435b8c73413
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/627bc5e39c3e718de09ddc0293997435b8c73413
Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Date: 2018-12-30 (Sun, 30 Dec 2018)
Changed paths:
M platforms/win32/vm/sqWin32Service.c
Log Message:
-----------
Use the eventually true UNICODE imageNameT if -DUNICODE
using `toUnicode` does not do the right thing: it promotes each UTF8 byte code to short...
... which can hardly work beyond ASCII.
Commit: 98fc85ddd56487492a4988ad457dbc2b3fe88397
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/98fc85ddd56487492a4988ad457dbc2b3fe88397
Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Date: 2018-12-30 (Sun, 30 Dec 2018)
Changed paths:
M platforms/win32/vm/sqWin32ExternalPrims.c
Log Message:
-----------
interpret pluginName as UTF8 rather than pure ASCII
toUnicode is just expanding bytes to short, and re-interpret them UTF16, not regarding original encoding.
This works well for pure ASCII, but is not really defined for other encodings.
We should prefer using UTF8 by default for all the image-VM string transfer.
Commit: 4f6f191613f6bf6cdb989b39e1002cf4938f475c
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/4f6f191613f6bf6cdb989b39e1002cf4938f475c
Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Date: 2018-12-30 (Sun, 30 Dec 2018)
Changed paths:
M platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c
M platforms/win32/vm/sqWin32.h
M platforms/win32/vm/sqWin32Alloc.c
M platforms/win32/vm/sqWin32Main.c
M platforms/win32/vm/sqWin32SpurAlloc.c
M platforms/win32/vm/sqWin32Utils.c
Log Message:
-----------
refactor sqMessageBox to void using toUnicode
Why to get rid of toUnicode fromUnicode fromSqueak fromSqueak2?
- we'd rather use UTF8 everywhere.
- and it's the last usage remaining!
Now the clients must use a TEXT() macro also for the format. In the future, we could eventually translate the VM messages...
Get rid of wsprintf variant which has no character limit and might be prone to buffer overrun.
An alternative for supporting both ASCII and WIDE is the _tcs* family in <tchar.h>
See https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/vsprintf-vsprintf-l-vswprintf-vswprintf-l-vswprintf-l?view=vs-2017
In order to avoid buffer overrun, prefer a vsnprintf variant
Note: I did also update the prototype in sqWin32SpurAlloc, but not the contents.
It is dead code, and only there for testing purposes.
We'd better remove it!
Commit: 545ec0a931166a8374683940f3344e27a110f42c
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/545ec0a931166a8374683940f3344e27a110f42c
Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Date: 2018-12-30 (Sun, 30 Dec 2018)
Changed paths:
M platforms/win32/vm/sqWin32.h
M platforms/win32/vm/sqWin32Utils.c
Log Message:
-----------
Discard now unused toUnicode fromUnicode fromSqueak fromSqueak2 lstrrchr
For UNICODE compatibility,
- every String coming from image to the VM should better be interpreted UTF8, and converted to wide String via MultiByteToWideChar()
- every String going to the image from the VM should better be converted from Wide string to UTF8 via WideCharToMultiByte()
See:
https://docs.microsoft.com/en-us/windows/desktop/api/stringapiset/nf-stringapiset-multibytetowidechar
https://docs.microsoft.com/en-us/windows/desktop/api/stringapiset/nf-stringapiset-widechartomultibyte
Side note: there is also a _tcsrrchr in <tchar.h> at least since visual studio 2015
See
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/strrchr-wcsrchr-mbsrchr-mbsrchr-l?view=vs-2017
<tchar.h> is also supported by mingw so if ever we need lstrrchr again, we'll use that.
Commit: 2024d4358c14482f4ad861180e412488e25aef7a
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/2024d4358c14482f4ad861180e412488e25aef7a
Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Date: 2018-12-30 (Sun, 30 Dec 2018)
Changed paths:
M platforms/win32/vm/sqWin32.h
Log Message:
-----------
#if 0 ? YAGNI ! we now use builtin _WIN32 _WIN64 anyway
Reminder: even in WIN64, _WIN32 is defined, so the comment was a bit misleading anyway.
Commit: e1e83f770aaa7f903509eae7166c858260bd3b7c
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e1e83f770aaa7f903509eae7166c858260bd3b7c
Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Date: 2018-12-30 (Sun, 30 Dec 2018)
Changed paths:
M platforms/win32/vm/sqWin32.h
Log Message:
-----------
which SetUpPreferences()? There is no SetUpPreferences()!
Commit: 8638522434f52dbacfdf634745ac50e387900ec6
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/8638522434f52dbacfdf634745ac50e387900ec6
Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Date: 2018-12-30 (Sun, 30 Dec 2018)
Changed paths:
M platforms/win32/vm/sqWin32Main.c
Log Message:
-----------
RegisterWindowMessage takes a TCHAR *
Commit: 1893512441e9838d3393896c1fe1abc507775c55
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1893512441e9838d3393896c1fe1abc507775c55
Author: Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Date: 2018-12-31 (Mon, 31 Dec 2018)
Changed paths:
M platforms/win32/vm/sqPlatformSpecific.h
Log Message:
-----------
Platform specific knowledge: WIN32_FILE and STD_FILE are mutually exclusive options
Therefore, when we define `WIN32_FILE_SUPPORT` we must also define `NO_STD_FILE_SUPPORT`
Until now, this knowledge was in build.win*/common/Makefile.*
(and a legacy MSVC project in plaftorms/win32/misc/Squeak.dsp - on pourrait réduire la voilure !!!)
Since it is easy to forget the second define, lets extend the knowledge in the sqPlatformSpecific.h
Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/49eff31f0372...1893512441e9
**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.
More information about the Vm-dev
mailing list