How can I use MSLU without shipping UnicoWS.dll?

by Michael S. Kaplan, published on 2005/05/05 14:25 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/05/05/414985.aspx

People often look at the Microsoft Layer for Unicode (MSLU) and wonder how they could avoid shipping an extra file.

Recently, Hans Hansen posted a message to the microsoft.public.platformsdk.mslayerforunicode, asking the question in the following way:

Unfortunately, the answer is that this option is not available -- you have to ship the DLL if you are running on Win9x.

The obvious question that people ask at that point is why things were designed this way.

Although to be frank, I can never tell when people asking if it is out of genuine curiousity or if it is to try to find a flaw in the reasoning that would convince me to change the whole direction of the project and give them exactly what they want. I always assume that the answer is the (usually mature) former rather than the (usually immature) latter, although I am probably underestimating the childish nature that developers often have (I am including myself here when I talk about that, since I still feel like a developer no matter what my title is).

Remember that the #1 performance goal was to not hurt the performance of applications running on NT-based platforms. This only makes sense since the project was being done primarily at the behest of a developer in the Windows Division and the payment for the project was approved by a Windows Vice President. Shipping something that would help encourage migration off Win9x or at least to take the best possible advantage of NT-specific features is a good thing, shipping something that slows down the platform even a little is not.

But the DLL itself does add some performance considerations. While it is itself loaded with a "delay load type" functionality, once it is actually loaded it does not itself "delay load" all of its own dependants. Thus loading UnicoWS.dll in a process will load a bunch of DLLs. There is a hit that only happens if you load the DLL, so if its full functionality was included in a .LIB, a lot of extra work would have had to happen to make sure that performance on NT-based platforms was not adversely affected.

It would also mean adding a whole bunch of code to your application binary that is simply never used on NT-based platforms. Now it would not mean adding the full size of the DLL to every project, but it would mean adding however much you are using in the way of APIs.

Now admittedly neither of these problems is unsolvable, but I learned a long time ago that successful software projects are based on focused and targetted goals and visions. Which does not work well with the idea of trying to solve every puzzle and fix every problem even if the problems are not part of the core scenario you are trying to address. I suspect that had the focus of MSLU been as unfocused as all that, it would have either never shipped or it would have been a year later and with a lot more bloat. And it may not have even been terribly usable after everything was said and done.

Which is not to say that a bit of undisciplined havoc never sneaks in (for example, think about the support for resource updating. Or the work to make sure that even those who do try to use UnicoWS.dll on NT-based platfoms will still see the calls forwarded to the OS).

But if you keep your primary project goals in mind, then the occasional diversion will not kill you. Or the project. Or the people who are doing the triage on features. The key is to not waste too much time or effort on items that are outside the scope of the project.

Which in this case (unfortunately) included the "never ship an extra file, even on Win9x platforms" feature....

(Before you hear me complain, let me state that I'm quite glad you posted on this topic and that you took the time to explain the issues to us. I'm quite appreciative of the time it takes to do something like that, so let me express my thanks.)

I was excited when I began reading this article because I expected it to contain a very solid, excellent technical reasoning for why Unicows.dll was not provided in static lib form.

Yet, the reason given is that "it's outside the scope" when there's really no technical reason unicows could not have been provided both in a static lib and in DLL form. In effect, it sounds like some developers have to hesitate making UNICODE transitions because they don't have the freedom to pick and choose which trade-offs they wish to make (i.e. performance vs. dependency).

For example, some of us author extremely-low-dependency executables (e.g. setup bootstrappers). Including this DLL in a side-by-side fashion for these is not a trivial matter! It can cost companies a significant amount of money to solve this problem. ("Immature") We toil with this sort of thing in our multi-lingual executables and have very little recourse except to write additional bootstrappers for those bootstrappers, or forego UNICODE support when we need it.

I would truly love to see this *additional* static lib support, especially if there's no major technical reason to avoid it (and it's primarily driven by a development team's desire to stay inside an artificially created mental box). I know, as a developer, I've been guilty of this many times myself, but it makes me sad to hear that it occurs also with something so handy as your unicows library. (It also makes me sad to hear someone speak of their 'customers' as immature when they ask for new features, but I won't digress into that topic.)

Anyway, as I said earlier, I absolutely appreciate you taking time to explain this, as well as all the time you've spent on the unicows project. Yet, I really wish Microsoft would also release a static library if the technical hurdles are not more than you express in this article. Then (as with MFC and MSVCRT, etc) the developers can decide if they wish to make the relevant trade-offs between the two.

Thanks for taking the time to read my comment,
-Mattie

Hello Mattie!

Quick note -- when I said "immature" it was just the image of the small child asking why they could not have the treat -- i.e. hoping that the act of asking would form the dialog that would get them what they want. It does not mean that everyone who wants features is immature -- it just means that if you come to the party with nothing but your wish list than you may not be treated as nicely as if you came to the party with more (like genuine interest or knowledge or whatever).

But project scope is pretty crucial -- it helps you make the triage decisions and it helps guide where the project goes. The work to make a static lib is possible but it is a significant work item to do. In such a case where you meausre the work in man years , the need to support doing it for a library that enables platforms which are themselves going to be less supported is a rough call to make, but not too hard in the end. It simply does not make sense from a business perspective to go in that direction.

So I would hesitate to call these issues an artificial distinction. Its actually a huge work item that hangs in the balance....

Referring to it as an 'additional work item' is a different thing entirely, and certainly is a valid excuse that I understand. (I.e., we can't afford to make this happen.) If that's the primary reason then I certainly can't fault the developers for it not being created. I didn't get that as a primary factor in your post above, and I appreciate the clarification.

Yet, there truly is a need for the additional support. So, the suggestion really should be extended to PM(s) who should consider staffing the effort. I worry that they will also turn away requests for this simply because it sounds 'outside the scope' and/or they've heard/misunderstood that there are valid technical reasons not to provide such support.

Anyway, thanks for taking the time to post this and respond. I truly appreciate your comments!

Thanks again,
-Mattie

I am of course never against forwarding feedback up the food chain, as it were. Of course these daye it turns out they read enough here that they will see it anyway. :-)

But like I said the real problem is in terms of how much longer Win9x itself will be supported, and how much it would take to allow people to avoid just shippine one more file in their redist.

When you take the full list of items that we are working on now (and which have us fully booked!), there is nothing that Thie becomes more impoartant than....