Upcoming Changes 1
Were considering a couple of upcoming changes. These things are a ways out, but I figure the time to bring them up is now. The first one is discussed below, the second will be in another post, that will go up shortly.
We're looking to upgrade to Visual Studio 2005. Along with that means a change from the 7.1 runtime to 8.0. We have a version that builds and runs under 8.0 just fine now. It didn't work straight out of the box the way we hoped, but the changes were fairly small once we understood them. I won't go into it in depth since the details don't effect anything exposed through the SDK. The short version is that Microsoft added some const specifiers in a few places that make sense, but caused the compiler to choke on some non-const operator and casting behavior.
From the perspective of an SDK user, the biggest impact is on distribution. It basically means you'd need to include the 8.0 merge modules instead of, or in addition to, the 7.1 ones. Hopefully this isn't too onerous. If it is, or there is some other terrible consequence that we're unaware, now's the time to let us know.
We're looking to upgrade to Visual Studio 2005. Along with that means a change from the 7.1 runtime to 8.0. We have a version that builds and runs under 8.0 just fine now. It didn't work straight out of the box the way we hoped, but the changes were fairly small once we understood them. I won't go into it in depth since the details don't effect anything exposed through the SDK. The short version is that Microsoft added some const specifiers in a few places that make sense, but caused the compiler to choke on some non-const operator and casting behavior.
From the perspective of an SDK user, the biggest impact is on distribution. It basically means you'd need to include the 8.0 merge modules instead of, or in addition to, the 7.1 ones. Hopefully this isn't too onerous. If it is, or there is some other terrible consequence that we're unaware, now's the time to let us know.
posted by aunomvo at 2:32 PM
2 Comments:
Typically when you develop components for 3rd party developers you want an object that targets the least common denominator in terms of development systems. Considering an update to VS 2005 leaves behind all applications that have been written with previous versions of development systems. Even your current product is difficult to use with Visual Studio 6.0 and now you are proposing moving to VS 2005 from VS.Net 7.X. It is possible that the VS 6.0 code bases will not work at all after you make that transition.
Normally, I would agree with you regarding the use of the lowest common detonator. However, when it comes to the C/C++ runtime there isn't any reverse or forward compatibility to be had. Any mismatch between runtime versions in an app vs. a module it includes can be a problem. It can even be a problem within the same version if there is a mismatch between release/debug or multi-/single-threaded.
Thankfully, for the SDK itself (IDevice and everything behind it), COM shields us from any problems with C/C++ runtime compatibility. As long as the rules of COM are obeyed it shouldn't matter what version of C or even what language is used by either the app using the SDK or the SDK components themselves. The SDK works just fine with Java and VB and so on regardless of the SDK is written in.
The reason the SDK is harder to use with version 6.0 is the absence of support for events. This is a feature of 6.0 runtime, so while unfortunate, it is also outside our control. However, it isn't likely to get any worse because we change the version of C we're using on our end. It is possible to implement support for COM events in 6.0 yourself, but it is non-trivial. On the other hand, without COM events like AudioEnbabledChanged, the SDK is fairly pointless.
The best we can do is provide PlantronicsDeviceEventSink.dll. This dll talks to IDevice but doesn’t create any COM interfaces of its own. That means, if you are using C 6.0, you don’t have to do support for COM events on your own. However, since PlantronicsDeviceEventSink.dll isn’t safely hidden behind a COM interface it is the most likely source of runtime incompatibilities. Thankfully, our testing so far has shown it to work just fine. Mostly because PlantronicsDeviceEventSink.dll doesn’t do anything like memory allocation that is the source of most runtime incompatibility problems.
The only change that you should notice is that the 8.0 runtime merge modules will have to be installed along with the SDK merge module instead of the 7.1 ones. Your 6.0 code base should continue to work just as it always has.
Post a Comment
<< Home