EXE as DLL

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

DLLProc

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

maybe not?

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

@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.

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.

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;
{$APPTYPE CONSOLE}
type TSum = function( A, B: Integer ): Integer;
var
  A, B: Integer;
  Handle: THandle;
  Sum: TSum;
begin
  Randomize;
  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 ) );
    end
    else begin
      WriteLn( 'Failed to find the sum routine.' );
    end;
  end
  else begin
    WriteLn( 'Failed to load DLL: ', SysErrorMessage( GetLastError ) );
  end;
  ReadLn;
end.

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;
begin
  Result := A + B;
end;
exports Sum;
begin
  MessageBox( GetDesktopWindow, 'Here we go', 'DLL', MB_OK );
end.

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

unit untInit;
interface
uses Windows;
implementation
initialization
  MessageBox( GetDesktopWindow, 'Hello', 'DLL', MB_OK );
finalization
  MessageBox( GetDesktopWindow, 'Goodbye', 'DLL', MB_OK );
end.

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... ;-)

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.



DragonSlayer.

@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

https://www.experts-exchange.com/questions/21163413/EXE-as-DLL-2.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...