When connected, an IOTCore device will sync the time periodically, using Windows Time NT service and a time server. You can configure the time server via w32tm if needed. There's a similar question/response here.
However, I suspect your scenario is different. Can you send me your previous feedback post and any additional details to my email: msaleh (*at) microsoft.com?
Re (1), The CRT non-standard functions serve many areas, many of which are not available for the Win32 APIs; e.g. the debug heap, but the important thing is consistency. This will reduce bugs and maintenance of course. Sometimes, you have to use CRT functions; for example if you're creating new threads and expecting to call CRT functions within the thread methods, then use _beingthread() or _beginthreadex() instead of Win32's CreateThread(). If you don't use _beginthread*(), then there could some memory leaks. Another example, is the environment variables functions. To make sure your environment variables are correctly read/updated, then either use the CRT functions exclusively or the Win32 API ones. Finally, the CRT functions have been designed to abstract away many of the complexities of the Win32 APIs, so you may find them easier to use. _exec* functions are much easier to use than CreateProcess for example.
Re (2), like you've mentioned yourself, as with the whole product, O/S version support for the new CRT is not yet finalized, but I will try to get more details for you here.
Re (2), this Connect bug talks about the same issue: "This [No XP support] behavior is by design in MFC and CRT for Visual Studio vNext. The minimum supported operating systems are Windows Server 2008 SP2 and Windows Vista. Windows XP is not a supported operating system for the release (design-time or run-time)." The release mentioned is "Developer Preview".
There's a workaround already described there as well, which is use the multi-targeting feature. If you have Visual Studio v10 and vNext installed on the same box, you can target v10 compiler toolset and libs inside Visual Studio vNext. The limitation of course, you'll not benefit from improvements to the CRT or compiler or other libs improvements/bug fixes.
Good catch. That was bad of me! The latest Windows Driver Kit (WDK), 7.1.0, build environment allows building using various library options. Please see here. According to that page, msvcrt is the preferred option.
@C64: Right, you should not link to msvcrt. Static linking to the Visual Studio CRT will be your best bet. And with these O/S versions you're targeting, Visual C++ 10 fits your needs. I don't know how much your app size will increase - it all depends on how much of the CRT you're linking in. But my guess, it should be within the range you're looking for. The easiest way to verify is build once with /MD and another with /MT and see how much the size increases. To reduce app size, there are some tweaks you can make, e.g. /O2 instead of /O1, use intrinsics, even use Win32 APIs instead of CRT functions when possible.