Question on Binary compatibility mode to step thru code?

[Giscardo]

I asked someone at work to let me have a copy of the source code for a software engine we use. The reason being I want to troubleshoot why some certain inputs to the engine are causing a crash. He responded with this weird email (I'm used to programming in C/C++/Java/C#, smaller type projects, mostly school projects so far so it seems weird to me), which doesn't really make much sense to me:

<he gave me a link to the .dll file for the engine>

> set binary compatibility, and just hit play.
> then any exe/project you run that references that dll will jump to the
> appropriate line number
> when an error occurs.

the software was written in vb (i am pretty sure in MS Vis studio)

THis response doesn't make sense to me, how is getting the .dll going to help me troubleshoot the codepath of certain inputs? What is binary compatibility? Wouldn't you have to compile the .dll with binary compatibility to begin with, or can I recompile a .dll? Is he assuming that I know the interfaces (function names, parameters and return types) in the .dll, and can reference them from some code I am supposedly writing? We work in different departments so there could be some assumptions of common knowledge going on here. He went on vacation and I really would like to get this done soon, can't wait for him to get back. Someone please give me a clue, this seems like a longshot.

 

[oog]

Your co-worker's explanation does make sense. I'm guessing that the component is a COM component written in VB 6. When you run a program that uses the component, what happens is that you reach the part where the component needs to be instantiated. The code that does the instantiation uses a Globally Unique Identifier (GUID) to identify the component. Based on the GUID, COM looks up in the registry the name of the DLL (or EXE) that implements the component and uses code in the DLL (or EXE) to instantiate it.

When you open up the VB project and hit play, the VB IDE will temporarily add data to the registry to intercept the COM lookup of the GUID so that the component that is instantiated will be the one running in the IDE, rather than one running in the DLL. I know this is a different model from how debugging in C++/Java works (where the debugging information is embedded directly in the DLL).

Anyway, the last piece of the puzzle is why you need to turn on binary compatibility. All components, as I said, have a GUID to uniquely identify them. If you change the signature of any of the public functions of a COM component, you are supposed to generate a new GUID. Microsoft went a little overboard with this -- by default, they generate a new GUID every time you run or recompile a component in VB. If you want to reuse an existing component's GUID (which is necessary for the interception I described earlier), you need to tell VB to be "binary compatible" with the component in the DLL.

Let me know if this wasn't clear.