Okay, I'm not in a hurry with this. I just want to know how to do this.

I have two executables. One is exporting a method while the other wants to import this EXE as a DLL and call this method.

Both executables should work as stand-alone executables, with proper forms and stuff like that. However, I want one EXE to also work as if it's a DLL. As a DLL it doesn't have to create forms or do other stuff. All it must do is offer the other EXE access to a method.

What would be the easiest way to solve this?

And no, I DON'T want to create a separate DLL for this method. Neither do I want some complex component set that can do this for me. I'm just experimenting here.
LVL 17
Wim ten BrinkSelf-employed developerAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

Slick812Connect With a Mentor Commented:
hello Workshop_Alex , , as far as I know an executables (Program) .DPR file has the same methods as a Library .DPR for exporting functions, as in a Library you just add the function to the " exports " clause, , maybe something like this -

program ColorConsole;

ConStr: String;

function IsRunning(hWnd: HWND): Boolean;
Result := IsWindow(hWnd);


Writeln('A Plain old Write Line for console');

- - - - - - - - - - - - - - - - - - - - - - -  - - - - -

unlike a DLL, I think the code between the programs  begin  and  end.  is not executed

you can use the same old LoadLibrary( ) with the Program executable path to use the exported function
Wim ten BrinkSelf-employed developerAuthor Commented:
More conditions. The EXE that will be used as a DLL is just a console application. It uses only the Windows unit. I want to keep this like that. NO MORE UNITS! When it runs, it writes some status information to the console and then closes. The exported method will provide the same status information to the calling process. However, it is very important that if the method is called, it is running exactly as if it's a DLL!
Although I have never tried it, I am not sure if the


for an executable is made available if it is loaded as a Library?

maybe not?
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

you can export functions from an executable no problem, but you can "only" execute those within DLLs loaded by that same Executable (used mostly by plug-ins)

There are (of course) undocumented functions that allow to treat executables as DLLs...

in theory and in a normal world, each executable gets executed in it's own process area and it's functions cannot be shared with other processes
Wim ten BrinkSelf-employed developerAuthor Commented:
@BlackTigerX, what I actually want is have one EXE loaded as a DLL in the process space of another executable. And it should behave like a true DLL in such a case. But it should also behave as a normal executable if started like that. I know how the exports clause works and have done some interesting things with it. I did even create a reverse-call project, where an Executable loads a DLL and the DLL then looks for functions the executable exported. The DLL itself would not export anything. The reason for this was simple... I wanted to make it harder for hackers to debug my DLL. And it worked quite nicely. The DLL could simply import the methods from the executable and use them to register itself, passing an interface object to the executable. The interface would then provide the further communication between DLL and executable.

But now I want to make it even a bit more complicated. I want functionality in one executable and then use it from another executable without any inter-process communications.
I think that Slick's idea is the way to go.  The code in the main program block may not be executed, but that's a good thing.
All you need to do is move all the code from that section into it's own procedure, then call the procedure from both the main program block and the exported library function.

Another approach that you might want to look at is playing about with the createprocess api call, and overriding all the input/ouput and control it directly from your first .exe (just like how CGI apps work). Just a passing thought, I don't think you want to do it like this though.
Wim ten BrinkSelf-employed developerAuthor Commented:
I'm still not in a hurry with this... :-)
This means I haven't found time to test Slick's idea. But I think it must be a bit more complicated than this. I could be wrong.
Wim ten BrinkSelf-employed developerAuthor Commented:
Well, okay. Slick812, you are right. By exporting a method from the execuitable, you can load it from another executable. However, there is no way to initialize the executable that I'm loading, except by adding an Initialization function myself. And this is what is troubling me. This means that Delphi isn't initializing anything when I load the executable as DLL. I'll give you the sample source I have now:

First the executable that will load the other executable.

program EXE;
uses Windows, SysUtils;
type TSum = function( A, B: Integer ): Integer;
  A, B: Integer;
  Handle: THandle;
  Sum: TSum;
  Handle := LoadLibrary( Pchar( 'DLL.exe' ) );
  if ( Handle > 0 ) then begin
    Sum := TSum( GetProcAddress( Handle, 'Sum' ) );
    if Assigned( Sum ) then begin
      A := Random( 10 ) + 1;
      B := Random( 10 ) + 1;
      WriteLn( A, ' + ', B, ' = ', Sum( A, B ) );
    else begin
      WriteLn( 'Failed to find the sum routine.' );
  else begin
    WriteLn( 'Failed to load DLL: ', SysErrorMessage( GetLastError ) );

As you notice, a call to "CloseHandle( Handle );" is missing too. If I close the 'DLL' then the system just crashes. This tells me that this solution is far from okay. But okay, now the very complex DLL... :-)

program DLL;
uses Windows, untInit in 'untInit.pas';
function Sum( A, B: Integer ): Integer;
  Result := A + B;
exports Sum;
  MessageBox( GetDesktopWindow, 'Here we go', 'DLL', MB_OK );

And the additional unit, which is also quite funny...

unit untInit;
uses Windows;
  MessageBox( GetDesktopWindow, 'Hello', 'DLL', MB_OK );
  MessageBox( GetDesktopWindow, 'Goodbye', 'DLL', MB_OK );

Basically, I'm trying to see when the DLL will be initializing itself. But it just does not happen. None of the dialogs are shown when I load this second executable as a DLL. Thus, this means that NOTHING is initializes in my Delphi code when I load it as a DLL. And this, of course, will lead to many bugs that are quite hard to solve. So I need to find a way to get things initialized after all.
The function call does work, btw. I do get the sum of the two values that I pass to my 'exe-dll' but if the system doesn't initialize any system variables in my dll then it will be quite unreliable.

Slick812, you have earned the 250 points plus A-grade for now but I want to keep it open just in case someone provides me a solution that also makes sure my 'dll' gets initialized properly. In which case I will double the points to 500 points, with A-grade. Thus, if you feel up for the challenge... ;-)
Wim ten BrinkSelf-employed developerAuthor Commented:
And for those who wonder why I'm trying to do this... Well, the DLL will be some console tool that has a method to read data and return an analysis of this data to the caller. If it's run from the commandline, it is just written to the commandline. But I want my application to use the same analysis data and I don't want to parse the output of the 'dll' just to read it back again. Neither do I want to create a separate DLL to support this analysis routine. And I don't want to use some interprocess communication between the two executables either since it seems to make it just a lot more complicated. I know there are other solutions but this is just an interesting challenge to me. :-)
make the DLL write to a text file =p

Hehe... couldn't think of anything intelligent to say, so hope you don't mind the crap above, LoL.

Wim ten BrinkSelf-employed developerAuthor Commented:
@DragonSlayer, LOL...
Yeah, there are enough work-arounds for this. Textfiles, separate DLL's, some kind of InterProcess communication, DCOM, the list is just endless. It's not that I want some solution. I want THIS to work. The words "It cannot be done" don't exist in my dictionary... :-P

http://www.experts-exchange.com/Programming/Programming_Languages/Delphi/Q_21163413.html is where I posted a continuation of this question. It's worth 500 points so more interesting for experts to answer. :-) Hopefully a bit more serious answers too.
Or am I asking the impossible? Who cares. We're experts, we do the impossible. We just ask more for miracles...
All Courses

From novice to tech pro — start learning today.