Re: [wcelibcex-devel] missing functions
Brought to you by:
mloskot
From: <syn...@gm...> - 2007-01-05 22:36:31
|
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; } >>>> '_getdrive': identifier not found >>> There are no drives in Windows CE, so this function could return >>> root directory >>> >>> int _getdrive(void) { return 1; // or other number } >>> >>>> '_O_NOINHERIT' : undeclared identifier '_S_IREAD' : undeclared >>>> identifier '_S_IWRITE' : undeclared identifier >>> These constants are already available in WCELIBCEX, used by stat() >>> function. >>> >> Yes, I've also figured it out, thanks. > > Here, a kind of dummy function can be used. > I call dummy functions as a compilation enablers :-) without any logic > behind. > >>>> '_wchdir': identifier not found >>> This function is already available. >>> >>>> '_wchmod': identifier not found >>> There is no concept of file permissions on Windows CE. ATM, I've no >>> idea how to implement it. >>> >> maybe a dummy? > > Sure, but you also need to check if the software you're porting won't > crash calling dummy function. Yes, a compile time error would be better. > >> What is the reason not to name all the functions like the original >> ones, but to prefix the name with "wceex_"? > > The reason is to distinguish these functions from Windows API (desktop) > or from POSIX libraries and to *explicitly mark* these functions as they > are extensions. > Also, even if the sources of WCELIBCEX are compiled using C++ compiler, > we intentionally use *.c files to indicate that it's a port of C API > from Windows/UNIX/POSIX, etc. > >> Then they could not be used as a drop in for the win32 headers. > > Yes, I know but it's intentional. Yes, I assumed this. > Now, you can use wce_stdlib.h from WCELIBCEX and stdlib.h from one of > Windows CE SDKs without any names clash. > wce_stdlib.h does not provide prototypes which are already available in > stdlib.h, so both files will mostly used together: > see below... > // I need some available function > #include <stdlib.h> > // Oh! I also need something what's unavailable, OK, > // let's get the extension > #include <wce_stdlib.h> > >> Here I have headers in 'ceinclude' which look like this: > > Sorry, I don't know what is the 'ceinclude'. > see below... >> #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. 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). 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 Peter |