Thread: [wcelibcex-devel] missing functions
Brought to you by:
mloskot
Menu
▾
▴
wcelibcex-devel
|
From: <syn...@gm...> - 2006-12-21 21:20:18
|
Hello, I'm thinking about porting a application to Windows CE 5.0. Below is a list of some compiler errors. What do you think about the complexity of implementing the functions not already part of wcelib? Best regards, Peter '_get_osfhandle': identifier not found '_getdrive': identifier not found '_O_NOINHERIT' : undeclared identifier '_S_IREAD' : undeclared identifier '_S_IWRITE' : undeclared identifier '_wchdir' : is not a member of '`global namespace'' '_wchdir': identifier not found '_wchmod' : is not a member of '`global namespace'' '_wchmod': identifier not found '_wgetcwd' : is not a member of '`global namespace'' '_wgetcwd': identifier not found '_wgetdcwd' : is not a member of '`global namespace'' '_wgetdcwd': identifier not found '_wsopen_s': identifier not found 'GetCurrentDirectoryW' : is not a member of '`global namespace'' 'GetCurrentDirectoryW': identifier not found 'GetFullPathNameA': identifier not found 'GetFullPathNameW': identifier not found 'GetLogicalDrives': identifier not found 'SEM_FAILCRITICALERRORS' : undeclared identifier 'SEM_NOOPENFILEERRORBOX' : undeclared identifier 'SetCurrentDirectoryW' : is not a member of '`global namespace'' 'SetCurrentDirectoryW': identifier not found 'SetErrorMode': identifier not found 'SystemTimeToTzSpecificLocalTime': identifier not found 'fd_set' : undeclared identifier 'FD_SET': identifier not found 'FD_ZERO': identifier not found 'rd' : undeclared identifier 'resolve': identifier not found 'select': identifier not found 'sn_except' : undeclared identifier 'sn_read' : undeclared identifier 'sn_write' : undeclared identifier 'sockfd' : undeclared identifier 'WaitForSingleObjectEx': identifier not found 'WM_NCCREATE' : undeclared identifier 'fd_set' : undeclared identifier 'FD_SET': identifier not found 'FD_ZERO': identifier not found 'rd' : undeclared identifier 'resolve': identifier not found 'select': identifier not found 'sn_except' : undeclared identifier 'sn_read' : undeclared identifier 'sn_write' : undeclared identifier 'sockfd' : undeclared identifier 'WaitForSingleObjectEx': identifier not found 'WM_NCCREATE' : undeclared identifier '_beginthread': identifier not found '_beginthreadex': identifier not found '_endthreadex': identifier not found |
|
From: Mateusz L. <ma...@lo...> - 2007-01-03 01:57:39
|
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 :-)
> Below is a list of some compiler errors.
>
> What do you think about the complexity of implementing
> the functions not already part of wcelib?
OK, I'll try to give a short overview below:
> '_get_osfhandle': identifier not found
This function returnes file handle (HANDLE) from file descriptor.
I can't see any solution about this now.
*osfhandle functions require some infrastructure deep
inside the C library like internal tables of file handles, etc.
WCELIBCEX does not provide such features on the lowest level of system
libraries. It just extends C and other system libraries with
functions possible to implement without implementing a very low level
stuff or affecting existing system libs.
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.
> '_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.
> '_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.
> '_wgetcwd' : is not a member of '`global namespace''
This function is already available.
> '_wsopen_s': identifier not found
This function is not available. I'm not sure how to implement it.
> 'GetCurrentDirectoryW': identifier not found
This function is already available.
> 'GetFullPathNameA': identifier not found
> 'GetFullPathNameW': identifier not found
These functions are available.
> 'GetLogicalDrives': identifier not found
> 'SEM_FAILCRITICALERRORS' : undeclared identifier
> 'SEM_NOOPENFILEERRORBOX' : undeclared identifier
There is no concept of drive on Windows CE.
I'm not sure how to implement it.
> 'SetCurrentDirectoryW': identifier not found
It's almost the same as chdir() and wchdir(), so I can sell
it's available :-)
> 'SetErrorMode': identifier not found
I can't see any way to have it working.
> 'SystemTimeToTzSpecificLocalTime': identifier not found
Not available, but should not be a big problem.
> 'fd_set' : undeclared identifier
> 'FD_SET': identifier not found
> 'FD_ZERO': identifier not found
> 'rd' : undeclared identifier
Functions for I/O synchronization and multiplexing.
I can't see any way how to implement it for Windows CE.
> 'resolve': identifier not found
> 'select': identifier not found
> 'sn_except' : undeclared identifier
> 'sn_read' : undeclared identifier
> 'sn_write' : undeclared identifier
> 'sockfd' : undeclared identifier
Sockets functions should be easy to implement.
> 'WaitForSingleObjectEx': identifier not found
It's easy to implement it as:
DWORD WaitForMultipleObjectsEx(DWORD nCount,
const HANDLE* lpHandles,
BOOL bWaitAll,
DWORD dwMilliseconds,
BOOL bAlertable /* not used */)
{
return WaitForMultipleObjects(nCount, lpHandles,
bWaitAll, dwMilliseconds);
}
> 'WM_NCCREATE' : undeclared identifier
It's GUI-related.
No such a message on Windows CE.
> '_beginthread': identifier not found
> '_beginthreadex': identifier not found
> '_endthreadex': identifier not found
These are usually wrappers on CreateThread and other functions from
Windows API, so it's feasible to have them on Windows CE too.
I hope my explanation will help you.
BTW, Are you porting an application from Symbian to Windows CE?
Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
|
|
From: <syn...@gm...> - 2007-01-05 21:06:26
|
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.
>> Below is a list of some compiler errors.
>>
>> What do you think about the complexity of implementing
>> the functions not already part of wcelib?
>
> OK, I'll try to give a short overview below:
>
>> '_get_osfhandle': identifier not found
>
> This function returnes file handle (HANDLE) from file descriptor.
> I can't see any solution about this now.
> *osfhandle functions require some infrastructure deep
> inside the C library like internal tables of file handles, etc.
> WCELIBCEX does not provide such features on the lowest level of system
> libraries. It just extends C and other system libraries with
> functions possible to implement without implementing a very low level
> stuff or affecting existing system libs.
>
> 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
>> '_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.
>> '_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?
>> '_wgetcwd' : is not a member of '`global namespace''
>
> This function is already available.
>
>> '_wsopen_s': identifier not found
>
> This function is not available. I'm not sure how to implement it.
>
wsopen should be enought.
>> 'GetCurrentDirectoryW': identifier not found
>
> This function is already available.
>
>> 'GetFullPathNameA': identifier not found
>> 'GetFullPathNameW': identifier not found
>
> These functions are available.
>
>> 'GetLogicalDrives': identifier not found
>> 'SEM_FAILCRITICALERRORS' : undeclared identifier
>> 'SEM_NOOPENFILEERRORBOX' : undeclared identifier
>
> There is no concept of drive on Windows CE.
> I'm not sure how to implement it.
>
>> 'SetCurrentDirectoryW': identifier not found
>
> It's almost the same as chdir() and wchdir(), so I can sell
> it's available :-)
>
Fine.
>> 'SetErrorMode': identifier not found
>
> I can't see any way to have it working.
>
>> 'SystemTimeToTzSpecificLocalTime': identifier not found
>
> Not available, but should not be a big problem.
>
>> 'fd_set' : undeclared identifier
>> 'FD_SET': identifier not found
>> 'FD_ZERO': identifier not found
>> 'rd' : undeclared identifier
>
> Functions for I/O synchronization and multiplexing.
> I can't see any way how to implement it for Windows CE.
>
>> 'resolve': identifier not found
>> 'select': identifier not found
>> 'sn_except' : undeclared identifier
>> 'sn_read' : undeclared identifier
>> 'sn_write' : undeclared identifier
>> 'sockfd' : undeclared identifier
>
> Sockets functions should be easy to implement.
>
>> 'WaitForSingleObjectEx': identifier not found
>
> It's easy to implement it as:
>
> DWORD WaitForMultipleObjectsEx(DWORD nCount,
> const HANDLE* lpHandles,
> BOOL bWaitAll,
> DWORD dwMilliseconds,
> BOOL bAlertable /* not used */)
> {
> return WaitForMultipleObjects(nCount, lpHandles,
> bWaitAll, dwMilliseconds);
> }
>
Great.
>> 'WM_NCCREATE' : undeclared identifier
>
> It's GUI-related.
> No such a message on Windows CE.
>
>
>> '_beginthread': identifier not found
>> '_beginthreadex': identifier not found
>> '_endthreadex': identifier not found
>
> These are usually wrappers on CreateThread and other functions from
> Windows API, so it's feasible to have them on Windows CE too.
>
>
> I hope my explanation will help you.
>
> BTW, Are you porting an application from Symbian to Windows CE?
>
no, from win32 only.
> Cheers
What is the reason not to name all the functions like the original
ones, but to prefix the name with "wceex_"?
Then they could not be used as a drop in for the win32 headers.
Here I have headers in 'ceinclude' which look like this:
#include <../include/windows.h>
#include "../src/wce_direct.h"
#define GetCurrentDirectoryW wceex_GetCurrentDirectoryW
#define _wgetcwd wceex_wgetcwd
Cheers,
Peter
|
|
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
|
|
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 |
|
From: Mateusz L. <ma...@lo...> - 2007-01-05 23:03:09
|
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? Cheers -- Mateusz Loskot http://mateusz.loskot.net |
|
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 |
Thanks for helping keep SourceForge clean.
X