Not a very nice limitation or workaround. But I do understand your motivations.
So far we have the following problems caused by your software protection:
- Unable to debug applications linked with the SD2.dll.
- Unable to run applications linked with the SD2.dll in a remote desktop session.
- Unable to use the SD2.dll in a Java JNI library.
We are implementing a barcode decode service to overcome these limitations. Communication with this server and the our other software is using shared memory. We are hoping that the cpu/memory overhead is not going to be to big.
We are currently evaluating barcode software from three different suppliers. Your software is the only one that are giving us such problems. The others are the barcode decoding software from Matrox and Stemmer Imaging. These suppliers are also using USB dongles for software protection. The choice of software is going to be based on barcode decoding performance and cpu/memory consumption.