> On 21 Nov 2016, at 10:23, Ben Coman <[email protected]> wrote: > > On Sun, Nov 20, 2016 at 9:50 PM, Dimitris Chloupis > <[email protected]> wrote: >> Once more I got lost in the the spaghetti called "Pharo code". I am >> referring to OSWindows. >> >> Ironically its easier to read Windows header files and disassemble memory >> than actually read pharo code :D >> >> Fortunately void pointers is not an issue since I already used them on Linux >> and Macos with UFFI without using FFIConstanthandle. >> >> By the way the comment in that class wonder whether handles in Linux and >> Macos are the same , they are not, in Window a handle is a void pointer , in >> Linux and Macos they are just regular integers (int). >> >> So far I have drawn the following conclusions >> >> Unicode means 2 bytes char , windows names it wchar_t , the equivelant on >> pharo must be long char , it stores unicode strings which VS C++ defines as >> L"my text", first byte is a hex number for the character itself, second byte >> in most cases is 0 except for special characters. >> >> Numbers 0-9 are 48 (hex: 30) to 57 (hex: 39) >> >> Characters A-Z are 65(hex: 41) to 90(hex: 5A) >> >> Characters a-z are 97(hex: 61) to 122(hex: 7A) >> >> So either I use Unicode as it is or use Unicode as a 1 byte char chaining 2 >> bytes together instead of 1 at a time. > >> Which will result in exact same >> memory value for all OS (Windows /Linux / Maco) > > reality check... > http://utf8everywhere.org/ > > Sorry I don't remember enough of my Unicode research six months ago to > be more help. > Only enough to know there are traps and hunt down that article.
First read the general introduction https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/Zinc-Encoding-Meta/Zinc-Encoding-Meta.html That should be more than enough (we got all basic covered in Pharo). If you want more, there is the Pharo Unicode project https://medium.com/concerning-pharo/an-implementation-of-unicode-normalization-7c6719068f43 But you most probably don't need that. I thought that Windows used UTF-16 internally https://en.wikipedia.org/wiki/UTF-16#Usage Sven > cheers -ben > >> >> either solution could work. >> >> windows PVOID(void pointer) and *wchar_t ( pointer to TCHAR [Unicode- 2 >> bytes]) are 4 bytes like Linux and MacOS equivalent pointers. >> >> So it seems the differences are not as massive as I feared , apart from >> Unicode text the rest appears to be more or less the same. >> >> But I will be sure as soon as I use UFFI to test these assumptions which I >> am about to do. >> >> On Sun, Nov 20, 2016 at 10:51 AM Esteban Lorenzano <[email protected]> >> wrote: >>> >>> Hi, >>> >>>> On 20 Nov 2016, at 00:52, Mark Bestley <[email protected]> wrote: >>>> >>>> >>>> Sorry I have not got a Windows machine here but MSDN should provide all >>>> the documentation you need. Some of these types are not translatable and >>>> have to be treated as opaque on the Smalltalk side ie just pass as data >>>> >>>> All are defined in Windows.h and MSDN provides documentation - for types >>>> see >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx >>>> >>>> Note the naming of many of these comes from Windows 2 or earlier so was >>>> used on 16 bit programs >>>> >>>> handle_t / HANDLE is a pseudo pointer that Windows has created and >>>> Windows system calls understand. They will dereference it to find something >>>> useful - This is similar to a POSIX file handle that you can only use as a >>>> parameter to system calls. >>> >>> and these are handled by UFFI by FFIConstantHandle (read the comment) >>> >>>> >>>> PVOID is a pointer to a void ie just a pointer to something >>>> >>>> LPCTSTR and TCHAR depend on Unicode >>> >>> yep… maybe you want to see OSWindows from Torsten, he already aliased many >>> of this types. >>> >>> Esteban >>> >>>> >>>> In Wnndows C API there are usually two forms of many systems call they >>>> either take 8 bit ANSI strings or 16 bit ones which MS says is Unicode >>>> (unfortuneatly for us now MS made the decision of 16 bit when all Unicode >>>> points fitted into 16 bits so not now a simple mapping. See >>>> https://msdn.microsoft.com/en-us/library/vs/alm/dd183415(v=vs.85).aspx and >>>> https://msdn.microsoft.com/en-us/library/2dax2h36.aspx >>>> >>>> I'll assume you want Unicode >>>> >>>> TCHAR is then a 16 bit Unicode character >>>> LPCTSTR is a const long pointer to a 16 bit Unicode string >>>> >>>> I would suggest finding a book or long tutorial :( and sorry I can't >>>> suggest any as I read this from Petzold books over 25 years ago >>>> >>>> Mark >>>> >>>> >>>> On 19/11/2016 18:51, Dimitris Chloupis wrote: >>>>> So now I need to port my CPPBridge to Windows and I have to deal with >>>>> this monster. And it would not be Windows if it did not make life a lot >>>>> harder , so it defines its own types. >>>>> >>>>> Such types are >>>>> >>>>> handle_t / HANDLE >>>>> TCHAR >>>>> LPCTSTR >>>>> PVOID >>>>> >>>>> also I will have to deal with Unicode , I have no clue how to proceed, >>>>> any help is greatly appreciated. >>>>> >>>> >>>> >>>> -- >>>> Mark >>>> >>>> >>> >>> >> >
