December, 2010

This is a story of a site. Well, half a story about a site. Part 2 is already written, and will be published tomorrow.

Regular reader Yuhoing Bao told me via the Contact link:

Go to GlobalDev and find one of the DBCS codepages. On these pages there will be hyperlinks on DBCS lead bytes. Click these links and see what you get

Okay, I am going to disobey the suggested directive here, as I need to start somewhere else in order to give the narrative, the history of how we got here.

Gather round!

Once upon a time, Microsoft put up the Global Software Development website at http://www.microsoft.com/globaldev for everyone to enjoy. Here is what was on the home page:

Welcome to Microsoft's revamped /globaldev site! Although it seems to have taken us forever to update these pages, we've finally managed to get around to it!

We've added, and will continue to add, content aimed at helping you develop software that meets the language and locale needs of all your users. Check out our FAQ pages, dealing with subjects such as locale support and the Multilanguage Version of Windows 2000. Look up your favorite Windows Codepages. Or relax with our checklist of recommendations for software globalization.

If you're a creature of habit, you'll be glad to find that our ARCHIVES contain all of our previously available material, some of which is sure to remain useful and relevant to your work.

Of course, to make this site truly useful we need your feedback. Please email us to let us know what you think about these pages, and what kind of information you'd like to see posted here in the future. We'll do our best to oblige.

That was from February of 1999.

The site was a wonderful resource for many years.

I briefly had a stake in it myself, when I was Dr. International (as I mentioned here).

Now I am not going to say i wass the biggest, most important part; I wasn't. And neither were many of the random articles.

Like with the first edition of Developing International Software, the mot important piece for many people was the data -- the code pages, the keyboards, the languages, the locales. the concrete things people could look at and count and reference.

Anyway, the problems started in I guess late 2007 or perhaps early 2008. But I think it was late 2007.

Everybody was talking about how the big problem with International was that nobody knew about it. And that the GlobalDev site was hard to discover.

Even then I disagreed -- the problem with their premise was that most people out there really didn't care. And for the people who did, there were only two real problems:

• Content not existing, and
• Search (inside or outside the site) not finding content that does exist.

But I only mentioned these two points occasionally, because people were often bitchingcomplaining about my attitude about the project.

Anyway, everyone was convinced that a new location would make a huge difference. Some people even expanded on that and gave reasons like "IT Pros don't want to go to a site call GlobalDev-- because they are not devs."

Seriously?

Or to quote a Windows Phone 7 commercial I like a lot,

Really?

Like I said, people simply need search to properly index the content. Assuming the content is provided, that is all anyone needs!

 As far as I was concerned, if you are an IT Pro who is looking for an answer who refuses to go to a site called GlobalDev because it says GlobalDev, then you are a whiny little biatch who deserves to get firedperson who needs to seriously rethink your career choice. That disastrous year where they split TechEd in two between dev and itpro even though the ones who self identified in group often had interests in the other.

The IT Pros I know never mind things being hard to find after they have found it, because now  they are inherently more valuable than some random person who doesn't know; they are not that much more valuable. I mean, c'mon!

But the move itself scared me beyond that, in practical terms. I was worried about links being missing, content not getting found. I was worried about the way MSDN didn't use regular, predictable URLs and tended to move around from time to time -- GlobalDev was in the same place for that whole time. I was also worried whether the International Fundamentals team could own such an effort, lacking the long-term ability to provide all of the content. I know I wasn't interested in more writing than I did here, in a more formal style where I couldn't say what I really thought. And I was worried about the core teams who weren't sitting on the hands doing nothing eager to do lots of writing -- so where would the content come from?

I was assured by many people that I was being overly pessimistic. That those problems could be solved.

You might have heard about the new site. I mentioned its soft opening in March of 2008 in Yesterday was GlobalDev; Tomorrow is GoGlobal! and its hard opening in July of 2008 in GoGlobal NOW!.

The site was okay.

I often got complaints that they couldn't find stuff looking at the site. I would help them by figuring out where the content was and giving them the new link. I didn't scream loudly at the problems on the site at this time, because the core stuff was still findable at least.

None of the teams that own the technologies on that site spend much time as owners of content there -- of updating it, fixing it, of providing new stuff. There was the one huge push to get a bunch of new MUI content up and that was nice. But as if desiring to prove me right, they didn't do anything after that and no other team jumped in to that degree.

Try going to the only two things that most people care about -- the code pages and the keyboards. Those links aren't on GoGlobal's home page, and there is no easy way to divine how to get to them. Search works okay here at least, but search also finds KB articles that point to the old site. Oops.

The most active thing on the Go Global Development Center used to be the links on the home page to my blog -- it was subscribed to the feed, but those were taken out recently. The blog links there right now are other people's blogs from 2009! No other interesting new content and hard to find the stuff you do need -- you have to use the search, which is what they should have had in the first place, like I said when all this started....

This blog will be continued in Part 2, found here, tomorrow. Unless you are me, the link will not be active until January 1, 2011 at 7:01am....

Previous blogs in this series:

• #1: Uniscribe filters nothing
• #2: Getting hurt while playing on the bleeding edge

Today would be another case where the role of Uniscribe is misunderstood, and the behavior of the things that aren't Uniscribe might be called into question a bit.

Now over in the Suggestion Box, Shachar Shemesh asked

I wanted to ask about Uniscribe's suggested policy, of passing strings to have their BiDi levels calculated and reordered only after the word wrap. It seems as that suggestion would create a BiDi display that is compatible with neither the Unicode BiDi algorithm nor common sense. What's worse, it seems like Windows (at least on Windows XP) actually does this this way.

One example is using LRO over the entire text. Windows, at least in an edit control, seems to "forget" the override as soon as the line breaks comes. A more subtle, but also more serious (as it doesn't use any control characters that no one has heard of) is the following. Assume an LTR paragraph:

english HEBREW 123 AND MORE.

If the text fits within a single line, Windows correctly reorders it as:

english EROM DNA 123 WERBEH.

Notice how the "123" is on the right of the "AND MORE". If a line break takes place immediately after the "HEBREW", the text looks like this:

english WERBEH

123 EROM DNA

The 123 is on the left of the "AND MORE", which neither makes sense nor is standard conforming.

Funny how the text went right to talking about Uniscribe policies and Unicode conformance.

Anyway, it isn't actually Uniscribe.

It was Andrew who unraveled the mystery for me.

What he found was that the error seems to be in Notepad, and the simple shell EDIT control. Although both Wordpad/RichEdit and Word retain the directional state, Notepad/EDIT forgets it on a line wrap. Since the String* Uniscribe functions that are being used here are workig at a per-line level, Notepad considering each line to terminate a run, regardless of whether it is a paragraph or not, is not entirely unreasonable.

Now Wordpad/RichEdit's behavior is slightly different here, though still perhaps less than perfect. It does not consider a new line to be new run, though it does consider a hard line break to be a run boundary. Thus an inserted RLO will e broken across paragraph boundaries, not line boundaries.

You can see them contrasted here:

And those hard returns can show the different RichEdit behavior, as right here:

Now neither of these things can rightfully be called Uniscribe policy, though when one considers that they are in the two core text edit controls (Shell EDIT and RichEdit), these two distinct behaviors are going to be pretty prevalent.

The different (smarter) behavior in Word of course indicates that anyone can do things their own way and not be required to behave similarly. Though in practice most people won't, so the behaviors of these two controls will be more common.

The Shell EDIT/Notepad behavior is following a particular design and I wouldn't necessarily feel comfortable trying to push for a change there.

The RichEdit/Wordpad behavior I am more willing to perhaps consider it a bug since Word compatibility in editing experience is often a goal of the control.

Though the owners of the control might disagree.

In general it would make more sense if both behaviors were configurable since a case could be made that neithe is ideal for every case. Though I imagine it would be hard to find anyone willing to spec that work, do it, and test it....

and Uniscribe isn't doing any of it by is own policies; it is The Protcols of the EDIT of Microsoft....

The question that came onto the distribution list was:

I have a customer who has removed administrative rights for the users in his domain and since then those users are not able to see the administrative tab in the Regional and Language Options on their respective workstations. The workstations are running XP SP2.

I searched on this and found that this is something by default and hard coded in the OS and thus difficult to work around. Can somebody confirm this please?

Thanks for your help.

Of course what these non-administrative users wanted to do in the Advanced tab of Regional and Language Options in XP is less clear:

Every single item there requires administrative permissions to do, since they all involve addng/deleting files in the SYSTEM32 directory and/or changing registry information under HKEY_LOCAL_MACHINE.

it was in fact Raymond who set the record straight on that internal alias about whether or not one could find formal documentation on whether one coukld work around this issue; summary version: one can't.

Maybe they just wanted an easy way to view what the default system locale was, or which code pages have been installed.

Now there are nuances here -- the generic check for administrative rights would not handle special cases where registry permissions were modified in unusual ways to try to make all of the operations on this tab work (and we don't really document what that method is, or even what changes get made, in any real way).

But of course given the fact that the issue is addressed for everything Vista and later makes the idea of modifying XP to support something that changes no real functionality would be pretty unlikely.

If one wanted to query information writing a simple application that does that bit is a lot more likely, and easy to do.

But there is no way to win here, completely, since:

• if you hide something they complain it's not there;
• if you have it there but disable it, they complain they can't change it;
• if you enable it and let them know via an error message that they cannot make the change in question, they ask how to work around it (and complain that the change was allowed in UI if it wasn't going to work).

Summary: people just want what they want, whether they have permission or not.....

It will come as no surprise to people who know my "World Readiness" persona that I am not so fond of the Emoji (like those added to Unicode 6.0).

For those who read this blog, it has come up before in the past here.

I don't like them, because they feel to me like such a betrayal of some of the core principles that I used to espouse.

And I still believe that.

But I like enough of what Unicode does that I can see past that.

I mean, here at Microsoft, for every Kin there's a Windows Phone 7, for every Vista there's a Windows 7, for every Bob there's also a Kinect, and so on. Overall I like the stuff that comes out of Microsoft, even though the working for them part feels more ordinary these days.

And I still believe that (both of those thats).

Now I think about the time I was on the NLS team (back when they were actually still called the NLS team) where everyone pushed so hard to get people off of legacy code pages and into using Unicode.

And everyone has been quite consistently on message for that.

I still believe that message is a correct one, and I believe there is no place for new code pages for languages.

But when I think of the Emoji, when I know that some people will probably want to use and support them (like the phone and instant messaging and email and so on), and when I think of files like Unicode's EmojiSources.txt from the Unicode Character Database, I wonder if maybe my belief system, and the belief system of all of those who have been espousing the above, might be missing out on something obvious.

From that file's header:

# EmojiSources-6.0.0.txt
# Date: 2010-04-24, 00:00:00 GMT [MS]
#
# Unicode Character Database
# Copyright (c) 1991-2010 Unicode, Inc.
# For terms of use, see http://www.unicode.org/terms_of_use.html
# For documentation, see http://www.unicode.org/reports/tr44/
#
# This file provides mappings between Unicode code points and sequences on one hand
# and Shift-JIS codes for cell phone carrier symbols on the other hand.
# Each mapping is symmetric ("round trip"), for equivalent Unicode and carrier
# symbols or sequences. This file does not include best-fit ("fallback")
# mappings to similar but not equivalent symbols in either mapping direction.
#
# Note: It is possible that future versions of this file will include
# additional data columns providing mappings for additional vendors.
#
# Format: Semicolon-delimited file with a fixed number of fields.
# The number of fields may increase in the future.
#
# Fields:
# 0: Unicode code point or sequence
# 1: DoCoMo Shift-JIS code
# 2: KDDI Shift-JIS code
# 3: SoftBank Shift-JIS code
#
# Each field 1..3 contains a code if and only if the vendor character set
# has a symbol which is equivalent to the Unicode character or sequence.

If the Japanese telcos or those products I mentioned or whoever needs to map from their various proprietary mappings to and from Unicode, then that is essentially what code pages are all about.

Perhaps being dogmatically against code page support is really not such a good idea.

Perhaps the focus should have been on language support (which really requires Unicode) and that Microsoft has to support things like GB 18030 anyway, and not been so against the concept of code pages for mappings that can still make sense.

Like the vendor mappings between Emoji and Unicode, whatever they may be.

I mean, every time one of my friends with an iPhone (and there are a lot of them) sends a tweet via Twitter and there smiley face emoticons are private use area characters, I know that Microsoft is not alone -- Apple is making the exact same stupid mistake that Microsoft is, albeit in a different way.

In my opinion, there should be symbol mappings added to a brand new code page (or if necessary multiple code pages) to support this key scenario.

Claiming that Emoji are crucial (which many people do claim) and not providing the proper mappings between them and the random crap that people are using throughout the world because of a frenzied dogmatic belief that code pages are evil and so no new code pages should be supported is a really bad product decision coming out of a really bad belief system.

With that said, I have minimal say in what these product groups do. Many of them read here and listen to what I say, shortly before they ignore it and do what they had already decided what to do.

In that way I am like a not-as-well-paid version of Ray Ozzie, whose thoughts on issues such as privacy and career stage profiles and the Cloud are brilliant and deserve better than to be discounted by the huge percentage of MS discounting them....

So I would be truly surprised to see things supported this way when the time comes to do the work to support Emoji. No one wants to admit they took a belief too far, since that would mean implicitly admitting one was wrong about something (and who wants to do that when the next review is in their minds?).

I'm no better, mind you; I doubt I'd be writing this particular blog if I was still on the NLS team.

Perhaps it is time to move on to a good idea, instead. That would be much better than forcing everyone to roll their own.....

Over in the Suggestion Box, Maurice asked:

Hi Michael,

while working on sending key input via scan codes to a different process (with possibly different keyboard layout) I found two behaviors I can't really explain. Maybe you can shed some light on these.

First, if the target window uses a Hebrew keyboad layout and I want to enter a '.' I get a ? (Final Tsadi). I've looked at the keyboard layout with MSKLC and found that the key with this character is assigned to VK_OEM_PERIOD and the '.' is actually VK_OEM_2. If I use VkKeyScanEx('.', hkl) I get VK_OEM_PERIOD which is the wrong value. Is there any way to get the correct value or do I have to handle this case myself?

The second problem I've encountered is that I can't seem to release the right shift key with SendInput when it's pressed on the physical keyboard. All characters will still be upper case but GetKeyState says neither shift key is pressed. Releasing the left shift, both control or alt keys works however. So what's so special about the right shift key?

Thanks,

Maurice

Interesting couple of questions there....

If you look at the Hebrew keyboard layout, you'll see Maurice appears to be right:

Clearly U+002e, aka FULL STOP, aka PERIOD, is on VK_OEM_2.

So what is going on here?

Well, the important thing to keep in mind is that the Hebrew keyboard layout has SGCAPS support, so the CAPS LOCK changes everything.

MSKLC lets you look at this, so if you click on that CAPS LOCK checkbox and look at the layout:

So there are multiple places that the keyboard layout has U+002e in it, and one of them is indeed VK_OEM_PERIOD.

And as I originally said back in 2006 in What the %$#!* is wrong with VkKeyScan[Ex]?, when a character is on the keyboard more than once, VkKeyScan and VkKeyScanEx will grab the first one it finds based on the way the keyboard layout's data tables are organized/enumerated, and there iws no way to control if from those functions....

These two function just continue to suck and I know of no plans to fix them in any way that would make them suck less, unfortunately.

This also points to a general limitation in the architecture of the basic keyboards created by MSKLC/kbdutool/kbdtool -- you can't change the VK values when you move to alternate shift states, which is very inconvenient for cases like this when you will have a VK_OEM_PERIOD that may or may not be a period.

Now Maurice's second question is something I am not entirely sure about the repro scenario, but when calling SendInput with anything even remotely complicated (like left vs. right keys, etc.), you have to know when to |= in the KEYEVENTF_EXTENDEDKEY flag so it knows that it an extended scan key (for almost every real world case you would only use VK_SHIFT and you would not specify the right or left key).

I suspect that is what is going on here, though if that does not solve the problem then perhaps Maurice can provide more info on his repro scenario....

This post is a metablog about the Blog and the Blog server.

So the other day I got a very strange email (name redacted, it's not like we're Wikileaks here!):

Subject: Please remove my post reply from the following page

Michael, I am directing this email to your address as I have found that http://blogs.msdn.com/b/michkap/ is run by you. In regards to: http://blogs.msdn.com/b/michkap/archive/2005/05/01/413835.aspx?PageIndex=912 My full legal name: ██████ █████ is mentioned in my reply to your post on that page. Please remove my reply from the content on that page. Thank you and Happy Holidays. -- ██████ █████

Hmmm. Really?

Now that link is a weird page that should not in fact exist, and is a bug in MSDN Blog Server.

It is a basic stream of all (or maybe most, it isn't like I verified every one of them) of the comments posted on the various blogs on this Blog.

I reported this page within the first week of the big migration to the new server as a part of the new server's completely busted trackback/pingback system, but since

• trackbacks and pingbacks had been disabled on the old server, and
• these bogus links were supposedly not available to the public

it was given a low priority, and to date not fixed.

Hmmmm -- sounds like the way we triage bugs at Microsoft (is it a regression from last version? No? Then it isn't high priority to fix...). :-)

Obviously if random people outside of Microsoft have hem, then it is externally available.

I have no permissions to delete the comments you find from that link, but by searching for ██████ █████'s name I was able to track the location of the comment down to a blog from 2006, and remove it as I was asked.

The comment didn't seen to me to be particularly remarkable and certainly it was not offensive as far as I could tell, but I saw no reason to argue the point.

I spent a little time in the thousands of pages of comments bereft of their original posts that the link represents, wondering if it was like those Garfield comic strips with Garfield removed that made for a whole new  interesting strip. Some people say that in blogs the comments can be more interesting than the Blog itself, so there was reason to believe it might be entertaining (though the comments on this Blog are much more scant than in other blogs so I did have doubts it would be a useful exercise).

My suspicions were confimed, it was like watching paint dry, bereft of the satsifaction of a completed job that said drying might inspire.

Thanks to Ellie, the young lady who provided that quote in a conversation I overheard in Pnk a few nights ago.

I had luck getting the same thing from other blogs, where as an alternate art form it has more potential. But I will leave it to the owners of thos blogs to decide what they think of this idea.

For now, if you have this link or want something removed, I will ignore the request from now on unless you find the actual blog the comment is in.

Maybe one day they'll fix the bug and that page that shouldn't be there won't be.

Of course when I say that "page" I am being overly simplistic -- anyone who points at a blog in this Blog (including me when I point to a previous blog), sees a trackback/pingback created. They all sit in my spam tab, and if I take them out of spam they will be another page with this same crazy behavior. With someone overon http://codebix.com/ discovering my blog this weekend, I am seeing several trackbacks from there at regular intervals.

Hell, if you fill in someone else's blog name but leave everything else the same (perhaps lowering the PageIndex if you don't have as many pages of comments), you'll see the same problem in their Blog, too.

In waiting for them to fix this, I won't hold my breath; somewhere between Microsoft and Telligent and the somewhat customized version of the software we use is a low priority bug that I can reproduce at will by despamming a pingback or trackback. And which no one seems to care about.

I officially wash my hands of the issue with this blog you are now reading, though. I am going to ignore these pages from now on whether they ever decide to fix the problem or not....

In honor of some principle or another that I find honorable, this entire blog is wrapped in a Comic Sans span!

I like Comic Sans MS.

There, I said it.

Prior to that I was one of those "There are only two fonts: Arial, and Arial 12pt" types, but the I started enjoying Comic Sans.

Ever since Athena (that terrible MS chat client that got me off the "unpaid MS product support" bandwagon I was on from the CompuServe MSAccess forum days like it was a straight shot of an ebola and hantavirus cocktail.

But I can't hate Athena completely, because she brought Comic Sans MS.

Hell, even after a Q&A with Gary Hustwit (the director of the film Helvetica), when asked what would the sequel be, he said that a sequel was unlikely, except maybe Comic Sans. He smiled as we all did, but I think everyone realized that public "Comic Sans spotting" would be as much fun as "Helvetica spotting", and maybe even moreso for the Comic Sans haters....

I even do my own Comic Sans spotting, like in The Company Meeting, the interesting science of Forensic Typography, and what happened after.

Now I realize you may not like it. You may be a disciple of Ban Comic Sans, or  an acolyte of Comic Sans Criminal.

If so, I feel sorry for you.

I mean, Comic Sans is a hero, like the "This video wasn't long enough, so we made it double-spaced" Font Conference College Humor video suggests:

Even if he sometimes shows up a little too late to actually, in fact, save the day, like this other College Humor video entitled Font Fight covers (which as a bonus finally settles the Helvetica vs. Arial issue, in a stunningly satisfying way):

But beyond that, I just like the font.

Now in blogs like

• The font width is broken? Well, fix it!
• The [non-]progress of the über-fixed width fonts 
• Sometimes everyone is happier when the game is Fixed (aka Consoling Consolas lovers),

 in addition to talking about the serious issue of trying to bring the notion of fixed width fonts to complex scripts and trying to get Consolas into the Console, I did bring up my fantasy font -- a fixed width version of Comic Sans:

Comic Sans Fixed

In fact in another blog (Look out for Font Rage) I shared my primitive notion of this font:

But in the end, as a going away present from my friend Carolyn Parsons, I finally have it.

You can see it here in Character Map:

though to be honest it looks the same here as regular Comic Sans does, mostly.

So here is a view that kind of shows the effect of it compared to its ancestor:

And maybe you can think about it in a code window.

Or look at (for example) this one from the Frosting project that was about encodings that no one ever used from ten years ago:

This is thoroughly amazing!

Now maybe this font isn't for you.

Actually, I am sure it isn't for you, since I have no permission to redistribute it! Though Simon did get a copy so it could conceivably ship one day if there were some Microsoft product or scenario designed to cater to people as batshit crazy weird as I am.

But I am pretty happy now in regard to my font situation.

In fact, the one thing that can make me happier (and which Sometimes everyone is happier when the game is Fixed (aka Consoling Consolas lovers) explains how to provide) is Comic Sans Fixed in the Console!

How senselesssansless is that? :-)

So it was oh so very recently that Twitter friend Lexi Love pointed me at one of the many CNN surveys:

As a by-the-way, it was Lexi's birthday just yesterday, and she is ten years younger than me. Aimee Mann, on the other hand, is ten years older. They both are rather interesting people (for largely entirely different reasons) So I guess I think of Lexi and Aimee as my outer markers bracketing my existence here on the third rock from the sun.

Lexi has effectively doubled the growing population (there are now two!) of vegans I know who aren't aggressively negative about my non-vegan diet. This community can only grow over time and I find this to be a positive development....

Hope you had a happy birthday, Lexi!

Anyway, back to the CNN survey: Air travelers hate removing shoes more than pat-downs.

Now as survey go, I thought the CNN one was was interesting.

The "taking off your shoes" thing didn't really start in earnest until after I was either in a Pride Mobility Go-Go scooter or an Independence Technology iBot.

And although for much of that time I could in theory stand and perhaps even walk, the likelihood of me falling over doing it has been rather ever-present, so for the hundreds of planes I have gotten on over these years I have stayed sitting in one of those two assistive medical devices.

So I remain sitting.

Now because I am sitting down, I don't really care whether I have to take my shoes off or not. But I know that if I had to walk around I'd be even more likely to fall over without shoes, and since my residual self image of me is someone who can walk around, I likely would have voted for the 'taking off the shoes" thing being the worst too.

I have been suffering the minor indignity of being felt up by TSA screeners for much longer than most of the people complaining about it, though to be honest that doesn't usually tend to leave me feeling any more violated than the majority of standard government interactions I have.

Though many have suggested that it is people "choosing" the non-back-scatter that leads to "aggressive' patdowns. They told me I couldn't go into the back-scatter anyway even if I wanted to, so perhaps TSA is being a scosh more gracious if a person doesn't have a choice of screening procedure....

Perhaps it is symbolic, like it was at the temple in India (described in My 2 out of 119 (11 + 108) trips around the Chilkur Balaji Temple's inner shrine), where they wanted me to remove my shoes despite the fact that my feet were never touching the ground.

In the case of TSA the examination of the chair was cursory at best, so taking my shoes seemed pretty symbolic too. I mean, I wasn't hiding anything, but if I were then hiding things in sandals seems pretty unlikely as far as plans go.

I think of former colleague Brandon Berg, who spent almost all of his time barefoot even at work, and I can't help wondering what he does when he flies. The things one never thinks to ask people before they leave to go work for Amazon....

So, I'm still deciding how I feel about this one:

Foreign words to be standardized

Chinese media organizations and publishers are banned from randomly mixing foreign languages with Chinese in publications. When it is necessary to use foreign phrases or words, they should be accompanied by a translation or explanation in Chinese, according to a new regulation.

The regulation was issued on Monday by the General Administration of Press and Publication (GAPP) with the aim of standardizing the use of language in newspapers and other publications, particularly when foreign languages are employed.

The administration said the increasingly random appearance of foreign words and abbreviations, especially English, in publications is damaging the Chinese language.

Under the regulation, abbreviations such as GDP (gross domestic product), CEO (chief executive officer) and CPI (consumer price index), which regularly feature in publications, should either be translated into Chinese or followed by explanatory notes in Chinese.

This includes requiring the use of English place names, people and companies to be translated into Chinese.

And so on.

Victor Mair talks about the issue over on Language Log, under the title English Banned in Chinese Writing.

He dissects the arguments much more effectively than I likely could.

But I wondered about the next phase. I mean, since in China there is often a long view. And a next phase.

I wonder if they will decide they feel the same way about localized software products.

At the most extreme, there are cases like the one I discuss in My name is Michael Kaplan and I work for Корпорация Майкрософт and Майкрософт vs. Microsoft, aka On choosing the most reasonable inconsistency, where a language wants and requires everything to be localized.

But for Chinese, there are many things kept in English by convention -- like keyboard shortcuts. And menu accelerators. And system account names. And passwords (the latter is because an IME would cause the password to be visible, a potential security issue).

If it suddenly became a GB18030 or equivalent requirement to do this in localized Windows and not have these bits of English, the product itself would break backwards compatibility, usability, and security expectations for the entire market!

I am still getting my head around this one, in case it becomes an issue.

The title's joking reference to the non-assclown version of  Michael Bolton's reaction to an old school hardware error message is to hint at another problem: the ENGLISH is often nonsensical crap to even very knowledgeable English users; it is unlikely that many of such "forced translations/transliterations to Chinese" would do anything beyond worsening the situation.

One could even make the argument that the purity of Chinese would be injured more by such a move -- it may well be better to leave these acronyms and confusing terms in English to keep this crap segregated from a language that someone has aspirations of keeping out of the gutter!

OK, more seriously....

On the plus side, hundreds of "we won't fix so leave us the hell alone" localizability bugs become "shut the hell up because you have to fix 'em" geopolitical bugs.

But on the minus side, the product wouldn't serve people in China very effectively.

We'll have to wait and see....

It was last week, in response to You can't ignore crap and hope it won't cause problems... that Cheong commented:

Yet in the question, we'd expect tar.IndexOf(r) returns -1 because content of r does not exist in tar. I can imagine having it return 0 will case some infinate loop problem in certain data stream processing functions if they're lazy enough to use string manipulation functions to process data.

This ends up being an interesting design decision!

I'll explain how things ended up where they did.

First comes the easy question: What do you return for "meow".IndexOf("") exactly?

The explicit decision that was made was that every string both implicitly starts and ends with the empty string.

Thus returning 0 here "makes sense" by that design.

Ignore the "".IndexOf("") inconsistency here, of course!

I believe Java does the same thing, though it has been a while since I have done much with Java. Perhaps someone else can confirm.

Now I think the design is kind of stupid, for what it is worth. For the same reason Cheong was thinking -- the possibility of infinite loops.

In fact, the very first version of FindNLSString that I checked in had behavior I believed to be more intuitive, but it was actually my manager at the time who came to me shortly thereafter who mentioned I was not being consistent with .Net. And since that was the whole reason FinsNLSString was being added, this was a blocking issue.

Now while grumbling and doing the research to get the behavior consistent (I was doing both at the same time since consistency with what I thought of as incorrect design is a worse sin than being half right), I found several inconsistencies in .Net as well. That manager found these inconsistencies very frustrating (though in truth he isn't the one who caused the problem; the parts he wrote were consistent), and he jumped in to fix the managed code to be consistent while I fixed the [new] native code to have the same behavior that he was busy making sure would be consistent.

Anyway, where was I?

Oh yeah, with "hiss".IndexOf("") returning 0.

Now when you have strings with no weight, they compare as linguistically equal to the empty string.

Thus "\uFFFD".Compare("") is expected to return 0.

Now there are some standards bodies in parts of the world I am not going to name at this moment that would take statements like:

    "hiss".IndexOf("") == 0
    "\uFFFD".Compare("") == 0

and then make the claim that

    "\uFFFD".IndexOf("") != 0

but for the sake of a fragile attempt at consistency, this route was not taken -- and thus the zero length string is indeed assumed to adorn the front of that string.

Native code and managed code still look at things that way, and huge chunks of the checkin suite verify this behavior is not broken by well-meaning developers who might try and "fix bugs" without realizing that they aren't considered bugs....

So, to summarize the point to Cheong, I agree with you 100%. But we're both wrong according to the spec.

Perhaps the spec was wrong, but I'm pretty sure taking that route with my changes would have created an uncomfortable working environment for me back then. and I doubt I would have won the argument in the long run anyway.... :-)

The title quote refers to a small bit from Martin Cruz Smith's Gorky Park that has very little to do with today's blog....

As with most of the items that eventually become blogs, today's blog started as a couple of emails to me.

Email #1:

Hello. I have code something like this:

System.Globalization.CultureInfo.CurrentCulture says fi-FI x.Name is a string.
foreach (var i in items.OrderBy(x=>x.Name)) foreach (var i in items.OrderBy(x=>x.Name,StringComparer.CurrentCulture))

both sort stuff beginning with W before V!  The other StringComparer settings sort OK. The Finnish alphabet goes v,w not w,v incase it needs to be said so this seems odd.
Paths in Explorer seem to be sorting correctly.

System win7 64 (english UI):
Region format Finnish (Finland)
location Finland
Default input language
Finland (Finland) - Finnish

Installed services:
Finnish (Finland) - Keyboard * Finnish
English (United States) - Keyboard * US

I have NET 4 SP1 Beta installed & tried on both targeting x86 NET 3.5 & NET 4.0 .

test code:

        static void Main(string[] args) {
            List<string> ls = new List<string>();
            ls.Add("Wtt"); ls.Add("Utt"); ls.Add("Vtt"); ls.Add("Stt");
            ls.Add("Wtt2"); ls.Add("Utt2"); ls.Add("Vtt2"); ls.Add("Stt2");
            Console.WriteLine("\r\nInvariantCultureIgnoreCase ");
            foreach (var ss in ls.OrderBy(x => x.ToString(), StringComparer.InvariantCultureIgnoreCase)) Console.Write(ss+" ");
            //Stt Stt2 Utt Utt2 Vtt Vtt2 Wtt Wtt2
            Console.WriteLine("\r\nCurrentCulture ");
            foreach (var ss in ls.OrderBy(x => x.ToString(), StringComparer.CurrentCulture)) Console.Write(ss+" ");
            //Stt Stt2 Utt Utt2 Vtt Wtt Vtt2 Wtt2  --- EXPECTED SAME AS ABOVE
            Console.WriteLine("\r\n"+System.Globalization.CultureInfo.CurrentCulture);
//fi-FI
            Console.WriteLine(System.Globalization.CultureInfo.InstalledUICulture);
// en-US
            Console.WriteLine(System.Globalization.CultureInfo.InvariantCulture);
// ""
        }

What's up, any ideas?

Happy holidays, AV

Email #2:

I wasn't able to find the standard online however I found an article explaining this a bit.
The article states, that if list-format contents are entirely in Finnish V & W are "equal" in terms of sorting.

The article roughly translated says "most lists can be understood to be multilingual, which can be formally argued to make the case for not mixing v & w".

Now I argue that since my Windows UI (InstalledUICulture) is English, I expect the UI to work the same everywhere. eg. Explorer sorts things correctly (no mixing of V & W). So unless somehow explicitly specified, the default sort should* assume multi-lingual lists because the standard says that in multi-lingual lists V & W can be separate (not mixed). http://web.archive.org/web/20040618085838/www.sfs.fi/standard/20000619.html

*(becauseFinland is multi-lingual country: everyone has to learn fi,eng,swe - so lists should not be assumed to be only in Finnish in Finland)

So what is the solution when I want every program consistenly by default to sort "english/invariant style" and show language in English but I need date, time and keyboard settings to be Finnish? It's still common occurrence that 3rd party programs do not respect UICulture resulting practically random program language all over the place.

I suggest the solution is to somehow hack the APIs so that if UICulture is English then only Date/Time/Key APIs use the Finnish settings. Probably hard to do but there doesn't seem to be other good solution.

I will start simply and point out that is entirely and completely by design, and unlikely to change any time soon.

But no one should be satisfied with that as an answer; its important for there to be an explanation that has facts on its side.

So, let me explain what is going on here....

The most important place to start, looking at that quote was a small challenge for me given the relatively poor quality of my Finnish reading skills, but I believe I can verify that the meaning of

Monikielisessä aineistossa v ja w voidaan nyt aakkostaa erikseen

is indeed that in the multilingual context, V and W can be sorted separately.

This is a very big problem for us, since the contention of s difference between "entirely Finnish" and "multilingual Finnish" as the latter does not exist as an option.

There are other letters in Finnish that will not sort properly if one does not use the Finnish sort.

The point is even more interesting when one considers the changes that the neighboring swedes may eventually be contemplating, which I described in Why do we call w 'double u' -- doesn't it look more like a 'double v' ?. Given that nearly 14 years prior the Finns were considering the need to distinguish the two letters in some contexts, it is interesting they had no interest in supporting an eventual change to distinguish them, to the point where they would suggest that bifurcation was the only way the Swedes would be able to change their sort....

Now at the moment (and absent the Swedish government pushing the suggested changes, for the foreseeable future) the Swedish and Finnish sorts are the same.

Now in addition to the changes to give "w" a secondary distinction from "v", at a minimum all of the following letters sort differently than they sort in English:

üÜåÅäÄöÖØØ

Now, being neither Finn nor Swede, I cannot calculate the exact impact on changing the W/V relationship, at the xpense of breaking the way all of those other letters are sorted. But I don't think it would be a positive one for either of them....

So, absent a new sort (I could not find the standard either so I couldn't say whether the Finns ever defined it -- just as with the Swedes), there is no way to make a change to change one letter;s behavior without changing any other.

You may be wondering what the sort keys of these varous strings in the above test look like. I know I was interested, at least.

So even if you weren't, then you'll have to sit through it, since here you are just along for the ride!

First we'll look at the strings in English (en-US), which will be the same as Invariant (the default table), in weight order:

Stt  0e 91 0e 99 0e 99       01    01 12 01 01 00
Stt2 0e 91 0e 99 0e 99 0d 1a 01    01 12 01 01 00
Utt  0e 9f 0e 99 0e 99       01    01 12 01 01 00
Utt2 0e 9f 0e 99 0e 99 0d 1a 01    01 12 01 01 00
Vtt  0e a2 0e 99 0e 99       01    01 12 01 01 00
Vtt2 0e a2 0e 99 0e 99 0d 1a 01    01 12 01 01 00
Wtt  0e a4 0e 99 0e 99       01    01 12 01 01 00
Wtt2 0e a4 0e 99 0e 99 0d 1a 01    01 12 01 01 00

And then we'll look at Finnish (fi-FI), in weight order:

Stt  0e 91 0e 99 0e 99       01    01 12 01 01 00
Stt2 0e 91 0e 99 0e 99 0d 1a 01    01 12 01 01 00
Utt  0e 9f 0e 99 0e 99       01    01 12 01 01 00
Utt2 0e 9f 0e 99 0e 99 0d 1a 01    01 12 01 01 00
Vtt  0e a2 0e 99 0e 99       01    01 12 01 01 00
Wtt  0e a2 0e 99 0e 99       01 03 01 12 01 01 00
Vtt2 0e a2 0e 99 0e 99 0d 1a 01    01 12 01 01 00
Wtt2 0e a2 0e 99 0e 99 0d 1a 01 03 01 12 01 01 00

And now you can see why the "W" can sometimes come before the "V" -- because that number at the end has a primary distinction, unlike that "W" has, in Finnish.

Now there are some random points about the installed UI culture which aren't relevant to this conversation, and the current culture, which are. But none of these things impact the behavior here.

Of course there is one last mystery here, which is explaining why paths in Explorer "seem to be sorting correctly", which of course (given the above) i would be considered incorrectly.

But that is something I am unable to reproduce here:

In these screenshots from Windows 7, the Format: language for the first is English (United States) and for the second is Finnish (Finland).

Perhaps the confusion about UI language or installed UI language having some impact on sorting (from email #2) led to some confusion on settings -- neither ever controls this behavior in Explorer.

So, as I said earlier, the described behavior is pretty much expected. Though in the larger world of the Finnish suggestion of different potentially desired "multilingual" sorting behavior and the potential eventual changes in Swedish, where all of this will end up in 5-10 years is completely uncertain.

To me, at least.

As is the exact meaning of the quote in the title, though I can probably divine that a bit more effectively (and no, I do not need to fry anyone in butter first to get the answer!)....

Previous blogs in this series:

• #1: Uniscribe filters nothing

Now I don't want to just totally knock Uniscribe.

Or any of the successor text stacks that were largely designed and implemented by the same people (when I say "Uniscribe" you can assume I'm talking about all of them unless I say otherwise).

Some very powerful things happen in regard to text rendering of languages and scrpts throughout the world.

But there is a particular flaw of Uniscribe that I am going to talk about here today.

As I pointed out in part 1, you have to promise not to tell anyone you heard it from me.

Even if you already knew about it.

The problem is that it never goes the whole distance when it adds support for a script.

Well, that isn't really the problem.

The problem is that for anything even remotely complex, the applicable shaping engines of Uniscribe tends to build a little fence around the distance they do go, and although they did not go so far as to put razor blades on the edges, the people who need support "beyond the fence" would readily agree with the metaphor as they probably have the cuts to prove it.

Take the Thai issue I talked about in part 1 and remove the lame SCRIPT_PROPERTIES->fRejectInvalid stuff, since it isn't really there for the most part anyway.

I admit that Word's "sequence checking" as I blogged about in You're not the one out of sequence, and that's the Word is related to that, but since you can turn that feature off I am prepared to forgive them for their sins in this area.

The other part (the SCRIPT_LOGATTR->fInvalid part) is still there, and it leads to a lot of those dotted circles.

When Matin Hosken was talking about Sequence Checking in Thai & Lao a few years back, he was pointing out that while there may be things that are illegal in Thai and Lao (the modern languages in use) that are perfectly acceptable in every other possible use of the Thai and Lao scripts. Including a not even close to insignificant number of minority languages within Thailand and Laos and Southeast Asia.

These uses will be rife with small instances of dotted circles.

These dotted circles may be true by the limited vision that Uniscribe brings to the task of determining what is or isn't illegal. And it is generally more impressive than how your UK English essay will look after you throw the US English spellchecker at it. But that is mainly because the spellchecker marks in red while Uniscribe does not.

One can essentially count on a terrible experience for many minority languages due to these overcorrecting "script mavens" that are the Uniscribe shaping engines. We can practically call them language specific given their tendency to treat as wrong text that has the nerve to fall outside of the small set of languages they are aimed at and whose principal benefit is that they have the most speakers and/or the most paying customers and/or the most government support.

And the South Asia connection is just due to the huge number of languages that Uniscribe does support now (within which sit the even huger number of minority languages that they do not support).

This applies to pretty much the entire world -- and it can even lead to people like Andrew West, who in some cases would be huge fans of all that Uniscribe can do, to write blogs like Prototyping Tangut IMEs, or Why Windows 7 Sucks. Because the situation is common: before support is there things work fine, but then once some support is added a whole bunch of stuff stops working.

At that point, the fences are up. And minority languages and other cases not explicitly handled

Now what is really needed is for the Uniscribe shaping engines to be a little bit less prescriptive, a little more willing to grant that the people authoring fonts may know exactly what the hell they are doing, especially in these edge and not-so-edge cases where these shaping engines don't have a clue. And couldn't find one even if Steve and that dog Blue were there to dig the clues up....

This is one of those posts about my medical situation. Skippable if you aren't into that sort of thing!

I've talked about Ampyra a few times before on this Blog, e.g. in blogs like these:

• Arising from one's own ashes. Like [up to 80% of ]a phoenix....
• Not everyone wants me to do The Right Thing™ + Ampyra update/irony...
• They got the $2000 from me, which is probably all they were looking for....

As that last blog indicated, I was on the fence about stopping the Ampyra.

It does help with some of the symptoms that contribute to my inability to walk without falling. Which is very cool.

But it does not help with all of them, and I really am still stuck in a wheelchair, albeit a cool one.

Now Ampyra, unlike the drugs that I am even now haunted by the fact that I wasn't taking over the last 15-20 years ago (described here) is a 100% symptomatic medication. Being on it has no long-term benefit for me.

Given the fact that this > $1000 per month drug alone will put me over the $11000 health care ceiling before which the post-health care change Microsoft will go back to 100% coverage (previously explained in The exciting nature of being ordinary and The ordinary nature of being exciting), I don't think the minor benefit to me that this drug would have is worth the $2000 annual salary decrease that it would guarantee.

Use of this drug could then be considered an official casualty of the Microsoft Health Care changes. By putting financial incentives in, I have decided it is more "responsible" to just not take it. And by "responsible" I mean "cheap". So Microsoft benefits from my responsibilitycheapness. Congrtulations.

So I am going to stop the Ampyra soon.

I could wait until the changes took full effect -- and perhaps I may wait a little bit. But I'd hate to find that the drug helped me some other unknown way and I had to decide whether the new exciting drug feature was worth $2000 of my own money. Better to go with the unambiguous situation.

I went to a couple of recent presentations that the pharmaceutical company (Accorda Therapeutics) put on -- one in Lynnwood and one at the airport Marriott -- and had a chance to talk to doctors, physical therapists, people from Accodra, and several patients. And I am prepared to take my suppositions from They got the $2000 from me, which is probably all they were looking for.... and call them facts.

And not just because of the smarmy nature of the presentations, that glossed over facts and limitations in the existing studies. Nothing is smarmier than these kinds of presentations.

And it is not giving out a drug in monthly doses that they guarantee to work within 0-6 weeks -- meaning that the drug company gets to make a free half month of money off this huge "hot dogs come in 8's, hot dog buns come in 10's" situation. I mean that is smarmy too, but they blame packaging (despite the fact that it is packaged in a bottle that could fit twice the dosage, so it could obviously fit 1.5 times the dosage!).

It is more subtle than all those things.

They could have targeted the studies better and gotten better info on who benefited from the drug, but Accorda is in it to make the money while they can.

I mean, it is only a matter of time.

Prescribe a medication whose accidental overdose beyond one pill every 12 hours can cause seizures to people with a disease that is known to cause memory problems?

That's just asking for trouble.

 Why spend more money to better target the drug when you can pocket the cash for as long as you can?

Anyway, the bit up in the title is true. One of the known uses of 4-AP (the main drug in Ampyra) is to induce seizures in birds, as a way to scare them off (the idea is that once a few birds are having seizures, the whole flock freaks out and they all leave). this kind of bird control measure is I'm sure something that many animal rights groups are pretty unhappy about. But it helps underscore how close to the surface this particular side effect is.

This fact was on one of Dr. Bowen's slides at the first presentation, added by him. The Accorda Therapeutics people were not amused, and said this would not be in the next presentation (it wasn't).

Until they can fix or improve my other related symptoms, I don't find it to be worth the costs.

So if Ampyra helps you then great (it was effective for me, though not good enough to help me in the long run). But be careful not to overdose. Unless you are a bird near the airport, in which case I suppose one should be doubling down....

It was just the other day that regular reader Random832 commented to my I think MaxLength needs protection to assure safer text:

Who decided that cutting off your string and beeping at you was good UI, anyway? Surely it'd be better to just not let the user submit the form until they delete enough stuff to fit [and provide interactive feedback about the limit, a la twitter]

Well, I'm only half-serious - i'm sure this was easier with the limitations programmers had to work with in 1983 - but surely no new programs should be using this "feature".

Now there's a question.

It is in fact an excellent point, though.

I mean, for all the bold talk about one of the possible indicatons for "complex script support" is indeed Filters out illegal character combinations -- and this is called out in Thai, specifically. GoGlobal goes a bit further in its Complex Scripts FAQ:

Why do we need to filter illegal character combinations?
Since Thai syllables consist of a consonant optionally followed by one vowel and/or one tone mark, some character combinations (e.g., two vowel marks in succession) are nonsensical. Thus, one of the tasks of complex script enabling is to filter out or disallow illegal character combinations.

Interestingly, it makes me think of the prototypical example of this behavior:

1. Open Notepad
2. Switch to the That Kedmanee keyboard
3. Type the "J" key, which tries to type U+0e48, aka THAI CHARACTER MAI EK

Every time you hit the key, the computer will beep and insert nothing.

But can I tell you a secret?

You have to promise that you won't tell anyone. It is kind of embarrassing.

Uniscribe isn't doing that.

Seriously.

I can put a bunch of those characters in a row just fine, in text, in an applicaion other than Notepad. And Uniscribe will display them.

I can even paste lines of them into Notepad:

or here:

่่่่่่่่่่่่่่่่่่่่่่่่
่่่่่่่่่่่่่่่่่่่่่่่่
่่่่่่่่่่่่่่่่่่่่่่่่
่่่่่่่่่่่่่่่่่่่่่่่่

and guess what? There's no problem with doing it.

The code that "filters" these characters sits in code called by the EDIT control that checks for two things:

• Does the script of the given text "disallow illegal sequences" as described by the SCRIPT_PROPERTIES->fRejectInvalid from GetScriptProperties TRUE, and
• is the SCRIPT_LOGATTR->fInvalid of the given character also TRUE?

If both are, while you are typing, this code that is not in Uniscribe itself will fail the attempt to insert the text, and it will beep.

Obviously that doesn't work so well for text that is already present (how do you scold someone for illegal text alreay typed?), so in that case Uniscribe will just do as it is told. And it will of course include the 'empty circle" that implies a missing base character.

Now there are several problems inherent in this direction for the text processin engine to go, and I am going to get into that more tomorrow.

But I wanted to start by saying that it is a limited number of dumb controls that screw with the input stream while you are typing that is doing the work here -- Uniscribe filters nothing.

There are some folks who will like upcoming parts to this series, so I hope that (for example) Andrew West and Martin Hosken are around. Because both of them and a few folks like them, are gonna like this one....

it may come as no surprise to regular readers that some of the people in the set of "people who read this Blog" work at Microsoft.

A few of that more restricted set even find one or more of the blogs within this Blog to be useful for their something in their work.

And then a few of that even further restricted set find an interesting problem or issue or bug or design limitation along the way.

In some of those cases, I help them get the bug in and/or help push for a fix in the bug.

This blog is not one of those cases.

In this case, the owners of the component that caused them trouble was deemed a "Won't Fix" bug, since i had a workaround.

This blog you are reading now is going to describe the bug, and the workaround.

First, the simple repro code:

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include <fcntl.h>
#include <io.h>

void Test1(int argc) {
    int Mode;

    Mode = _setmode(_fileno(stdout), _O_U16TEXT);
    fwprintf(stdout, L"first\nsecond\n");

    if (argc > 2) {
        fflush(stdout);
    }

    if (argc > 1) {
        _setmode(_fileno(stdout), Mode);
    }
}

void __cdecl wmain(    int argc,  PWSTR *argv) {
    SetThreadUILanguage(0);

    Test1(argc);
    exit(0);
}

So there are three cases here:

1. When you execute the above with no additional command line arguments, e.g.
   
         test > out.txt
   
   the result is fine.
2. When you execute the above with 1 additional argument, e.g.
   
         test 1 > out1.txt
   
   the result contains a spurious 0x0d byte that destroys the integrity of this UTF-16 file.
3. When you execute the above with 2 additional arguments, e.g.
   
         test 1 2 > out2.txt
   
   the result is fine.

 Obviously, proper line breaks are what we expect here, so that case #2 clearly looks like a bug.

Now the most interesting case to me is the first case, and for some developers it is the most common.

It has two features many developers who aren't the sort to be reading this Blog do quite commonly, in that

• no explicit flush of the file is done (it relies on the implicit flush expected to happen during cleanup), and
• the mode that is changed is not restored.

This first case sees no bugs.

Now the second case, which has no explicit flush (it still relies on the implicit flush) but does restore the mode, because even though the app is about to exit, many developers do like to do that sort of cleanup of settings they change.

There are many reasons for this, but the one I find myself doing this for is that people often copy/paste code samples that they put elsewhere. This way, someone will do the cleanup in their app even if they don't pay the same attention to details....

The third case is an interesting one, because in a console app that does not have its output redirected often does not flush.

This simply doesn't occur to the developer in most cases; if the do think about it, they know that stdout will be implicitly flushed anyway.

And here lies the hint as to the problem:

All of the CRT's pending "text mode autoconvert \n to \r\n" that happen during the implicit fflush are done using the current mode of the stream, not the mode at the time that text was fwprintf'ed. And the pending text in the stream is in a state that is halfway to being handled.

Therefore, to avoid the risk here, it is best to always explicitly flush in the current mode, rather than having the implicit flush happen after the mode has changed.

If I don't get any email from a doc writer (there are some doc writers who also read this blog) in a week or so, then I'll probably put in a bug suggesting the need to explicitly fflush prior to a mode change being added to the _setmode documentation. I'm just saying....

Now I had in mind two different potential punchlines to end this blog on:

• one involving the need to not rely on the autoflush mechanisms found in so many airport and Microsoft campus toilets, just in case the flush doesn't happen correctly;
• another equating the mode change to whether one put the seat back in the state it was in (often down if a lady regularly uses the same toilet) and the desirability of msking sure to flush and make sure that the everything is clean prior to lowering the seat.

But I couldn't think of any way to make either of them work out well (toilet humor is undignified, as are flush puns); this blog has been sitting in my "almost finished" pile for over a month now as I tried various ways to redeem it for a world that finds Jackass-style movies to be entertaining before I simply gave up.