 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
LarryJ
Guest
|
 Posted: Fri Mar 09, 2007 2:39 am Post subject: COM Upgrade and back compatibility |
 |
|
My application uses a COM link to a third party program by selecting
Project->Import Type Library... and then using the CLSID_ to create the COM
object. The third party program seems to upgrade about twice a year and they
release a new version of COM dll. Every time this happens my application
will no longer create the COM object because the GUID IID__ in the dll's
type library change. Below I show the type library GUID IID__ created by
BCB6.0 for three different version of the COM dll. Each time this happens I
have to get the new version of the third party program and import a new type
library and recompile my application. So my application will then work with
the newest version of the COM object but has no back compatibility with the
old versions of the COM dll. Is it possible to setup a switch to let my
clients select the third parry program version they are using and then have
my program use the correct type library based on their selection? Is there
any way to create back compatibility? Can I grab the GUID dynamically so I
don't have to import a new type library?
TCOM_cTC2000 TC;
HRESULT hr = TC.CreateInstance( CLSID_cTC2000 );
if( SUCCEEDED(hr) ){
........
}else{
ShowMessage("Could Not Create a Link to TC2000");
}
DLL Version 1.0
const GUID IID__cTC2000 = {0x8986FD1A, 0x607F, 0x48C8,{ 0x8F, 0x93,
0xCF,0x7E, 0xA0, 0xCD,0x1A, 0xDC} };
const GUID IID__cTC2005 = {0x861BAF02, 0x9B97, 0x405E,{ 0xB9, 0x85,
0x40,0x35, 0x73, 0xB1,0x79, 0x79} };
DLL Version 2.0
const GUID IID__cTC2000 = {0x5E1EF53E, 0x8F0A, 0x4248,{ 0xB1, 0x0D,
0x0B,0xCF, 0x8A, 0x58,0xCF, 0x7C} };
const GUID IID__cTC2005 = {0x131985F3, 0x654C, 0x4B95,{ 0x8A, 0x62,
0x85,0x13, 0x6D, 0xD1,0xB5, 0xAD} };
DLL Version 3.0
const GUID IID__cTC2000 = {0xD6D697E5, 0xAF29, 0x4436,{ 0xA3, 0x55,
0x18,0xCF, 0xCF, 0x91,0x3B, 0x41} };
const GUID IID__cTC2005 = {0x7E40984F, 0x4FA0, 0x4DB3,{ 0x93, 0xD5,
0x82,0x09, 0x3C, 0xB9,0x0D, 0xCF} };
Thanks
Larry Johnson |
|
| Back to top |
|
 |
Remy Lebeau (TeamB)
Guest
|
| Posted: Fri Mar 09, 2007 3:48 am Post subject: Re: COM Upgrade and back compatibility |
|
|
"LarryJ" <LarryJ33 (AT) austin (DOT) rr.com> wrote in message
news:45f074a1$1 (AT) newsgroups (DOT) borland.com...
| Quote: | The third party program seems to upgrade about twice a year
and they release a new version of COM dll. Every time this
happens my application will no longer create the COM object
because the GUID IID__ in the dll's type library change.
|
Then that company is not following the rules of COM correctly. They
are not supposed to be changing their existing interfaces and GUIDs at
all from version to version, for exactly the reason of backwards
compatibility.
| Quote: | Is it possible to setup a switch to let my clients select the third
parry program version they are using and then have my program
use the correct type library based on their selection?
|
No. What you can do, however, is dynamically look up the current
CLSID and IID at runtime instead of using the static values at
compile-time. You can either look up the values manually in the
Registry, or better is to simply create the object by ProgID instead
of by IID and let COM do the lookup for you.
| Quote: | Is there any way to create back compatibility?
|
As long as the interfaces are not changing, only the IIDs, then you
could alternatively simply start with the latest IID, attempt to
create, then create the next oldest if it fails, and the next oldest
if that fails, and so on until you find a match that works.
Otherwise, I suggest you contact the company and ask them to stop
violating the COM rules in the first place.
| Quote: | Can I grab the GUID dynamically so I don't have to import
a new type library?
|
That is what ProgIDs are for.
Gambit |
|
| Back to top |
|
|
Alan Bellingham
Guest
|
| Posted: Fri Mar 09, 2007 4:16 am Post subject: Re: COM Upgrade and back compatibility |
|
|
"Remy Lebeau \(TeamB\)" <no.spam (AT) no (DOT) spam.com> wrote:
| Quote: | Then that company is not following the rules of COM correctly. They
are not supposed to be changing their existing interfaces and GUIDs at
all from version to version, for exactly the reason of backwards
compatibility.
|
Hmm, I'd possibly maintain that they *are* following the COM rules. If
they change the interfaces, then they *should* change the GUIDs.
Of course, by doing so, they are stating that there is no actual
relationship between the old and new components, which is not exactly
helpful to their clients, even if honest.
IMAO, what they should be doing, is (a) extending existing interfaces
(always making sure that all existing methods remain 100% backward
compatible), and (b) providing a mechanism for the client to know which
version of the interface is being supplied (so it doesn't use something
which doesn't yet exist).
Oh, and they should spend more time up front designing the thing.
Alan Bellingham
--
Team Thai Kingdom
<url:http://www.borland.com/newsgroups/> Borland newsgroup descriptions
<url:http://www.borland.com/newsgroups/netiquette.html> netiquette |
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Fri Mar 09, 2007 4:47 am Post subject: Re: COM Upgrade and back compatibility |
|
|
"Alan Bellingham" <alanb (AT) episys (DOT) com> wrote in message
news:bh21v211fp0td1d7nbn2s0ec8t0mfu6k1h (AT) 4ax (DOT) com...
| Quote: | Hmm, I'd possibly maintain that they *are* following the COM rules.
|
No, they are not. The IIDs are changing each time, but the interface
names are not. That is a violation of the rules.
| Quote: | If they change the interfaces, then they *should* change the GUIDs.
|
But they are not changing the interface names (_cTC2000 and _cT2005
exist in all three versions with different IIDs), so the IIDs have to
stay the same as well. Also, they should not be changing the
interfaces themselves, either. If they are, then that is also
violating the rules. Once an interface has been published, it cannot
be changed. Quoted from MSDN:
Interface Design Rules
http://msdn2.microsoft.com/en-us/library/ms692709.aspx
the following rules apply to all interfaces implemented on a COM
object:
- They must have a unique interface identifier (IID).
- They must be immutable. Once they are created and published,
no part of their definition may change.
So, an interface has to remain unchanged for the rest of its life, so
old clients are not broken. Any new functionality being added has to
be exposed as a completely new object, or at least as a new interface
that an existing object implements so that newer clients can query it
when needed. This is core feature of COM and should not be overlooked
lightly by any COM author.
| Quote: | IMAO, what they should be doing
|
Please read the COM rules at MSDN. They are very clear about the
requirements.
| Quote: | (a) extending existing interfaces (always making sure that
all existing methods remain 100% backward compatible)
|
To extend an existing interface, all they have to do is define a new
interface (with a new IID) that derives from the old interface. That
way, the old interface remains intact and continues using the old IID,
and the new interface inherits all of the old functionality and has
new functionality to offer. Clients can then choose which interface
to work with without breaking when new versions are released.
| Quote: | (b) providing a mechanism for the client to know which version of
the interface is being supplied (so it doesn't use something which
doesn't yet exist).
|
That is not how COM works. This is exactly the type of scenerio that
QueryInterface() was designed for. If a client wants to use a
particular feature, it creates an instance of the object and then
queries it for the appropriate interface that exposes the desired
feature. If the feature is not available, then QueryInterface()
reports E_NOINTERFACE and the client can move on to other things. If
the feature is available, then QueryInterface() reports S_OK, returns
a pointer to the requested interface, and the client can use the
feature as needed. There is no versioning present in that process,
and it is backwards compatible.
| Quote: | Oh, and they should spend more time up front designing the thing.
|
Nobody can design the perfect object on their first (or even their
hundredth) attempt. There is nothing wrong with releasing new
versions. They just need to expose it properly and stop changing
things they shouldn't be changing to break old clients.
Gambit |
|
| Back to top |
|
|
Alan Bellingham
Guest
|
| Posted: Fri Mar 09, 2007 5:18 am Post subject: Re: COM Upgrade and back compatibility |
|
|
"Remy Lebeau \(TeamB\)" <no.spam (AT) no (DOT) spam.com> wrote:
| Quote: | No, they are not. The IIDs are changing each time, but the interface
names are not. That is a violation of the rules.
|
Hmm, I thought the IIDs were what mattered, so changing the IIDs when
the interfaces changed (in an incompatible way) was what was necessary.
It would seem that the use of names at all completely obviates the whole
point of GUIDs - if you don't have a way for names to be guaranteed
unique, and if it matters that names aren't unique, then why provide a
mechanism that *does* provide guaranteed unique identifiers?
| Quote: | Interface Design Rules
http://msdn2.microsoft.com/en-us/library/ms692709.aspx
the following rules apply to all interfaces implemented on a COM
object:
- They must have a unique interface identifier (IID).
- They must be immutable. Once they are created and published,
no part of their definition may change.
|
Looks like the rules have been made stricter. What I remember (from a
long time ago) was what I said - no changes may be made that would break
code using a previous definition. No existing methods could be removed,
no parameters on those methods could be changed - once something was in
an interface, it was immutable. *But* an interface could be *extended*.
| Quote: | Please read the COM rules at MSDN. They are very clear about the
requirements.
|
Not very clear. Or rather, not very clear now that the rules are
different from what I remember. (I now see what Verity Stob's rant was
about. I've never seen her rant before.)
| Quote: | Nobody can design the perfect object on their first (or even their
hundredth) attempt. There is nothing wrong with releasing new
versions. They just need to expose it properly and stop changing
things they shouldn't be changing to break old clients.
|
I did actually notice recently a COM interface that followed the rules
you mention, though, and I was wondering quite why. It was notable
inasmuch as it's the *only* time I've ever noticed those rules being
followed.
Alan Bellingham
--
Team Thai Kingdom
<url:http://www.borland.com/newsgroups/> Borland newsgroup descriptions
<url:http://www.borland.com/newsgroups/netiquette.html> netiquette |
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Fri Mar 09, 2007 6:03 am Post subject: Re: COM Upgrade and back compatibility |
|
|
"Alan Bellingham" <alanb (AT) episys (DOT) com> wrote in message
news:rc51v2heo163mo7br11ubgbvnr8bukvg97 (AT) 4ax (DOT) com...
| Quote: | Hmm, I thought the IIDs were what mattered, so changing the IIDs
when the interfaces changed (in an incompatible way) was what
was necessary.
|
If the interface definition is changed (which in itself is a
violation), then the IID must ben changed as well. The rules do state
as much.
| Quote: | It would seem that the use of names at all completely obviates the
whole point of GUIDs - if you don't have a way for names to be
guaranteed unique, and if it matters that names aren't unique, then
why provide a mechanism that *does* provide guaranteed unique
identifiers?
|
The code still has to use the names when being compiled. If you have
older code compiled to use a particularly named interface, and that
interface changes in a newer version but keeps the old name, then it
won't match the old definition. Any older code that still uses that
named interface will not work properly when run with the new version,
regardless of whether the IID changes or not. Not everything in COM
is based on IIDs alone. You can have methods return interface
pointers without using IIDs at all.
| Quote: | Looks like the rules have been made stricter.
|
These rules have always been in place.
| Quote: | What I remember (from a long time ago) was what I said - no
changes may be made that would break code using a previous
definition.
|
Which is exactly what is happening now.
| Quote: | No existing methods could be removed, no parameters on those
methods could be changed - once something was in an interface,
it was immutable.
|
Exactly. That is still the case.
| Quote: | *But* an interface could be *extended*.
|
That is a completely different issue. You are not allowed to change
an interface - period. To extend an interface is to expose new
interfaces via QueryInterface() to implement the new functionality.
That has always been the case. That does not mean adding new methods
to an existing interface, which would change the structure of its
vtable.
| Quote: | I did actually notice recently a COM interface that followed the
rules
you mention, though, and I was wondering quite why. It was notable
inasmuch as it's the *only* time I've ever noticed those rules being
followed.
|
Most every commercial COM object I have ever used has followed the
rules. And I make sure that my own COM objects follow them as well.
I have never had any compatibility problems with any of them when
upgrading their implementing programs.
Gambit |
|
| Back to top |
|
|
Michael Harris
Guest
|
| Posted: Fri Mar 09, 2007 9:10 am Post subject: Re: COM Upgrade and back compatibility |
|
|
I realize MS is bad about not following their own rules .... for example
where the class name is Microsoft.XMLDOM
the appllication should be looking up CurVer and getting
Microsoft.XMLDOM.1.0
look up that GUID and find it is the same in each version
HKEY_CLASSES_ROOT\Microsoft.XMLDOM
HKEY_CLASSES_ROOT\Microsoft.XMLDOM\CLSID =
{2933BF90-7B36-11d2-B20E-00C04F983E60}
HKEY_CLASSES_ROOT\Microsoft.XMLDOM\CurVer Microsoft.XMLDOM.1.0
HKEY_CLASSES_ROOT\Microsoft.XMLDOM.1.0
HKEY_CLASSES_ROOT\Microsoft.XMLDOM.1.0\CLSID =
{2933BF90-7B36-11d2-B20E-00C04F983E60}
But then the rules can seem to contradict each other.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes
\<Version-Independent ProgID> = <Program>.<Component>
\CLSID = <CLSID>
\CurVer = <ProgID>
Value Entries
< Program>.< Component>
The name of the latest version of the object application.
< CLSID>
The CLSID of the newest installed version of the class.
< ProgID>
The ProgID of the newest installed version of the class.
NOTES:
The version-independent ProgID is stored and maintained solely by
application code. When given the version-independent ProgID, the
CLSIDFromProgID function returns the CLSID of the current version.
--
Michael |
|
| Back to top |
|
|
Remy Lebeau (TeamB)
Guest
|
| Posted: Fri Mar 09, 2007 9:10 am Post subject: Re: COM Upgrade and back compatibility |
|
|
"Michael Harris" <techonos-NO-SPAM-@attbi.com> wrote in message
news:45f0e00e (AT) newsgroups (DOT) borland.com...
| Quote: | I realize MS is bad about not following their own rules ....
for example where the class name is Microsoft.XMLDOM
|
That is a version-independant ProgID. Loading an object using such a
ProgID will always load the latest version that is installed, without
the application having to figure it out beforehand.
| Quote: | the appllication should be looking up CurVer and getting
Microsoft.XMLDOM.1.0 look up that GUID and find
it is the same in each version
|
Of course they are the same. 1.0 is the first version released. If
the CurVer is 1.0, then no other versions have been installed, so both
keys will point to the same physical library. A CLSID identifies the
library that contains the object. However, if newer versions were
installed, then CurVer might point to a completely different library,
while 1.0 is still present and works alongside of the new version.
| Quote: | But then the rules can seem to contradict each other.
|
No, they don't. Microsoft is following its own rules in regards to
versioning its COM libraries. There is a version-dependant ProgID
that points to a specific library version that is installed, and then
there is a version-independant ProgID that points to the latest
library version that is installed. It just happens that your example
is referring to a setup where both ProgIDs refer to the same library,
because there is only one installed. But there can be multiple
versions installed at a time as well. Looking through my Registry, I
see several COM object entries that refer to 3-4 versions that are
installed side by side.
Gambit |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
