Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Breaking Binary Compatibility
- Thread starter pankajv
- Start date
The binary compatibility will be broken if the public interface has been changed:
Method removed, property get/let/set removed, enum removed, typedefs removed, arguments/return values changed etc.
In short EVERYTHING that used to be there must still be there and it must be EXACTLY the same as it was before. If only the slightest bit is changed, then your binary compatability has been broken.
Any client referencing a COM server whose bin comp has been broken will have to be recompiled against the new public interface.
Greetings,
Rick
Method removed, property get/let/set removed, enum removed, typedefs removed, arguments/return values changed etc.
In short EVERYTHING that used to be there must still be there and it must be EXACTLY the same as it was before. If only the slightest bit is changed, then your binary compatability has been broken.
Any client referencing a COM server whose bin comp has been broken will have to be recompiled against the new public interface.
Greetings,
Rick
It's OK to add functionality, but you can't take anything away.
This includes adding parameters to existing functions. If you were to insert a new parameter at the start of the list of parameters, then from the compiler's viewpoint you took something away. Add new parameters to the end of the parameters lists. Better yet, write a new function that has the new argument list, and have it call the original one (polymorphism).
Chip H.
This includes adding parameters to existing functions. If you were to insert a new parameter at the start of the list of parameters, then from the compiler's viewpoint you took something away. Add new parameters to the end of the parameters lists. Better yet, write a new function that has the new argument list, and have it call the original one (polymorphism).
Chip H.
- Thread starter
- #5
What about this scenario:
Dll 1 has 10 methods out which 5 methods are used in dll 2 which is referring to dll 1.
One of the methods in dll 1 undergo some changes which will break compatibility, but is not used in dll 2.
Do I need to recompile dll 2 in this scenario?
Dll 1 has 10 methods out which 5 methods are used in dll 2 which is referring to dll 1.
One of the methods in dll 1 undergo some changes which will break compatibility, but is not used in dll 2.
Do I need to recompile dll 2 in this scenario?
SemperFiDownUnda
Instructor
I call the fact that you can add methods to a vb class without breaking compatibility a bug more than anything. As stated before ANY change to the public interface should change the compatibility. The fact that VB allows what it does now is a problem because it means that if you have class X and add method Y the can program Z uses method Y but you install Program Z on machine A with the old Class X then it will work until it hits method Y and dependent on what you have done it might break earlier.
SemperFi -
I suppose if you write software for internal use only, this might seem annoying. But if you write software for sale, then this becomes a very nice thing to have -- if you need to add functionality to a module, you can (carefully!) add it, without requiring a re-compile and re-ship of all COM components that make use of it.
It does, however, require you to have excellent change-control management to avoid DLL hell.
Chip H.
I suppose if you write software for internal use only, this might seem annoying. But if you write software for sale, then this becomes a very nice thing to have -- if you need to add functionality to a module, you can (carefully!) add it, without requiring a re-compile and re-ship of all COM components that make use of it.
It does, however, require you to have excellent change-control management to avoid DLL hell.
Chip H.
The problem is not only whether or not older clients and newer clients will be able to work with the new component. COM is all about interfaces. And once an interface has been published, you should NEVER change anything about it. An interface is like a contract between a COM server and its clients. When a specific interface is supported in a COM server a client should ALWAYS be able to rely on the fact that all methods, typedefs etc. are there. And if you were to add methods to an existing server, you should add a new interface for these methods. This case a client will be able to query for a certain interface and not crash because of missing methods.
Greetings,
Rick
Greetings,
Rick
mattKnight
Programmer
LazyMe
I understand exactly your argument... but for the sake of completeness ( and me!!) can you illustrate how you add a second (or third) interface to a VB COM object.
Thanks
Matt
I understand exactly your argument... but for the sake of completeness ( and me!!) can you illustrate how you add a second (or third) interface to a VB COM object.
Thanks
Matt
Yeah, you got me there (I always program COM in C).
But I think you can try this:
Create an empty class which only holds the public interface, NO implementation. use the implements keyword in your COM object and implement the interface there. I think this should work.
Greetings,
Rick
But I think you can try this:
Create an empty class which only holds the public interface, NO implementation. use the implements keyword in your COM object and implement the interface there. I think this should work.
Greetings,
Rick
There exists an add-in that really can help to keep binary compatibility in most cases no matter you change the public interface.
This add-in can lead you directly into dll-hell that's true. But during the development of an application with many activeXs it can save so much time when you haven't to recompile all again and again... mostly in a certain order...
All the sugestions above are right and would be the better way I think... but sometimes you really have to keep binary compatibility.
The add-in is called Binary Compatibility Add-in (SyncCmp) and can be found on
Be aware that the add-in only works with Windows NT
Schweiger
This add-in can lead you directly into dll-hell that's true. But during the development of an application with many activeXs it can save so much time when you haven't to recompile all again and again... mostly in a certain order...
All the sugestions above are right and would be the better way I think... but sometimes you really have to keep binary compatibility.
The add-in is called Binary Compatibility Add-in (SyncCmp) and can be found on
Be aware that the add-in only works with Windows NT
Schweiger
- Status
Similar threads
- Locked
- Question
- Locked
- Question
