Using LoadLibrary on an executable -- initialisation

[R.Wieser]

Hello All,

When I use LoadLibrary on a DLL its DllMain gets called with the apropriate
arguments. It enables me to (among others) initialize and finalize its use.

I need to be able to load an executable and use its exposed functions. The
problem is that I can't seem to find the equivalent to a DLL initialisation
and finalisation entries ...

The question therefore is : Does an executable-loaded-as-libraray have such
methods and if so where can I find info about it (MS own site does not even
hint at it*)

Regards
Rudy Wieser

*http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).a
spx

[R.Wieser]

Something odd is going on:

I've just loaded an executable into another one and retrieved the address of
an exposed funcion in it, but whenever I call that function with anything
meaningfull inside it (I tried a simple "beep,5000,250") I get a GPF.

However, the very same function in a DLL works allright.

Anyone knows why (I have a couple of guesses, but thats all they are).

Regards,
Rudy Wieser


-- Origional message
R.Wieser <add...@not.available> schreef in berichtnieuws
4eb7afd1$0$6974$e4fe...@news2.news.xs4all.nl...

[Ulrich Eckhardt]

Am 07.11.2011 14:01, schrieb R.Wieser:
> Something odd is going on:
>
> I've just loaded an executable into another one and retrieved the address of
> an exposed funcion in it, but whenever I call that function with anything
> meaningfull inside it (I tried a simple "beep,5000,250") I get a GPF.
>
> However, the very same function in a DLL works allright.

Two things I would check:
1. Call the function from inside the executable when run as executable.
2. GetProcAddress() that function from inside the executable when run as
executable, and then call the function using that function pointer.

I'm guessing that the calling convention is simply wrong. A bit more
nasty would be if the module setup was missing, so that the EXE loaded
as DLL was simply defunct, but I don't think that is the case.

BTW: What is the executable written in? I'd try with one using plain C
with the least possible amount of additional stuff.


Uli

[Jeroen Mostert]

On 2011-11-07 11:18, R.Wieser wrote:
> When I use LoadLibrary on a DLL its DllMain gets called with the apropriate
> arguments. It enables me to (among others) initialize and finalize its use.
>
> I need to be able to load an executable and use its exposed functions. The
> problem is that I can't seem to find the equivalent to a DLL initialisation
> and finalisation entries ...
>

The executable does of course have an entry point, but there's no point to
LoadLibrary() calling it because it would never return (the executable would
start running as if its Main() were called, and end with ExitProcess()).
Note that there is nothing special about the entry point, it's the same
field in both .EXE and .DLL files but the calling conventions are different.
This is another reason for the loader not to call the entry point.

When loading an executable with LoadLibrary(), imports aren't resolved
either. Without initialization and imports, there is no chance of code
running correctly unless it's aware it's in this environment, and then it
might as well be put in a DLL. In particular, you can't use the C standard
library. The only supported way of loading an .EXE is with
LOAD_LIBRARY_AS_DATAFILE, to access resources, not code.

There are also reports that from Vista onwards, address relocation is broken
under ASLR for executables loaded with LoadLibrary(), upgrading this
scenario from "pretty unlikely" to "damn well impossible" (see
http://www.osronline.com/showthread.cfm?link=136276).

If you need a DLL, build a DLL. With the exception of .NET assemblies (which
use their own loading mechanisms and truly don't care about their executable
types) you can't load an .EXE as if it were a library. It could have been
made to work, but it's just not a supported scenario.

--
J.

[R.Wieser]

Hello Ulrich,

> 1. Call the function from inside the executable when run

I've done that many times in other executables, and used the same line. It
worked O.K. every time. The very same line in a DLL works without problems.

> BTW: What is the executable written in?

Maybe you will not believe it, but its Assembly (using Borlands Tasm5.0).
Lower/simpler than that you won't get. :-)

Regards,
Rudy Wieser


-- Origional message

Ulrich Eckhardt <ulrich....@dominolaser.com> schreef in berichtnieuws
0pglo8-...@satorlaser.homedns.org...

[R.Wieser]

Hello Jeroen,

> The executable does of course have an entry point, but there's no
> point to LoadLibrary() calling it because it would never return
> (the executable would start running as if its Main() were called,
> and end with ExitProcess()).

Exactly that, which is why I wondered.

> This is another reason for the loader not to call the entry point.
>
> When loading an executable with LoadLibrary(), imports aren't
> resolved either.

I already got the feeling that that would be the case.

> The only supported way of loading an .EXE is with
> LOAD_LIBRARY_AS_DATAFILE, to access resources,
> not code.

That also crossed my mind.

Gee, aren't I thankfull that MS left that outof the comments (on the page I
linked to) ? Nope, I guess I'm not. :-((

> It could have been made to work, but it's just not a
> supported scenario.

Yeah, thats what I have to conclude too. Not funny when you know that an
executable and a DLL are the same in most every detail ... but for the
entry-point.

Oh well, a lesson learned.

By the way:

> If you need a DLL, build a DLL.

I wanted a *single* file, not two.

Regards,
Rudy Wieser


-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws
4eb84c90$0$6875$e4fe...@news2.news.xs4all.nl...

[Jeroen Mostert]

On 2011-11-09 14:55, R.Wieser wrote:
>> If you need a DLL, build a DLL.
>
> I wanted a *single* file, not two.
>

No problem. Build it as a DLL. If it needs to run as an .EXE, supply a stub
file that loads the DLL and calls the ExeMain() entry point you can expose
from that DLL.

There is already a stub EXE like that supplied with Windows itself, good old
RUNDLL32. Just conform to its calling convention.

--
J.

[R.Wieser]

Hello Jeroen,

> supply a stub file that loads the DLL and calls
> the ExeMain() entry point

So, again two files ?

> good old RUNDLL32

You know what it is, I know what it is. However, most people have no clue
...

It does not really make starting the executable (which than also does not
have an icon anymore) any easier..

Regards,
Rudy Wieser


-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws

4ebac5bc$0$6886$e4fe...@news2.news.xs4all.nl...

[Jeroen Mostert]

On 2011-11-09 22:21, R.Wieser wrote:
>> supply a stub file that loads the DLL and calls
>> the ExeMain() entry point
>
> So, again two files ?
>

Are you paying a tax on them or something? I thought your concern was having
to build the same code in two different files, but apparently it's the
absolute number of them.

You already have two files as you're trying to load the file as a DLL in
another file. How is three files that much worse?

>> good old RUNDLL32
>
> You know what it is, I know what it is. However, most people have no clue
> ...
>

I wouldn't expect them to. That's what shortcuts are for.

> It does not really make starting the executable (which than also does not
> have an icon anymore) any easier..
>

Feel free to complain to the Windows developers, but at this point I think
you're just sulking. No, you can't have your pudding, I'm sorry, you'll have
to make do with something less.

--
J.

[R.Wieser]

Hello Jeroen,

> but apparently it's the absolute number of them.

Yes, it is. Think portability.

One file is easy to keep track of. Anything above it is asking for parts of
it to be forgotten/left behind while copying it to a new destination (or not
cleaned up when the executable is removed by simply deleting it)

> You already have two files as you're trying to load the file
> as a DLL in another file. How is three files that much worse?

I'm sorry, but my question was how I could use an EXE with exposed methods
as a DLL. That means: a *single* file, not two.

> I wouldn't expect them to. That's what shortcuts are for.

Again, that would again be causing more than a single file. Also, .LNK
files are not really movable (between different computers).

Also try to double click the DLL to start it. Al you get is a "pick your
poisson to start it with" dialog. Not even an easy "Its a DLL, do you want
to start it as an Executable ?" question.

In short: Not many users will know that they can/how to pick a target, and
even less will know that they should, in this case, pick RUNDLL32 (which is
not even in that list) ...

> Feel free to complain to the Windows developers, but at this
> point I think you're just sulking.

I'm sorry you think that.

But I've got a bone to pick too: Why did/do you consequently suggest methods
which would consequently defeat the easyness of having the two files (EXE &
DLL) combined into one ?

If I wanted to have two files I would just create an EXE and a seperate DLL
(which is what I have now).

> No, you can't have your pudding, I'm sorry, you'll have
> to make do with something less.

I have done that for a couple of years now. It was time to spend some
energy on trying to find a better solution. I hoped I had simply overlooked
a setting.

Regards,
Rudy Wieser


-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws

4ebaf95d$0$6979$e4fe...@news2.news.xs4all.nl...

[Ulrich Eckhardt]

Am 10.11.2011 10:52, schrieb R.Wieser:
> One file is easy to keep track of. Anything above it is asking for parts of
> it to be forgotten/left behind while copying it to a new destination (or not
> cleaned up when the executable is removed by simply deleting it)

Ahem, there's this new invention called "folder", which allows you to
store multiple files. ;^)

>> You already have two files as you're trying to load the file
>> as a DLL in another file. How is three files that much worse?
>
> I'm sorry, but my question was how I could use an EXE with exposed methods
> as a DLL. That means: a *single* file, not two.

Yes, but what is going to load that DLL? Is it Joe Normal that can't run
a DLL with RUNDLL.EXE? So why does it need exported functions at all if
not for a second file?

Anyway, there are EXE packers that generate another self-extracting
executable. You could use this to unpack the multiple files (which you
probably won't get around) and which then unpacks them to a temporary
directory which is cleaned up regularly. I'd also take a look at how
others do it, there is http://portableapps.com that aim to provide
portable (in the sense of runnable from a thumbdrive) versions of
various programs.


I also think you're sulking a bit. However, I also understand your
strive for perfection and I wish you success with that! :)

Uli

[Jeroen Mostert]

On 2011-11-10 10:52, R.Wieser wrote:
>> You already have two files as you're trying to load the file
>> as a DLL in another file. How is three files that much worse?
>
> I'm sorry, but my question was how I could use an EXE with exposed methods
> as a DLL. That means: a *single* file, not two.
>

If the EXE could be loaded as a DLL, something would be doing the loading.
That involves the original file and at least one other, since I assume you
weren't trying to get the EXE to load itself as a DLL...

>> I wouldn't expect them to. That's what shortcuts are for.
>
> Again, that would again be causing more than a single file. Also, .LNK
> files are not really movable (between different computers).
>

If you're going for XCOPY deployment, there are plenty of techniques for
that, possibly involving just one file. See Ulrich Eckhardt's post.

> Also try to double click the DLL to start it. Al you get is a "pick your
> poisson to start it with" dialog. Not even an easy "Its a DLL, do you want
> to start it as an Executable ?" question.
>

Why do you even want a DLL?! I think I'm just not getting your scenario.
Then again, you never fully explained it.

> In short: Not many users will know that they can/how to pick a target, and
> even less will know that they should, in this case, pick RUNDLL32 (which is
> not even in that list) ...
>

Of course not! DLLs aren't suitable for end-user consumption, that's as
plain as the nose on my face (which is rather big, by the way, so I'm not
being purely metaphorical). I was imagining a regular setup scenario that
creates a shortcut and shows no trace of the DLL. Again, without a scenario
I'm going to assume a common case...

>> Feel free to complain to the Windows developers, but at this
>> point I think you're just sulking.
>
> I'm sorry you think that.
>
> But I've got a bone to pick too: Why did/do you consequently suggest methods
> which would consequently defeat the easyness of having the two files (EXE&
> DLL) combined into one ?
>

For the same reason I would suggest alternatives to putting a cow on the
moon by the use of a catapult: the literal thing can't be done due to
inherent restrictions in things beyond your control. I'm just spitballing
possible alternatives to whatever you're *ultimately* trying to accomplish,
under the assumption that what you're *ultimately* trying to accomplish is
not something impossible.

> If I wanted to have two files I would just create an EXE and a seperate DLL
> (which is what I have now).
>
>> No, you can't have your pudding, I'm sorry, you'll have
>> to make do with something less.
>
> I have done that for a couple of years now. It was time to spend some
> energy on trying to find a better solution. I hoped I had simply overlooked
> a setting.
>

You didn't. Good luck.

--
J.

[R.Wieser]

Hello Ulrich,

> Ahem, there's this new invention called "folder", which allows
> you to store multiple files. ;^)

A "folder" you say ? Whats that ? Something new ? Mind you, I'm still
using DOS v1.0 Are you saying there is a new version ? :-)

> Yes, but what is going to load that DLL?

Another program.

But thats not the problem. I need to be able to *easily* start the intended
hybrid. You know, like a standard EXE: a double-click and there you go.
I would not mind to need to do a bit more work to be able to use the hybrid
in DLL-mode

> I also think you're sulking a bit.

:-(

> However, I also understand your strive for perfection
> and I wish you success with that! :)

Its not really perfection I'm aiming at, but rather the need to understand
why certain things can, or in this case, cannot be done.

You know, I have no idea whatsoever why, using LoadLibrary, a DLLs
references are resolved and an EXEs not. The files structures are
absolutily identical ... There must be a good reason for that, but I can't
come up with any.

And to be frank about it, -- nothing personal -- but I am getting a bit
tired of all those people who "answer" questions not by trying to solve the
problem, but by asking why I do not do it differently. If I wanted to do
it differently I would have asked for it. Its as simple as that.

Mind you, I'm willing to investigate different solutions, but only *after*
my initial question has been answered (if I would let myself being
side-tracked whenever someone says something I would never reach an/the
end).

> Anyway, there are EXE packers that generate another
> self-extracting executable.

Not really needed. I could include the DLL as a resource into the
executable and extract it whenever the executable is run. If needed I could
probably even make the DLL self-deleting.

But I rather not do that kind of thing if its not really neccessary.

Regards,
Rudy Wieser


-- Origional message:

Ulrich Eckhardt <ulrich....@dominolaser.com> schreef in berichtnieuws

rjnso8-...@satorlaser.homedns.org...

[R.Wieser]

Hello Jeroen,

> If the EXE could be loaded as a DLL, something would be doing
> the loading. That involves the original file and at least one other,
> since I assume you weren't trying to get the EXE to load itself as
> a DLL...

I left the program loading my EXE/DLL outof the equation to keep it simple.
But if you now want to throw it in so you can say you where right after all
than be my guest. Don't expect me to give you browny point s for such
behaviour though.

> If you're going for XCOPY deployment,

What about drag-and-drop ? Windows does support that you know. Easy as
anything.

> Why do you even want a DLL?!

You obviously did not pay attention. Re-read my first post. In it I
mentioned :

[quote]I need to be able to load an executable and use its exposed
functions[/quote]

> I think I'm just not getting your scenario.

You do not need to. I asked a simple question. Comparable to how to use
the stick-shift in a car. You than do not need to know which roads I'm
currently driving on. Maybe I will even try to use that stick-shift on
roads I'm currently not even aware of.

> Then again, you never fully explained it.

You never bothered to ask.

Regards,
Rudy Wieser


-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws

4ebc0ebb$0$6872$e4fe...@news2.news.xs4all.nl...

[Jeroen Mostert]

On 2011-11-10 22:38, R.Wieser wrote:
>> If the EXE could be loaded as a DLL, something would be doing
>> the loading. That involves the original file and at least one other,
>> since I assume you weren't trying to get the EXE to load itself as
>> a DLL...
>
> I left the program loading my EXE/DLL outof the equation to keep it simple.
> But if you now want to throw it in so you can say you where right after all
> than be my guest. Don't expect me to give you browny point s for such
> behaviour though.
>

No need to get huffy. We're not in a contest. I'm not interested in getting
one over on you, I'm clarifying my assumptions. I'm too old for brownie
points anyway.

> You obviously did not pay attention. Re-read my first post. In it I
> mentioned :
>
> [quote]I need to be able to load an executable and use its exposed
> functions[/quote]
>

I see where the confusion came in. I think in terms of end-user scenarios.
If you ask me for something impossible, I'm not going to spend more time on
the original question then to say "it's impossible and here's why". If I'd
known you'd get annoyed with the follow-up (exploring ways in which whatever
you're trying to do could be accomplished differently) I wouldn't have
bothered. Sorry for wasting your time; I hope the discussion is of use to
someone else in the future.

--
J.

[Deanna Earley]

On 10/11/2011 21:09, R.Wieser wrote:
> And to be frank about it, -- nothing personal -- but I am getting a bit
> tired of all those people who "answer" questions not by trying to solve the
> problem, but by asking why I do not do it differently. If I wanted to do
> it differently I would have asked for it. Its as simple as that.

Many people are stupid and don't know about what they asking, and tend
to get the wrong end of the stick and refuse to let go.
People answering can't normally tell the difference :)

--
Dee Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

[R.Wieser]

Hello Jeroen,

> We're not in a contest

My apologies. But than why did you mention it ?

> I'm clarifying my assumptions

Again, my apologies. I thought I have precluded that assumption by stating
"load an executable and use its exposed functions". The most common way to
do that is by another program. I did not think it needed any more
clarification.

> I think in terms of end-user scenarios.

So did I. And I tried to explain that. I mentioned portability, and how a
single program makes such a thing easier.

> If you ask me for something impossible, I'm not going to
> spend more time on the original question then to say "it's
> impossible and here's why"

I suggest you re-think that. One of the reasons I got "huffy" was because
all I heard was someone who did not seem to bother to think about the
origional question, let alone underbuild why he thought it was impossible.

Mind you: I'm a (hobbyist) programmer. It means that *I need to know* the
how-and-why of stuff so I will not run into the same problem again later on.
It also means that a solution/information I'm looking for is not only for
the here-and-now, but also for future projects.

> If I'd known you'd get annoyed with the follow-up.

As mentioned in the above, I seem to have missed the part of the
conversation you followed-up on .... :-\

Regards,
Rudy Wieser


-- Origional message.

Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws

4ebccb88$0$6949$e4fe...@news2.news.xs4all.nl...

[Jeroen Mostert]

On 2011-11-12 13:18, R.Wieser wrote:
>> We're not in a contest
>
> My apologies. But than why did you mention it ?
>

Because it seemed silly to me that someone would object to a solution just
because it had two files in it, considering that any solution to your
original problem would already feature two files (the executable being
loaded and the one doing the loading) so what's one more?

A solution with *exactly* one file is simple (nothing being loaded, just an
executable). A solution with two files seems hard to distinguish from a
solution with three, in terms of deployment, maintenance or anything else
you can think of.

>> I'm clarifying my assumptions
>
> Again, my apologies. I thought I have precluded that assumption by stating
> "load an executable and use its exposed functions". The most common way to
> do that is by another program. I did not think it needed any more
> clarification.
>

I think we're talking past each other, so I'll leave it alone.

>> If you ask me for something impossible, I'm not going to
>> spend more time on the original question then to say "it's
>> impossible and here's why"
>
> I suggest you re-think that. One of the reasons I got "huffy" was because
> all I heard was someone who did not seem to bother to think about the
> origional question, let alone underbuild why he thought it was impossible.
>

You *did* read the link I provided, right? From Vista onwards, there's a bug
that screws up relocation. Even pre-Vista, imports aren't resolved because
the loader doesn't bother. if you read between the lines on the MSDN (but
then again, when do you not need to read between the lines there) the
picture becomes pretty clear that it doesn't work because it's not a
scenario MS supports -- they support loading an executable for resource
extraction, and that's it. The loader isn't written to put more effort into
it than necessary.

Can you fix that? Sure, patch Windows, or petition Microsoft to. Most people
wouldn't consider those realistic solutions, but if you like you can pretend
I answered that and left it there.

> Mind you: I'm a (hobbyist) programmer. It means that *I need to know* the
> how-and-why of stuff so I will not run into the same problem again later on.

Well in this case, the how and why is not too interesting, all you need to
remember is that it doesn't work -- problem solved.

--
J.

[R.Wieser]

Hello Jeroen,

> Because it seemed silly to me that someone would object
> to a solution just because it had two files in it, considering
> that any solution to your original problem would already
> feature two files (the executable being loaded and the one
> doing the loading) so what's one more?

Nope, wrong. Sorry. My hybrid EXE/DLL is aimed at a program already on
the computer. A possibility you did not think of.

> You *did* read the link I provided, right?

Nope, as I'm not using/targetting "Vista onwards" it does not apply to me.
I should have thanked you for the offering though.

> Even pre-Vista, imports aren't resolved because the loader
> doesn't bother.

Do you have any info to substanciate that ?

And by the way : if you want to talk about links, did you read the MS link I
provided in my first post ? I don't know about you, but I can't find what
you are saying anywhere in there.

Its also part of why I thought that I might have missed something -- like a
simple setting somewhere or maybe a LoadLibrary function specifically for
EXE-type files.

And another thing: why can I expose functions in an EXE (like as in a DLL)
when the OS does not allow me to use them ? Already thought about that ?

> Well in this case, the how and why is not too interesting, all
> you need to remember is that it doesn't work -- problem solved.

I'm sorry, but I seem to have trouble with the "just believe me" kind of
answers. Those tend to fade from my memory within a few days.
Fact-supported information seems to work a lot better for me.

Regards,
Rudy Wieser


-- Origional message:

Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws

4ebeca43$0$6937$e4fe...@news2.news.xs4all.nl...

[Jeroen Mostert]

On 2011-11-12 22:20, R.Wieser wrote:
>> Because it seemed silly to me that someone would object
>> to a solution just because it had two files in it, considering
>> that any solution to your original problem would already
>> feature two files (the executable being loaded and the one
>> doing the loading) so what's one more?
>
> Nope, wrong. Sorry. My hybrid EXE/DLL is aimed at a program already on
> the computer. A possibility you did not think of.
>

This post is rather long. You may want to skip to the end if you don't feel
like reading, most of it won't help you out but the end bit will.


If you're still here, great! All assumptions are now spelled out in full.
Only *now* do I know why none of my answers are useful to you.

The problem is that you wanted me to answer only your original question, in
full detail ("why doesn't calling loading executables and calling exported
functions from other executables work?"), with authoritative references and
everything. That's not what I did because it's not how I usually approach
problems. If I think something isn't practical I'll start cooking up
possible alternatives, not spend time working out exactly *why* the original
approach won't work and if, by more effort, it can be made to work. I'm not
saying that's not interesting, by the way, or that you shouldn't do it, just
that it didn't seem like a good use of *my* time to *me*.

There is probably no way you could have formulated your original request to
avoid pointless suggestions from me other than by working out all solutions
in advance and spelling them out with reasons why they're no good in your
original post, so I'm sorry about that.

If it were me, I'd simply drop the "it must be a one-file copy requirement"
because I don't see the users needing to copy two files as opposed to just
one to be a big problem. For a download, I'd offer one .ZIP to extract (or a
setup, since .ZIPs require the user to first do the "unblock" dance, which
is not as friendly -- setups just give a one-time warning you can click
through).

Your mileage may vary, but to me the original problem isn't worth the effort
-- I'd bail out at the first sign of trouble, because this is an
optimization and not something that allows people to do something truly new,
which I prefer spending time on. Again, your mileage may vary.

>> You *did* read the link I provided, right?
>
> Nope, as I'm not using/targetting "Vista onwards" it does not apply to me.
> I should have thanked you for the offering though.
>

It contains pre-Vista info about why calling functions from .EXEs doesn't work.

This is also the first time you inform us that you're not running Vista (not
targetting Vista is another matter, that's certainly interesting but not
immediately relevant), so we can take ASLR off the table as a candidate for
problems.

You can evaluate stuff I said and conclude it's not good/doesn't apply to
you by telling me why not. You can also ignore stuff I said up-front because
it seemed obvious to you it didn't answer your question. I can't tell the
difference if you don't say anything.

You don't need to thank me for anything, especially if it's not useful to
you, but if you want me to be relevant, give feedback. Keep the thoughts
flowing -- I wouldn't be spending time answering you if I wasn't interested
in seeing your problem solved, one way or another.

>> Even pre-Vista, imports aren't resolved because the loader
>> doesn't bother.
>
> Do you have any info to substanciate that ?
>

Besides the link I posted? No. I'm assuming random people on the Internet
who cared more than I do (because they really wanted it to work) know more
about it. That's the extent to which I'm willing to spend my free time.

If you want to substantiate it, fire up WinDbg and check the import table.
Better yet, you reported a crash. Fire up WinDbg and figure out what the
crash is. I'm definitely too lazy to do this just so I can be authoritative
on Usenet -- I don't think this scenario is interesting enough. Sorry about
that, but you get what you pay for.

> And by the way : if you want to talk about links, did you read the MS link I
> provided in my first post ? I don't know about you, but I can't find what
> you are saying anywhere in there.
>

This is the MSDN we're talking about. In some spots, the MSDN is an
excellent and complete source of info. Those spots are unfortunately not
numerous. In this case, the MSDN is far from complete.

It *does* document what LoadLibraryEx() does when faced with an executable
(http://msdn.microsoft.com/library/windows/desktop/ms684179), and we can
*assume* (again, I haven't fired up WinDbg to see if LoadLibrary() defers to
LoadLibraryEx(), but I'll be damned if it doesn't) that LoadLibrary() has
the same "problems": if you pass an executable module, it will act as if
DONT_RESOLVE_DLL_REFERENCES was specified, and that in turn says that "the
system does not load additional executable modules that are referenced by
the specified module".

From that we can infer that at least some modules will not have their
imports resolved because they're not loaded. I suppose modules like KERNEL32
*might* be resolved correctly because they're already loaded/implicitly
loaded, but it might also very well be that no resolving is done, and ASLR
then makes sure that no function can be called correctly -- even odds,
should be checked, as there is no documentation and at least one person
reported problems consistent with this theory (you) I haven't looked further.

This is all speculation, albeit reasonable speculation. You can get down to
the bottom of things if you want to.

> And another thing: why can I expose functions in an EXE (like as in a DLL)
> when the OS does not allow me to use them ? Already thought about that ?
>

Sure. DLLs and EXEs are the same file format. The loader doesn't treat them
the same, but it makes no sense for other tools to treat them differently.
That's extra work.

I have no difficulty imagining nobody at Microsoft bothered to implement an
error mode for the linker where it goes "you know, on an NT platform, you
will have almost no chance of calling these functions correctly, so I'll do
the right thing and give an error that you shouldn't export these functions
from an .EXE" (for all I know this worked on Windows 3.1 or even Windows 95
-- I don't think so, but I don't know).

It's not that the OS doesn't allow you to use them -- it's that it goes to
no trouble to *enable* you to use them. As a programmer you can probably
appreciate not putting in effort to make things work you don't support,
unless people encourage you to. I don't think MS has been encouraged by
anyone to make this scenario (which you have to admit is rather unusual)
working reliably.

>> Well in this case, the how and why is not too interesting, all
>> you need to remember is that it doesn't work -- problem solved.
>
> I'm sorry, but I seem to have trouble with the "just believe me" kind of
> answers. Those tend to fade from my memory within a few days.
> Fact-supported information seems to work a lot better for me.
>

If you want more information on how to use WinDbg to get it, just give a holler.

If you want authoritative info, this is not the right place to get it. You
can open a support ticket with MS, or use the officially sanctioned forums
by MS (those are at http://www.microsoft.com/communities/forums/default.mspx
-- this NG has officially been decommissioned by MS, even though there are
still people here).

--
J.

[Alf P. Steinbach]

On 07.11.2011 11:18, R.Wieser wrote:
> Hello All,
>
> When I use LoadLibrary on a DLL its DllMain gets called with the apropriate
> arguments. It enables me to (among others) initialize and finalize its use.
>
> I need to be able to load an executable and use its exposed functions.
> The
> problem is that I can't seem to find the equivalent to a DLL initialisation
> and finalisation entries ...

There is no such thing.

Instead, factor out the relevant functions and put them in a DLL.

> The question therefore is : Does an executable-loaded-as-libraray have such
> methods and if so where can I find info about it (MS own site does not even
> hint at it*)

Nope.

But if your goal is merely to export functionality from a single
executable, then you can do that by letting the executable be a COM server.

It will then be an out-of-process COM server, with marshaling involved
for calls of the functions.

So it's better to put those functions in a DLL.

If you can.


Cheers & hth.,

- Alf

[Leo Davidson]

On Nov 12, 9:20 pm, "R.Wieser" <addr...@not.available> wrote:

> And another thing: why can I expose functions in an EXE (like as in a DLL)
> when the OS does not allow me to use them ?  Already thought about that ?

I don't know if it is an intentional feature of Windows, or just
something that works by happy accident, but being able to expose
functions in an EXE is useful. It allows other code, be it in a plugin
DLL or a third-party (static or dynamic) library, to GetProcAddress
those functions and use them as callbacks.

This saves having to pass every library or plugin a table of function
pointers (or similar) if you want to provide them with callbacks into
your EXE. Instead, they can simply look them up themselves.

OpenSSL is a well-known library which uses this in some places. It's
also something we took advantage of in Directory Opus to provide
plugins DLLs with an API of utility functions, without having to
change the existing way our plugin DLLs are initialised or worry about
the function table changing over time.

[Jeroen Mostert]

On 2011-11-13 09:30, Leo Davidson wrote:
> On Nov 12, 9:20 pm, "R.Wieser"<addr...@not.available> wrote:
>
>> And another thing: why can I expose functions in an EXE (like as in a DLL)
>> when the OS does not allow me to use them ? Already thought about that ?
>
> I don't know if it is an intentional feature of Windows, or just
> something that works by happy accident, but being able to expose
> functions in an EXE is useful. It allows other code, be it in a plugin
> DLL or a third-party (static or dynamic) library, to GetProcAddress
> those functions and use them as callbacks.
>

Neat. To clarify, this is the scenario where the executable is the main
module, right? That's consistent with the "imports are not resolved" theory
because imports are resolved for the executable loaded as the main module.

--
J.

[R.Wieser]

Hello Alf,

> So it's better to put those functions in a DLL.

The funny thing is that that is what I currently have. :-)

I just thought to see if I could merge them into a single file.

Regards,
Rudy Wieser


-- Origional message:

Alf P. Steinbach <alf.p.stein...@gmail.com> schreef in berichtnieuws
j9nmbo$if2$1...@dont-email.me...

[R.Wieser]

Hello Leo,

> ... to GetProcAddress those functions and use them as callbacks.

I was wondering about the same, but discarded that possibility.
Reason ? One "initialize" call providing the call-back address as an
argument (among others) is all it takes.

Supporting information: I've seen several function-calls (mostly
enumerations or sorting) to which a call-back address is provided as an
argument. I've never even seen/heard of such a static callback (resolved
at load-time) mentioned anywhere, let alone seen a DLL which uses it...

But yes, its possible.

Regards,
Rudy Wieser


-- Origional message:

Leo Davidson <leonudel...@gmail.com> schreef in berichtnieuws
c5aad207-be05-4ef3...@r9g2000vbw.googlegroups.com...

[R.Wieser]

Hello Jeroen,

> The problem is that you wanted me to answer only your original
> question, in full detail ("why doesn't calling loading executables
> and calling exported functions from other executables work?"),
> with authoritative references and everything.

Ehhh ... Well, that is how I felt after a few of your suggestions, yes.
An agressive defensive measure I'm afraid.

You see, I wondered why someone would suggest to me to create a second
program to be able to access both parts in the hybrid. Creating a single
program from two (the EXE and DLL) only to need a second program to be able
to use it. It would fully nullify the reason of the merging ...

> If I think something isn't practical

... than you could be looking at something at a different angle than a
(random) other person ...

> I'll start cooking up possible alternatives,

I do the same, but normally only *after* the 'not practical' part of it is
defined.

> not spend time working out exactly *why* the original approach
> won't work and if, by more effort, it can be made to work.

That might be a difference between us two than. I always like to know the
why of it. It helps me not to stumble into the same pitfal again, and
sometimes even to find an (easy) alternative.

> just that it didn't seem like a good use of *my* time to *me*.

.. Which, alas, made us talk in talk in different directions.

> There is probably no way you could have formulated your original request
to
> avoid pointless suggestions from me other than by working out all
solutions
> in advance and spelling them out with reasons why they're no good in your
> original post, so I'm sorry about that.

:-) In the past I tried both methods (minimal info and full disclosure) and
found that providing as little as possible also means that there is little
to stumble over, generating the least ammount of static in the replies.

> If it were me, I'd simply drop the "it must be a one-file copy
requirement"

Its actually not a requirement. Its an avenue I wished to explore.
Currently I'm using the two-file solution (EXE and seperate DLL), and it
works well. It would have been handy if it would have been possible.

> It contains pre-Vista info about why calling functions from .EXEs doesn't
work.

After your previous mentioning I decided to read it anyway. What I saw was
a mentioning of different algorithms (a bug) which could be the cause of
trouble for someone.

As for the reason of it not working, the not resolving of the loaded
executable (dll functions and maybe also relocation) ? Yes, I got the
feeling that might have been it (I mentioned as much in my "update" post).

It however did not contain any reasoning for this behaviour. Do you know
(why a DLL is resolved and an EXE not) ?

> I can't tell the difference if you don't say anything.

The problem is that that goes two ways. At my end I was really wondering
about where your responses came from. :-\

> > Do you have any info to substanciate that ?
> >
> Besides the link I posted? No. I'm assuming random people on the Internet
> who cared more than I do (because they really wanted it to work) know more
> about it. That's the extent to which I'm willing to spend my free time.

And there I was, hoping to find one of those "random people" :-)

> If you want to substantiate it, fire up WinDbg and check the import table.

That is pretty-much exactly what I was thinking about myself. Alas, it can
only serve to confirm my suspicion(s). It cannot shed any light on how to
solve it (which function/method to use instead) ...

> Sure. DLLs and EXEs are the same file format. The loader
> doesn't treat them the same,

Thats the question: Why ? Is there a problem with doing so ? With the
absense of information I'm failing to see the logic in them being treated
differently.

> I have no difficulty imagining nobody at Microsoft bothered to ...

Not funny, but quite true.

> It *does* document what LoadLibraryEx() does when faced with an executable

Yes, after posting my question I thought about checking that one too. And
yes, it confirmed that its "little brother" would probably behave the same,
and that the LoadLibrary approach would most likely not be usable.

To be honest, I realized that after I posted my first question. Hence my "-
update" post about 3 hours later.

But I thought that maybe there would be a badly-documented other way. Like
a "secret" bit in the LoadLibraryEx flags. Or another function.

> It's not that the OS doesn't allow you to use them -- it's
> that it goes to no trouble to *enable* you to use them.

No, the other way around: If the executable cannot expose its internal
functions (in any meaningfull way), why than allow functions (like
GetProcAddr) which cannot return any meaningful data to return anything else
than an error ?

> As a programmer you can probably appreciate not
> putting in effort to make things work you don't support,
> unless people encourage you to.

I do, and that is what made it odd for me: From my POV it looks like some
one deliberatily changed the behavior of the LoadLibrary function to handle
an EXE and a DLL different in this respect (resolving of functions and/or
relocation).

But than again, I cannot bring this past MS. Its actions are, at times,
allmost indistinguable from being random ... "Bugs with seniority" equal
"features" and all that. :-)

Oh, by the way: both an EXE as well as a DLL have the "executable" bit set
in its header. The only difference for a DLL is that it has the "I'm a
DLL" -bit set too.

> If you want authoritative info, this is not the right place to get it.

Maybe not for the info itself, but I could imagine that someone here knows
where to find it. It would be a helluva bit better han having to have to
scourge a metric ton of websites hoping to find a hint to such info (not
that I'm a stranger to that).

> You can open a support ticket with MS, or use the officially
> sanctioned forums by MS

I'm sorry, but I have less than good experiences with its payed support, and
I'm afraid that my question is not related to any specific language, program
or project. I would not, in that list/those sublists, know where to put it
(granted, I did not check them all out). But I'm open to suggestions (to
where to put a question like mine) though.

Regards,
Rudy Wieser


-- Origional message:
Jeroen Mostert <jmos...@xs4all.nl> schreef in berichtnieuws

4ebef8bb$0$6926$e4fe...@news2.news.xs4all.nl...

[Leo Davidson]

Yes, exactly.

FWIW, OpenSSL uses *both* methods of allowing the main EXE to provide
static callbacks which the library code uses to access the EXE's
version of CRT functions (malloc, etc.) and similar.

Parts of OpenSSL use init functions that the EXE calls to pass
function pointers to the library, but at least one part relies (in
some circumstances) on your EXE exporting functions that the OpenSSL
code tries to GetProcAddress. (The exports are a bit hidden as you're
just told to include a .c file in your project, but that's what the .c
file does if you look inside it.)

I get the impression that this has evolved over time, and maybe
someone got sick of adding more and more init methods (you can't
change the old ones because it would break binary compatibility
between old clients and new DLLs) and decided using exports was easier
for future changes. Or maybe each thing was just done by a different
person who was unaware of the others.