|
|
|
|
|
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 C-Logic 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 C-Logic-developers for Exact C-Logic-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 C-Logic
developers to understand, let alone to use the dll's. For Exact C-Logic,
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 C-Logic 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 C-Logic-dll's and the client application. That dll
could consist of wrapper classes and methods making the life of the programmer
easier. In addition, Exact C-Logic 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 C-Logic 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 C-Logic SDK is easy, virtually
self explaining and opens a whole new world for developers like you, wanting to
integrate your applications with Venice.
|
|
|
|
|