August, 2009

Nothing technical, you know the drill....

This blog is not going to be about politics.

Well, not really.

I'll mention politics a bit but hopefully not enough to rile up the kind of people who get riled by such things.

If I'm wrong, I'm gonna ignore the commentary anyway. So probably best not to dig in about it, if you know what I mean....

Anyway, I have a friend who is a secular republican who really believes in the need to keep government off our backs.

In other words, more of a libertarian. :-)

The other day she was telling me she felt really awful about what Obama's plans for health care would mean for me.

You know, since I have multiple sclerosis and all.

I pointed out that there is not a whole lot that health insurance or really medical science outside of experimental/research work can do for me, at this point.

Since I am kinda secondary progressive now, that is. No more relapsing/remitting, no more drugs that really work on me, etc.

So even if she is right and health care gets flushed down the crapper in the USA, it won't mean much of a difference for me.

She was confused -- was there really nothing left I can do?

Well, there is one thing, but it way too primitive and no insurance covers it nor will it for the foreseeable future.

Of course she waited for me to explain what I was talking about.

Well there is some promise in the area of stem cells, the stuff that research was forced to stagnate on because of the other republicans (the non-secular ones) and their feelings about such things.

The old plans won't be covering it any time soon and I doubt any new plan would, either.

Kind of ironic that my libertarian friend is wrong that I might be screwed in the future due to the fact that some of her fellow travelers she doesn't see eye to eye with might have made sure I was screwed in the past....

In case we needed further proof that government in general is the best way to make sure everyone gets screwed with their pants on....

Now I know I am very fortunate to have the employer that I do -- most wouldn't have approved the iBot. And at its price it doesn't seem like the kind of thing that most proposed future plans would cover either (not their fault if even a fully covered person might not have gotten it before, of course).

It has been a game changer, a life changer, a world changer for me.

But it probably still wouldn't be medically necessary....

I know I had a point when I started writing this blog, but I can't remember what it was now -- maybe it was that point which seemed so ironic to me about how even if the Democrats were gonna screw me over the fact that the Republicans did first made it kind of a non-issue.

But in retrospect I hope that wasn't the only point since it seems kind of weak now that I am looking at it.

Oh well...

I was at a party this last weekend, maybe I'll talk about it some time. It's definitely a party I'd never have gone to if not for the iBot being there. And that goes triple for the Halloween party I was invited to while I was  there. So the iBot is doing something for my quality of life, at least! :-)

Although Microsoft tries to be more transparent and give people more ways than ever to contact them, not all of those methods include the formal training of the handoff.

Now the handoff is very important because in many or possibly even most cases, the first Microsoft person that a customer contacts is not the one who can best answer the question.

In those cases, he or she has to get the customer in touch with some other person.

And the handoff is the process whereby the contact with that other person happens.

At a conference this means walking the customer to the right person and introducing them, rather than vaguely pointing off in some direction. And by email it is staying on the email thread long enough to make sure that the other person has picked up the issue.

The goal? To make sure that the issue is not dropped.

All of this is background. So now the blog can start....

The story started, as it often does, with an email. This email was from someone inside of Microsoft, and went like this:

The translation of “Misc” in PropertyGrid to Polish on Windows 7 pl-pl (.NET 3.5) is sexually explicit.

The screenshot of the property sheet in question was:

I suppose it helps if you know Polish. Obviously this would eventually be put in front of some Polish localizer who would see the issue and not need the details spelled out explicitly. Though it might have helped the triaging so that people would know how urgently to make that happen to have it spelled a tad more explicitly.

In tis case, it was not needed.

Because the issue sounded eerily familiar to me.

Ah yes, here it is: a Connect item titled Translation Request - PropertyGridView. Added nearly a year prior.

You can read more about the details there, basically the term

różne

which means "miscellaneous" was abbreviated by removing that middle vowel, making it

rżne

which in Polish is suggestive of a word for fuck (I am pretty sure the literal meeting is more like sundry after talking with a few people, rather than something sexually explicit, though I know of many words in English that can fall into the same trap).

The fact that two different Polish-speaking people reported it suggests that this may be an issue to look into, at least.

Oops!

Or maybe Rżne!

Of course the real oops was that the bug had been sitting there for almost a year and no one noticed that apparently the handoff had been dropped, and no one owned the issue....

The customer correctly realized that providing that extra context would be important to getting the issue placed in front of the right people, though that didn't seem to help in this particular case it generally helps a lot.

Ah well.

The handoff had been picked up again, and now they are working to fix the problem at the next reasonable opportunity.

Sometimes you have to just say (as Tom Cruise taught us in Risky Business) "What the rżne!"

I have the feeling that certain questions are going to keep getting asked.

Some in person, like "What's up with your facebook profile pictures?"

Or others via email, like the one about people not feeling like a code page selection is right for a particular locale.

Just the other day, the question came in like this:

Hi,

We have been trying to use Welsh and found that the NLS table (http://msdn.microsoft.com/en-gb/goglobal/bb896001.aspx) maps Welsh to codepage 1252.

This has confused me because Welsh can contain Ux0174 (and others) that are not in 1252. (http://www.microsoft.com/globaldev/handson/user/welsh.mspx)

Is there going to be any changes to this mapping to create a Welsh codepage, or an equivilent of Celtic?

Thanks

Stephen Cornes

Now admittedly this is not the same case as On not looking at Uyghur through a Chinese prism where the question is framed in a way that suggests ignoring a language's concerns and requirements in order to fulfill a particular market's. In those kinds of cases, it is easier to pitch Microsoft as the good guy, doing its best. And it doesn't feel like marketing spin to me.

Plus I was in the meetings where this one was decided, and a lot of careful and thoughtful conversations and even arguments happened; only technical issues were raised, as far as I can recall, the "spin" issue didn't come up.

But the Welsh case is slightly different, since the desire is purely to want the best language support. And a pretty direct, honest question.

Sure, code pages aren't enough, I've said so often enough before (like in this blog). But why wouldn't a better choice be made? Perhaps one including Ŵ (U+0174, aka LATIN CAPITAL LETTER W WITH CIRCUMFLEX).

In this case, there are several facts conspiring against Welsh:

1. There is no better code page available to choose from with better coverage;
2. We are no longer creating new code pages;
3. We can't change the code page, ever. Never. Not even a little but. Not at all.

This one feels like much more of a "saved by the bell" issue (the excuse sense, not the television show sense) because the policies block the action.

Whew?

Of course this is not always the case, and I'll give an example of that next time....

But for now if you use Unicode then all of the letters in Welsh are supported -- so once again I say just use Unicode!

This blog is not about the economy!

Regular readers may remember this blog, where I mentioned how much I limited my negative categorizations -- the whole English language and I was holding it down to three adjectives.

It turns out that there is a part of Microsoft that has even less variability in its expression of negatives! :-)

Over in the Suggestion Box, Johannes Rössel asked:

Hello,

I am currently trying the Windows 7 Beta and decided to play around a little with the Regional and Language Options. So I set the negative sign symbol for numbers to U+2212 MINUS SIGN, instead of U+002D HYPHEN-MINUS. I just wanted to try how far I would get with that until I see misbehaving software.

So far, so good, I headed over to the Currency tab where you can select a negative currency format. However, neither the sign use for negative currencies is customizable, nor is the sign set in the numbers tab used. It always shows U+002D (except for the variants where the number is simply put into parentheses.

Is that kind of unlinking number and currency formats intentional? If so, why exactly? Is there a locale where the number negativity sign is different from that for currency?

Regards,

Johannes

This question delves into many of the interesting issues that drive the nature of choices in locale data.

The behavior in question is one you can see in pretty much any version of Windows; it is not specific to Windows 7....

Sure enough there is a LOCALE_SNEGATIVESIGN one can set in SetLocaleInfo but there is no negative sign for currency values. And what is worse is that like Johannes indicated, LOCALE_SNEGATIVESIGN doesn't change the negative sign used in formatting currency values.

If you look at locale data at more of a macro level, much of the data that can be set really owes its presence to the fact that some locale expected a particular kind of behavior. It is usually not developers who find bugs, it is instead either end users who notice things in Regional and Language Options, or the stakeholders providing data for a new locale who note something thast they do not seem to be able to specify.

This feedback drives limitations on what can be set (for an example I have talked about before see When the roof got raised, and why) and also what data is available to be set.

In theory developers have mush more exposure since they can look at any data, though in practice bugs are found by regular users finding problems in data that is directly exposed (bugs in the data not as visible to users can stay unfixed for years since the problem can be unknown for so long!).

Now this case in particular, I cannot imagine that there is a situation where any locale actually expects a negative sign for regular numbers but not currency values -- I certainly don't know of one. Thus my initiasl assumption would be that the problem is mostly an oversight.

Though since it is so long-standing a serious inquiry would be required for all locales to make sure such an initial assumption is true (similar assumptions in the past about the decimal separator in number and currency values have proven to be false).

It is almost something I could imagine having linguistic consequences since we are talking about formatting and in a way grammar. Though I don't know to what extent people might object to results in specific locales.

The consequences for changes here to anyone who has made the effort in parsing/formatting would also need to be considered, as that scenario is the one case where developers do sometimes report bugs: when they get unexpected data in their algorithms and assume the unexpected result is a bug. In this case, no developer has done so, but it is hard to guess who might have noticed this discontinuity and worked around it already (in a way that fixing the problem might break).

I'll be honest and say the one thing I miss the most about the time period I was involved in locale data (what I like to think of as the silver age of locale data) is the conversations about what should be done to handle problems like this. In fact I am having lunch later today with one of my comrades from those days and will likely mention this issue while I'm there!

But I will also be honest and say that even though I loved discussing and working through the issues on such bugs, I seldom enjoyed the final decisions in such cases since they can always potentially lead to negative consequences for users (end users or developers, or maybe both!).

I should probably explain the whole silver age thing further, but that can wait for some future blog, probably. :-)

I just remembered that I have a Suggestion Box!

In it, Abdusalem asked:

Hi Michael,

I would like to ask/or suggest as a topic something about the Uyghur (PRC) locale in Windows 7.

This is a new locale that has been supported by Windows since Windows Vista as you might know.  The current default code page of this locale is set to Arabic (Windows-1256) but this code page cannot fully support the script of Uyghur since it lacks some essential Uyghur-specific characters (ې ,ۈ ,ۇ ,ۆ ,ە).  These characters are five out of eight vowel letters in Uyghur, not providing support for these five letters means it does not make any sense for Windows-1256 to be the default code page.  Does it have to be the default for the Uyghur (PRC) locale anyway?

And there's another issue with this locale.  This locale doesn't provide support for GBK (ANSI/OEM 936).  The major reason we need for the support for GBK is that most of the applications in PRC are/were written in GBK/GB2312-80.  If the system default locale is set to Uyghur (PRC) then the default code page will be Arabic (Windows-1256) and if we try to run GBK/GB2312-80 applications, there will be a messy characters on the UI of the applications since the locale doesn't provide any support for these code pages.

So I'm wondering:

1. why Arabic (Windows-1256) must be set to the default code page for the Uyghur (PRC) locale while this kind of applications are rarely used in the People's Republic of China;

2. if and how the Uyghur (PRC) locale can provide support for GBK/GB2312-80 applications in order to correctly run applications based on these code pages.

I've been playing around with Microsoft Locale Builder to see if the 2nd item is feasible but I didn't make it =P

Perhaps you can't believe that I am starting the week with Uyghurstuff, or with China. If so, I can only say that you don't know me very well....

Actually, I have talked about all of the relevant points here before, actually -- makes my job much easier!

In blogs like this one, which topically remind everyone that code pages are not enough, for anyone.

In Arabic itself, there is no room to sully support the last few characters needed for Farsi (Persian), and there are many many characters needed for Urdu that are not there.

Yet they both still use code page 1256.

That is the way of things; of you think a code page is enough then you are ignoring the rules of governments behind these languages that clearly put in requirements for more characters.

I won't even get started on China here, which takes my argument and proves it times 20,000 when it comes to GB-18030, which supports all of Unicode!

Now clearly the Microsoft model for code pages is not to say "if you can't do everything, then do nothing!" which is what a cp936 selection would have meant for Uyghur.

There are two very good reasons that the "if you can't do everything, then do nothing!" model is not chosen:

1) It disrespects the language completely -- one cannot say that Uyghur, a language written with Arabic letters, will support 0% of the letters in the language;

2) It disrespects Microsoft's customers by giving them intentionally wrong data that their applications can try to use.

Since Microsoft tris to values both languages and customers, the right (or as right as possible) answer is usually best....

If the code page had not been 1256, then Uyghur would have been a Unicode-only locale, just like Tibetan, Mongolian, and Yi were.

The answer was never going to be cp936.

In that case, is the cp1256 choice, the "as good as one can get" choice, truly so bad?

Now Abdusalem's troubles with Locale Builder are explained in Where the hell did Replacement Locales come from?, which explains why the default system code page cannot be updated in a replacement locale.

Even if all of this were not true, then there are the issues mentioned in Can a codepage be changed? How about which codepage a locale points to? -- code pages cannot be changed, and locales c

But for the people who really want the behavior Abdusalem describes -- anyone who feels that their Uyghur experience is better served with a Chinese code page -- has an easy answer:

Uyghur default user locale

Simplified Chinese default system locale

With that, the problem is solved.

Remember that the default system locale is only about the language and some minor details related to font behavior which, to be brutally honest, anyone who prefers the PRC's code page for Uyghur would probably want anyway!

There was a recent [internal] discussion thread where someone was asking about what was the best way to output localized text to the console.

After a bit of thread drift, STL pointed out that blog post (Conventional wisdom is retarded, aka What the @#%&* is _O_U16TEXT?) which explains how to fix the bulk of the problems one sees with wprintf and such.

Not that it did much good initially, since the conclusion reached:

Thanks.

Why not using WriteFile always and drop WriteConsole? Unicode string may be converted to ASCII one before calling WriteFile. The code is simpler and the output is uniform – both, string in file and one copied from console, are ASCII. Otherwise, console string is ASCII, but file contains Unicode.

clearly suggests that the topic was not read to the bottom! :-)

It's okay, he was set straight very quickly, so no worries there. Given how unlikely I am to read a email from a VP all the way to the end, I can't expect people to read a blog post of mine to the end; they have staffs and get paid a helluva lot more money for what they wrote and even spell-checked it!

Anyway, one thing that was mentioned even further in the thread, after someone complained about the documentation being inadequate (a problem I talked some too, in the original blog and Before you say "What's next?" you have to figure out the action items), was that all of the correct info was sitting in the header file (fcntl.h):

/* O_TEXT files have <cr><lf> sequences translated to <lf> on read()'s,
** and <lf> sequences translated to <cr><lf> on write()'s
*/

#define _O_TEXT         0x4000  /* file mode is text (translated) */
#define _O_BINARY       0x8000  /* file mode is binary (untranslated) */
#define _O_WTEXT        0x10000 /* file mode is UTF16 (translated) */
#define _O_U16TEXT      0x20000 /* file mode is UTF16 no BOM (translated) */
#define _O_U8TEXT       0x40000 /* file mode is UTF8  no BOM (translated) */

So this explains the difference between the various _O_*TEXT defines much more concisely than the documentation does! :-)

Now yes blog posts do not add up to official documentation, even when they are more accurate and are cited by technology owners.

And yes header files (especially ones with warnings like the one at the top of fcntl.h!) might not be either in some legal sense.

But remember that when documentation is wrong, the only bad consequence is confusion -- it does not make programs spontaneously fail.

Header files, on the other hand, are intended to represent what the developer was honestly expecting the code to do, and there is an honest chance that a non-comment mistake in a header file will keep something from building -- which means there is a greater chance that the problem might be fixed!

So if you want to know What the @#%&* is _O_WTEXT?, you may want to check the header file first. You might be surprise yourself....

The other day I was looking for something.

On the Internet.

You know how that goes, I'm sure.

I didn't find it, though I know it is out there.

You probably know how that goes too.

I tried with both Google and Bing.

Now I'm not a religious nut about either of them like some are; the first search of the day i try both of them and whoever is best in terms of results is my search engine for the rest of the day.

But on this day, neither one found what I was looking for.

They found something else, though.

It was a very old bug.

KB article 115431 (Turkish Character in Directory Name Hangs Windows NT).

This bug was not entirely unique, mind you.

Julie Bennett, the developer at the time whose change (inspired by an attempt to better support Turkish) combined with someone else's use of a CompareString call, was behund it.

It was fixed with the next service pack.

And when I say not unique, I mean it.

The developer directly (in trying to fix this bug even earlier) helped this bug to happen, and at that point the system couldn't fully boot with Turkish settings (some failure trying to open SYSTEM.INI since it was trying to open system.ini, if memory serves).

That one was fixed without ever being released in beta. Before my time either way (just like the one in the KB article).

Then there was another one around the Windows XP timeframe. The Turkish casing results were added to collation and Internet Explorer was broken in some horrendous way.

Well, not horrendous as compared with being unable to boot Windows. But bad.

I was around for that one; while not the one who checked in the fix, I was one of the people who agreed it was time to try and fix the bug, finally.

We were wrong, obviously.

I mean, i was wrong.

Since Internet Explorer is fairly important to a couple of people here. And maybe also in Turkey.

That one was caught during beta too.

And then finally the bug was fixed, in Vista. By adding a new flag so it was opt-in.

NORM_LINGUISTIC_CASING

That one was done in beta and actually did manage to ship.

An nothing hung or crashed or attacked any users.

At least as far as I know, of course. Perhaps the attack was stealth or something. :-)

Anyway, back to that one in the KB article.

What was cool (in the way that a fight at a hockey game is cool), what was different, was that it actually shipped.

International test was not so big back then as it later became.

We were even smaller then -- Mini would have loved Microsoft back then we were so small.

It was a much simpler time. Unless you live in Turkey.

I guess we once were small enough to be internationally stupid....

So, in a quick follow-up to Garbage in, garbage out -- and this means Ü! from the other day, the investigation into the cause has happened:

ok, what happens is that MFC is actually throwing an exception, because _mbsupr_s() does return EILSEQ. The crash is caused by the unhandled exception.

if you put a try catch around the MakeUpper, you'll see the exception being caught:

        try {
            tt.MakeUpper();
        } catch(CException *) {
            printf("mfc exception\n");
        }

_mbsupr_s() is called by Checked::mbsupr_s from StringUppercase:

        static LPSTR __cdecl StringUppercase( _Inout_cap_(size) LPSTR psz, _In_ size_t size ) throw()
        {
            Checked::mbsupr_s(reinterpret_cast< unsigned char* >( psz ), size);
            return psz;
        }

_mbsupr_s() returns EILSEQ because 0xFC is a lead byte in MBCS Japanese.

Okay, so now blame can be assigned. :-)

Everyone is clearly doing what they meant to be doing, at some level. Though the question of whether there should be a different way to handle this case is an interesting one (an exception in a MakeUpper method call seems like it may be somewhat unexpected.

Why do I think that?

Well, the data itself is invalid on its face -- the meaning of a solitary 0xFC in dats purporting to be Japanese is invalid.

But is it truly the job of MakeUpper to do data validation?

At the point where the data is already in a string and one wishes to uppercase it is perhaps not the best time for anyone to start screaming about failing to tag second base.

And I am not so keen on MakeUpper in the role of umpire, either :-)

So while I will still say the caller of the code, the who made the invalid code page assumption (about the ubiquity of Ü) that is at fault, it is hard to wonder whether this small amount of over-officiousness is also at least a little bit to blame for the problem, too.

This is not unlike the things that bother me about over-validation in codepage conversions -- in both cases I'd want options to have the functions I call do less work and be less demanding of their notion of data purity.

Just a desire to trust the caller unless the caller asks for validation of some kind....

I'll admit that I am till wrapping my head around the problem here, but I thought I'd run it up the flagpole and see what others thought.

Ideas, anyone?

Very very very very offtopic. I can barely excuse myself for writing it; your reading it is simply unacceptable....

There are always multiple sides to any story.

And the subject of this blog is no exception.

The issue is the way that drunk driving or driving under the influence is handled with wheelchairs and power wheelchairs (henceforth known in this blog you are reading as the device).

This seems kind of important since I drink sometimes. As you may know if you read hear....

Now to start with the most important piece -- is the device considered a vehicle?

Now where I live now (Washington state), RCW 46.04.400 (which defines Pedestrian) claims that

"Pedestrian" means any person who is afoot or who is using a wheelchair, a power wheelchair, or a means of conveyance propelled by human power other than a bicycle.

So in my home place, even a power wheelchair classes me as a pedestrian, not a vehicle.

My top speed in standard mode is ~7mph, which is faster than any human can walk, really. But it can be outrun.

Now this is a crucial issue because although even public drunkenness while one is standing still can be an offense if one is disturbing the peace in some way, the penalties for doing so when one is in a vehicle are always going to be worse since the laws are crafted to consider the potential for harm to be worse in a vehicle.

There are nuances with items such as powered scooters (like I used to drive), and to be honest those nuances exist because the law here is not entirely clear as to whether such a scooter is a "wheelchair" under this legal definition. Though I have asked several police offices in Redmond and Bellevue and Seattle -- they all said that provided it is a medical condition they will consider it like a wheelchair.

Those same officers will not usually consider a Segway to be a wheelchair and there are entirely different nuances regarding Segways that I am not going to cover here except to say that sometimes even city or county ordinances call them out and restrict their usage in cases where incidents have occurred. Clearly they are not protected in the same way....

Generally when the law is written this way, it is for a good reason -- a wheelchair, even a powered wheelchair, is a natural extension of a person moving around on their own as best as they are able. There are fascinating nuances if one is not required to be wheelchair-bound but is instead joyriding in such a device, but I won't cover those much anyway since they are not covered by the law all that well, in this jurisdiction (or most jurisdictions, actually).

Now not all jurisdictions in the country or the world judge things the same way, so your mileage can obviously vary here, on all of the above points.

Once you get past determining what the device in fact is, one has to deal with the issue of how disruptive one appears to be  when they are drunk.

This is crucial when one is considered to be a pedestrian, since none of the laws regarding the use of breathalyzers (including the right of an officer to require one) are relevant to pedestrians. And since even in those few jurisdictions that might consider the device to be a motor[ized] vehicle are not licensed and thus compelling such a test is a very rough bit of uncharted territory that the average police officer does not wish to set any precedents in....

Thus obviously how much of a disruption a person is in the view of the police officer is the most important factor, in any case.

Things get even trickier at this point, as what the police officer is to do next is yet another very gray area.

Obviously there can be (and usually is) a certain amount of sympathy (or even pity) when someone is in a wheelchair. Especially if they are drunk, as it is natural to fill in so much in the way of motives due to the poor sod's lot in life, being stuck in a wheelchair, etc.

And in the USA, the image of the ADA-violating lawsuit that can get a police office disciplined, suspended or even fired and can cost the town more money than it really wants to part with is a factor that is hard to ignore.

It takes a real lack of both empathy and intelligence for a police officer to not be consciously and/or subconsciously be aware of these factors. Because of this, except for the most egregious offense (e.g. trying to drive the device in the fast lane of the interstate, running the device into a car or into people) will most often result in little more than working to get the person safely home or somewhere that no further ham can be done. This will seldom be an arrest and in most cases not even be a night in jail due to a reluctance to incarcerate someone in a wheelchair even overnight (jails are just not set up for such things, usually).

Now all of this has been gleaned from conversations with police officers as I have never been in a state that such a tough choice would need to be made. I don't think sympathy on the part of those officers led to then lying to me, though admittedly I have no way to check on that.

From that time in the scooter at TechEd 2005 where I was rolling between two different bars all night getting smashed to more recent incidents from time to time in the iBot, I have managed to get quite drunk on occasion, but to be honest never lost control of the scooter or the iBot (the iBot adds a new level of weirdness here since no matter how unsteady I feel the iBot doesn't and thus I stay balanced even when I have no real right to).

In a way, the attitude of law enforcement is generally designed to allow for not just me who is not causing a disruption but for others who might be -- a way to treat people who have this extra cross to bear like people.

Whether that is due to sympathy or empathy or pity or pragmatism or whatever, it is clearly a force.

And the net effect is that whether one likes it or not (and to be honest even I myself sometimes dislike it as it seems unfair) a person in a wheelchair is simply much less likely to get in the kind of trouble that someone who is not in wheelchair can.

Fair?

Not so much.

But on the other hand neither is being stuck in a freaking wheelchair, so....

In case you haven't noticed from the other gazillion blogs and tweets, Windows 7 released today.

Windows has released a bunch of times, so what makes this one different, exactly?

Well I could be boring and explain at length why it is the best, most secure, most popular and shiny version ever.

People say that every version, so I am sure it is true again in some sense. Even Vista RTM does that by some metric, I'm sure. :-)

But you can get that from execs and official marketing materials and such. If you're here then you probably aren't looking for that.

If you are then consider the message delivered, though!

No, Windows 7 is doing something unique, something that Windows in its (depending on how you reckon it) 20-odd prior releases has never done before.

Microsoft is simultaneously releasing all 36 languages in one single wave.

I should repeat that; it sounds vaguely important....

Microsoft is simultaneously releasing all 36 languages in one single wave.

Here are some of the stats surrounding the amazing accomplishment of the final media verification, which is one of the larger of the factors that has led to delay in prior versions:

Wow, I am stunned.

Before this, the XP/Server 2003 numbers required 3-6 months for the same work to be done, and it was more like 6-9 months in the Windows 2000/NT4 days.

With a lot fewer images and SKUs, obviously.

Now if you deal with multiple languages and have both customers and marketing organizations that serve those customers in other countries, then you know that this sim-ship has even larger meaning beyond the obvious benefit of customers not having to wait for their Windows -- it means that those marketers and salespeople can piggyback off the earliest work rather than having to wait. It is a wonderful symbolic gesture to point hows much we care about all languages.

In fact, to be pedantic in a fun way for a moment?

English was not the first language to have its media verification completed!

Both French and German actually finished before English did. :-)

Does anyone need more proof that English is just another language?

Now people who know me know that I have the same uncomfortable feeling about the "I" word (Innovation), which gets misused a lot these days. And more often from Microsoft than a lot of people.

But this accomplishment was in large part due to the creative and yes innovative changes to the way that validation was accomplished and automated.

So in a world where "everyone knows" it takes a long time to get localized product out there, I am happy to say that due to these and other amazing efforts Windows 7 turned that knowledge on its head. There has never been such a large release before of an operating system.

To everyone related to the planning, spec'ing, developing, building, releasing, testing, or beta testing of any language version of Windows 7, you are all rock stars as far as I am concerned. And you have changed the world here, you really have.

I am both proud and humble to have been a part of it.

So McDowell asked in a comment:

Apologies if this is the wrong place, or this has come up before, but does 64bit Windows sound the death knell for OEM code pages on the console? I haven't run a 64-bit version of Windows, so I can't check if I'm just behind the times.

I can see the point of cmd.exe defaulting to a DOS codepage for DOS compatibility, but if the operating system no longer supports 16bit apps, it might be a good time to change. I live in hope that, even if Unicode isn't on the table, it might one day default to the system default "ANSI" encoding. (Yep, I'm aware of TT fonts/chcp and PowerShell.)

Or are there deeper issues of which I am not aware? I've never had cause to go near the recovery console and I know the rules change on full-screen.

Now yes this was very very very offtopic and it would have been better asked the Suggestion Box, but I figured I'd just answer it -- he knows for next time! :-)

Let's start by looking at the argument itself -- the relationship between 16-bit apps and 32-bit DOS (i.e. OEM) apps. We'll momentarily stipulate that there is such a relationship.

One could perhaps have made the argument when 64-bit first came out, in Server 2003 and 64-bit XP.

But now that

• Server 2003 64
• XP 64
• Vista 64
• Server 2008 64
• Windows 7 64
• Server 2008 R2 64

have shipped with things as they are, it is a bit too late to make such an argument.

No of course there is a flaw in the stipulation, too. Because the two are not coupled together so closely!

The use of 8-bit SBCS and MBCS code pages predates Unicode, obviously. But as much of a fan as I may be of Unicode, I do not claim that 64-bit support is connected; each and every documented ANSI and OEM function in the Win32 API is a regular 32-bit function call on 32-bit platforms and 64-bit function call on 64-bit platforms. Pointers to OEM strings are 64-bit pointers, and so on.

And more to the point, the fact that so many of the OEM code pages date back to the time when there were only 16 bit apps doesn't mean that dropping support for one means dropping support for the other.

Things don't work that way; they can't!

Changes to make the OEMCP or a locale equal the ACP are definitely not possible, either -- no one wants to break as many applications as that would do....