Installer for VB6 Runtimes on Win 7 client PCs ?

[JohnReam]

Q1: Is there a redistributable VB6 runtime vbrun60sp6.exe from MS to re-install the newer files onto Windows 7 or 2008 in case these files somehow become corrupted, deleted or changed?

Win 7 & 2008 version preinstalled is MSVBVM60.dll 6.00.9815 Jul 13 2009 (and handful of other files such as OLEAUT32.dll)

XP/Vista version in existing vbrun60sp6.exe is MSVBVM60.dll 6.00.9782 Feb 23 2004


Q2: Are VB6 programmers having success with Win7 customer PCs and the new 6.00.9815 version files, especially with the extended runtimes such as CONDLG32.ocx? We have seen some nasty App Crashed occurring related to COMDLG32 on Win 7. We are hoping that the just released April 2012 cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files makes a positive difference.

Thanks,
John

[dilettante]

Q1: Don't use this. It is a hack meant to help pave over a few specific awkward situations and there is no guarantee a given download of it will have recent SP6 files, let alone versions tailored for recent OSs, and under modern versions of Windows attempts to install it are ignored through Windows File Protection anyway.

Q2: The preinstalled versions of the runtime and "extended runtime components" work fine.


Warning:

Do not install the April 2012 cumulative rollup. I have seen nobody verify it yet and it is a re-issue of the known-problematic December 2008 cumulative rollup that was re-issued at least 3 times in 2009 (and they never got it right).

This cannot be uninstalled from a development machine. It breaks numerous components with "off by one" bugs that result in things like failures using collection properties within the components, truncation of String valued properties in others, etc. It also has broken typelib info that can result in double-registration of these components leading to failure in several scenarios. Once installed the only fix is reformat and reinstall Windows.


Why are you even asking this?

Most of the problems of the kinds you hint at with VB6 programs on modern versions of Windows happen because of:

• Developing on Windows XP, often with a hosed VB6 tools configuation.
• Compiling using VB6 SP5 or older.
• Packaging components that always were (or have become over time) system components.

The ideal VB6 development environment today is 32-bit Vista (the last OS version officially supporting VB6 development) with SP2, VB6 with SP6 installed, PDW Redist folder and VB6DEP.ini manually updated per 12 years of MS KB articles, VSI 1.1. There is no need to jiggle the handle further.

Next best is 64-bit Vista, then 32-bit Win7, and as a last resort 64-bit Win7. Win7 SP1 contains a particular deathtrap of its own in regard to ADO though there are detours.


We are having no problems developing for Windows 95 through Windows 7, 32- and 64-bit. The only problem with Server editions/versions has been a few 64-bit Server OSs where WOW64 is optional and had not been installed.


Problems with COMDLG32.ocx most likely stem from the use of bad installer packages that try to deploy COMDLG32.dll across an OS mismatch. COMDLG32.dll is tailored code, every OS version has its own. The infamous Inno ("No, No!") Setup is often the culprit here. This is a hazardous tool in the wrong hands and there are many poorly written script examples for it loose on the Web that can trash not only your application but other applications already present on a target (victim?) machine.

[JohnReam]

Thanks dilettante for the reply.

Important: We believe strongly that the April 2012 cumulative rollup files are REQUIRED for our customers with PCs using Windows 7 SP1. It's all about the new MSVBVM60.DLL preinstalled on the newer operation system which is appearing to have real problems with the VB6SP6 (2004) OCXs and extended runtime files resulting in various fatal app crashes and errors. We had a couple of customers report serious problems, yet interestingly we were never able to reproduce the problems in our development offices.

So we have updated our installer to now deploy the handful of the OCXs we need from the new April 2012 collection in extended runtimes. So far so good, customers are running error free as far as we know.


Just wanted to share this with the VB6 community. It would be a sad day if we all lose the ability to deploy our VB6 apps on PCs running newer Microsoft operating systems. We all need to work together to share knowledge of these DLL/OCX hell experiences and the solutions.


What's your experience? Good, bad, same?

John

[dilettante]

I don't know who you're quoting there (who "we" is) but there is no such problem on Windows 7.

I checked and that dangerous, broken security rollup hasn't even been reissued. All I can find are two MS KB "scare" articles dated May 2012 trying to get people to install it. "It" being the broken update from 2008/2009 that cannot be uninstalled.

Believe me, tons of people are successfully deploying VB6 programs to systems running anything from Windows 95 to the Windows 8 Preview release - with no such problems whatsoever.

[JohnReam]

Didn't mean to make rile you, sorry, just discussing and sharing, let's keep it down low, thanks.

I work for a SMB for 15 years, one very solid commercial VB6 app, many corporate clients. We deploy with Wise 9.02 installer, and only include the minimal ocx redists as needed, we've been deploying aok for years, even thru the Vista years, until Windows 7 SP1 came along. Clients problems very random and hard to repro such as our app simply disappearing (ie. End) out of the blue. Or 429s on forms that have some ctls like comdlg32.ocx, random. Very frustrating for our clients and us. We've been suspecting the newest files MSVBVM60.DLL and COMDLG32.DLL for a while now. THEN, we tried the newly released April2012 files specifically for these clients having issues, and the issues are now gone. Only about 12 of the standard common Ocx files being the difference in deployment.

Regarding that Dec 2008 cumulative update: yeah we know, good news for us is that we never installed the Dec 2008 update, or even the later quick-fix attempts of May 2009, etc. We didn't need them since nothing was broken for us so we never installed them. For years we have been at VB6SP6 Feb/Mar 2004. Fast forward to May 2012, our 2004 redist Ocxs now seem to involved with issues with some clients new Win7 preexisting files. We did a through beta test of April2012 ocx files with some of our impacted clients, 100% sucessful so far. 100%. That's our story, and we're sticking to it, this is our experience for others to ponder if they they are having similar issues.

[dilettante]

The only April 2012 update I know of is MS12-027 that involves mscomctl.ocx:

MS12-027: Description of the security update for Visual Basic 6: April 10, 2012

This is completely unrelated to comdlg32.ocx or comdlg32.dll (which is part of Windows and doesn't ship as a VB6 library anyway and should never be deployed, even to Win9x systems).

The ill-fated MS08-070 never pretended to fix any bugs. It was only intended to patch security holes, which of course are bugs too but not the kind that hurt program execution.


Is there another fix from April that you are talking about here? A link might do wonders to clarify the whole thing.

[JohnReam]

"Is there another fix from April that you are talking about here? A link might do wonders to clarify the whole thing."


Yes there is. Here are the MS VB6 links for the April 2012 Cumulative Update.


Microsoft Visual Basic 6.0 Service Pack 6 Cumulative Update, VB60SP6-KB2641426-x86-ENU.msi 9.8 MB, April 19, 2012
http://www.microsoft.com/en-us/downl...s.aspx?id=7030

Description of the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files, KB article: KB957924 April 20, 2012
http://support.microsoft.com/kb/957924

You wrote of update MS12-027, which only addresses one file mscomctl.ocx. KB2641426 addresses that same file and about 30 others popular extended runtime files. KB2641426 is the April 2012 Cumulative Update. Do you still advise against this using this file?

As I mentioned earlier, we are seeing 100% success so far with the April 2012 Cumulative Update. We believe these newer versions OCXs are required for app stability on Win 7 SP1 clients running similiar versions MSVBVM60.dll and COMDLG32.dll which are the O/S embedded prexisting files.

.

[dilettante]

Ahh yes, this is the re-issue of the broken MS08-070. See the article Description of the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files

This (a.) doesn't "fix" anything, but is a security patch update, and (b.) is very likely to have broken versions of the component libraries that are ticking time bombs.


This update doesn't do anything about "stability on Windows 7" at all, read the description. What it does do is attempt to pave over (fix) flaws in MS08-070's earlier versions. Sadly the list of things the description says it fixes in the broken MS08-070 are not any of the items we already showed to be broken in this and other VB6 forums.

So (repeating myself once again) this does not address Windows 7 at all, and has not been vetted by the community and should be considered hazardous until proven otherwise. If you install it you cannot uninstall it, beaking your machine for development purposes.


Windows 7 SP 1 ships with comdlg32.ocx version 6.1.97.82 which is known to be working.

I suspect what you have really been running into is trying to force-deploy an older version of the OCX that is not compatible with XP SP3, Vista, Win7, or Win8. Playing around with UAC settings to make this possible is bad karma for many reasons.

This (6.1.97.82) is the version you should redistribute. You will find that it is the same version contained in the current Merge Modules for Service Pack 6 for Visual Basic 6.0 and Visual C++ 6.0 download.

[dilettante]

Some good news at least:

The version of MSChart.ocx in the April 2012 security rollup (6.1.98.16) appears to work properly using the test suite that failed miserably using the earlier version of this MS08-070 security patch (6.1.98.13).

Of course the VB6SP6 merge module version of the same library (6.0.88.4) has always and continues to work as well, on any system with the VB6SP6 runtime including Windows 7 and Windows 7 SP1.


The big problem is the time it takes to set up sandboxed tests of every library included in these security rollup packages. "Fool me twice, shame on me" so the community is right to no longer trust Microaoft on these things, especially this series of attempts to get MS08-070 right.

All I can confirm is that for this one library I have one test case that earlier attempts at MS08-070 broke and this new attempt does not. There could be other traps and timebombs embedded in it yet though.


And the good news is that no attempt at a properly function MS08-070 is really needed by almost anyone. These are security fixes primarily aimed at the use of the control when embedded in an Internet Explorer web page! Pretty much nobody does that anymore anyway.

These security-patched versions of the libraries are not required on Windows 7. If they were we'd be seeing people screaming all over the place. Since they are not it sort of proves the point.


This is a "big deal" because MS08-070 has cost enormous amounts of lost productivity as well as loss of good will between developers and customers over the past 4 years. It has been a real Trojan Horse in the classic sense (not the malware sense).