C++ - A scenario - any recommendations please?
-
Hi there, I had a very tough scenario, and seriously i had no idea how to solve this. It will be long as i tried to explain in detail. I need a good solution based on those who coded c++ and writes dlls. Before this: There is a dll called by UtilityA.dll. It was called by a UtilityMain SDK. In UtilityA.dll, it actually calls a 3rd party dll called 3rdPartyv1.dll. The main reason of UtilityA.dll existence is to write a wrapper and simplies stuff. So the UtilityMain SDK can call it easier. No idea why it is done like that. Now: We had released a new hardware. The new hardwares uses the new 3rdPartyv2.dll. There are 19 functions inside the 3rdPartyv2.dll if compare to 3rdPartyv1.dll which only contains 15 functions. But the names are roughly the same, but in some functions, there are additional paremeters and return different data types. I need to write a wrapper for the 3rdPartyv2.dll that will called the new UtilityB.dll instead of UtilityA.dll with additional new 4 functions (19 - 15). So my SDK can called my UtilityB.dll. The problems now: 1) We had many SDKs, around 20 versions. On different companies and countries. 2) If we use a different wrappers name, we had to recompile the SDK. Which is kind of tough! 3) If we stick the same called UtilityA.dll, but just say in future, the hardware already more advanced and a different modal. We can't just use UtilityA.dll again and again. Real example: Reader - Utility435.dll which calls the MXM435.dll which MXM435 is a reader device. Now there is a new model called MXM467 reader. If i use back the same Utility435.dll, which is misleading, does not represent anything. No choice the previous coders, never think of this problem. 4) There are many applications already being developed in VB6. We can't ask all the clients to recompile their apps because the SDK had been modified. Very very tough deployment. How can we solve this scenario? Now is between the wrapper and the SDK. Is there anyway to write a plugin to the SDK. As what i know from C#, you can write a library that exposes some interfaces, so you can write a plugin to it. But now the SDK had existed, and it was badly done i suppose. I not even sure it can have plugin enabled. I was hoping to write something, that can add on to the SDK on run time or dynamically without recompiling any existing codes, and won't affect any parties. But of course I had to change the new 3rdPartyv2.dll and the new wrapper. Just don't want to recompile the SDK. 3rdPartyv1.dll and 3rdPartyv2.dl
-
Hi there, I had a very tough scenario, and seriously i had no idea how to solve this. It will be long as i tried to explain in detail. I need a good solution based on those who coded c++ and writes dlls. Before this: There is a dll called by UtilityA.dll. It was called by a UtilityMain SDK. In UtilityA.dll, it actually calls a 3rd party dll called 3rdPartyv1.dll. The main reason of UtilityA.dll existence is to write a wrapper and simplies stuff. So the UtilityMain SDK can call it easier. No idea why it is done like that. Now: We had released a new hardware. The new hardwares uses the new 3rdPartyv2.dll. There are 19 functions inside the 3rdPartyv2.dll if compare to 3rdPartyv1.dll which only contains 15 functions. But the names are roughly the same, but in some functions, there are additional paremeters and return different data types. I need to write a wrapper for the 3rdPartyv2.dll that will called the new UtilityB.dll instead of UtilityA.dll with additional new 4 functions (19 - 15). So my SDK can called my UtilityB.dll. The problems now: 1) We had many SDKs, around 20 versions. On different companies and countries. 2) If we use a different wrappers name, we had to recompile the SDK. Which is kind of tough! 3) If we stick the same called UtilityA.dll, but just say in future, the hardware already more advanced and a different modal. We can't just use UtilityA.dll again and again. Real example: Reader - Utility435.dll which calls the MXM435.dll which MXM435 is a reader device. Now there is a new model called MXM467 reader. If i use back the same Utility435.dll, which is misleading, does not represent anything. No choice the previous coders, never think of this problem. 4) There are many applications already being developed in VB6. We can't ask all the clients to recompile their apps because the SDK had been modified. Very very tough deployment. How can we solve this scenario? Now is between the wrapper and the SDK. Is there anyway to write a plugin to the SDK. As what i know from C#, you can write a library that exposes some interfaces, so you can write a plugin to it. But now the SDK had existed, and it was badly done i suppose. I not even sure it can have plugin enabled. I was hoping to write something, that can add on to the SDK on run time or dynamically without recompiling any existing codes, and won't affect any parties. But of course I had to change the new 3rdPartyv2.dll and the new wrapper. Just don't want to recompile the SDK. 3rdPartyv1.dll and 3rdPartyv2.dl
Well, I must admit this scheme looks quite silly. However to find reasonable solution I think we need to clarify something. You said that you don't want to change SDK, but how do you expect users to access new function in 3rdPatry.dll? Unless of course those functions for Utility.dll use only and if this is a case then I don't see problem anymore.