How Windows 7 broke VB6's RightToLeft property, and how to get it fixed

by Michael S. Kaplan, published on 2010/02/13 15:01 +00:00, original URI: http://blogs.msdn.com/michkap/archive/2010/02/13/9962894.aspx


It started many years ago.

Oh wait, it started even before the date I was thinking of originally.

This was back at the tail end of the last century.

I was helping people with some VB add-ins that had to be supported in multiple languages when everyone suddenly realized (after an email I sent out about the subject) that the sample code provided to help with runtime localization was not going to work for Arabic or Hebrew since VB's RightToLeft property couldn't be changed at runtime. It wasn't their fault, really; it was the CreateWindowEx function in the Win32 API that was to blame since you could never change the directionality of a window after it had been created.

VB's position was that this was by design since the technology they were using didn't support the notion, but I convinced Jim (a VB developer who is no longer at Microsoft) of the speciousness of that argument, since Windows wasn't sticking an easy property out there that anyone could set. So for VB 6.0, Jim made this property settable and did the work behind the scenes to destroy the window and recreate it (at the time a novel concept since suddenly, the handle on the window could change, a rich source of bugs for testers to find!).

Anyway, fast forward a little bit.

There were a bunch of people who were being persuaded, convinced, and cajoled to support the new ComAddIn interface that Office 2000 was going to use to let people plug their Visual Basic 6.0 add-ins into the suite by a program manager named Dave who also no longer works for Microsoft.

I myself (still a mere vendor to Microsoft at the time but who was doing a number of different jobs for various groups) had contracts to help with the integration of four different add-ins, including one that I had written myself and another of which I had mostly written.

Anyway, it was around the first week in December I think that there was some panic since Dave had promised a localization framework. The panic was Dave's as there was no such framework. How could there by VB add-ins in the Office box if no one was going to be able to translate them into the Office languages.

He started to write something but it really wasn't very good, plus it was incomplete.

So with no holiday plans, I just decided to write a framework.

Dave was overjoyed since it meant he was not going into the midyear with a major initiative flopping, and other devs looked at the framework and saw it would do the job they needed. Everyone was happy.

Of course, no one wanted to pay me for the three weeks of work.

Dave was willing but they had no money, the teams that I was working for specifically refused to pay for it since the work I was doing for them was scoped tightly and this work was being promised by a shared team. Other teams felt the same way, plus no one wanted to own testing the framework or supporting it.

I suppose I could have been a jerk and just sent a cease and desist and made them take the framework out of those products. Someone would have paid me then but I doubt I'd have a whole lot of future work to look forward to for groups at Microsoft.

I decided to be magnanimous and just grant Microsoft a permanent, non-transferable, non-exclusive license to my "Win32Dialog" class. Perhaps not entirely selfless since it saved at least four of those contracts. :-) Anyway, crisis averted, though even years later I would have someone in legal sending me email asking me about the two files (win32dlg.bas and win32dlg.cls) with the header that said:

' This module is a "common software module or tool" owned by
' Trigeminal Software, Inc.

and how to get that taken care of. When I explained the situation and told them to take care of it all they had to do was pay me for the three weeks they decided they could live with it.

I suspect I will never be paid for that work.

A modified version of the code went into my book (Internationalization with Visual Basic).

Of course the code included the RightToLeft property and its ability to be set (this was the one piece of the code that would fail in VB 5.0). This was used by several different add-ins and I am told some other projects though I never got a full list.

Now getting back to that property, the implementation was set up to only work on systems with "Right to Left" support, which sometimes included Windows 2000/XP but not always given the nature of What isn't in the default install for NLS. There is a generic dislike within Microsoft of hacks like hard-coding Arabic and Hebrew but there did not seem to be another option. Though luckily, or perhaps unluckily for reasons that will later become clear, some old code supporting WinMe/NT4 using an Arabic/Hebrew specific hack of a special flag to IsValidLocale was found and used instead.

Somehow using someone else's hack is more palatable than using one's own hack. :-)

Now fast forward a few more years, to Windows 7.

Neither Windows Me nor NT 4.0 are covered by even extended support, and no one knew anything about what the hack was there for or why and everyone hated this kind of thing anyway. So after a small amount (some would say too small but I'm going to be broad-minded here) of due diligence they removed the hack (roughly akin to fixing the glitch!) and Windows 7 shipped that way.

Fast forward a small amount, and suddenly complaints start rolling in about the broken RightToLeft property on Windows 7. At least four sustained engineering requests for fix to Windows and perhaps some on VB and lots of public outcry including threads like this one and many others you could probably find if you tried for a few minutes.

Apparently people noticed that this little old property that was added because I complained enough to Jim one night a decade ago was broken.

Okay, first things first - the quickest/easiest thing to fix is the documentation problem. Which they did, in IsValidLocale:

Note  Setting dwFlags to 0x39 is a special case that can behave like LCID_INSTALLED for some locales on some versions of Windows. This functionality is deprecated and only provided for compatibility. The flag 0x39 should not be used; use LCID_INSTALLED instead.

Okay I guess that's close enough. :-)

Of course they also had to add the hack back so that Windows 7 would stop breaking VB6 here. That part was also fairly straightforward since all they had to do was put the code back that had been taken out. :)

The hotfix is officially available, but the KB article is perhaps not out yet (it was not when I just looked). You have to contact Microsoft Product Support and ask for the hotfix associated with KB979643 to fix the VB6 RightToLeft property when running on Windows 7 (Microsoft Product Support can look it up on their tools). Make sure you specify the flavor(s) you need (x86, x64, ia64) and they can get you the hotfix. It will also be rolled into the next service pack but the hotfix is good for the people broken now (a list that includes at least one police force, one government, one hotel chain, and one publisher!).

Now I am not going to try to take responsibility here for any of this since my involvement in the break was non-existent (I was no longer on the team) and my involvement in the fix was minimal (I reported one case and pointed out the underlying reason but they figured it out independently).

I suppose maybe it was because of me that the property was added and because of the person who added the property that the flag  was used and because of the nameless MEPD dev that the flag no one knew about even existed.

There may even be a moral here about not deleting stuff if you don't know why it's there, but like I said there was some due diligence involved and code can get heavy enough from the hacks and workarounds you know about, let alone the ones no one understands.

The real moral of the story is that the original hack should have been commented better. This mistake was remedied in the re-inserted code:

        //                                   Removing this code will break RTL
        //  support for VB6 applications/script, and possibly more.

And this change (which would have kept the break from happening in the first place) will certainly keep it from being broken again.
 


comments not archived

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2010/03/10 They pushed out of the formatt[ing|er]

go to newer or older post, or back to index or month or day