A published GUID is carved in stone. The GUID for the original SIEVE DLL component was generated on a machine I don’t use anymore, and part of the number came from the network adapter on that machine. I could never generate that GUID on my current development machine no matter how many billions of times I ran GUIDGEN. Yet I’m bound by the immutable laws of COM to keep using that GUID for every version of the component until the mountains crumble to the sea.
The first edition of this book provided EXE and DLL versions of the Sieve component. When I created the components for this version, I had to decide whether to make them compatible with the old versions. The methods and properties of this version are exactly the same, so compatibility would have been possible. Of course, in those days you couldn’t write controls or global libraries in Visual Basic, and you couldn’t compile to native code, so the only candidates for compatibility were the p-code DLL and EXE versions.
Realistically, buyers of the second edition don’t need to run my new servers from the old Sieve client program. But I could do it if I wanted to prove a point. Nothing but common sense keeps me from creating a compatible native code version of my DLL component that would scream with the old version 4 Sieve client. Of course, I’d have to keep both version 4 and version 5 run-time libraries available, but...I didn’t actually try this. If there’s a problem, I don’t want
to know.
If I had wanted a compatible version, I would have had to set binary compatibility and point the compatible file field to the appropriate DLL and EXE components. To avoid overwriting the old versions and getting sharing violations, I would have renamed the old versions to a new extension. CMP is becoming a semi-standard extension for compare versions. I wouldn’t have been able to rename the classes or make any other changes, no matter how small. My new component would have had a different implementation, but for all COM purposes it would have been the same component. The GUIDs for all its interfaces, classes, and type libraries would have been identical, and it would have looked the same (except for a higher version number) in the registry. But of course I ignored all that crap and created completely new components that just happened to have the same methods and properties.
It’s a different situation for the Notify server that will be discussed in Chapter 11. The old version of this server would be just as useful to Visual Basic version 5 applications as it was for version 4 applications (or for C++ applications, for that matter). The only reason to update it is to take advantage of better performance features, but as you’ll learn when you read the details, performance isn’t critical for this particular application. The old version is fast enough.