Suggestions for using Delphi to make DLL multiplexed files

There are some occasions in the company where DLLs need to be made, because they are familiar, convenient and simple, most of them are made using Delphi. Now give some personal suggestions on this topic.

Try to use standard DLL interfaces. It means that the passed parameter type and function return type cannot be unique to Delphi, such as string (AnsiString), as well as dynamic arrays and composite types (such as records) containing these types of members, nor can they contain data members of these types of members. Object type to avoid possible errors. If you use string type or dynamic array type and the caller is not a Delphi program, you will basically report an error. An error may also occur if the caller is Delphi but the caller or the callee is not in the first containing unit of the project file, which is not ShareMem.

If the caller is a Delphi application, you may be able to use objects that do not contain data members of the prohibited type (string, dynamic array) as parameters or return values, but should also be avoided as much as possible.

If the caller and the called party are both Delphi programs and need to use string or dynamic array as parameters, the first inclusion unit of the project file between the two parties must be ShareMem. (The C++Builder program may be the same, but it has not been tested.)

If the caller is not a Delphi program, string, dynamic array, compound data types and class instances containing string or dynamic arrays cannot be used as parameters or return values.

Therefore, in order to improve the multiplexing range of DLLs and avoid possible errors, the standard WIN32 API standard parameter type should be used. Previously, using string variables, PChar(s) conversion can be used. Dynamic arrays are converted to pointer type (@array[0]) and add the length of the array.

If the caller and the called party are both Delphi programs and do not want to perform the above conversion for the convenience of writing, it is recommended to use the form of a runtime package. Runtime packages can ensure the correct release of dynamically allocated data. This way, because of its extension (.bpl), it shows that the file is limited to Delphi/C++Builder (unlike DLL).

Secondly, try to avoid using overload functions/processes as much as possible. If there are multiple methods in the same operation, you can make the function/process names slightly different, similar to the functions and methods such as FormatXXXX, CreateXXXXX and other functions and methods in Delphi, such as CreateByDefaultFile and CreateDefault.

Finally, as a provider of DLLs, you should provide direct programming interface files such as .pas or .dcu in Delphi (preferably .pas, as there can be comments), .h and .lib in C and C++. Instead of letting users create it themselves. This is particularly important if you have to have an overload function/process. In addition, as a Delphi application, the .pas file provided can be connected in advance (using external to specify the output function in the DLL) or later (using LoadLibrary and GetPRocAddress). The DLL provider provides programming interface files, which not only shows that it is Formal (or HiQoS), and guaranteed.