wcelibcex-devel Mailing List for Windows CE C Library Extensions
Brought to you by:
mloskot
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(1) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Petr Š. <yn...@tr...> - 2009-03-13 12:37:04
|
Hi, attached patch contains all modifications needed for compilation of luace[1], Lua on Windows CE. -- ynezz 1. http://github.com/ynezz/luace |
From: Kevin M. <kev...@fl...> - 2008-09-09 18:52:41
|
Hi, This library is a lot of help to those of us doing ANSI C on wce based platforms! There's an issue with the localtime function for timezones that are in DST. Currently, the code does not apply the daylight time bias while the local time zone is in DST or apply the standard bias in time zones that have a nonzero bias in standard time. Here's an updated function that seems to correctly report the local time (I can provide a diff if that works better). -Kevin struct tm * wceex_localtime(const time_t *timer) { register struct tm *tmp; long tzoffset; TIME_ZONE_INFORMATION tzi; DWORD tzi_return; // Retrive timezone offset in seconds tzoffset = 0; tzi_return = GetTimeZoneInformation(&tzi); if (tzi_return != 0xFFFFFFFF) { tzoffset += (tzi.Bias * 60); if (tzi.StandardDate.wMonth != 0 && tzi_return == TIME_ZONE_ID_STANDARD) { tzoffset += (tzi.StandardBias * 60); } else if (tzi.DaylightDate.wMonth != 0 && tzi_return == TIME_ZONE_ID_DAYLIGHT) { tzoffset += (tzi.DaylightBias * 60); } } tzoffset *= -1; tmp = __wceex_offtime(timer, tzoffset); return tmp; } |
From: Mateusz L. <ma...@lo...> - 2008-03-15 00:53:25
|
Chad DeWitt wrote: > I have downloaded the WCELIBCEX files. I do not have access to Visual > C++ 2005 but I do have eMbedded Visual C++ 4.0. I tried creating a > project file for eVC++ 4.0 and added the wcelibcex source files but I'm > having troubles getting the project to build. What troubles do you exactly have? > I would appreciate any sample eVC++ 4.0 project files you could provide > me or links to where I may find some on the internet. Or, if it is not > too much trouble, directions on how to properly set up a project file to > build a Windows CE libtiff library. I do not use eVC++ so I don't have any project files you are asking for. You may try to open solution files (they are XML/text files) and try to clone those settings to eVC++ project. Greetings -- Mateusz Loskot http://mateusz.loskot.net |
From: Chad D. <cd...@nt...> - 2008-03-14 23:50:02
|
Greetings, First off, thank you for the work that has been done on putting together a libtiff build for Windows CE. It would be very helpful to me to do some tiff image scaling in a Windows CE application that I am developing and save me a ton of development time if I could use the libtiff utility for this. I have downloaded the WCELIBCEX files. I do not have access to Visual C++ 2005 but I do have eMbedded Visual C++ 4.0. I tried creating a project file for eVC++ 4.0 and added the wcelibcex source files but I'm having troubles getting the project to build. I would appreciate any sample eVC++ 4.0 project files you could provide me or links to where I may find some on the internet. Or, if it is not too much trouble, directions on how to properly set up a project file to build a Windows CE libtiff library. Thank you, Chad DeWitt Software Engineer CCSI/NTS Inc 435-986-4500 ext. 1007 cd...@nt... |
From: Mateusz L. <ma...@lo...> - 2007-05-25 21:45:59
|
ronys wrote: > Hi, > > As I understand the MIT license it should be possible to incorporate this > project into the PasswordSafe source tree, providing: > 1. The code is in a directory of it's own > 2. PasswordSafe's README.txt file & credits.html states that the PPC version > incorporates code from this projext, along with the license terms > 3. Files with modifications to the original be clearly marked as modified. > > Of course, it would be best to get the project owner's explicit permission. Rony, I think your understanding is correct but it needs a few comments. Here is IMO one of best and short explanation of what MIT license allows to do with the project: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License/MIT_License Summarizing: - you are allowed copy, use and modify the WCELIBCEX for any use - you're required to preserve license/copyright notice in all copies of WCELIBCEX files Cheers -- Mateusz Loskot http://mateusz.loskot.net |
From: ronys <ro...@gm...> - 2007-05-19 16:36:00
|
Hi, As I understand the MIT license it should be possible to incorporate this project into the PasswordSafe source tree, providing: 1. The code is in a directory of it's own 2. PasswordSafe's README.txt file & credits.html states that the PPC version incorporates code from this projext, along with the license terms 3. Files with modifications to the original be clearly marked as modified. Of course, it would be best to get the project owner's explicit permission. Rony -----Original Message----- From: pas...@li... [mailto:pas...@li...] On Behalf Of Steffen Ryll Sent: Saturday, May 19, 2007 3:04 PM To: wce...@li...; pas...@li... Subject: [Passwordsafe-devel] Compatibility of MIT License and ArtisticLicense X-Post to wcelibcex-devel and passwordsafe-devel Hi all, I am currently in the process of porting Passwordsafe (which is under Artistic License) to the PocketPC OS. I had to discover that MS didn't implement a number standard C run-time functions, though they are declared in the usual header files (time.h for instance). After some googleing and surfing I found the wcelibcex project (which stands under the MIT License) on Sourceforge which fills most severe gaps in MS's implementation. My question to both sides, in particular to the respective copyright holders, is now whether both licenses are compatible. Is it acceptable to distribute wcelibcex source code along with Passwordsafe for PocketPC source code and to incorporate binaries of wcelibcex into binary Passwordsafe releases? In my understanding it is ok, but that shouldn't count here :-) Both license texts can be found here: http://www.opensource.org/licenses/artistic-license.php http://www.opensource.org/licenses/mit-license.php Interested readers can find sources for both projects here: <http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/branches/V1_92P PC/pwsafe/pwsafe/> <http://wcelibcex.svn.sourceforge.net/viewvc/wcelibcex/trunk/> Regards, Steffen ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Passwordsafe-devel mailing list Pas...@li... https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel |
From: Steffen R. <ste...@st...> - 2007-05-19 12:04:48
|
X-Post to wcelibcex-devel and passwordsafe-devel Hi all, I am currently in the process of porting Passwordsafe (which is under Artistic License) to the PocketPC OS. I had to discover that MS didn't implement a number standard C run-time functions, though they are declared in the usual header files (time.h for instance). After some googleing and surfing I found the wcelibcex project (which stands under the MIT License) on Sourceforge which fills most severe gaps in MS's implementation. My question to both sides, in particular to the respective copyright holders, is now whether both licenses are compatible. Is it acceptable to distribute wcelibcex source code along with Passwordsafe for PocketPC source code and to incorporate binaries of wcelibcex into binary Passwordsafe releases? In my understanding it is ok, but that shouldn't count here :-) Both license texts can be found here: http://www.opensource.org/licenses/artistic-license.php http://www.opensource.org/licenses/mit-license.php Interested readers can find sources for both projects here: <http://passwordsafe.svn.sourceforge.net/viewvc/passwordsafe/branches/V1_92PPC/pwsafe/pwsafe/> <http://wcelibcex.svn.sourceforge.net/viewvc/wcelibcex/trunk/> Regards, Steffen |
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 |
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 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 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 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-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...> - 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...> - 2006-11-18 16:56:34
|
The clock() function has been added. Cheers Mat Mateusz Loskot wrote: > One of users on the PocketPCDN.com forum, with nickname 'hav', posted > a very nice implementation of clock() function: > > http://www.pocketpcdn.com/forum/viewtopic.php?p=19152 > > hav agrees to included it to WCELIBCEX library. > > Here is the function > > #include <time.h> > #ifdef _WIN32_WCE > #include <winbase.h> > > clock_t clock(void) > { > SYSTEMTIME stCurrent; > FILETIME ftCurrent; > > GetSystemTime(&stCurrent); > if(!SystemTimeToFileTime(&stCurrent, &ftCurrent)) > { > //throw _T("Can't convert time in sc_support::clock!"); > } > __int64 ticks = *(__int64*)&ftCurrent; > > return (clock_t)ticks; > } > #endif > > I'll include it ASAP. > > Cheers -- Mateusz Loskot http://mateusz.loskot.net |
From: Mateusz L. <ma...@lo...> - 2006-09-24 13:37:05
|
One of users on the PocketPCDN.com forum, with nickname 'hav', posted a very nice implementation of clock() function: http://www.pocketpcdn.com/forum/viewtopic.php?p=19152 hav agrees to included it to WCELIBCEX library. Here is the function #include <time.h> #ifdef _WIN32_WCE #include <winbase.h> clock_t clock(void) { SYSTEMTIME stCurrent; FILETIME ftCurrent; GetSystemTime(&stCurrent); if(!SystemTimeToFileTime(&stCurrent, &ftCurrent)) { //throw _T("Can't convert time in sc_support::clock!"); } __int64 ticks = *(__int64*)&ftCurrent; return (clock_t)ticks; } #endif I'll include it ASAP. Cheers -- Mateusz Loskot http://mateusz.loskot.net |