by Michael S. Kaplan, published on 2008/10/11 14:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/10/11/8996201.aspx
Conventional wisdom tells us that size matters, and unconventional (or more accurately, inappropriate?) wisdom tends to concur.
Most of the time it refers to the idea that bigger is better.
But there are some times that it matters in the opposite way -- where the smaller something is, the happier people seem to be.
Like the other day in an interesting email conversation where somebody noted:
However, it's a stretch to say TCHARs belong in the 1990s. The PC I bought new in 2000 came with Windows 98, and it lasted five years.
In the real world (i.e., outside Microsoft), you don't always have the luxury of ignoring older platforms. The last product I worked on before joining Microsoft still has a small but significant Win 9x user base. Most of the growth opportunity was outside the US, and in those countries, older OSes were even more commonplace.
We investigated Unicows, but since the product was download only, and since the users on the older machines tended to be dial-up rather than broadband, we couldn't convince product management to let us add Unicows to the download.
When I say "the product was download only", I meant the ISV's product, not the MSLU redistributable. Making the ISV product dependent on Unicows would mean including the redistributable in the download.
Since most of the customers who were on the Windows 9x/Me platforms also had slow dial-up connections, the cost was considered too high.
Now I am a big fan of MSLU (the Microsoft Layer for Unicode on Windows 95, 98, and Me Systems), and not just because I was the developer on the project.
After all, as I mentioned in Why/how MSLU came to be, and more:
But when she laid out the idea of a layer that would be able to let people write Unicode applications that would do incredible things on Windows 2000 while still being functional on Win9x, I was amazed. When she asked whether I would I be interested in doing this project if she could get people behind the idea of making it happen, I think I said Hell yes! or something equally coherent. It sounded like an amazing project to be involved with!
Notice that I was amazed before I had any idea that she was trying to figure out if I'd be interested in the job. It was just amazing on its own, and would have been so even if I had nothing to do with it.
There are countless such projects that I have mentioned in the past that I had nothijg to do with other than as a fan. It is just my way!
Anyway, I have a big [erson connection to the project, since it has beedn interesting to me since the first time someone laid the idea out in front of me.
It really gave me pause to think that the download size was such a hassle, though.
The full download that the developer would need to bring on their machine that you would get from here is 225KB (the site erroneously claims it is 261KB, I think because an older build was). But that download includes the license, redist information, PDB file, and DLL -- which is way more than any product would ever need to ship since only the DLL is needed.
The DLL is a whooping 252KB, compressible down to a mere 108KB with WinZip legacy compression and 94.3KB with the maximum optimized compression.
This small size was not technically one of the design goals, but other goals involving minimal resources required and minimal working set increase helped to indirectly lead to the same thing.
Now perhaps we are talking dial up connections to Windows 95 and such an addition is just unacceptable, but I have a hard time taking it quite that far as to think that a decision is being made based on whether it would cause the download to be 100KB larger.
But clearly it was.
Unbelievably, I found myself wracking my brain figuring out where to re-enlist in the source project, thinking about the code itself and wondering what I could do to make it smaller, how I could magically delight a customer who is likely way past that now and who would probably not be interested anyway.
So there I am, tilting windmills and trying to solve problem that can't be solved at this point.
It just so happens that this all occurred at 2 AM, a time when I probably should have been sleeping.
And the punchline?
How often is it that a man is keeping himself up at night wondering how to delight someone by making that special part of his package smaller? :-)
This boog brought to you by âȘȘ (U+2aaa, aka SMALLER THAN)
Tihiy on 11 Oct 2008 6:32 PM:
Oh, as a Win9x enthusiast (yeah, sounds bizzare), the most terrible thing in MSLU (after specific API issues) is windowing layer.
I dunno, MSLU was supposed to preserve compatibility from inside (pseudo-NT pseudo-Unicode world) and outside (existing APIs), but it always ends terribly when those worlds mix - after subclassing window procedure ends being 0x7FFFFFFx and leads to crash when existing CallWindowProc (or direct window procedure call) is used on that function. When combined other way - i.e. first 'native' subclassing, then Unicows subclassing - MSLU just loses track of window nature.
Who decided that 'those who call our world from outside deserve to crash immediately'? Why that horrid 'static subclassing' with locking information inside window property referring to that memory buffer was invented? Where was Raymond Chen :\
And yeah, sorry, i understand that there is no rules changing in a game after the game is over.
Michael S. Kaplan on 11 Oct 2008 8:17 PM:
MSLU actually does really well in most of the scenarios (and you can crash on NT if you mix ANSI/Unicode wndproc situations and don't go through CallWindowProc so that problem isn't unique to MSLU (we inherited it from our sister model!).
There are some cases where it can get confused, though this is less common than you are implying, and of course none of that has anything to do with the size issue. :-)
Tihiy on 12 Oct 2008 4:15 AM:
I bet you mean 'you can crash on NT', not 'you can crash NT' :-)
I just believed that NT (judging from Wine) has window procedure translation array (or thunks?), not static buffer... you're right for common cases, it's just when MSLU is abused being in complex weird program it upsets itself, sorry ;).
As for size issue, what if instead W<->A macros there could be common procedures for (LPWSTR); (LPWSTR, nMaxCount); (param, LPWSTR, nMaxCount) functions that could reduce code noticeably for simple cases!
Michael S. Kaplan on 12 Oct 2008 10:36 AM:
The work was actually tested both ways, the final model we went with had much better performance characteristics and less heap fragmentation (which in the end proved to be more compelling than just the raw size)...