What does export mean as a Delphi procedure directive? - delphi

I'm trying to crack the DLL referenced here: How do I call a delphi function that takes and returns pointers of custom type from Python?
The DLL's signature is:
Procedure myFunc(Ptr:Pointer;Var Result:Pointer);Export;
I can't figure out what the "Export" at the end of signature means.
Looking through the docs it seems like "Export" is where a directive should go, but "Export" isn't one of the directives listed. In this tutorial they show a procedure with "export" as a directive, but they don't explain it.

export is a now defunct directive. It has no effect. From the documentation:
The directives near, far, and export refer to calling conventions in 16-bit Windows programming. They have no effect in Win32 and are maintained for backward compatibility only.
This export directive was used in 16 bit programs when exporting functions from a module.
FWIW, the link you gave in the question is not the product documentation but rather a third party website. I suggest you use the official documentation.

Related

Where can I find Delphi Declarations for Windows API calls?

I want to be able to see how one calls the Windows API in Delphi. Recently I had a question about GetProcessorAffinity and the Delphi declaration was posted as part of the answer. I would like to know how to find that kind of information.
There is no function named GetProcessorAffinity. Probably you mean GetProcessAffinityMask. That function is declared in the RTL unit Winapi.Windows. The source file for this is supplied with Delphi. You can use CTRL + click to navigate to the declaration of any function.
If you do so with GetProcessorAffinity then you will be taken to its implementation in Winapi.Windows. Now, that implementation looks like this:
function GetProcessAffinityMask; external kernel32 name 'GetProcessAffinityMask';
This is not terribly useful, but the information you are looking for is close by. Now that you are in the file which contains the implementation, you can find the declaration. Move to the top of the file and search for GetProcessAffinityMask. That will take you here:
function GetProcessAffinityMask(hProcess: THandle;
var lpProcessAffinityMask, lpSystemAffinityMask: DWORD_PTR): BOOL; stdcall;
That's the information that you need.
Many of the Windows API functions, but not all, are declared in Winapi.Windows. But the process described above will take you to the right file in any case.
The other technique that is useful is to search within files. From the IDE Search menu select Find in Files. Configure the dialog like this:
Note that you'll need to use a path suitable to your version of Delphi. For instance, my example is from XE7, which is version 15, but you have XE5 which is version 12.
Delphi comes by default with some Windows API's in different units (a lot of them in the (WinApi.)Windows unit.
A more complete translation of the Windows API headers can be found in the Delphi Jedi Apilib project.

Build a delphi EXE which has no procedure names in it?

For security reasons a customer is asking us if we could build a version of his executable which contains no references to procedure names we use in the code. At first I thought this was relatively easy and could be achieved by not building using Debug Information.
Sadly ... when opening the EXE using a text editor like NotePad, we are still able to see a lot of information if our EXE. Especially procedure names which are public. I thought that without debug information all this would be obfuscated.
Now I'm wondering if there is an easy way to achieve this. Build my EXE which has no references to procedure names.
Any suggestion is welcome.
You can include following compiler directive in units you don't want to emit extended RTTI information, and leave only RTTI for published properties, fields and methods that are usually used by streaming or other RTTI based mechanisms.
{$RTTI EXPLICIT METHODS([vcPublished]) PROPERTIES([vcPublished]) FIELDS([vcPublished])}
However, that will not obfuscate class names and will leave RTL/VCL/FMX RTII information intact.
Any suggestion is welcome.
Embed a web browser in the main form and move all code to a web application. Then launch the web app home page in your Delphi program. Try to use notepad now - and Bingo. :)

Delphi XE6 DLL: Unwanted export: TMethodImplementationIntercept

When you compile a DLL in Delphi XE6, it automatically exports the function TMethodImplementationIntercept from System.Rtti.pas. I tried to find a way to avoid this export but didn't find any configuration or compiler directive that could do the trick.
The System.Rtti unit is nearly impossible to avoid because it's used indirectly by almost everything in delphi.
Is there a way to avoid exporting this function when building a DLL in XE6?
The code in the System.Rtti unit looks like this:
{ This function has been added to be used from .s .c files in order to avoid use mangled names}
procedure TMethodImplementationIntercept(const obj:TMethodImplementation; AFrame: Pointer); cdecl;
begin
obj.Intercept(AFrame);
end;
exports TMethodImplementationIntercept;
This function and the exports directive, were added in XE5.
Is there a way to avoid exporting this function when building a DLL in XE6?
If your library includes the System.Rtti unit then the DLL will export that function. If you want to produce a DLL that does not export the function I can see the following options:
Use an older version of Delphi.
Don't include System.Rtti in your library.
Use a modified version of System.Rtti that does not export the function.
Modify the DLL after it has been produced to remove the function from the PE export table.
The first two options seem to me to be not very appealing. The third option seems attractive but I think it might turn out to be difficult to make work. It seems that this long standing trick no longer works. I've not yet been able to re-compile an RTL unit and avoid the dreaded X was compiled with a different version of Y error.
So that leaves the final option. Again, not massively attractive. You may well decide to just suck it up and accept this stray export. Perhaps a QC report might put a little pressure on Embarcadero to reconsider this decision.
For what it is worth, in my opinion no compiler library code should ever unconditionally export a function. It should be the consumer of the library rather than the implementer of the library that takes that decision.

Has anyone used ICU with Delphi?

Has anyone used the ICU ( see http://site.icu-project.org/ ) DLLs from Delphi?
Specifically I'm interested in the Code Page Conversion and Collation functions.
Looking at the header files it would appear that they are mostly in C++ using classes, so without having done much research yet, I would assume that it's necessary to create a simple wrapper around this that exports simple functions which can easily be imported in Delphi.
Has anyone done any work for that yet?
Or can anyone recommend a different solution for Delphi that has similar extensive coverage for codepages and collation orders?
I don't use it, but there's a very complete translation called ICU4PAS that wraps the DLLs and provides a nice Delphi-based interface.

Virtual Library Interfaces for Delphi/Win32?

I read this article and find the concept of Virtual Library Interfaces nice for runtime loading of DLLs. However it seems that they aren't available for Win32. Is this true? And if so: Why? I don't see what would tie the idea to .NET.
EDIT: I'm mostly rephrasing here what Rob already wrote. :-)
I'm not after plugins or similar - it's about plain old Win32 DLLs. What appeals to me is the idea to let the compiler deal with all the details of loading a DLL at runtime - no need to call GetProcAddress for every function in the DLL etc.
It seems to me like the three answers so far have completely missed the point of your question. That, or I have. You're asking why Win32 Delphi doesn't have something like the magical Supports function that Hallvard's article talks about, aren't you? Namely, a function that, given the name of a DLL and the type information of an interface, returns an object that implements that interface using the standalone functions exported from the DLL.
Hydra seems to be all about calling .Net code from a Win32 program, not about importing functions from a DLL. TJvPluginManager requires that the plug-in DLLs export a special self-registration function that the manager will call when it loads the DLL, and the function must return an instance of the TJvPlugin class, so the plug-in DLL must be written in Delphi or C++ Builder. The Supports function, on the other hand, works with any DLL written in any language. You could use it on kernel32, if you wanted.
I don't know why Win32 Delphi doesn't have such a thing. Maybe CodeGear didn't see much demand for it since Delphi and Turbo Pascal had already gone for so long without it.
It's certainly possible to write a function that works like that, and I don't expect it would be any harder to write than the .Net version must have been, unless Microsoft's .Net libraries already provide most of the pieces and Delphi just wraps them up into a convenient-to-call function that looks like the several other overloaded versions of Supports that Delphi has had for years.
There would be a few steps to implementing that function in Win32. (I'm providing only a sketch of what's necessary because I don't have a running copy of Delphi handy right now. Ask nicely, and maybe I'll find more details.) First, you'd need to make sure that type information for an interface held, at a minimum, the undecorated names of its methods. Then, Supports would need to generate a function stub for each method in the interface (besides _AddRef, _Release, and QueryInterface). The stub would go something like this, assuming the calling convention is stdcall:
asm
// Pop the return address,
// discard the "this" pointer,
// and restore the return address
pop eax
pop ecx
push eax
jmp AddressOfFunction
end;
As Supports generated each stub, it would fill in the actual function address, gotten from calling GetProcAddress with the name of the corresponding interface method. The stdcall calling convention is easy to wrap like that; cdecl is a little cumbersome; register is a pain in the neck.
Once it has all the stubs generated, it would need to generate an "object" that looks like it implements the given interface. It doesn't have to be an actual class. At compile time, Supports doesn't know the layout of the interface it's going to be asked to implement, so having a class wouldn't accomplish much.
The final step is to provide implementations of the _AddRef, _Release, and QueryInterface. _AddRef would be unremarkable; _Release is where you'd call FreeLibrary when the reference count reached zero; QueryInterface wouldn't do much at all, except claim that it supports IUnknown and the interface given to Supports.
Delphi used to come with a sample program that demonstrated implementing an interface without any classes at all. It was all done with records and function pointers (which is all an interface ultimately is, after all). Delphi also came with the corresponding code to do it with classes, in part to show how much easier Delphi can make things. I can't find the name of the demo program now, but I'm sure it's still around somewhere.
There are a number of Win32 options for this type of functionality. Project JEDI has an open source plugin system as part of the JVCL that loads either DLLs or packages, and can include forms and whatnot as additional functionality.
There are also a number of commercial products available, including the TMS Plugin Framework and RemObjects Hydra.
This is nothing new or special. The article's just talking about plugins. Native code's been able to do plugins for years. The only special thing about P/Invoke is that it allows native code and .NET to talk to each other in a plugin system, and the little trick where "the DLL can be seen as a singleton object that implements the interface [so that] you can use the Supports function from the Borland.Delphi.Win32 unit to check if the DLL and all the methods are available."
If you want to do what the article's talking about in Delphi for Win32, look at the LoadLibrary, GetProcAddress and FreeLibrary Windows API functions. If you absolutely must have an interface like the article describes, you have to write it yourself, either in the DLL (if you wrote the DLL yourself) by writing an exported function that returns an interface, or in the calling app, by writing a function that uses GetProcAddress to create an interface dynamically. (Caution: this requires mucking around with pointers, and is usually more trouble than it's worth.)
Your best bet is probably just to do what Tim Sullivan mentioned: use TJvPluginManager from the JEDI VCL if you only need native code, or Hydra if you have to talk to .NET assemblies.
I've used Hydra myself for a Delphi only solution (i.e., didn't interface to .NET) and it works great for that too. It's easier to use and adds some niceties, but I think that it's basically implemented the same way as the "roll-your-own" plugin framework that is well-described in this article:
http://www.saxon.co.uk/SinglePkg/
I would look for a plugin framework that's interface-based (like Hydra and the "roll-your-own" system in above paragraph), rather than one that simply sends messages between apps.
There is a Delphi plugin framework on sourceforge, don't know whether it's the same one as in JEDI project or not: http://sourceforge.net/projects/rd-dpf
There are also a couple of other commercial solutions, one of which is Dragonsoft's:
http://www.dragonsoft.us/products_dsps.php
What is wrong with doing this with simple com objects? Declare a simple interface that all of your plugins implement, and require that each com object include an exported function that returns its class guid. Then using the "plugins" is as simple as walking thru the plugins directory looking for DLL's which expose the special registration function, invoking it and then using the class guid to then invoke the com object.
I used something like this in a WIN32 commercial application with great success. The advantage was I could switch plugins in and out at will (provided of course the application wasn't running to remove existing ones), the magic was all in the interface that each one implemented.

Resources