Fog Creek Software
Discussion Board




Handling multipler version of standard OCXs?

Hi,

I'm not an expert on OCX components, so I might be unaware of something obvious to experts out there... but is there a clean, tried and true way to keep multiple versions of a given standard (ie. Microsoft) OCX in a Windows host, so that applications that depend on those versions do not break if a customer installs additional applications that replace those OCXs with different (older, or possibly newer) versions?

Since our applications makes use of standard Windows OCXs like RichEdit etc., the inevitable issue that has popped up every so often, is that a customer installs additional applications that replace the ones we installed, with different versions of the same OCXs.

As of now, I haven't investigated to see if Visual Basic is hard-wired to only accept the exact same version that was used in the project intially, or if it accepts using more recent versions of an OCX.

I understand that COM provides the capability of supporting multiple versions of an object in one OCX file through new interfaces, so I assume the problems we have only occur when another application installed an OCX that is older than the one we used to build the project.

I have read on the Net that a given OCX can have only one entry in the Registry, making it impossible to support multiple versions. Is that true?

=> In the mean time, my dad came up with the quick & dirty solution of keeping copies of standard OCXs in our local directory, and renaming the files before registering them in the Registry. I really don't like this idea, but... is there a better solution?

Thx much for any tip

Frederic Faure
Tuesday, January 07, 2003

>>As of now, I haven't investigated to see if Visual Basic is hard-wired to only accept the exact same version that was used in the project intially, or if it accepts using more recent versions of an OCX.

As long as the interface doesn't change (and it shouldn't) then newer versions shouldn't break older clients..

>>I have read on the Net that a given OCX can have only one entry in the Registry, making it impossible to support multiple versions. Is that true?

Yes

Tony E
Tuesday, January 07, 2003

"=> In the mean time, my dad came up with the quick & dirty solution of keeping copies of standard OCXs in our local directory, and renaming the files before registering them in the Registry. I really don't like this idea, but... is there a better solution?"

That shouldn't help at all. What counts for an OCX is the class id, not the name of the file. This one is registered in the Registry, and the association class id / DLL is saved there. As soon as another program install with a newer version, the registry will be updated to reflect the new DLL location.

Robert Chevallier
Tuesday, January 07, 2003

BTW, welcome to the infamous DLL hell!

And don't count on complete upward compatibility between versions. Good luck!

Robert Chevallier
Tuesday, January 07, 2003

It's sloppy programming for your application to depend on specific versions of third party components.

Must be a manager
Tuesday, January 07, 2003

And how would you get around it? In COM, you specify which component you want via CLSID, which gets looked up in the registry.

When your component vendor screws up and breaks compatibility, how are you gonna know? Your code uses the same CLSID, now it's getting a different component?

EVERY COM developer has been burned by this - MS has a history of stupid mistakes in controls that break compatibility.

And even if you say "Well, we'll use version 2.0 - that fixes the bugs in V1.0" - all it takes is one broken installer to register version 1.0 on your client's machine again and you're right back into the crapper.

It's one of the reasons that one of the big features in .NET is side-by-side deployment.

Chris Tavares
Tuesday, January 07, 2003

[flame on] MDAC 2.1 vs MDAC 2.5 [flame off]

Better than being unemployed...
Wednesday, January 08, 2003

Thx everyone for your contributions. I still don't know of a cleaner way to protect our applications from users installing different versions of standard Windows OCXs.

Tony E>>As long as the interface doesn't change (and it shouldn't) then newer versions shouldn't break older clients..

OK. So... an OCX file can contain different versions, one interface for each, and if downward compatibilty is provided, a single OCX can be used by applications that expect different versions?

Robert Chevallier>>That shouldn't help at all. What counts for an OCX is the class id, not the name of the file.

It did solve the issue, because we are now positive that no one else will replace standard Windows OCXs with versions different from the ones on which our applications depend. Saving those OCXs under a different filename and registering them generates a new CLSID in the Registry.

Must be a manager>>It's sloppy programming for your application to depend on specific versions of third party components.

I don't know if it does. VBP files include CLSID and version number of all the OCXs that a Visual Basic project uses. I don't know if VB accepts running with newer versions, or if it barfs up if the different is simply different (ie. older or newer)

Frederic Faure
Wednesday, January 08, 2003

>>> It did solve the issue, because we are now positive that no one else will replace standard Windows OCXs with versions different from the ones on which our applications depend. Saving those OCXs under a different filename and registering them generates a new CLSID in the Registry.
<<<

Umm... *how* did it generate new CLSID's? The CLSID is hard coded into the DLL - it doesn't have anything to do with the filename? Or are you manually creating registry entries with new clsids?

Chris Tavares
Wednesday, January 08, 2003

Chris,

Indeed, I copied richtx32.ocx as acme.ocx, and ran regsvr32.exe to register it into the Registry... and the same CLSID is saved:

richtx32.ocx
{3B7C8860-D78F-101B-B9B5-04021C009402}

acme.ocx
{3B7C8860-D78F-101B-B9B5-04021C009402}

I'm not positive my dad has actually validated his experiment, eg. replace richtx32.ocx with a different version (older or newer), and see if his applications still work thanks to the copies he made... but the interesting thing, nonetheless, is that two OCX files can be registered with the exact same CLSID, which, I though was not possible.

Thx much for the tip

Frederic Faure
Thursday, January 09, 2003

Yes two files can appear to be registered with the same CLSID, but its the last one that matters.

Simon Lucy
Thursday, January 09, 2003

That's a bitch. Originally, I figured that regsvr32 would create new CLSIDs on the fly, but since CLSIDs are embedded in the OCX file itself... the last one does indeed work.

Considering that plain DLLs could be preserved simply by locating them in the local directory... seems to me that ActiveX is more a nuisance that anything else.

Is there really no way besides telling customers that they must use W2K/98SE and use applications that use install programs that support  side-by-side installs?

Thx much everyone.

Frederic Faure
Thursday, January 09, 2003

<quote>
[..]is there a better solution?
</quote>

Sure, it's called Delphi.
[Oops, I'm being a religious zealot again.]

Jan Derk
Thursday, January 09, 2003

I recommend that you visit the VB COM tutorial at http://www.develop.com/devresources/ResourceDetail.aspx?type=tut&id=5 for a detailed explanation of ActiveX technology in VB and the issues.

John Topley
Thursday, January 09, 2003

What does Delphi do to solve this issue? I understand that it embeds DLLs in EXEs, but we end up with bigger EXEs and having the same code in each Delphi-generated EXEs.

Frederic Faure
Thursday, January 09, 2003

[Wow. Somebody actually responded. I must be an efficient zealot]

Delphi creates dll's and exe's just like VC or VB. It does not embed dll's in exe's.

It does however compile it's (VCL) components into the exe. The single exe is especially an advantage if you distribute your application to a significant amount of computers/platforms. Due to the single exe you will have no ocx files, nothing to register, no conflicts ever.

Use a database like dbisam and you will even have full database support in a single 1MB exe that will run everywhere. No need to install/configure the multi-MB MS database engine du jour.

If you want you can still split up your Delphi application into multiple exe/dll/bpl files or even use OCX components. The good thing about Delphi is that you got a choice.

[OK I'll stop it now]

Jan Derk
Thursday, January 09, 2003

See, the part that never quite worked out about the DLLs is that every installer needs to carry every potentially necessary DLL anyway to prevent annoying the user.

So the only advantage to DLLs is that you can upgrade the DLL and fix bugs without releasing a new version.  However, there are so many wrinkles there (i.e. MS breaking things) that you loose that advantage, too.  Hence DLL hell.

DLLs do work well as a way to access a vendor-supplied API or as a way for individual applications to update pieces of themselves without updating the whole thing.  In all of this mess of DLLs and OCXs and Registries and whatnot is a simple solution to the versioning, updating, and configuring of software components.  That the worlds of Unix nor the world of Windoze have managed to accomplish.

w.h.
Thursday, January 09, 2003

*  Recent Topics

*  Fog Creek Home