by Michael S. Kaplan, published on 2007/09/10 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/09/10/4850360.aspx
It was over a year ago that I wrote a post about a Visual Basic language feature that has been around forever, and two specific problems with it (entitled Is the SendKeys juice worth the squeeze?) that intended to focus on two specific issues:
Both of these architectural moves were mistakes, in my opinion.
The first issue made up as much as 5% of my pre-Microsoft career consulting for folks to help fix up VB projects needing language support due to how much confusion it inevitably leads to.
And the second was a short-sightedly naive as opening up registry keys for read using a KEY_ALL_ACCESS request in the call to RegCreateKeyEx that works great on Windows 95 but dies on the vine when you run on an NT-based system and get introduced to security. I have some personal experience with that registry issue -- the Microsoft access wizards were riddled with that behavior, and in the world of least privilege with big corporations that did not give all their employees full access it was a deployment blocker of the first order.
Of course this was not communicated well, and you can see in the comments how one customer focused on the VB backcompat issue and the fact that all of their applications would be broken.
Luckily when the VB team stepped up with an updated version of the Visual Basic runtime DLL (msvbvm60.dll) that had a graceful fallback to a SendInput implementation, that was communicated as well, and the unhappy customer was able to be happy again (also for correcting me since I had apparently said it would not be fixed -- I had not; I just said that Windows wasn't gonna fix the problem, since it was a VB bug!).
Anyway, long time colleague and comrade Karl Peterson asked me whether the VB6 runtime "shim" could be done for msvbvm50.dll as well.
Of course the fix was not a shim, it was an updated binary. So I guess the answer is (strictly speaking) "NO" since it never was a shim, though the less literal answer to whether a VB5 runtime fix would also be forthcoming would be that "I don't know, since I don't know their plans here." When in doubt I would recommend asking someone like Paul Vick since he is much more likely to know stuff.
Though if I had to guess I'd look at the fact that according the DLL Hell database, the last update was done for products back in 1998 and every white paper I have seen goes out of its way to emphasize the 6 in its description of the supported, making me really unsure what the VB5 story is here. There has to be a reason, right?
Anyway, I did learn something from that old blog post about misunderstandings and how easy it was to have them happen and how unlike the world of sitcoms like Three's Company they were in the blog -- they simply aren't funny, and they are kind of distracting.
And the juice was not worth the squeeze, in any case....
This post brought to you by ၍ (U+104d, a.k.a. MYANMAR SYMBOL COMPLETED)
Yuhong Bao on 22 Apr 2009 9:47 PM:
BTW, it seems that the versions of msvbvm60.dll shipped with Vista and later has no symbols on the MS symbol server, while some but not all older versions did have symbols though some of them was built with a PDB but only the DBG file was published on the symbol server.
Also you misspelled "DLL Help" as "DLL Hell".
Yuhong Bao on 22 Apr 2009 10:18 PM:
BTW, the frustrating thing about issues with NT security in general is that Windows NT, with all it's security, existed before Windows 95! In fact, the Designed for Windows 95 logo in general required compatibility with NT 3.51, though of course there were exceptions to this rule.
BTW, compare how SetFilePointer supported large (and by large I mean larger than 4 GB) files with how GetDiskFreeSpace (yes, the original GetDiskFreeSpace) was supposed to support large disks (and actually did in NT 3.x). The fact is that SetFilePointer, GetDiskFreeSpace, large files, and large disks all existed since NT 3.1, but MS was forced to cap the output of GetDiskFreeSpace to 4 GB with NT 4.0 and 95 OSR2 because of a common error.
go to newer or older post, or back to index or month or day