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) 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 <esteba...@gmail.com> wrote: > Hi, > > > On 20 Nov 2016, at 00:52, Mark Bestley <s...@bestley.co.uk> 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 > > > > > > >
