Re: googletest - localtime() isn't supported on WinCE

[Vlad Losev]

[+googletes...@googlegroups.com]

Kevin,

Please address your questions to the mailing list. If you contact developers directly, your mail may end up in the spam folder, never looked at.

On Wed, Oct 12, 2011 at 2:22 PM, Kevin Connor <ke...@striiv.com> wrote:

Hi Vlad,

I'm having trouble building gtest for WinCE.  One problem was due to WinCE not supporting localtime() which is required for the timestamp feature you added.  Maybe that could be wrapped in an ifdef GTEST_OS_WINDOWS_MOBILE?

One would need to implement similar logic for Windows CE. I imagine it would be something like this:

#if GTEST_OS_WINDOWS_MOBILE

  // Windows CE has no localtime() API.

  FILETIME file_time;

  file_time.dwLowDateTime = static_cast<DWORD>(ms * 10);

  file_time.dwHighDateTime = static_cast<DWORD>((ms * 10) >> 32);

  SYSTEMTIME system_time, local_time;

  FileTimeToSystemTime(&file_time, &system_time);

  SystemTimeToTzSpecificLocalTime(NULL, &system_time, &local_time);

  return String::Format("%d-%02d-%02dT%02d:%02d:%02d",  // YYYY-MM-DDThh:mm:ss

                        local_time.wYear,

                        local_time.wMonth,

                        local_time.wDay,

                        local_time.wHour,

                        local_time.wMinute,

                        local_time.wSecond);

#else

  // Using non-reentrant version as localtime_r is not portable.

  ...

#endif  // GTEST_OS_WINDOWS_MOBILE

Can you prepare such a patch and send it? We have no access to Windows CE and will not be able to test such a patch.

The other problem I'm still working through.  Windows is expecting _tmain or wmain instead of main when UNICODE is defined.

This one should be simple. Instead of using gunit_main library, write your own _tmain function. 

 

-Kevin

[Vlad Losev]

Kevin,

We try to keep the framework free from extra dependencies. Each extra dependency makes it harder for users to deploy the library. When you install Google Test, you don't have to install boost, google-glog, or expat. That's why I was careful to use only native API calls in my proposed patch. I wonder if you can take my patch as a base or write your own patch that doesn't use other dependencies.

On Wed, Oct 26, 2011 at 2:32 PM, Kevin Connor <ke...@striiv.com> wrote:

Hi Vlad,

Here's a patch for localtime() on WinCE.  I opted to make use of an open source lib  http://time.codeplex.com/ (not mine) rather than disabling the feature.  The lib is not included but a reference is in the code.  The lib unfortunately does not support setting the timezone so the tests were disabled for WinCE.  

There's also a small change at the end of gtest_unittest.cc to compile on windows.  Toss it if you don't want it.  Maybe it's not needed in a cmake env.  Cmake doesn't work for WinCE although patches have been submitted.

Let me know if you need me to sign a contributor's agreement.

You might want to run dos2unix after applying the patch.

-Kevin

Regards,

Vlad

[Vlad Losev]

What problems are you having on Winfdows 7?

On Windows CE, SetTimeZoneInformation will try to set time-zone information system-wide and that is a privileged operation. You normally cannot do it.

What you can do is inject the timezone information into ormatEpochTimeInMillisAsIso8601 instead. Here is how it could look:

In gtest.cc:

namespace internal {

// Used only for testing.

TIME_ZONE_INFORMATION* g_injected_tzinfo = NULL;

}  // namespace internal

...

string FormatEpochTimeInMillisAsIso8601(...) {

  ...

  SystemTimeToTzSpecificLocalTime(g_injected_tzinfo, &system_time, &local_time);

  ...

}

then in the test file, set the information for the case of WinCE:

class FormatEpochTimeInMillisAsIso8601Test : public Test {

 public:

  virtual void SetUp() {

    // Set up _tz_info for UTC.

    g_injected_tzinfo = &_tz_info;

  }

  virtual void TearDown() {

    g_injected_tzinfo = NULL;

  }

 private:

  TIME_ZONE_INFORMATION _tz_info;

};

TEST_F(FormatEpochTimeInMillisAsIso8601Test, ...) {

  ...

}

On Fri, Oct 28, 2011 at 12:00 AM, Kevin Connor <ke...@striiv.com> wrote:

Hi Vlad,

My apologies, I overlooked your suggested patch when I came back to this problem.  It works fine against WinCE 6.  I added some changes to gtest_unittest.cc so the relevant tests would pass.

Testing on Win 7 fails for me.  I tried using the WinCE code instead of the tzset code but that didn't work either.  I think it has something to do with process privileges but I don't have a fix for it.  Does it pass for you?

Here's sample code for windows mentioning process privileges:  http://msdn.microsoft.com/en-us/library/windows/desktop/ms724944(v=vs.85).aspx

-Kevin

[Vlad Losev]

Hi Kevin,

As we have no access to Windows CE, I strongly prefer to have an already tested complete patch that I'd only make minor changes to. That will save us from multiple rounds of 'does this work now?' exchanges. Can you post such a patch as described in http://code.google.com/p/googletest/wiki/DevGuide#Contributing_Code?

On Tue, Nov 1, 2011 at 10:47 PM, Kevin Connor <ke...@striiv.com> wrote:

Hi Vlad,

Please accept the WinCE patch as is.  The Win7 suggestion you make is good but won't work for WinCE because it doesn't have SystemTimeToTzSpecificLocalTime().  That's ok because WinCE doesn't have the problem with permissions.  I'll work the Win7 patch in after the WinCE patch is in.

In that case, it should be possible to set the desired timezone on WIndows CE using SetTimeZoneInformation. The test can save the existing timezone and set PST-07 in SetUp and then restore the original timezone in TearDown.

Oh, I did have a problem using namespace internal {...}  in gtest.cc.  I guess because it's already used in that file, it caused it to not compile (at least in MSVC).  I used a different namespace and it compiled but it didn't run as expected.  I'll work on it some more when I get a chance.  

-Kevin

Regards,

Vlad

[Vlad Losev]

Kevin - 

I haven't yet been able to review the path and get it through our internal approval process. I promise to do that at the first opportunity.

One question I can ask in advance though: you mentioned that setting timezone didn't work under Win7. This looks strange to me, as setting timezone a part of the standard library and not that of SDK. I wonder what was your configuration. Was the binary in question built under Win7 or was it build under XP/Vista and run on Win7? What version of Platform SDK did you use to build it?

Thanks,

Vlad

On Thu, Dec 8, 2011 at 3:57 PM, Kevin Connor <ke...@striiv.com> wrote:

Hi Vlad,

Here's the requested patch.  CLA has been faxed.  

This patch uses native api's for windows and WinCE to support the timestamp feature.  WinCE had a problem with this feature when it was using the unsupported localtime() call.   Windows does support localtime() but the unit tests were failing due to a lack of required permissions to set the timezone.  So the native api calls were used for that platform too, which allowed us to get the local time for a given timezone rather than what the system was set to. 

Please let me know if you need an issue to file this against.

-Kevin

[Vlad Losev]

[adding back the list to keep the discussion archived]

On Mon, Dec 12, 2011 at 2:11 PM, Kevin Connor <ke...@striiv.com> wrote:

Hi Vlad,

It was built on Win7 using Microsoft Visual Studio 8\VC\PlatformSDK.  I don't have VS2010 to check against.  It doesn't seem strange to me that an api call might require permissions but I'm no authority on it.

The tzset function Is described in Visual C++ documentation as follows: "The _tzset function uses the current setting of the environment variable TZ to assign values to three global variables: _daylight, _timezone, and _tzname". As you see, it makes no Windows API calls and as such is not a subject to permission restrictions.  As you mention it failing on Win7, it makes me scratch my head. What happens if you run on Win7 the test built on XP/Vista?

-Kevin

- Vlad

[Vlad Losev]

Hi Kevin,

I have updated the patch to make it simpler and comply with the Google C++ style guide. it's uploaded at  http://codereview.appspot.com/5490066/. Check it out and let me know if still works on Windows CE. If it doesn't, please make the necessary fixes and upload a new patch set to that issue.

I've reverted the changes to the mainline Windows implementation: if the tests still fail on Win7, I prefer to investigate futher. But if it turns out to be a failure in Win7 or MS's SDK or standard lilbrary and and it doesn't affect the gtets library itself, I'm still OK checking it in.

Regards,

Vlad