by Michael S. Kaplan, published on 2007/04/28 15:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/04/28/2314479.aspx
I had someone ask me the other day what kind of testing was done for MSLU.
I told him that the whole project was an interesting example of how the places you expect to find bugs are fine while the places you think are fun have many bugs!
As a starting point, I actually took lots of the actual tests run on NT on all of the functions that MSLU covered, compiled them to use MSLU, and ran them on Win9x with MSLU on the machine. This found a few bugs in the beginning, though most of them related to determining the ideal settings for unicows.lib/unicows.dll integration, which ultimately helped defined the instructions. There were very few bugs found through those tests.
From there I downloaded all of the VC++ samples I could get my hands on like CTRLTEST and HELLO and HELLOAPP and MDIDOCVW and OCLIENT and like about sixty others, and converted them all to integrate with MSLU. This was an educational experience for me since I was always much more of a command line builder than someone to use Visual Studio, and I ended up having good instructions that worked with all of the samples I tried -- including features like function overrides and even MSLU loader overrides (required for MFC applications).
Now with these samples I did find some bugs (surprisingly enough to me more than the actual tests), but again, most of what was learned related to integration, not bugs in actual functions.
I was given ten machines to set up a small test lab in. After discussion with Julie and others about the fact that we were dealing with three different versions of Windows with three major flavors (SBCS, DBCS, RTL), the machines were set up a follows:
I was given the lab as my office which was amusing since the A/C was broken in some kind of "always on" way that required me to wear a winter coat when I was in there. Any time I had to talk to people they asked me to meet them in their offices due to the ambient temperature. :-)
The SBCS machines found very few bugs, the DBCS ones found a bunch of bugs in buffer sizes, and the RTL ones found a few GDI bugs early on but then none afterward.
Other than being able to verify that a few things worked on Win95 vs. Win98 vs. WinMe that had special case code for the platform (to handle functions that existed in the later but had to be faked in the earlier), there was really no case where either Win95 or Win98 were needed -- the whole thing could have been handled with one Win95, one Win98, and eight WinMe machines with good coverage....
The source for lots of the code that made its way into MSLU came from various Unicode layers all over Microsoft, from the VSAnsi layer to the MSO functions to the Access ones to many many others (something like 32 in all). In the beginning they were f great help, toward the end I was usually sending people email about all of the things that were broken in their layers!
Starting in the middle of that time and then continuing on past the initial release, I worked with ISVs and internal devs at Microsoft who were building huge projects and who wanted to consider using MSLU -- from an early version of Product Studio to projects being produced by the then-named Crystal Reports that were going into the VS box to several other, similar applications.
There were even a few cases where existing applications had link re-run on them to make them MSLU-ized (something I never even considered until "linker god" Dan Spalding suggested it), like Paint, Notepad, Wordpad, both NT4 and Win2000 Character Map, and even a few third party apps I had on my machine. I even got permission from Asmus Freytag to run a copy of UniBook compiled MSLU-style, and at his request made some "code review" suggestions as "payment"....
I can honestly say that this is where the bulk of the bug reports came from -- on real applications. Which actually makes a lot of sense, when you think about it.
So, would it all have been done differently had we known at the beginning what we learned by the end?
Probably.
But we did cover a lot of ground between that first lunch interview with Julie I described here and the time that Win9x as a platform fell out of support (described here). I probably got to learn more about all of these different projects than I ever would have been able to, otherwise.
Was it a fun project to work on?
Indubitably!
This post brought to you by Ｗ (U+ff37, a.k.a. FULLWIDTH LATIN CAPITAL LETTER W)
# Pavanaja U B on 29 Apr 2007 11:12 AM:
Does MSLU support Indic? AFAIK, it doesn't. Need the confirmation from you.
Regards,
Pavanaja
# Michael S. Kaplan on 29 Apr 2007 2:29 PM:
For most of the functions in it, no -- since the DLL's job is to provide a Unicode interface but make it look like a non-Unicode client when talking to the OS.
But several functions (like GDI ones that support Unicode versions on Win9x) will still work just fine.