Re: [wcelibcex-devel] missing functions
Brought to you by:
mloskot
From: <syn...@gm...> - 2007-01-05 23:22:31
|
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 |