I was sitting around debugging some code and I stumbled across this line in SysUtils.pas:
procedure ConvertError(ResString: PResStringRec); local;
What does the local keyword do exactly? It seems the ConvertError function is not declared in the interface section of the file, is this just a clarification that the function is indeed local, or is there a practical benefit to using this directive beyond that?
It dates back to the Linux compiler, Kylix. Here's what I can see in my Delphi 6 language guide, page 9-4:
The directive local, which marks routines as unavailable for export, is platform-specific and has no effect in Windows programming.
On Linux, the local directive provides a slight performance optimization for routines that are compiled into a library, but are not exported. The directive can be specified for standalone procedures and functions, but not for methods. A routine declared with local—for example.
function Contraband(I: Integer): Integer; local;
—does not refresh the EBX register and hence
cannot be exported from a library.
cannot be declared in the interface section of a unit.
cannot have its address take or be assigned to a procedural-type variable.
if it is a pure assembler routine, cannot be called from a another unit unless the caller sets up EBX.
Related
I'm trying to figure out a safe way of passing objects from a main app to a DLL (for a plugin system).
The idea is to use the main app's TZConnection (database access from Zeos Lib) in the dll's.
I'd rather not use Runtime Packages, and DLL must be the way to go (I don't need BPL's need to recompile each time, and have no idea of how to use COM).
I've been told it's possible to do it with Interfaces.
I've never used them before, but been messing around with it, and managed to do it... But, I don't know if I did it right (as in, safe).
Here's my Interface unit.
unit PluginIntf;
interface
uses
ZConnection, ZDataSet;
type
IQueryResult = interface ['{743AB77E-7897-403E-A0D9-4D02748E565D}']
function GetRecordCount: Integer;
function GetDataSet: TZQuery;
end;
IPluginHost = interface ['{A5A416B4-437E-4A1E-B228-0F94D54840B0}']
function RunSql(const SQLString:WideString): IQueryResult;
end;
IPlugin = interface ['{8D9591C3-5949-4F0A-883E-6ABD02597846}']
function GetCaption: WideString;
end;
implementation
end.
In IQueryResult, I'm passing a TZQuery. It works, but... Is it safe?
Is there any other way to wrap it in the Interface?
Thank you
Nuno Picado
TZQuery is a class. Therefore it is not safe to pass one across the module boundary unless you use runtime packages. Use a class with DLLs and you actually have two separate types, one in each module.
You are correct that interfaces are safe for this but you need to restrict yourself to DLL interop safe types. That is simple types, records, pointers to arrays, interfaces, or combinations of these types.
You need to wrap TZQuery with an interface that exposes it's functionality.
I'm curious about this:
When I import a function from a dynamic link library that exports using stdcall calling convention, is it mandatory to add stdcall before external in Delphi starting from version 7?
i.e.
LIBNAME int __stdcall Foo(void);
as
function Foo: Integer; stdcall; external 'libname.dll';
or I can get away with just
function Foo: Integer; external 'libname.dll';
IIRC by default it will use stdcall but I'm not 100% sure on this, your opinion is required.
EDIT:
The question is related to 32bit library, Arnaud Bouchez has made a good point that for 64bit, the calling convention is not taken into consideration since there's only one.
If you omit stdcall then the default calling convention register will be used. So you must include that stdcall.
The fact that you are using external does not change anything. The default calling convention is register, even for external imports.
Of course, this only matters when compiling for 32 bit. On x64 Windows there is a single calling convention specified in the ABI. On x64 Windows, all calling conventions specified in code are ignored and all function calls are made with the Windows x64 calling convention.
I am using functions from an external .pas file. I can use some of the functions, but not others. As far as i can see the functions are declared the same way, I would like to post some of the file, but don't know ho to post large amounts of code.
You can use the functions that are declared in the interface section, that is the section of code before the implementation section.
You are probably trying to call functions that are defined only in the implementation section, that is that code that appears after the implementation keyword.
These different sections are how Delphi implements public and private visibility at the unit level.
Usually, in well written units, there will be a reason for functions being made private to the unit. But if you feel it reasonable to override the author's decision then you need to redeclare the function in the interface section. This will make it available to your code which uses the 3rd party unit.
The file is not properly linked and/or not included in your projects search path and/or shadowed by some other file with same function names and/or odd functions are within $IFDEF clauses.
Check spelling, uses clauses, working function location (Ctrl+click on function name in your code), $IFDEF clauses.
The file is not properly linked in Delphi environment options
The file could be located outside of project search path. Hence it's not linked.
The file path is typed wrongly in project (DPR file). E.g. you are referring to older path with olde version of a file.
In each of these cases some functions could be taken from other files if name fits. E.g. function gluUnproject can be taken both from OpenGL.pas and dglOpenGL.pas, if first unit is not linked properly I would get the same problem as you are having now - some functions work and some are missing. In any of the cases you should compile your project, Ctrl+Click on a working function name and see where it brings you, check file version location.
The functions could be inside of $IFDEF clauses. These are compiler directives and code within such clause will be invisible to compiler if certain condition is not met. E.g. {$IFDEF MSWindows} Func {$ENDIF} won't be accessible on Linux.
I have a DLL file from which I need the memory address of a class procedure. I am getting the handle to the DLL file, but when I use GetProcAddress, I can't get the address of the procedure. I have tried the following strings for the process name parameter:
"ProcName"
"ProcClass.ProcName"
"ProcClass::ProcName"
"ProcInterface::ProcName"
"ProcInterface.ProcName"
In none of the cases have I gotten the memory address of the procedure. I am mostly certain that the procedure is public.
What is the string format for doing this? Would it be easier to declare a function pointing to the external procedure and get the address later? Like this:
procedure ProcName(); stdcall; far; external 'Example.DLL';
ProcPointer := #ProcName;
GetProcAddress only gives you the address for exported functions. Your DLL surely doesn't export the methods of a class!
Use an PE explorer to look for the exported names. For example, use the PE explorer available in GExperts. I've got a "PE Information" menu entry under the GExperts menu.
You are into reverse engineering territory here.
I think that if I were you I would just step through in the CPU view of the debugger, following a call to the method of interest, and find the entry point address. I'd subtract it from the base address of the DLL and that would be the offset. Then to calculate the address at runtime you just add the offset it to the base address of the DLL in memory at that time. You can find out the base address with calls to LoadLibrary or GetModuleHandle.
Why hard code the offset? Well, since you can't modify your DLL it doesn't seem to be too limiting. If hard coding the offset is not viable then there are other means of locating entry points, but I must admit I'm not the world's greatest expert on that.
Finally, when you implement the replacement method, you will need to replace it with a global function/procedure with an extra parameter, the first parameter, which takes the place of Self.
I might be reading this wrong. But it seems to me you wrote the DLL.
You should write a function that is NOT a member of any class, and export it from your DLL. Inside that function, call your class method.
If you didn't write the DLL, you still need to find out what functions it exports, and it is very unlikely any of them were class methods, at least not in Pascal.
If someone wrote a dll in C++ and exported its methods, then you would have to investigate C++ name mangling rules.
For a server-side plugin framework I would like to implement DLLs which expose a RegisterPlugin method that returns a class reference (TInterfacedClass).
The host application then creates the instance(s) of this class, and instances will run in the context of the host thread(s). (This is different for example from the Jedi VCL plugin framework which instantiates the plugin in the DLL or BPL and returns the instance to the host.)
First tests showed no problems so far. However, are there hidden problems with memory management I should be aware of? As I am using Delphi 2009 for this project, FastMM4 is the default memory manager.
Here a sketch of the plugin DLL project:
library ExamplePlugin;
uses
...
type
TPluginOne = class(TInterfacedObject, ...)
...
end;
function RegisterPlugin: TInterfacedClass; stdcall;
begin
Result := TPluginOne;
end;
exports
RegisterPlugin;
{ TPluginOne }
// ... plugin class implementation
begin
end.
No problems with memory manager, because FastMM works as a shared memory manager between the EXE and the DLL. But I'm really not comfortable with the concept of passing pure objects, or (worst) metaclasses between the DLL and the EXE. The problem is, TInterfacedObject from the EXE is not the same as TInterfacedObject from the DLL! Sure, they might look exactly the same, but they're not! And if you ever upgrade the version of Delphi for the EXE or for any of the DLL's, you'll need to rebuild everything (thus losing whatever advantage you gained from implementing a Plugin framework).
A much more portable solution would be to return a "Factory Interface", something along the lines of:
IFactoryInterface = interface
[GUId-goes-here]
function MakeWhateverInterfaceYouNeed: IUnknownDerivate
end;
then export a function with this signature:
function RegisterPlugin: IFactoryInterface;
Your code is incomplete but from what you have included there is one obvious flaw.
You appear to be exporting a class (TInterfacedClass) from a DLL. This is going to cause problems when clients try to consume your class with a different version of Delphi. What's more it's going to leave them helpless if they want to write plug-ins in a different language.
Personally I'd go for a COM based interface which will allow plug-in authors to create plug-ins in any language. This is in fact the very problem that COM was invented to solve.
If you are happy to be constrained to using the same compiler for plug-ins and host app, and you prefer to expose classes to COM interfaces, then you need to make sure that all deallocation is performed with the same memory manager as allocated the memory. The simplest way is to use ShareMem and then you'll be safe.
UPDATE
Cosmin points out in a comment another flaw with exporting classes across module boundaries. It's basically something that you shouldn't do. COM was designed for this very purpose and it still should be the first choice for you. Delphi interfaces which are COM compatible so you can get the same benefits of binary interoperability without having to create servers, register CLSID's etc.
I think your plug-in should look like this:
library ExamplePlugin;
type
TPluginOne = class(TInterfacedObject, IPlugin)
[GUID]
public
constructor Create(const Host: THostApp);
end;
function RegisterPlugin(const Host: IHostApp): IPlugin; stdcall;
begin
Result := TPluginOne.Create(Host);
end;
exports
RegisterPlugin;
begin
end.