On 10/19/2010 10:28 AM, Domagoj Saric wrote:
"Marsh Ray" <marsh@extendedsubset.com> wrote in message news:4CB35BC2.5040302@extendedsubset.com...
Be aware that native API calls are not always documented and are subject to change.
I'm aware of that, however considering that: - Interprocess already uses the native NT API
The documented parts or undocumented parts?
- interdependencies between Microsoft's/Windows' own components (and the sheer number of those) make it reasonable to assume breaking changes to the native NT API can in practice ever occur only between major OS releases
Or service packs, or whenever. http://msdn.microsoft.com/en-us/library/bb432200.aspx :
The functions and structures in Winternl.h are internal to the operating system and subject to change from one release of Windows to the next, and possibly even between service packs for each release. To maintain the compatibility of your application, you should use the equivalent public functions instead. Further information is available in the header file, Winternl.h, and the documentation for each function.
I.e., "fair notice is given: ignore it at your peril".
- in practice breaking changes to system APIs have to be expected between major OS releases even for Win32 and other 'old&public' API as was demonstrated for example by the changes for interactive services between XP and Vista
That was a rare architectural change to Windows (explicit kernel support for multiple terminal services sessions) that broke the previous single-user assumption. App developers had been told that change was coming since post-NT4 days, IIRC. It doesn't discredit the general claim of compatibility across Win32. To the contrary, look at all the processes on your Windows system. How many are created as acutal native NT processes? Maybe two or three (winlogon, csrss), and last I checked the first thing they did was to load kernel32 like everybody else. Step through MS's own internally developed code and you'll see that even they use the documented Win32 APIs as much as possible.
I'd consider this 'danger' practically irrelevant (more like 'academic/by the book paranoia')
My impression from reading the list is that a lot of Boost developers appreciate the "by the book" observance of documented APIs. It's a design principle, not just a paranoid fear based on a perceived probability of breakage. Interfaces are defined not just for the purposes of assigning "blame", but so that we can discuss program correctness rather than just making empirical statements about observed behavior. Next time you read industry reports like "IT departments are delaying deployment of the update (containing 43 critical security fixes) for a few months until they better assess app compatibility" you might take that as evidence that app developers as a whole are not excessively "paranoid".
...especially considering the convenience and efficiency benefits the native NT API gives over Win32...
OK, at work we ship some commercial code that runs on Windows. We use Boost libraries extensively. Sometimes, we have to do some fairly "heroic" and undocumented things to implement the functionality of our product. DLL injection, API hooking, the type of stuff antivirus programs need to do. Right now I'm working on the Vista implementation of a feature that works three different ways on three different versions of Windows. So we are willing to go there when necessary and, most importantly, when there is no other option. But we do it with our eyes open, knowing the maintenance effort it may bring. Occasionally we run into situations where another 3rd party vendor has some creative ideas of their own for the same system customization points and we end up in undefined territory that way. Earlier Boost functionality had been implemented with just standard C++ features, but there was lots of compiler-specific stuff too, mainly to deal with divergence from the standard. Once Boost began venturing into system-level territory, it started acquiring code that needed system headers and specific operating system features. (Isn't it easy to cross these lines silently?) But now we are talking about dependencies on stuff that the platform vendor explicitly disclaims stability across OS versions and even interim updates. Again, if it's necessary to implement useful functionality, that's fine. Yeah I agree that the Nt* APIs aren't going to change all that often. BUT PLEASE STATE THIS DEPENDENCY BOLDLY IN THE LIBRARY DOCUMENTATION along with which OS versions and service packs (not just compiler versions) the library has been tested to work with. Pretty please? :-) It wouldn't rule out the use of such a library in our code, but we would at least know where to focus the extra testing with specific OS versions and where to start looking when customers report unexpected incompatibilities. - Marsh