Re: [wcelibcex-devel] missing functions

[<syn...@gm...>]

Mateusz Loskot wrote:
> Peter Kümmel wrote:
>> Mateusz Loskot wrote:
>>>> Too bad. But maybe this helps:
>>>>
>>>> http://www.codeplex.com/wiki/view.aspx?projectname=CESSH
>>> I don't think so. I don't see anything helpful inside sources of
>>> this project, for this problem.
>>>
>> OK, I've done a look at ssh/sshcomat/file.c: There are implementions
>> of _open, _close,..., and they use a cast for the job (as you
>> allready menioned):
>>
>> int _open(const char* filename, int flags/*, int mode*/) { .... (int)
>> hFile; }
> 
> I'm sorry, I think I missed one important difference.
> You are asking about open() function and I replied as about fopen().
> Regarding the fopen(), the FILE* to HANDLE conversion or doesn't work:
> 
> See my "XXX - mloskot" about "FILE* to HANDLE conversion" comment in
> this file:
> 
> http://wcelibcex.svn.sourceforge.net/viewvc/wcelibcex/trunk/src/wce_rewind.c?view=markup
> 
> But HANDLE to file descriptor mapping may be feasible by casting, indeed.
> 
> Sorry for confusing.
> 
>>>> #include <../include/windows.h> #include "../src/wce_direct.h" 
>>>> #define GetCurrentDirectoryW wceex_GetCurrentDirectoryW #define 
>>>> _wgetcwd wceex_wgetcwd
>>> And that's the way to go.
>>>
>>> Here is a short exmple of how I use WCELIBCEX in one of my
>>> projects:
>>>
>>> http://www.gdal.org/srctree/port/cpl_config.h.wince
>>>
>>> Simply, the rule of thumb here is to *not* to define by default the
>>> same symbols which are available in Windows/UNIX/POSIX APIs, but to
>>> define our own symbols which can be redefined where
>>> appropriate/needed.
>> I think there is a other solution possible: On Windows CE there are
>> no Posix functions so there are no problems when we define them by
>> ourself, so that it works as under win32.
> 
> Right.
> 
>> Therefore we must add the declarations to the headers which are 
>> available under Windows CE but which misses some functions (which we
>> implement in winceex).
> 
> Right.
> 
>> This could be done by: - add the the SDK include path to the the
>> include search path - BUT add the include patch of a new include
>> directory (e.g. above ceinclude) before the SDK patch which hosts our
>> stdlib.h (above ceinclude)
>>
>> By this construction it is possible to "#include <stdlib.h>" in a 
>> client file so that all SDK stdlib.h AND all wcelibex symbols are 
>> available. This is the way we handle it for the posix functions for
>> the KDE Windows port:
>>
>> http://websvn.kde.org/trunk/kdesupport/kdewin32/include/msvc/stdlib.h?rev=599842&view=markup
>>
> That's a very interesting idea and I like it.
> I'm open for refactoring current structure and make it more
> friendly this way.
> 
> Could give some explanation how would you see the structure of WCELIBCEX
> according this idea?

The trick is the

/* regular header from msvc includes */
#include <../include/stdlib.h>

we only need a include directory within WCELIBCEX which hosts all
the standard-named headers, and this directory must not me named 'include'.

In kdewin32 this is achieved my the struture:
kdewin32/include/msvc, but this makes no sense for WCELIBCEX
because there is only msvc, therefore im initial idea to name
this directory 'ceinclude'. But maybe a 'wincelibcex' is a better
name (in boost all headers are in 'boost').


-- 
Peter Kümmel