dcsimg
Results 1 to 11 of 11

Thread: Follow-up on Binary Compatibility

  1. #1

    Thread Starter
    Junior Member
    Join Date
    Jun 2018
    Posts
    31

    Follow-up on Binary Compatibility

    I've been able to successfully implement Binary-Compatibility to prevent Class ID changes between object compilations. I reviewed the conditions under which compatibility will fail.

    In summary, as I understand it, binary-compatibility will be maintained between compilations if the public interfaces (properties, functions and subroutines) to an object remain unchanged. Changes would include names of the properties, functions and subroutines, and the number and names of arguments to functions and subroutines.

    The question to the forum; is the summary correct?

    Please advise as to corrections.

    Thanks, Mickey

  2. #2
    Frenzied Member
    Join Date
    Jun 2015
    Posts
    2,038

    Re: Follow-up on Binary Compatibility

    That's correct as far as I know. Unfortunately I think this includes public enumerations too. Although I wonder if there's ways around that.

  3. #3
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    17,450

    Re: Follow-up on Binary Compatibility

    Quote Originally Posted by MickeyXm View Post
    The question to the forum; is the summary correct?
    Yes. If including public UDT (type defs), can't change those either (applies to DLL, OCX). I also believe that changing public enumerations is a restriction. If others chime in and say I'm wrong, then so be it and ignore the last paragraph below.

    In short, need to tweak a public method signature: don't. Instead, create a new public method like Microsoft often does, appending Ex or 2 or something else to the name. Example. Navigate2 in the IWebBrowser class

    If you want to add more items to an enumeration, create a new enumeration with just the new items or copy all the items from a previous enumeration, changing their names slightly, then add the new items.

    Edited: Dex beat me to it, regarding enums
    Last edited by LaVolpe; Jul 9th, 2018 at 09:15 AM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  4. #4

    Thread Starter
    Junior Member
    Join Date
    Jun 2018
    Posts
    31

    Re: Follow-up on Binary Compatibility

    Thanks for all the great input; I'll add enumerations to the list.

    One other thing, if after a compilation, compatibility fails does the IDE create a new Class ID immediately, or does it allow for corrections to be made; if for example, a public element was mistakenly changed?

    Additionally, assuming a new Class ID is created, if the mistake is corrected and compatibility is restored, does the original Class ID come back into effect?
    Last edited by MickeyXm; Jul 9th, 2018 at 09:39 AM.

  5. #5
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    31,784

    Re: Follow-up on Binary Compatibility

    If you do something to break compatibility, you will know when you compile. The compiler will let you know. It will be painfully obvious. And since the compile failed, no new ClassID will have been created.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  6. #6
    Fanatic Member
    Join Date
    Jan 2013
    Posts
    631

    Re: Follow-up on Binary Compatibility

    If a build is going to break Binary compatibility, VB will tell you so before it does so.

    If I recall correctly, it offers you the change to break compatibility, or "downgrade" it to "Project" Compatibility (although I never really got my head around what that one does) or to cancel because, as you say, you may well have done something by mistake.

    As far as I know, there is no way to "recover" the previously used Class ID[s], Interface ID[s] and Type Library ID[s] involved; all being GUIDs, once they're changed, they're changed for good.

    Regards, Phill W.

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    19,082

    Re: Follow-up on Binary Compatibility

    Type libraries have a LIBID and Major & Minor versions that are significant as well.

    Once again I suggest you look at the SyncCmpt IDE add-in and the document that comes with it.

  8. #8

    Thread Starter
    Junior Member
    Join Date
    Jun 2018
    Posts
    31

    Re: Follow-up on Binary Compatibility

    Thanks again for all the great information. I was hoping the compiler, on detecting the binary mismatch would not only flag it, but not create a new binary and hence a new Class ID.

    BTW: If you've had a lot of clutter built up in the Registry of extraneous classes, prior to using binary compatibility, I've found it convenient to temporally rename the project folder, then run a Registry cleaner (I've used GlarySoft, now Glary Utilities with great success). This will remove all the extraneous Class ID's. Then all you need to do is name the project folder back to the original, and recompile the ActiveX, and re-reference the client. Perhaps this is a well known procedure.

  9. #9
    Fanatic Member
    Join Date
    Jan 2013
    Posts
    631

    Re: Follow-up on Binary Compatibility

    > "I was hoping the compiler ... would not only flag it, but not create a new binary and hence a new Class ID."

    That is how it behaves.

    See this posting for a sample of the warning dialog that it displays before breaking everything. (The Poster's issue is different - it's just the image I'm interested in).

    Regards, Phill W.

  10. #10
    New Member
    Join Date
    Sep 2011
    Location
    Lima
    Posts
    1

    Re: Follow-up on Binary Compatibility

    Please Read Before Using

    (C) Copyright 1998 Microsoft Corporation. All Rights Reserved. The Visual Basic SyncCompat.Dll Add-in ("Add-in") accompanying this license is licensed under the same terms and conditions contained in the End User License Agreement (EULA) you acquired with Visual Basic version 6.0. By installing, copying or otherwise using the Add-in, you agree to be bound by all of the terms and conditions of the EULA applying to the “SOFTWARE PRODUCT” as such term is defined in the EULA. The Add-in shall not be deemed part of the “Redistributables” as defined in the EULA. Notwithstanding the foregoing, the Add-in is provided “AS-IS,” without warranty of any kind, and any use of the Add-in and any documentation provided regarding the Add-in is at your own risk. To the maximum extent permitted by applicable law, Microsoft and its suppliers disclaim all warranties and conditions, either express or implied, including, but not limited to, implied warranties and conditions of merchantability, fitness for a particular purpose, title, and non-infringement, with regard to the Add-in.

    Binary Compatibility and the SyncCompat.Dll Add-in

    Binary Compatibility GUID Reversion

    Binary Compatibility as implemented in Visual Basic 5/Visual Basic 6 is a great feature to ensure that new versions of shipping products are fully compatible with older versions. The difficulties in using the feature derives from the fact that Visual Basic makes a shippable executable file every time you compile, even for a temporary build which has no chance of ever shipping. In particular, if you add new methods, properties, constants, or events to your classes with binary compatibility set, then Visual Basic will generate new data for you on every compilation (until you update your compatibility file). This will make your Visual Basic-built component a moving target for other consuming projects which are simultaneously under development. This document contains a description of the problem, as well as introducing a Visual Basic add-in that builds a new compatibility file to stabilize the target.

    GUID Changes
    There are three classes of GUIDs (Globally Unique IDentifiers) which are used in the type library of any COM component. The first is a library identifier (LIBID), which identifies the type library on the system. The second is a class-identifier (CLSID), which is used to create a new object. In Visual Basic 5, setting project compatibility locks the LIBID. In Visual Basic 6, setting project compatibility locks both the LIBID and the CLSIDs. The third type of GUID used in a type library is an interface identifier (IID), which is locked only when selecting binary compatibility.

    An interface (identified by an IID) is an ordered list of function definitions. To indicate that a COM class supports a given interface, it must respond to an interface request (QueryInterface) based on the IID. If the request succeeds, then the returned object reference must support all functions (vtable entries) of the corresponding interface. Visual Basic takes this rule very seriously. If you add a function to your interface, then Visual Basic will not let you use the IID of the original interface to describe the new one. The new class still responds to the original IID, making it a binary replacement for the original component. However, compilation against the new IID is required to call any new functions.

    Based on this information, lets look briefly at the steps taken by Visual Basic to ensure compatibility against a base interface as defined in a binary compatibility file.
    1. Make sure all functions (properties and methods) as defined in the base interface are still defined with the same definition in the new class. Layout the class such that the original order is maintained.
    2. If a new public function has been added to the class, then generate a new IID and add the function to the end of the interface.
    3. Make sure the new class responds to a request for the old IID, and modify the interface key for the original IID in the registry such that it simply forwards all requests to the new IID.
    4. Repeat 1-3 whenever you build.

    Step 4 is what gets you in the most trouble. The first problem is bloat: as you add functions to your interface, the number of IIDs which need tracking in the runtime object and the registry also grow. When you ship version 2 of your Visual Basic component, you can easily end up shipping baggage for multiple interim interface changes which existed only for a short period of time on development machines. The second problem is caused by trying to avoid bloat: if your class has public functions which aren't in the compatibility file, then the Visual Basic compiler generates a new IID, without caching the original new one, for every compilation. Therefore, the following steps fail:
    1. Build a Visual Basic component against a binary compatibility file, adding a method to the original interface. Note that Visual Basic gives no warning since binary compatibility is not broken. The minor version of the type library is automatically updated, and a new IID is generated for the new interface.
    2. Compile a client against the component.
    3. Edit or reopen the project in 1 and recompile against the original binary compatibility file.
    4. Run the client. Now no code written against the component built in 1 will execute because the IID which it was compiled against in 2 was replaced in 3. This is particularly bad for clients written in C++, where and interface change updates header files and forces a major rebuild.

    The static IID approach
    The automatic Visual Basic IID handling contrasts sharply with the interface maintenance generally applied when programming COM objects in C++. When an interface change is made in a multi-developer C++ project, the developer generally sends out e-mail saying something like "When you update foo.idl, you must also update foo.cpp and callfoo.cpp”. The implication is that the old foo.cpp won't compile against the new foo.idl, and code compiled against the old callfoo.cpp will crash when calling a new implementation of the interface. You can actually remove or modify functions from the interface using this approach. If compared to modify existing interface functions, adding new functions to the end of the interface is even less painful. Only code that uses the new functions needs to be updated and recompiled. All existing code and executables that don’t use the new functions do not need to be modified. Throughout this process, IIDs are never changed.

    This static IID approach does not have the built-in interface safety of Visual Basic's binary compatibility mechanism. If you have a new client that calls a new function on a machine where the old client is installed, then you're code will crash on the function call. However, this crash is easily avoided by versioning your components and using proper installation procedures. In other words, when maintaining the same IIDs, you must rely on file version compatibility as opposed to binary interface compatibility to ensure that your components work well together.

    Static IIDs in Visual Basic
    For components that are under serious flux during an initial or version update development cycle, the static IID approach causes less IID changes, full project rebuilds, unanticipated type library version changes, and cached IID baggage. The goal is to stop your Visual Basic generated IIDs from updating when you extend or modify your interfaces.

    Using the SyncCompat.Dll Add-in
    The SyncCompat.Dll add-in (provided in Visual Basic 5 and Visual Basic 6 versions) will rebuild your compatibility file with updated interfaces and static IIDs. NOTE This will not work on a machine that contains both versions of the product.

    To use this add-in:
    1. Using Windows Explorer copy the SyncCompat.dll file from VB98\VBWebSamples into the VB98\Wizards folder. Click the Start, Run and type in RegSvr32. Click on the copy of the SyncCompat.dll file in Windows Explorer in the VB98\Wizards folder and drag it to the Run dialog. Click the OK button.
    2. Start Visual Basic 6.0. NOTE Your development machine must be running under Windows NT.
    3. In the Visual Basic design environment, choose Add-Ins/Add-In Manager and load Rebuild Compatibility File (NT Only, VB6).
    4. Make sure Version Compatibility in the Project/Properties/Component tab is set to Binary Compatibility.
    5. Build your executable file. If you get compatibility error dialogs, choose Break Compatibility and Continue.
    6. Make sure your project is saved.
    7. Choose Add-Ins/Rebuild Binary Compatible File (the menu bitmap indicates a sad GUID and a happy GUID). NOTE This will not work under Win95/98.
    8. If the add-in prompts you for the version of the new compatibility file, then choose the desired version. The suggested version is taken from the compatibility file. You can enter any major.minor version you like. See Precautions below for further comments on versioning.
    9. If the LIBID is currently different than in the compatibility file, then the add-in will prompt you for the LIBID. The suggested LIBID is taken from the compatibility file. You can also specify a new LIBID at this time.
    10. If the file is updated successfully, then you will get a message indicating the name of your new binary compatible file. If your old binary compatible file is original.cmp, then your new compatibility file will be original.cmp1 (or the first available number). The original compatibility file is unchanged, allowing you to keep a running history of your compatibility changes.

    At this point, your compatibility file has the same IIDs as the original file, but the current interface information from the last build of your executable.

    Warning
    Binary Compatibility and type library versioning is an important feature. Overriding it arbitrarily by rebuilding the compatibility file will get you into trouble if you are not very careful with the distribution of your components. This is especially dangerous if you're using DCOM components, where the interface definitions on the client and the server must be in sync. Also, if you add classes, interfaces, event interfaces (you define an event on a class which had no events previously), public enums in public class modules, and public user-defined types in public class modules, then the internal ordering of your type library may also change. In this latter case, even if you keep the same GUIDs, you must allow the minor version of your type library to increment if the original component has already been released.

    Implementation Details
    SyncCompat.Dll takes the following steps to rebuild the compatibility file:
    1. Create a temporary type library which looks exactly like the library in your current built executable file, but has the GUIDs of the compatible server. GUIDs are linked based on class and interface name.
    2. Make a temporary copy of the current binary compatible file. This file has cached IID information which must be maintained in the new compatibility file.
    3. Replace the TYPELIB resource in the temporary compatibility file with the temporary type library.
    4. Rebuild the executable against the temporary compatibility file.
    5. Copy the built executable as the new compatibility file and clean up temporary files.



    NOTE
    ZipPassword: vbforums.com

    -Attachment removed by moderator-
    Last edited by dday9; Jul 23rd, 2018 at 09:44 AM.

  11. #11
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    31,784

    Re: Follow-up on Binary Compatibility

    Albertomi - your post has been reported as it violates the rules of the site about uploading compiled binaries. We've been burned too many times by that. If you have something to share, that's great, but you'll need to post the source files so that people can inspect the code for themselves. Currently all that is in the zip file is a text file and the compiled dll, so none of us have any way of verifying it. It's not that we don't trust you, but we don't trust you. Like I said, we've been burned before and aren't willing to take that chance again.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width