Re: [wcelibcex-devel] missing functions
Brought to you by:
mloskot
From: Mateusz L. <ma...@lo...> - 2007-01-05 22:11:30
|
Peter Kümmel wrote: > Mateusz Loskot wrote: >> Peter Kümmel wrote: >>> Hello, I'm thinking about porting a application to Windows CE >>> 5.0. >> If you'll want to use WCELIBCEX, please drop me a note. I'd love to >> hear who is using it :-) >> > > I try to port a win32-library to ce. Is this the name of the library: win32-library ? >> The only possible solution I can see for now is to use: >> >> long _get_osfhandle(int filehandle) { return (long)filehandle; } >> >> but Windows CE's HANDLE does not map directly to file descriptor. >> So, simple casting won't work in many cases. >> > > 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. >>> '_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. > 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. 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: // 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'. > #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. Cheers -- Mateusz Loskot http://mateusz.loskot.net |