The Old New Thing

not actually a .NET blog

My Links

Blog Stats

News

You can propose a new topic in the suggestion box.

Archives

Post Categories

Blogroll

Links

News for dummies

What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?

In a previous entry I discussed the story behind the functions with the funny names BEAR, BUNNY and PIGLET. But what about the ones with goofier names like BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?

For this, you need a deeper history lesson.

Back in the old days of real-mode Windows, all callback functions had to be exported. This was necessary for complicated technical reasons I may bother to explain if anybody really cared but I doubt anybody does any more. So the window procedures for all of the standard window classes (edit controls, list boxes, check boxes, etc.) were exported from USER. So too were various other callback functions like timer procedures. This was in addition to the usual collection of internal functions so USER, KERNEL and GDI could coordinate their efforts.

Some people reverse-engineered all these internal functions and printed books on how they worked, and as a result there were a lot of programs that actually used them. Which was quite a surprise to us because they were internal functions. And then when we wanted to redesign these internal functions (for example, to add a parameter, or if we decided that we didn't need it any more and tried to delete it), we found found that the progams stopped working.

So we had to put the functions back, with their old behavior. The new features were were contemplating had to be redesigned, redirected, or possibly even abandoned entirely. (If we wanted to delete a function, then the work could continue, but the old function had to stay around with its old behavior. It was basically dead code from the OS's point of view, hanging around just because some random app or other decided to cheat and bypass the documented way of doing things.) But to teach people a lesson, they often got given goofy names.

For example, BOZOSLIVEHERE was originally the window procedure for the edit control, with the rather nondescript name of EditWndProc. Then some people who wanted to use the edit control window procedure decide that GetWindowLong(GWL_WNDPROC) was too much typing, so they linked to EditWndProc directly. Then when Windows 2.0 (I think) removed the need to export window procedures, we removed them all, only to find that programs stopped working. So we had to put them back, but they got goofy names as a way of scolding the programs that were doing these invalid things.

Things got even worse in Windows 95, when all our window procedures were converted to 32-bit versions. The problem is that the old window procedures were only 16-bit. So we couldn't even simply export the 32-bit window procedure under the name BOZOSLIVEHERE. We had to write a conversion function that took an illegal 16-bit function call and converted it to the corresponding illegal 32-bit function call.

This is just the tip of the iceberg with respect to application compatibility. I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95. (Games were the worst. Often the game vendor didn't even care that their program didn't run on Windows 95!)

posted on Wednesday, October 15, 2003 1:34 PM

Feedback

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 2:18 PM Israel

That's really funny. >We had to write a conversion function that took an illegal 16-bit function call and converted it to the corresponding illegal 32-bit function call.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 2:48 PM RJ

Maybe just breaking the apps (and contacting the authors with an alternative) would have been a better solution? There can't have been *that* many apps that use undocumented code. It might have resulted in a slightly better view of MS to *some* people today. As far as I can see if someone tells me something is undocumented and/or internal, I steer well clear, those that claimed MS were putting in *special* code for themselves are just being silly - aren't they?

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 3:38 PM Florian W.

Why not just print a message box saying "The stability of the software could not guaranted" ? I remember that Windows 3.* prints something like this, when tried to get running on [Dr|Novell]-Dos.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 3:40 PM runtime

How could you rename the exported callbacks in Windows 2.0 without breaking the apps using the old but undocumented function names? I guess this was back when DLLs exported functions using ordinals instead of function names?

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 5:06 PM Keith Mason

Talking of funny API calls, was the item ID structure SHITEMID deliberately named by the developers for a laugh? The Windows API is riddled with such things; now seems to be the ideal opportunity to ask something I've always wondered.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 5:27 PM Brian

Back in the days of Windows 3.0 and 3.1 (and WfWG) I remember that careful examination of the most popular Microsoft applications (Word and Excel -- very much the same as they are today) revealed that they used the undocumented internal functions. Though some claim that using internal functions was bad programming practice it was done inside Microsoft. That gave many sotware authors the idea that special features and performance were being kept behind closed doors for MS use only. Whether that was true or not (still in dispute) the end result of difficulties for Windows was set by the perception. Now the secret APIs are far more difficult to get at and better documented (in the DDK). And applications are just slightly better behaved.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 6:44 PM Mike Dunn

SHITEMID is one of my favorites. You can find it in the help by typing the first four letters. ;)

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 8:00 PM John B.

How about the structure INITCOMMONCONTROLSEX?

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 8:05 PM runtime

I used to work at Microsoft in the Windows NT QA team. I heard of at least one undocumented Microsoft-only API. I don't remember the name of the API. In an old version of the API, one function parameter was a pointer. In a later version, when the API's dwFlags parameter had some extra bit flag set, the API's pointer parameter would be treated as an array. array[0] would contain the documented pointer value. array[1] and beyond would contain "bonus" parameters to trigger undocumented behavior used by some Microsoft app. I thought this was a clever twist of the C language, but I felt it was ethically dubious.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 8:06 PM runtime

and don't forget the BURGERMASTER! I've driven by the real Burgermaster, but I've never eaten there. (I'm a vegetarian.)

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 8:07 PM Ian Hanschen

A friend of mine worked in the compatibility group for XP - he'd take apps and have to debug and sometimes disassemble them to figure out what had gone wrong. You might want to mention the AppPatch architecture in a future post - it works so well for compatibility that most people don't know it's there.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 8:52 PM Shane King

The problem is that programmers may not always know the right way of doing things. There's nobody in the world who's an expert at everything. So when I need to do something that I'm not sure about, I look it up. These days that involves a google search, but in the old days you can substitute books, articles etc. If the first answer I find is the wrong way, but it works, I'll probably keep on using that way. I'll never know it's wrong - since it works! Then some day the program I've written will be one of the ones you're complaining about having to maintain backwards compatability for. How was I to know? In the case of the exported functions, I'd say it's Microsoft's fault, not the developers. If you don't want people to use a function, you don't export it. There may have been technical reasons why it had to be done that way, but that's tough luck .. the developer doesn't and can't know that. They just see the exported function, and think it's OK for use. API designers needs to realise that if you make a function publically accessable, you're commiting to maintaining that function, potentially for a very long time. It doesn't matter whether users are meant to use it, it doesn;t matter if you document it with a big red sign "Do not use this". Some day someone's going to use it, probably not even knowing that such documentation exists. The .NET framework is setting itself up for similar issues, since if you look through MSDN, you'll find all sorts of classes that are publically exposed yet have the documentation "This is intended for internal .NET framework usage". Well if it's intended for internal usage, why make it public? If you have to make it public due to technical reasons, you have to realise you've made a commitment to maintain that function through versions, and it's simply not good enough to say "bad programmer, don't use it". It's a simple rule really. If it's publically exposed behaviour, it's part of the API. Documented or not. Intentional or not.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 9:12 PM Vimal Subramanian

Totally agree w/ Shane. This situation is comparable to why Microsoft chose to implement certain methods for some value types as Explicit interface method implementation just to keep the documentation short at the cost of confusing the developers!!!

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/15/2003 10:45 PM Ian Hanschen

Wow. That's a great point, Shane.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/16/2003 1:56 AM Raymond Chen

The functions were exported only by ordinal. There was no documentation, there was no LIB file to link against, the function wasn't named; you had to reverse-engineer the LIB file and link with it. Surely that must've been a clue that what you were doing was the slightest bit dodgy. Office probably found those undocumented functions the same way you did. In the Windows division, we treat Microsoft applications the same as any other company's applications. In fact, earlier versions of the programs now known collectively as Office were such problems that -- I hope the Office folks' feelings aren't hurt by this -- we made up insulting names for them just to keep our sanity. The only one that comes to mind right now is "PowerPig". (I must point out that in the intervening years, the Office folks have done a fabulous job of getting their act together.)

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/16/2003 5:46 AM Oliver Anhuth

On the topic of undocumented API calls. There are some Win32 functions which do not work as they are documented. For example GetClassInfoEx is documented to return a BOOL. However when you look at the ATL headers, you notice that the return value is cast to a window class ATOM. I was wondering if this was a documentation error or if the ATL developers used some internal knowledge. I guess that changing GetClassInfoEx to return a plain BOOL would cause a lot of code to break.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/16/2003 8:29 AM LemonSmasher

What's with spUnkContainer in AtlAxAttachControl? How come this isn't closely associated with a 'CSpermDonor' class?

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/16/2003 8:43 AM Sean Legassick

I had a usenet conversation with you on precisely this subject (workarounds for bad app-coding) with IShellFolder. I was particularly annoyed because the workaround broke my code. Anyway we dealt with the problem, I moved on, so it's all history now. Reading this makes me more sympathetic than I was then: http://groups.google.com/groups?selm=Hh0%3DOKJDm8rj%2BeKTQJbUMYXjIasX%404ax.com

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/16/2003 10:18 AM Mike Dimmick

Indeed, if you look at the various AppCompatibility registry settings, WINWORD seems to be a frequent offender (among many!)

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/16/2003 3:29 PM John Topley

Raymond, I have it in the back of my mind (probably something I read once) that Neil Konzen was one of the lead developers of USER - is this correct? I remember in "Unauthorized Windows 95" Andrew Schulman mentions that he once had a chance to see the source code for USER, and "was frankly appalled"!

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/16/2003 3:59 PM Michael Geary

"Back in the old days of real-mode Windows, all callback functions had to be exported. This was necessary for complicated technical reasons I may bother to explain if anybody really cared but I doubt anybody does any more." Probably no one cares :-) but it was even worse than that. Not only did you have to export callback functions, but in most cases you had to call MakeProcInstance() on them too, and use the return value from that function instead of just a simple function pointer. And it wasn't just real-mode Windows. 16-bit protected mode Windows had the same problem. Except for one thing: It was never true. EXPORTS and MakeProcInstance() were never necessary, even in the days of Windows 1.0. Those kludges were needed only because of the particular function prolog code that compilers generated in that day. I wrote a little program called FixDS that patched the prolog code to eliminate the need for EXPORTS and MakeProcInstance(), and later on all the Windows C compilers adopted this technique. For the historians out there, I dug up the original readme file for FixDS and posted it here: http://www.geary.com/fixds.html That readme file has all the gory details on why EXPORTS and MakeProcInstance() were (but really weren't) necessary.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/16/2003 4:56 PM Alfons

DS != SS.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/17/2003 5:48 AM Hal

"I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95. (Games were the worst. Often the game vendor didn't even care that their program didn't run on Windows 95!)" Yeah, I was working support for Toshiba notebooks at the time, and remember more than one CEO say that their $4000 Portégé sub-notebook was "a paperweight" because it wouldn't run their favorite game any more... Which would turn out to have some weird-ass never-before-seen DOS memory extender and graphics engine. As far as I can tell, this is mostly because every game programmer on the planet believes they can write a better graphics engine than anyone else in the world. Trouble is, unless their name is John Carmack, they're wrong.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/17/2003 6:56 PM Michael Geary

"DS != SS." My terse friend, you are right. Silly me, what was I thinking? USER.EXE was a DLL, where DS != SS. The whole FixDS thing was for EXE files, not DLLs--so the exports were necessary in USER.EXE after all. Shows you how long it's been since I've touched 16-bit Windows. Thank goodness! :-) -Mike

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/18/2003 6:46 AM KiwiBlue

But why on Earth three core DLLs from Win 3.x (kernel, user, gdi) had an .EXE extension? I remember that I've tried to 'launch' them from Norton Commander :)

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/20/2003 7:57 AM Peter Lund

I /do/ care about the complicated technical reasons :) -- and what are those reload thunks that Michael Geary mentioned in his fixds readme? (poor man's VM?) -- and why the inc bp in the function prolog? That was something about being able to tell near and far functions apart while doing a stack walk (through the pushed bp's), wasn't it?

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/20/2003 5:00 PM Alfons

IIRC Mike called the fixds thunks "reload thunks". They reload DS. It's pretty amusing to see those famous "THAT VALUE WAS JUST SITTING IN ANOTHER REGISTER WAITING TO BE USED." Brings back that nice chuckle moment I had when I encountered fixds for the first time.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/21/2003 12:37 PM Michael Geary

Reload thunks were indeed the poor man's, real mode VM--they were how Windows dynamically loaded code segments and kept track of how recently they were used. And yes, the INC BP was for keeping track of near/far functions on the stack. Amazingly enough, a Google search for "reload thunk" will find a link to a copy of the original edition of Petzold's book that somebody in Ukraine has put online: http://geonic.net/lib/development/win/petzbook/part3_7.txt This has all the details of how painful (and rather clever) real mode memory management was in Windows.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/21/2003 12:59 PM Michael Geary

I'm glad you got a chuckle out of that, Alfons. It was fun to dig up that old readme file and reminisce a bit. Just glad we don't have to deal with that any more! :-) "But why on Earth three core DLLs from Win 3.x (kernel, user, gdi) had an .EXE extension?" In Windows 1.0, the .dll extension was not used at all. All DLLs had to have the .exe extension. I have no idea *why* that was, though, and it was soon fixed (I think in Windows 2.0) to allow other extensions.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/21/2003 1:06 PM Michael Geary

One mistake: I said that geonic.net link was the "original edition" of Petzold's book. Actually, it's the version of the book for Windows 3.0. But this memory management stuff was pretty much the same in real mode and 16-bit protected mode.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 10/23/2003 9:36 AM Fabi

"I remember that careful examination of the most popular Microsoft applications (Word and Excel -- very much the same as they are today) revealed that they used the undocumented internal functions." Wether they got them from internal docs or found out by themselves - But that's one of the reasons that the competitors accused MS for: That they had to live with the "official" API and MS could use the internal (and better? - I don't know) functions which would give them an advantage over the others. Maybe the Windows dev team should have slapped on some fingers instead of fixing things.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 11/4/2003 5:07 PM Larry Osterman

Historically, Microsoft applications were the LAST versions to work on any version of MS-DOS, because they were so sleazy. And they got their information from reverse engineering DOS, just like anyone else. Back when I was in the DOS group, the apps guys didn't have access to our source code (the sources were on the 68K Xenix boxes (Snuffy and Hal in particular, if I recall) in the machine room and the apps guys didn't have accounts on the boxes). And Fabi: To my knowledge, there wasn't a single real-world application written for MS-DOS that only used the documented DOS API set. EVERY application used some form of hack (either the indos flag, or writing directly to video memory, etc). The only possible exception MIGHT have been the compilers, but I'm not willing to bet on them. EVERYONE broke the rules.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 12/10/2003 4:24 AM Norman Diamond

Perhaps you should have given a higher priority to making Windows 95 compatible with itself and with its own documentation, and a lower priority to making Windows 95 compatible with broken applications? "We had to write a conversion function that took an illegal 16-bit function call and converted it to the corresponding illegal 32-bit function call." "If any application failed to run on Windows 95, I took it as a personal failure." EVERY application failed to run on Windows 95 after a blue screen. Windows 95 could be sitting doing nothing and get a blue screen, or have Office FindFast running in the background and hang, etc. But usually the user would be doing something silly like having Word, Outlook, and Internet Explorer all open at the same time, and lose their work when Windows crashed for Windows' own reasons. It still happens today in Windows 2000 and XP. I admit that the Windows NT4 and 2000 and XP kernels don't tend to give blue screens all by themselves the way that Windows 95 used to. With real kernels, it is device drivers. But most of these drivers are still part of the Microsoft product, signed and certified and published by Microsoft, delivered by Microsoft on the Windows 2000 or XP CD, and installed automatically during Windows installation. Some came with NT4 service packs or Windows Update downloads. Again, "If any application failed to run on Windows 95, I took it as a personal failure." Did you take it as personal failure when legal Win32 applications stopped working every time Windows 95 crashed? Imagine if priority had been given to making legal 32-bit function calls work better than illegal ones.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 12/10/2003 11:37 AM Raymond Chen

Yes, I took it as a personal failure when Windows 95 bluescreened. I debugged a boatload of those. To the point where I could debug many of them just by looking at the numbers in the error message. Most of them were heap corruption caused by drivers. For Windows 2000, a bunch of really smart people developed the Driver Verifier and Windows XP improved upon it. The Driver Verifier injects itself between a driver and the kernel and watches for various misuses of kernel services, detects various classes of heap corruption, forces obscure timing scenarios to flush out edge conditions. We simply didn't have that sort of tool back in 1995. I wish we did.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 12/10/2003 9:09 PM Norman Diamond

The Driver Verifier is good news. Is it OK if I name names of a few Microsoft-supplied drivers in the Windows 2000 and XP CD-ROMs which need to be tested with the Driver Verifier? Actually Microsoft already knows about one of them. The Windows 2000 HCL used to say that the Trident 9385 was compatible. But Microsoft edited the Windows 2000 HCL so it no longer says so. By the way, do not confuse this with the Trident 9385 Reference Model or something like that, I mean an actual Trident 9385. (The Windows XP driver for the Trident 9385 has the problem fixed, but I couldn't find a way to force this driver into Windows 2000. Some other Windows XP drivers do run under Windows 2000 and vice-versa, so I tried to see if this one might. It didn't so I'm still left with the Windows 2000 built-in blue-screener. By the way some wags on alt.os.windows2000 said that I should pull out the chip and put an entire display adapter board in this notebook PC.) Actually Microsoft already knows about another one too. A Windows 2000 service pack, I think SP2, was documented as fixing a known bug in the TCP-IP driver which caused blue screens, but the blue screens continued without knowing about the purported fix. Actually Microsoft probably knows about some Windows XP drivers such as PCMCIA.SYS because Windows XP provides that nice error reporting tool after a blue screen. Now only if there were some way to get action on them. It's not always drivers though. Sometimes it's the Visual Basic Common Dialog Box (including VB6SP5 and I don't know yet if it includes VB .Net). Sometimes it's Internet Explorer. These cases don't usually lead to blue screens, these usually lead to individual applications crashing. Of course it is much better for an individual application to crash. However, these are perfectly legal applications. It still would be nice if more effort were made so that legal applications wouldn't crash, instead of concentrating on making illegal applications not crash.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 12/10/2003 9:16 PM Norman Diamond

By the way, to interleave another thread here, on 10/21/2003 Michael Geary responded to someone: >> But why on Earth three core DLLs from Win 3.x (kernel, user, gdi) >> had an .EXE extension?" > > In Windows 1.0, the .dll extension was not used at all. All DLLs had > to have the .exe extension. I have no idea *why* that was, though, Remember where NT's architect came from. Though actually I wonder why this wasn't fixed immediately while being copied in. One of the most confusing things in VMS was to try to execute a .EXE file and find out that it wasn't executable. VMS's predecessor to DLLs, with the same kind of functionality, was called a shareable image.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 12/10/2003 10:01 PM Raymond Chen

In fact by far the vast percentage of the effort is indeed towards making perfectly good applications not crash. But those stories aren't as fun to tell. Just because I talk about X more than Y doesn't mean that X gets more attention than Y. In fact, it's likely to be the opposite. I tend to talk about things that don't get *enough* attention.

# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 12/11/2003 8:38 PM Norman Diamond

> In fact by far the vast percentage of the effort is indeed towards > making perfectly good applications not crash. Unfortunately the results of that effort aren't visible to customers... Or maybe they are! Word 95 through Word 2000[*], and Internet Explorer all versions and Outlook Express all versions, being not perfectly good applications, it shouldn't be a surprise that these applications crash themselves, and it shouldn't be a surprise that these applications crash the entire Windows session if it's Windows 95 or 98. But then what happens when Internet Explorer and Outlook Express become part of the OS? > But those stories aren't as fun to tell. Agreed. [* I don't have enough experience with Word XP yet to either include it or exclude it from this list. However, I did observe that Word XP displayed one particular file without occupying 100% of the CPU. Word 2000 SR1 occupied 100% of the CPU, just displaying the file without any editing. In fact after spending a few seconds scrolling about half-way down that 60-page file, I didn't even touch it any further for 8 hours, and it used 8 hours of CPU time on a 333MHz Celeron. Word 2000 SP3 also occupied 100% of the CPU but I shut it down after a few minutes.]

# backward or forward? 6/16/2004 3:47 PM Gregor J. Rothfuss

joel spolsky wrote an excellent article how microsoft shifted from making sure all applications continue to run on new os...

# PowerPig and BURGERMASTER 6/17/2004 9:49 AM ta bu shi da yu from Hulver's site

BURGERMASTER... that was a variable or something in Windows 3.1x that did something with memory, right?Nevermind. This comment is far more interesting...<br>
# RE: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?&amp;nbsp; 10/16/2003 1:56 AM&amp;nbsp; Raymond Chen<br>
The functions were exported only by ordinal. There was no documentation, there was no...

# re: What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS? 6/18/2004 9:23 AM Raymond Chen

Commenting on this article has been closed.

# Testing Obsolete Methods 6/28/2004 3:14 PM Omer van Kloeten's .NET Zen

# Testing Obsolete Methods 6/28/2004 3:16 PM Omer van Kloeten's .NET Zen

Title  
Name  
Url
Comments   
Privacy | Terms of use