A recent blog post over at pcjs.org explores some of the mysteries surrounding information that at one point or another was published as a Microsoft KnowledgeBase article (or a KB article for short).
It’s not entirely clear where the KB articles originally came from or when, or what happened to them. The current best guess is that the KB articles started being written around 1987 and were likely accessible through some online service (dial-up, that is). They were never particularly well organized and relied on using keywords, which were themselves not clearly defined. The KB articles were written by Microsoft support personnel with input from product development, and often corresponded directly to bugs reported by customers. Finding something was a little difficult, and it appears that the main purpose was to publish something that customers could be pointed to.
KB articles were also updated, so the a KB article with a given number in 1989 was not necessarily identical to the same KB article in 1992. The information content was largely the same but the exact text was not. Some KB articles were also removed entirely, not always for obvious reasons.
Many KB articles contain useful information not found anywhere else, but finding them can be tricky. Sometime in the mid to late 1990s, Microsoft started publishing KB articles on the web and that became the official KB repository. But many KB articles never made it there in the first place (such as KB articles related to OS/2, which Microsoft had thoroughly disowned by then). Does that mean the old KB articles are gone? Well, not exactly…
There was a large archive of KB articles on Microsoft’s FTP. This was updated until about 1999 but after that, only the web versions were kept up-to-date. Again, the FTP KB archive is incomplete and doesn’t contain certain old articles.
Before the Internet was widely available, Microsoft published KB articles as part of the MSDN Library, which started out around 1992. The caveat is that over time, Microsoft added not just new articles but entire categories of articles to MSDN Library, and some of those categories were themselves quite old. The upshot is that a MSDN Library from 1998 might contain KB articles from 1990 that were not part of MSDN Library from 1994. It is unclear if the newer KB article archives on newer MSDN Library releases are proper supersets of older MSDN Libraries.
Before the MSDN Library showed up, there was Microsoft Programmer’s Library or MSPL (1988 to 1991), and that also contained select KB article archives. The MSPL notably includes KB articles related to the original OS/2 SDK which probably didn’t survive anywhere else. As is the norm with KB articles, it’s a bit of a mess—for example the mouse-related KB articles mentioned on pcjs.org are present in MSPL 1.3 but not MSPL 1.4, probably because they were misfiled and perhaps not intended to be published on MSPL in the first place.
A set of KB articles has been posted on pcjs.org for everyone’s reading pleasure. I believe it is just the “Microsoft C” category from MSPL 1.3, but it’s obvious that the categorization by topic was fairly random and there are many articles that have very little to do with C. For anyone trying to use Microsoft C 5.1/6.0, it would have been a very useful resource.
There is clearly more work to be done in recovering old KB articles and making them available where Microsoft does not.
I had to use web.archive.org pretty often recently for old KB articles which was easily available not long ago.
And nowadays Microsoft seem to be zealously deleting KB articles written for Windows XP (even if they’re still applicable to later versions) as it’s “not supported”, while older articles about Windows 3.1 or DOS are still easily found…
Not to mention that the URLs seem to change pretty frequently so keeping track of useful articles is pretty much impossible.
Somebody (and it would take quite a dedicated “somebody” considering all the work involved) should probably work on building a comprehensive archive of all KB articles, with revision history where possible. With all the sources/distributions mentioned there should be enough data out there to build something fairly comprehensive if someone were dedicated enough. Microsoft clearly have no interest in preserving anything historically significant.
Me too – I often get the feeling that Microsoft is or has been purging its archives of anything or almost anything not dealing with XP (or even 7) or newer. D-:<
Even the online portions related to Windows 10 are fairly hit or miss as half the time any request I send results in a long delay before being redirected to the Windows home page.
Compuserve had a partial mirror of what was available through the MS BBS which in turn was not complete. Ran up more charges thanks to the hourly fee than I should admit tracking down needed information.
No one should ever use MS C 6.0 for any purpose. The MSPL will provide examples of some of the severe bugs contained but there were a lot more and many only showed up when trying production compiles. Works in the debugger; crashes at the customer; not a happy place for a programmer.
A similar thing happened when Windows 9x was retired. I think Microsoft basically tries to make it as difficult as they can to run those old OSes without explicitly breaking them.
I thought CompuServe probably had something. At some point it was apparently also possible to send an e-mail with the KB article number in subject and they’d send back the article.
I never used MS C 6.0 for anything serious, but I have heard horror stories from programmers who were forced by the bugs to use Borland C (and never looked back). I’m actually not sure if MS C 5.1 or 6.0 was worse in that regard.
Just about all Windows 2 applications were done with MS C 5.1 so it was not that bad. There was a lack of other C compilers able to handle Windows libraries. Turbo C had flaws and only produced smaller DOS executables; Borland C++ was a choice for big applications but only got into the Windows realm about the time Windows 3.1 was shipping. By then, MS was offering their apology footlocker under the guise of MS C 7 and both Zortech and Watcom had modest followings.
The bugs in MS C 6 are mind boggling. Sending a string to output would result in that string having nulls placed into the middle of it. Unexpected behavior that makes no sense and the work around of having to create a twice as many variables solely to communicate with the C libraries ate up a lot of memory. All the promise of a unified IDE under OS/2 squandered by one of the worst code generators in history.
And it was mostly MS’s fault that it took so long for Borland to support Windows.
On the subject of archive.org links, about a year ago, Microsoft trashed a good number of their backups by updating their robots.txt. They really have become a customer-hostile company in a way they never were during the bad old antitrust days.
I’ve just been playing with using https://sourceforge.net/projects/helpdeco/ to convert the .MVB data from an old MSDN CD back to RTF. HTML Help Workshop can convert that to HTML but it really needs some massaging, and it seems that some of the metadata (e.g. the hierarchy of topics used to display them in a tree) must be in some other file and format.
Be sure to compile helpdeco for a 32 bit architecture, amongst other things it uses “long” in some structs it reads from disk and hence breaks when built for 64 bit.
I’m hoping to convert the product documentation into something more readable with modern tools but this might also be useful for programmatic extraction of KB articles from the older MSDN CDs.
Yes, in the Windows 2.x days MS C was pretty much the only game in town, Microsoft greatly benefited from developing the compilers and systems in parallel. How big the actual Windows 2.x software market was I don’t know, but for Windows (and OS/2!) there weren’t real alternatives before 1992 or so.
Those are some interesting bugs 🙂 I think MS C 6.0 was the only one which got an ‘A’ update release (6.0A), then there was 6.0AX, and I don’t know if it was really mostly bug-free at that point.
Oh yeah. That would probably work well for the KB articles because they’re basically plain text. The question is if there’s anything on MSDN CDs that isn’t elsewhere (MS FTP archive, for example), but it’s probably impossible to tell without extracting the KB articles first.
I extracted the knowledge base articles from the January ’93 CD to (ugly) HTML using helpdeco, some hacking of the .rtf, then HTML Help Workshop. HTML Help Workshop doesn’t use PRE tags!
Anyway I can dump out the article numbers and compare them to other sources. Where precisely might one find knowledge base articles in an archive of the MS FTP site? I have some files like:
01/30/1996 vbkb16.exe VB KB Help File (16-bit) 30-Jan-96
12/13/1995 vfkb-ge1.exe Windows 3.x Help File of General KB Articles
11/17/1993 dlgskb.exe Knowledge Base for Windows SDK
but I don’t think I have many for developer tools.
I feel like it shouldn’t be hard to make a database showing which KB article is in what source with what last modified date, which is something I wanted to make not for KB articles but product documentation (e.g. “which of these CDs has the Microsoft C 7 documentation on it?”) but is similar.
I’ve also worked out the format used for the early MSDN CDs for the topic tree, and was able to use this to create a HTML Help version of the C7 documentation from the first MSDN CD with the topic hierarchy almost correct.
Are there any better places to discuss this, e.g. forums?
I’m not aware of a better place to discuss this.
The MS FTP used to have the KB articles in the /MISC and later /MISC1 directory. It was over 60,000 text files. I didn’t even know of the KB archives you found there, so that’s good to know 🙂
I have been going through a few MSDN CDs in the meantime. What I found is a bit depressing, the set of KBs changed every time. Not only were new articles added (predictably) but a number of old articles vanished. At least some of the old MSDN CDs also did not include any ‘last modified’ information, so we can only guess when they were actually last updated.
Yeah, Microsoft can be grade-A assholes at times…
The few times I’ve searched for KB articles, I’ve found them on c-bit.org, such as
http://www.c-bit.org/Q/165989/EN-US/
which is referenced in old NSPR sources[1]. Since I don’t search for anything current when it comes to Microsoft, I don’t find it on the MS website.
The thing here, is that to understand what the NSPR workaround is actually about, I need to read the actual KB article. Just the code and cryptic comment is not enough.
There are likely more such code comments scattered in public and private sources, and MS is just being assholes by removing the articles. How are developers to know if the workaround can be removed, if they don’t know what version(s) have been fixed? We all know that there can be decades between a fix applied and a subsequent code review if it’s still required.
[1] “See Microsoft Knowledge Base article ID: Q165989” — prsocket.c:306 in NSPR 4.1.1
Interesting, though the font they use is awful. I wonder what the source for those KB articles is (web, MSDN, TechNet, something else).