Re: [boost] [interprocess] OS version dependencies

Subject: Re: [boost] [interprocess] OS version dependencies
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-10-19 15:20:55

On 10/19/2010 10:28 AM, Domagoj Saric wrote:
>
> "Marsh Ray" <marsh_at_[hidden]> wrote in message
> news:4CB35BC2.5040302_at_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