Demystification

Back in the old DOS days, every program (executable) contained all the binary code necessary to implement the functionality the exe was supposed to provide. Venice was (and still is) a collection of several executables (modules) and some of them provide portions of identical functionality. The Customer.exe and Sales.exe, e.g. both were able to create a new customer card and therefore they both contained the same binary code.

Windows introduced a new concept: dynamic link libraries. These dll's enabled us to move the common binary code out of the executables into the dynamic link libraries, making the exe's smaller and easier to maintain. The moment an exe is launched, it not only loads its own binary code into memory, but also all the code required from the dll's. So, from now on, Venice remains a collection of (smaller) exe's, but the majority of the binary code resides in dll's.

Question: 'If the programming team of Exact Venice is able to import the functionality of the dll's into their exe's, is a third-party developer able to do the same?'
Answer: 'Yes, but...'

You may well imagine the dll's are not conceived with a third-party developer in mind. They are built by Exact Venice-developers for Exact Venice-developers, who know exactly how to use them. There is no need for 'wrappers' making the usage more user-friendly. Omitting this overhead makes the code faster and more compact. The only drawback is that it is very difficult for non-Exact Venice developers to understand, let alone to use the dll's. For Exact Venice, it would take months, or even years, to document all the classes, members and methods. For you, the third-party developer, it would be a huge effort to understand and learn the documentation, and it would even be harder to use the dll's correctly. Moreover it would also be very dangerous to use the dll's since Exact Venice would have no control over what the third-party programmer does. This is, of course, unacceptable.

A possible solution would be to create an interface-dll that resides between the native Exact Venice dlls and the client application. That dll could consist of wrapper classes and methods making the life of the programmer easier. In addition, Exact Venice would have control over what the client application wants to do and we would be able to provide only the functionalities we want.

But in what language should we create this interface-dll?
C could be an option. C is a very standard language and the different compilers and linkers generate binary compatible code which can be used from within many different other languages like VB, C++ but not VB Script (often used in web applications)! Besides the incompatibility with VB Script, C has the disadvantage that it is not an object oriented language.
So, could we use C++ instead? No, because C++ compilers and linkers all produce different binary code making it almost impossible to use from another language or even another brand of compiler or linker.
Isn't there another solution then?

Yes... COM!

In the early nineties, the concept of the Component Object Model was introduced. It is a way of exposing the inner working of the binary code in a portable, universal way to the outside world using language-independent interfaces. The plus point is that (almost) any language can make use of the dll, as long as it connects to the binary code via the interfaces. Another advantage of interfaces is that modern development tools are able to use 'Intellisense' or auto-completion. These development tools just 'know' all the possible methods and properties the COM-server provides and helps the programmer by showing a list of all possible methods he can use, including parameter lists, data types and help info.

How does it work?
The COM-server defines several objects and methods, contains the binary code to make them work and imports the functionality of other dll's. What's more, it also defines and exposes the interfaces. Therefore, the name of each COM-object and COM-interface is written in the registry and points to the correct COM-dll or COM-exe. When a client application tries to create a COM-object, the language runtime (VB Script) or the compiler looks for the name of the COM-object in the registry and loads the correct dll into memory, enabling the client to use the objects interfaces and their methods.

And this is what the Exact Venice Software Development Kit (SDK) is all about, an 'In process COM server'! It is a server, because it provides functionality to others. It uses the COM technology and it is 'in process'. This means the SDK doesn't do anything on its own, it runs in the address space of the client application. No client application means no SDK. It is a dll, remember.

It doesn’t matter how COM really works (it is quite complex, we won't go into details). However, read on and within a few hours you will be creating objects and using its methods. The Exact Venice SDK is easy, virtually self explaining and opens a whole new world for developers like you, wanting to integrate your applications with Venice.