by Michael S. Kaplan, published on 2010/02/13 07:01 -05:00, original URI: http://blogs.msdn.com/b/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!).
Update 16 March 2010: You can get the hotfix from the request site, right here: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=979643
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.
Dmitry Ginzburg on 23 Feb 2010 2:15 AM:
First I'd like to thank you for this post, as I have exactly the problem you described in my VB6 application.
I wonder if you have any suggestions on how to solve another problem - which is also related to multilingual support.
The problem is best described here:
"LoadKeyboardLayout is very slow on Windows 7"
Although I develop in MS-Access, I believe this is essentially the same problem. The fields in MS-Access have "KeyboardLanguage" property. With this property set, it takes forever just to enter the field.
Michael S. Kaplan on 23 Feb 2010 9:02 AM:
You already have high tier support engineers talking to core folks on the product team in that one, so I think you are already in better hands than mine. :-)
Though I will say you are changing the keyboard way too quickly and you are doing it with the wrong function -- you should be storing HKL values and using them.
i can't speak to the MSAccess issue, but I don't think they are using LoadKeyboardLayout, and once again it is doubtful one needs to switch as often as that....
But this is very offtopic for here, if you want it on the list the Suggestion Box is probably better. :)
M.T.P on 2 Mar 2010 2:52 AM:
what is the result of this topic?
how we can fix?
please upload a Project or Setup for fix this problem.
Michael S. Kaplan on 2 Mar 2010 2:57 AM:
I gave the answer above, in red. You must call Microsoft and ask for the fix in the KB article with the ID I listed.
Or you can wait for the service pack, whenever that might be.
No one has the legal right to upload a project or setup file.
Yuhong Bao on 14 Mar 2010 5:41 PM:
It has been a month and the KB article is still not published.
Michael S. Kaplan on 14 Mar 2010 5:54 PM:
It is internally published and people can request the hotfix from Product Support, which is all the KB article would have done anyway... and many have gotten the fix after following this advice.
Yuhong Bao on 15 Mar 2010 11:23 PM:
Online hotfix request now works though:
1120 on 15 Apr 2010 8:15 AM:
this hotfix not work in win7 64 bit !
please help us : ((
Michael S. Kaplan on 15 Apr 2010 8:24 AM:
There is an x64 hotfix available, make sure you download the right one and it installs properly. After that if you still have problems (it worked for me) you can go through support (as with all hot fixes)....
inbal on 4 Aug 2010 8:06 AM:
i have never installed hotfix, and i am pretty new in vb6. i am programming on windows xp and install the program that i built on windows 7 and the RTL does not work (it does work on XP, just as described above). should i just run my windows 7 get the hotfix installed and after that all my vb6 application will work? should i do something else? i should install the hotfix on the computer with the windows 7 and not on the computer that i program in, right?
inbal vb6 on 4 Aug 2010 8:12 AM:
i have never installed hotfix, and i am pretty new in vb6. i am programming on windows xp and install the program that i built on windows 7 and the RTL does not work (it does work on XP, just as described above). should i just run my windows 7 get the hotfix installed and after that all my vb6 application will work? should i do something else? i should install the hotfix on the computer with the windows 7 and not on the computer that i programming in (the one with XP), right?
Yuhong Bao on 2 Sep 2010 9:44 PM:
Yes, install it on the Win7 target computer.
Yuhong Bao on 20 Jul 2011 10:29 PM:
"some old code supporting WinMe/NT4"
You mean Win9x?
Michael S. Kaplan on 21 Jul 2011 10:45 AM:
No, I mean what I wrote -- it supports NT4 as well.
Yuhong Bao on 31 Jul 2012 7:22 PM:
WinMe did not exist back when VB6 was released.
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