wcelibcex-devel — Mailing list for project developers

[wcelibcex-devel] [PATCH] dependencies for Lua on Windows CE

[Petr Š. <yn...@tr...>]

Hi,

attached patch contains all modifications needed for compilation of luace[1], Lua
on Windows CE.

-- ynezz

1. http://github.com/ynezz/luace

[wcelibcex-devel] wceex_localtime daylight savings time issue

[Kevin M. <kev...@fl...>]

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;

}

Re: [wcelibcex-devel] eVC++ 4.0 Build For libtiff

[Mateusz L. <ma...@lo...>]

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

[wcelibcex-devel] eVC++ 4.0 Build For libtiff

[Chad D. <cd...@nt...>]

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...

                        

Re: [wcelibcex-devel] [Passwordsafe-devel] Compatibility of MIT License and ArtisticLicense

[Mateusz L. <ma...@lo...>]

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

Re: [wcelibcex-devel] [Passwordsafe-devel] Compatibility of MIT License and ArtisticLicense

[ronys <ro...@gm...>]

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

[wcelibcex-devel] Compatibility of MIT License and Artistic License

[Steffen R. <ste...@st...>]

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

Re: [wcelibcex-devel] missing functions

[<syn...@gm...>]

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

Re: [wcelibcex-devel] missing functions

[Mateusz L. <ma...@lo...>]

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

Re: [wcelibcex-devel] missing functions

[<syn...@gm...>]

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

Re: [wcelibcex-devel] missing functions

[Mateusz L. <ma...@lo...>]

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

Re: [wcelibcex-devel] missing functions

[<syn...@gm...>]

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

Re: [wcelibcex-devel] missing functions

[Mateusz L. <ma...@lo...>]

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

[wcelibcex-devel] missing functions

[<syn...@gm...>]

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

Re: [wcelibcex-devel] clock() function

[Mateusz L. <ma...@lo...>]

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

[wcelibcex-devel] clock() function

[Mateusz L. <ma...@lo...>]

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