by Michael S. Kaplan, published on 2008/08/13 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/08/13/8856228.aspx
The mail from the contact list:
"Though ultimately the funniest part being the requirements for both functions:
Client Requires Windows Vista, Windows XP, or Windows 2000 Professional.
Server Requires Windows Server 2008, Windows Server 2003, or Windows 2000 Server.
This is something that makes very little sense given just the header file alone, let alone the pragmatic knowledge between the two topics and the past knowledge of many a Windows developer. :-)"
Dig out the Platform SDK for Windows Server 2003 SP1's documentation. Current versions has gotten rid of some of the references to versions of Windows prior to Windows 2000. Talk to the Windows SDK team for more on this.
The reference was from my blog Oceania is at war with WM_SETTINGCHANGE; Oceania has always been at war with WM_SETTINGCHANGE.
Holy missing my point, Batman!
I understand the idea behind yanking out information about versions that are no longer supported.
That even makes sense.
But when looking at topics like the WM_WININICHANGE message and the WM_SETTINGCHANGE message, there is more involved than just taking Win9x off the list. There is in such topics huge allusions to backcompat and prior versions, versions which no longer exist.
In this new world there are only three choices:
Personally, though I find the third option to be the most fun from the standpoint of writing blogs, I kind of prefer the first choice best....
That is the whole method behind the madness in topics like Obsolete Windows Programming Elements, after all.
And I think WM_WININICHANGE message is honestly much more of something there for compatibility with 16-bit Windows anyway, the parent topic in which Obsolete Windows Programming Elements sits. It was indeed 16-bit Windows that using WIN.INI wasn't discussed in terms of backcompat.
Though it makes me wonder whether the answer is to expand the topic to include Win9x, or have a separate set of topics for the Win9x backcompat story.
I could really see that one argued either way (though WM_WININICHANGE is really there for 16-bit more than anything else, there may be other elements more suited to Win9x compatibility!)....
This post brought to you by ᅅ (U+1145, a.k.a. HANGUL CHOSEONG
IEUNG-SIOS)
Yuhong Bao on 14 Aug 2008 6:44 PM:
If you are curious, I posted this comment and sent this email about the docs.
"WM_WININICHANGE is really there for 16-bit"
WM_SETTINGCHANGE did not exist in NT 3.x, at least according to the Platform SDK for Windows Server 2003 SP1's documentation.
Many people believe Win95 was the first 32-bit OS. NOT TRUE! NT 3.1 was the first released 32-bit OS.
Also, it isn't just Win9x, NT 4 and earlier info are also being eliminated from the docs.