Yes, you read that right: Locking a simple mutex initializes a framework for periodic timers in the C++ Runtime of Visual Studio 2017. It didn’t take long for the first surprise:ĬreateTimerQueueTimer is actually called from the Concurrency::details::LockQueueNode constructor in crt\src\concrt\rtlocks.cpp, and that call originates from my std::mutex::lock() call. These stubs would just show a Message Box when being called, thereby giving me plenty of time to attach a debugger and examine the callstack. I decided to find out and implement simple stubs for all missing Timer Queue APIs in EnlyzeWinCompatLib. Is it maybe just an unused dependency that isn’t optimized out during build? What is Visual Studio doing here? So what is actually calling CreateTimerQueue?
None of these are recurring tasks and I’m also not doing any other timer-related operations. The most sophisticated thing my test application does is spawning threads and locking mutexes.
VISUAL STUDIO 2017 APPLICATION WIZARD CODE
They belong to the set of Timer Queue APIs, which were introduced in Windows 2000 and are rooted deeper in the OS.Īs always, the ReactOS source code comes handy to find out how complex they really are: reactos/sdk/lib/rtl/timerqueue.cīut wait a minute, why are these APIs actually needed in the first place? The remaining APIs are not so easy though. LpNewFilePointer ->QuadPart = liDistanceToMove.QuadPart If (liDistanceToMove.LowPart = INVALID_SET_FILE_POINTER) LiDistanceToMove.LowPart = SetFilePointer(hFile, liDistanceToMove.LowPart, &liDistanceToMove.HighPart, dwMoveMethod) This function can be implemented in its entirety using SetFilePointer. _CompatSetFilePointerEx(HANDLE hFile, LARGE_INTEGER liDistanceToMove, PLARGE_INTEGER lpNewFilePointer, DWORD dwMoveMethod) Taking the different return values into account, our compatible implementation of SetFilePointerEx looks like this: This can only be understood through the lens of history:Ĭ/C++ compilers did not always support 64-bit math natively, and so this workaround had to be used to accept 64-bit values anyway. Where SetFilePointerEx takes a 64-bit offset to move the file pointer and outputs the 64-bit absolute position after moving, SetFilePointer splits up each value into a low 32-bit part and a high 32-bit part. SetFilePointerEx is even better in that it can be implemented in its entirety around the SetFilePointer API. Two of them are dead simple: InitializeCriticalSectionAndSpinCount is just an optimization of InitializeCriticalSection, which has been with us since the very first release of Windows NT.Ī compatible implementation can just call InitializeCriticalSection and be done with it. The test application was already made Windows 2000-compatible using the previous approach.ĭependency Walker yielded the following missing APIs from Windows NT’s KERNE元2.DLL: I opened a test application (using std::mutex and std::thread) in Dependency Walker on Windows NT 4.0 SP6. It all begins with my naive attempt to port the v141_xp toolset of Visual Studio 2017 down to Windows NT 4.0.Īfter my successful attempt to get it Windows 2000-compatible, what should possibly go wrong?
VISUAL STUDIO 2017 APPLICATION WIZARD SOFTWARE
We’re going to use a wholly different approach to build software that also runs on Windows NT 4.0, without any compromises.Īnd we’ll end up with what’s probably the most modern way to compile C++ code in Visual Studio. So at some point, we inevitably stumbled upon industrial control systems that were still running Windows NT 4.0 from 1996.īefore you want to close the tab now, because you think that this is just an ordinary sequel to my previous blog post, be assured: Our method to build software compatible down to Windows 2000 using Visual Studio 2017 served us well for several months.Īnd trust me, I had really hoped that Windows 2000 would be as low as we ever had to go.īut the world of industrial manufacturing surprises you every day. Adapted EnlyzeWinCompatLib Project on GitHub.
0 kommentar(er)
