DLL file (the compiled library itself), an. Suppose you are given a DLL built in C or C++. In Delphi programming it is common to use DLLs written in C or C++. I won't explain the C++ code in detail (it's basically C code, anyway) but will focus instead on the calls between the Delphi application and the C++ DLL. Once the function is properly defined, you can call it in the code of your Delphi application just like any other function.Īs an example, I've written a very simple DLL in C++, with some trivial functions, just to show you how to call DLLs from a Delphi application. To call a function that resides in a DLL, you can provide its declaration and external definition, as shown above, or you can merge the two in a single declaration. The name directive is not necessary if the Pascal function (or procedure) name matches the DLL function name (which is case-sensitive). The other element is the name of the DLL function itself. DLL extension, or the program will not work under Windows 2000 (even though it will work under Windows 9x). The external definition of these functions refers to the name of the DLL they use. This helps keep the Delphi and C++ identifiers in synch, so that code can be shared between the two languages. This symbol prevents the corresponding Pascal symbol from appearing in the C++ translated header file. This has little to do with Delphi itself it applies to C++Builder. In Windows.PAS there is a heavy use of the directive. Then, in the implementation portion, instead of providing each function's code, the unit refers to the external definition in a DLL:įunction PlayMetaFile external gdi32 name 'PlayMetaFile' function PaintRgn external gdi32 name 'PaintRgn' function PolyPolygon external gdi32 name 'PolyPolygon' function PtInRegion external gdi32 name 'PtInRegion' Functions are declared in the interface portion of the unit, as shown here:įunction PlayMetaFile(DC: HDC MF: HMETAFILE): BOOL stdcall function PaintRgn(DC: HDC RGN: HRGN): BOOL stdcall function PolyPolygon(DC: HDC var Points var nPoints p4: Integer): BOOL stdcall įunction PtInRegion(RGN: HRGN p2, p3: Integer): BOOL stdcall As you might remember, all the API functions are declared in the system Windows unit. The abusive use of delayed can damage the speed performance of the program (as perceived by the end user).We have already used existing DLLs in examples in this book, when calling Windows API functions. Using the delayed directive enables you to check, at run time, whether the Operating System supports the required APIs only then you can call the imported routines.Īnother potential use for the delayed directive is related to the memory footprint of the application: decorating the less probably to be used routines, as delayed may decrease the memory footprint of the application, because the libraries are loaded only when required. If the routine is not found in the loaded library, or the library does not exist, the Operating System halts the execution of the application. Statically imported routines require that the operating system find and load the library when the application is started. The delayed directive is useful in the case where the imported routines do not exist on the target operating system on which the application is run. The delayed directive ensures that somelibrary.dll is not statically linked to the application, but rather dynamically. In the example above, the GetSomething routine is imported from the somelibrary.dll library. For example:įunction GetSomething : Integer external 'somelibrary.dll' delayed The simplest way to import a procedure or function is to declare it using the external directive. Whichever method you use, the routines are not linked to your application until run time.ĭelphi does not support importing variables from DLLs or shared objects. This can be done in two ways: by declaring an external procedure or function, or by direct calls to the operating system. If you want to avoid validation, use LoadLibrary and GetProcAddress as described in the Dynamic Loading section.īefore you can call routines defined in DLL or shared object, you must import them. On other platforms, such as Linux, to resolve an external reference, you have to link to a shared object. It means that the library does not need to be present when you compile your program. On Windows and macOS, there is no compile-time validation of attempts to import a routine. These routines are usually in a DLL or in a shared object. You can call operating system routines that are not linked to your application.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |