size : 5524 uploaded_on : Mon May 17 00:00:00 1999 modified_on : Wed Dec 8 14:03:40 1999 title : Technical problems for multi language programming org_filename : Multi.txt author : Unknown authoremail : description : Problems to be solved, when using modules in different programming languages keywords : tested : not tested yet submitted_by : The CKB Crew submitted_by_email : ckb@netalive.org uploaded_by : nobody modified_by : nobody owner : nobody lang : plain file-type : text/plain category : delphi-migration __END_OF_HEADER__ Technical problems in multi-language programming. In this article multi-language programming means the usage of different programming languages in one project and not writing a program to provide an interface in different languages (internatialization). Modules in all prgramming languages are converted into code for a real or emulated processor, so theoretically it is possible to mix modules written in any programming language, but the efford needed varies. Since each programming languages needs it own compiler, we can assume that the modules are precompiled object modules generated by different programming environments Rule 1: Precompiled modules must be compiled for the same processor. Example: you can't mix code for an Intel (x86) with code for an Alpha processor even if both modules are targeted for Windows NT and written in the same prgramming language. The first problem is the programming environment, which is used for building the project. Rule 2: The precompiled modules must be compatible with the programming environment, used to build the final project. This is the main obstacle for Turbo Pascal/Delphi programmers. The format for precompiled building blocks is propriatary and changes from version to version of the compiler. But both environents also have (rudimentary) support for the .OBJ format. For 32 Bit versions Borland uses another format than Microsoft, the versions of the 16 Bit versions (DOS) have been compatible. In 16-Bit projects you use the $L compiler switch to manually link object code into a Pascal Unit. In 32-Bit Project you can change the project environment to use the *.OBJ format instead of the *.DCU format. The next problem are unsatisfied externals. Rule 3: Each module referenced by the modules to be mixed must also be converted. If the module uses a library routine of any kind, either delivered by the Vendor of the original programming environment or by third party vendors, the reference library mut also be converted. This problem is the knock out criteria for a lot of modules. In an extreme case you must convert or simulate the complete library set of one language in the other. If you look at programming environments which state that they directly can use modules written in another language (in most cases Visual C++) you will realize that the programming environment has been written in that language. The Borland C++ environment uses the VCL classes of Delphi and thus provides language extensions to make C++ classes compatible with Object Pascal classes, and thus allows the usage of Delphi components in C++ programs. But the support for the opposite direction is missing. Rule 4: In the Windows environment you can minimize the problem by changeing the design. Use DLLs or Interprocess Communication to avoid the pitfalls of mixing the modules directly. When you want to mix 16-Bit and 32-Bit modules in one project, the Interprocess comunication approach is the only way to go, since Windows NT doesn't support the usage of thunking. Thunking is only available in Windows 9x, since the whole operating system is basicly a 32-Bit to 16-Bit thunk itself. You just have to follow the calling chain of some APIs. The real work is done in the 16-Bit version. By providing a wrapper DLL the problem of mixing the different languages is reduced to the problem of converting the procedure headers, a problem which has to be solved anyway. Rule 5: You can only use compatible data type in a multi language environment. Compatible not only means that both languages contains a type for an used variable but also that they use the same way of transferring it. * Integer Values The standard integer types ( 8 Bit, 16 Bit, 32-Bit ) are harmless. * Floating point values The floating point types (incl. Comp, alias large integer, alias currency ) have the same pitfall. The way of returning them as a function result is different in a lot of environments, especially Delphi and Visual C++. Thus floating type results should be converted into variable parameters. * Strings Strings produces much more problems. The first one is the way to define the length of the current version. Pascal strings start with the length, while C strings are delimited by the first character containing an Hex 0 value. The next one is the need to define the maximal length of the string buffer. The most common way is the usage of a memory manager. The three most used manages are: The Visual Basic memory manager: This is the mangager used in VBX modules and Basic programms. The Delphi memory manger: This manager manages the long Strings in 32-Bit Delphi versions. The Windows memory mangager: This is the manager used in OCX modules. The three ways to transfer strings between modules in different languages are: 1. Character array of a fixed size. 2. Pointer to a variable size array plus an additional parameter containing the size of the buffer. 3. The usage of the Windows memory manager, thus the usage of OLE-Strings. * Structures. The main problem is to assure that each meber of the structure starts at the offset expected by the module in the other language. Each programming environment has its own way of determing the offset of a structure member. If the environments don't have a compatible way to define the boundery value (packed, multiple of two, multiple of four ... ) dummy members are needed to provide expected gaps.