Share via


time.h on Windows CE

Since my last post was time related, why not another?  Don't worry too much about why this is on a Networking Blog even though it has nothing to do with networking.  I own this stuff since there's a lot of technology in CE and not a ton of developers, so we get to cover all sorts of ground.  And I'm not inclined to create a "cetime" blog to cover time related functions on CE :).

Once in a while I'm asked on a newsgroup or internally someone wants to use a Unix style "time.h" function for whatever reason.  The answer here is sorry, no, this isn't supported.  In order to save resources (both ROM and developer), we decided only to implement Win32 time related functions.

However, it's not quite that simple.  We do ship time.h in %_WINCEROOT%\public\ie\sdk\inc.  This because some code we've ported from the desktop needs the time related structures, though it obviously can't use the Unix style functions declared in this file since they're not implemented anywhere.  (The main data structure people use is tm, not to be confused with Toastmasters (which is a wonderful organization by the way).)

This causes problems for developers who are using Intellisense.  Intellisense sees the C runtime functions defined in time.h and doesn't realize that they're not implemented, so people write code that calls into them and their code compiles but they get link errors.  Understandably this is frustrating.  The workaround here is obviously not to trust Intellisense for this particular case.  For future versions, we're looking at removing time.h from this source place or at a minimum removing all the Unixy functions like time(), gmtime(), localtime(), etc... so Intellisense doesn't get confused.

[Author: John Spaith]

Comments

  • Anonymous
    April 29, 2006
    Or better implement the missing functions. After all, you are going to implement the C runtime you have to do the whole job and not most of it. C runtime conformance should be important. Yes?

  • Anonymous
    May 01, 2006
    sorry, john, but IMHO this isn't the full truth.
    since the class "time" in a c++ program has constructors to act as the classic unix-like time() function, coredll.dll holds all the code we would need. but only the ansi-c implementation lacks of the code.

    thus, I cannot see any reason for not having time() in ansi-c. At least no reason but make my work of writing OS dependend code much harder.

    And, at the end of the day, what do we have? Each second developer who needs time() & co builds its own - less or more flawed - implementation of the ansi-c time() stuff. So, pleas do NOT removing the header but finish the implementation also for c. As said, its already done in c++.

  • Anonymous
    May 10, 2006
    Having been in WinCE +7 years and ported a ton of code from WinXP to CE, I definitely appreciate making CE as easy as possible to port to as possible.  That said, unfortunately we just can't port everything from Win32 or even the C runtime because we don't have the people and we need to watch the ROM space.  I'm sure time.h wouldn't be hard to do, but multiply it by the few dozen headers people really want to make porting easier and it starts to become pretty hard.

    That said, we in CE have a certain bias for porting from Win32->CE, where these functions (at least in code I've ported) are really hardly ever used but instead the win32 stuff is.  If other people out there actually are being hurt by the lack of this because they're targetting UNIX also or just prefer the CRT stuff over Win32 at some point then we can examine adding this functionality to CE.  So I guess if anyone else out there is hurt by this they should speak up.  As always, no promises.

    I wish I had a better answer for you on this one.

    John Spaith

  • Anonymous
    May 18, 2006
    Thanks for the info John. As an aside, if you create a Smart Device project in Visual Studio 2005 against a CE 5 SDK you can finally use streams, at least in theory. Unfortunately the streams header files include time.h and hence fail to compile.

    Cheers,
    Dave

    PS - Sorry you weren't at MEDC06 John; would have loved to say hi. Did you have to stay back and hold the fort?

  • Anonymous
    May 24, 2006
    Please finish the c-runtime for CE, it would make like so much easier.  Currently we have ported OpenBSD time functions for CE and use that.

  • Anonymous
    May 28, 2006
    I'm hurting by that!
    I have piece of code that call to those function. My code should be not depend on OS and that is forcing me to make sure that every new use of a function from the CRT is suppored in every OS.
    Another thing, it took me few days to find that article that confirm that the problem is not in my project!

  • Anonymous
    May 28, 2006
    Sorry, another thing, what is the suggestionworkaround for that problem ?

  • Anonymous
    June 13, 2006
    To answer the many questions since i last checked the blog feedback - no, unfortunately I didn't get to go to MEDC (nice someone would want to talk to me other than complain about time.h :)), yes i feel your guy's pain, yes I've passed all this along to the CRT owner (though in CE 6.0 it's very very unlikely we can do anything), and as far as workarounds you really have to implement it yourself or ideally find one person in the community to do it for you & then share the source.

    John Spaith

  • Anonymous
    September 03, 2006
    This is a very annoying shortcoming of WindowsCE, here's my eMbedded Visual C++ solution:


    time_t time( time_t inTT ) {
     SYSTEMTIME sysTimeStruct;
     FILETIME fTime;
     ULARGE_INTEGER int64time;
     time_t locTT = 0;
     
     if ( inTT == NULL ) {
       inTT = &locTT;
     }
     
     GetSystemTime( &sysTimeStruct );
     if ( SystemTimeToFileTime( &sysTimeStruct, &fTime ) ) {
       memcpy( &int64time, &fTime, sizeof( FILETIME ) );
       /
    Subtract the value for 1970-01-01 00:00 (UTC) /
       int64time.QuadPart -= 0x19db1ded53e8000;
       /
    Convert to seconds. /
       int64time.QuadPart /= 10000000;
       
    inTT = int64time.QuadPart;
     }
     
     return *inTT;
    }


    Would a small function like this really break the ROM limits form WinCE?

    /Fredrik

  • Anonymous
    September 06, 2006
    We always viewed doing time.h as part of a larger CRT as far as dev/test/ROM hit, and didn't think of time() functions by themselves.  Based on feedback on blog & newsgroups, I realize that a lot more people are hit by this than we realized.  I'll pass this information onto our kernel/compiler team for a future version.

    In the meantime thanks for the src code, Fredrik.

    John

  • Anonymous
    September 19, 2006
    Hello Sir,
                I am a beginner in WinCE.As you have written in this post about time() function.
    Here in my code for winCE i m using openSSL.
    i build openSSL for WinCE and got two library ssleay32.lib and libeay32.lib.
    Now my problem is that it gives me so many linking error while compling my code..
    some are for time() function..
    some are for getenv() function...
    as u told winCE doesnt support time functions......
    Is there any other way so that i can solve these errors..
    Thanx in advance..

  • Anonymous
    October 02, 2006
    Zehra - for time() itself, look above in the blog posts to Fredrik's comments since he was nice enough to post his implementation here.  For getenv(), WinCE does not support the idea of environment variables.  You either need to hard-code whatever env. variables are being retrieved, or else modify the code so you read this from either the registry or some configuration file on the device.I'd recommend you post to one of the newsgroups at http://blogs.msdn.com/cenet/archive/2005/12/05/500181.aspx for other questions, since I'm better checking there than here & we have better discussions on newsgroups in general.John

  • Anonymous
    December 05, 2006
    The comment has been removed

  • Anonymous
    January 24, 2007
    Zehra: You have to use the WCECOMPAT library. Read about it in the OpenSSL docs.

  • Anonymous
    March 22, 2007
    Windows CE does not support the time.h structures, as I blog about here . Fortunately Chris Tacke at

  • Anonymous
    June 07, 2007
    Quite peculiar. Most of the common C runtime functions are done, but not time, which most non-trivial functions will use at some point.The comments about "targeting Wince" are a non-sequitur. The majority of developers will use standard C library functions first before having to resort to Win32 API functions, because this ensures much bettter portability, even within the windows world.

  • Anonymous
    July 20, 2007
    I wanted to know whether the function localtime() is available for wince or not  ? If no,  what is your suggestion for other alternate for the same.

  • Anonymous
    July 26, 2007
    CE doesn't do localtime() either.  I'd recommend checking out http://blogs.msdn.com/cenet/archive/2007/03/22/time-h-for-wince-at-opennetcf.aspx for OpenNetCF implementation of these routines.

  • Anonymous
    August 03, 2007
    I have a query related to logo submission. Is there any test suite similar to DTM(WDK) for Window Mobile CE  devices? If so,  can you let me know about the same.

  • Anonymous
    August 13, 2007
    jntupal - I know there is a logo test but I know very little about it.  I'd recommend a newsgroup at http://blogs.msdn.com/cenet/archive/2005/12/05/500181.aspx, or if you're working with someone at Microsoft (your TAM maybe - technical account manager) take the issue with them up directly.

  • Anonymous
    December 08, 2007
    I came across this today, and have to agree with what Aaron said above.

  • Anonymous
    May 27, 2008
    I got bitten by this today. My code compiles but won't link? That's dumb.Why not at least provide these functions as inline functions if you don't want them in the CRT DLL? (yeah, they may be too big to inline, but the compiler can choose not to inline it, right?)Not providing standard C functions that every other platform has is really irritating. Like Aaron said: "the majority of developers will use standard C library functions first before having to resort to Win32 API functions, because this ensures much bettter portability, even within the windows world."

  • Anonymous
    May 28, 2008
    Oh, I'd like to add that the time.h time_t should be updated to be 64-bit.I know the time.h APIs are poorly designed but I still prefer their portability.

  • Anonymous
    July 11, 2008
    Thanks for the post man- I was going mad not finding my appication run. It used to form the object file but the final compilation used to give an error. But what i say is that there should be an implementation of the basic functions or atleast use the name for other function that you make so that the ppl can search for solns when there programs give errors on compilation. Atleast th help shud have had something for us...