Boost logo

Boost :

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
>> 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. :
> 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

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

> 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.


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

- Marsh

Boost list run by bdawes at, gregod at, cpdaniel at, john at