can we export any function in exe like in a dll?
Allen
can we do export any functions from a exe? and in these functions, can we
use any APIs in the runtime without "access violation"?
thanx.
--
Allen Zhan
az...@waytechinc.com
--
Allen Zhan
az...@waytechinc.com
Robert Quirk
"Allen" <az...@waytechinc.com> wrote in message
news:e8BWz53ECHA.2624@tkmsftngp04...
Alan Carre
You can export functions from an EXE however this is not advisable because
the EXE's startup code does not get executed on LoadLibrary (ie.
mainCRTStartup will not get called, nor the code that normally executes
before control is passed to the program's entry point). Further, no static
data will be initialized and no function addresses will be valid
(CreateProcess patches function and variable addresses before jumping to the
exe's entry point).
If you 'CreateProcess' instead, then the .EXE will execute correctly,
however you will not be able to call the exported functions from within the
address space of the EXE, so you will get the same result.
- Alan
"Allen" <az...@waytechinc.com> wrote in message
news:e8BWz53ECHA.2624@tkmsftngp04...
Robert Quirk
combined is the following ..
The EXE starts
It calls a DLL function
The DLL function calls a function which has been exported from the EXE
In this case all the CRT calls have been called for you by running the EXE.
"Allen" <az...@waytechinc.com> wrote in message
news:e8BWz53ECHA.2624@tkmsftngp04...
Joseph M. Newcomer
reason you export functions from a DLL is so that when the DLL is implicitly loaded, the
imported names can be resolved. Nothing ever imports a .exe file, so there is no semantic
meaning to the idea of "exporting" from a .exe.
joe
On Fri, 14 Jun 2002 16:36:25 +0800, "Allen" <az...@waytechinc.com> wrote:
>it is easy to export functions from a dll.
>can we do export any functions from a exe? and in these functions, can we
>use any APIs in the runtime without "access violation"?
>
>thanx.
>
>--
>Allen Zhan
>az...@waytechinc.com
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm
Alan Carre
since someone could Load the .EXE and call one of the exported functions
(incorrectly). Usually it's best to use some sort of callback mechanism if
you want to have the .EXE called-back on.
- Alan
"Robert Quirk" <robert...@emrad.com> wrote in message
news:1024063709.27625....@news.demon.co.uk...
![Doug Harrison [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/AOh14GiHXn8Hz6xRD8R5XxenIbA2-iyO8yVtz-Be3SZN=s40-c)
Doug Harrison [MVP]
>it is easy to export functions from a dll.
>can we do export any functions from a exe?
While it isn't a common thing to do, the answer is yes. Users will
most likely use GetProcAddress to "import" the functions from the EXE.
For example, an interpreter which supports loading functions from DLLs
for extension purposes might be specially built with some of these
normally DLL-based extensions linked into the EXE. So its dynamic
loader can work normally, a simple modification is to maintain a list
of these statically linked modules and look inside the EXE when
they're referenced. In effect, the EXE imports functions from itself.
So that's one reason an EXE will export functions.
To see which Windows executables export symbols, at the command line
try:
dumpbin /exports c:\windows\system32\*.exe
In WinXP a handful of system EXEs export symbols; some kernel EXEs
export thousands of symbols.
>and in these functions, can we
>use any APIs in the runtime without "access violation"?
Make sure everyone links dynamically to the same CRT DLL, e.g.
msvcrt.dll for VC6 release builds, and you should be fine.
--
Doug Harrison
Microsoft MVP - Visual C++
Eluent Software, LLC
http://www.eluent.com
Tools for VC++, VS.NET, and Windows
Allen
would you send me a sample for that?
in my case,
(1)i add a .def to my project, build a.exe.
(2)in b.exe, i use LoadLibrary("a.exe"), and GetProcAddress(myhDll,
"my_fun"), it works.
but, we can not use any api in "my_fun" function of "a.exe", it said:
"unhandled exception KERNEL32.DLL Access Violation..."
Regards,
--
Allen Zhan
az...@waytechinc.com
"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
news:d29kgu8v2i6m94g4g...@4ax.com...
Allen
pls see my reply for Doug Harrison, i found that we can load "exe" and it
works.
but i can not use any API in runtime, it show a error"access voilation".
you can send me some sample about "callback mechanism" as you said? someone
told
me that i have to use the com sever. it is right ?
thanx.
Regards,
--
Allen Zhan
az...@waytechinc.com
"Alan Carre" <al...@twilightgames.com> wrote in message
news:eEpJaV8ECHA.864@tkmsftngp04...
Michael (michka) Kaplan
The issue is that unless the EXE is in the same process of the DLL (i.e.
unless the EXE *is* the one for the process) then there is no way to do it.
Allen, is that the case?
If not, then the answer is NO.
--
MichKa
Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/
International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/
"Robert Quirk" <robert...@emrad.com> wrote in message
news:1024059916.25938....@news.demon.co.uk...
Allen
i wish that i can export funcitons from a a.exe, and another b.exe file can
import these funcitons.
so i use a .def file of a.exe project. and then i call these functions in
b.exe. but as i said, we can not use any api
in the runtime. we got error about"access voilation". i guess that maybe it
is impossible to export functions in exes?
someone told me that i have to use the com server...
any advise?
--
Allen Zhan
az...@waytechinc.com
"Michael (michka) Kaplan" <forme...@nospam.trigeminal.spamless.com> wrote
in message news:Oiwrf1aFCHA.436@tkmsftngp07...
Doug Harrison [MVP]
>Hi,
>
>would you send me a sample for that?
>
>in my case,
>
>(1)i add a .def to my project, build a.exe.
>(2)in b.exe, i use LoadLibrary("a.exe"), and GetProcAddress(myhDll,
>"my_fun"), it works.
>
>but, we can not use any api in "my_fun" function of "a.exe", it said:
>"unhandled exception KERNEL32.DLL Access Violation..."
I've only ever tried using __declspec(dllexport) from an EXE, and
having DLLs or the same EXE use GetProcAddress on the exported
functions. In your case, there is no DllMain for LoadLibrary to call,
so various initializations won't be performed, e.g. global objects
won't be constructed, and the EXE startup code won't be run. So your
imported functions may be very limited in what they can do in this
context. Have you determined if you can successfully call an empty
function? If you can't do that, then something more fundamental is
wrong.
Allen
operation. but we can not use any API...
humm, maybe we have to use com server?
--
Allen Zhan
az...@waytechinc.com
"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
news:hhmqgus562fgl0s0j...@4ax.com...
Alan Carre
*already* in the same address space of the EXE), then a simple callback
would suffice. However, if you are not intending to run the EXE explicitly,
you'll need to use DCOM.
To use the DCOM mechanism, you'll need to export some sort of COM interface
from your EXE. Then, from the second EXE, you can create an instance of said
interface (whatever it is) and call functions on it. This will cause the
first EXE to be properly loaded. It would be best to limit your calls (into
the first EXE) to members of the interface you construct... I'm not sure
what happens if you create the interface as an "inproc server" in this case
(ie. will the first EXE be in the address space of the second EXE? Not
sure).
- Alan
"Allen" <az...@waytechinc.com> wrote in message
news:eJyVjgaFCHA.2488@tkmsftngp04...
Michael (michka) Kaplan
--
MichKa
Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/
International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/
"Allen" <az...@waytechinc.com> wrote in message
news:#jNBW$aFCHA.2488@tkmsftngp04...
Ismail PAZARBASI
I don't have an idea about exporting/importing functions from exe files,
but I can just suggest you a way.
typedef VOID (WINAPI *THISISYOURFCT)(void *);
typedef BOOL (WINAPI *YOURFCTCALL)(HINSTANCE);
static void WINAPI InjectFunctionToMemory(void *pParam)
{
THISISYOURFCT tfct = (THISISYOURFCT)pParam;
tfct();
}
static void WINAPI MarkFunctionEnd(void)
{
}
void WINAPI LoadFunction()
{
HINSTANCE hinstExe = GetModuleHandle(your_exe_file_name_as_LPCTSTR);
HANDLE hheap = GetProcessHeap();
const int cbFuncSize = ((LPBYTE)(DWORD) MarkFunctionEnd -
(LPBYTE)(DWORD) InjectFunctionToMemory);
void *pMyMem = HeapAlloc(hheap, HEAP_ZERO_MEMORY, cbFuncSize);
memcpy(pMyMem, InjectFunctionToMemory, cbFuncSize);
YOURFCTCALL yfc=(YOURFCTCALL)GetProcAddress(hinstExe, your_fct_as_LPCTSTR);
yfc(your_void_pointer_param_here);
}
........
Something like this. I have seen such a code in MSDN, its been a long time.
By a similar way, you can load your function from an exe to your heap, and
call it. Learn more about above functions.
Regards.
Ismail PAZARBASI
"Allen" <az...@waytechinc.com> wrote in message
news:e8BWz53ECHA.2624@tkmsftngp04...
Doug Harrison [MVP]
>we can do return a value, we can do simple codes, e.g, we can do "1+1=2"
>operation. but we can not use any API...
>humm, maybe we have to use com server?
Maybe. Or can you put the functions into a DLL, which both executables
mentioned in your previous message will use?
Ismail PAZARBASI
Regards.
Ismail PAZARBASI
Allen
api... but it can call these functions from
a exe.
--
Allen Zhan
az...@waytechinc.com
"Ismail PAZARBASI" <gl...@cdrom.com> wrote in message
news:#TM$5NmFCHA.2680@tkmsftngp12...
Ismail PAZARBASI
I do not understand that api thing; What API does this function use? Of
course, it will use Win32 API to work on a win32 machine. And, it does not
require any additional libraries (i.e. DLLs). As you know, all those
functions are defined, and implemented in Win32 Platform SDK. It can work on
all Windows machines, I think it can work with Windows 95, and NT also.
Again, I do not know, if you can export a function from exe, or not.
However, following code simply works for DLLs. Following API calls can load
an executable file by other means, it will let you load your function to
your process' heap. You have to load this exe into your process' heap to use
it.
Tell what you want to do exactly, why you do not want to use an API? And
what API you mean, if it is not Win32 API? You SHOULD use Win32 API to load
function into your heap. (no offence!!)
Regards.
Ismail PAZARBASI
"Ismail PAZARBASI" <gl...@cdrom.com> wrote in message
news:#TM$5NmFCHA.2680@tkmsftngp12...
Michael (michka) Kaplan
As has beern stated here, you CANNOT export a function from an EXE and call
it from another EXE. Period. End of sentence.
Please re-read the above until it is understood. At least 21 times, if not
more!!!
--
MichKa
Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/
International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/
"Ismail PAZARBASI" <gl...@cdrom.com> wrote in message
news:ekU32XnFCHA.2652@tkmsftngp13...
Allen
are free,
maybe you are willing to debug it?
--
Allen Zhan
az...@waytechinc.com
"Ismail PAZARBASI" <gl...@cdrom.com> wrote in message
news:ekU32XnFCHA.2652@tkmsftngp13...
Allen
maybe you can explain your ideal more carefully? yes, i know it is not good
plan to export
from a exe.
but as we know:
(1) both dll and exe are the window's executable. but dll has to share the
data segment with
calling application(exe). so why not we use a exe like a dll?
(2) in windows' system, many exe files work as dlls. why. how to explain
this?
thanx.
--
Allen Zhan
az...@waytechinc.com
"Michael (michka) Kaplan" <forme...@nospam.trigeminal.spamless.com> wrote
in message news:uo5k7pnFCHA.2492@tkmsftngp13...
Michael (michka) Kaplan
> maybe you can explain your ideal more carefully?
They are not my ideals, they are the way things work under Win32.
> yes, i know it is not good plan to export from a exe.
Progress!
> but as we know:
> (1) both dll and exe are the window's executable. but dll has
> to share the data segment with calling application(exe).
????? That is not what is happening, it sounds like you are trapped in the
Win16 world here. Win32 gives each process 4gb of virtual address space and
it does not let different processes talk to each other without doing a lot
of special work.
> so why not we use a exe like a dll?
Thats not how things work, sorry.
> (2) in windows' system, many exe files work as dlls. why. how
> to explain this?
You are wrong; EXEs do not work as DLLs.
Spend some time at the following web site:
http://msdn.microsoft.com/library/en-us/vccore/html/_core_DLL_Topics.asp
Particularly the first article "Differencds between applications and DLLs"
but also other ones. Perhaps it will help you understand the way things work
here?
Doug Harrison [MVP]
>"Allen" <az...@waytechinc.com> wrote...
>
>> maybe you can explain your ideal more carefully?
>
>They are not my ideals, they are the way things work under Win32.
>
>> yes, i know it is not good plan to export from a exe.
>
>Progress!
>
>> but as we know:
>> (1) both dll and exe are the window's executable. but dll has
>> to share the data segment with calling application(exe).
>
>????? That is not what is happening, it sounds like you are trapped in the
>Win16 world here. Win32 gives each process 4gb of virtual address space and
>it does not let different processes talk to each other without doing a lot
>of special work.
>
>> so why not we use a exe like a dll?
>
>Thats not how things work, sorry.
>
>> (2) in windows' system, many exe files work as dlls. why. how
>> to explain this?
>
>You are wrong; EXEs do not work as DLLs.
>
>Spend some time at the following web site:
>
>http://msdn.microsoft.com/library/en-us/vccore/html/_core_DLL_Topics.asp
>
>Particularly the first article "Differencds between applications and DLLs"
>but also other ones. Perhaps it will help you understand the way things work
>here?
I don't think he's ever been talking about one process importing a
function from another process. An EXE, on the other hand, is just a
file. As I described in another message, it's certainly possible for
an EXE to export functions which are imported using GetProcAddress by
DLLs loaded into its process or by the process itself. As documented,
LoadLibrary can map an EXE into another's address space, and in one of
his replies, he stated he's using LoadLibrary and GetProcAddress. I
can find no prohibition on using GetProcAddress on an EXE loaded this
way, and I see no reason it wouldn't work, modulo the initialization
issues I described in an earlier message. Here's a demonstration, in
the form of two programs, exe1.cpp and exe2.cpp.
exe1.cpp:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
__declspec(noreturn)
void
die(const char* msg)
{
fputs(msg,stderr);
fputc('\n',stderr);
exit(EXIT_FAILURE);
}
int main()
{
HMODULE hmod = LoadLibrary("exe2.exe");
if (!hmod)
die("LoadLibrary");
int (*f)() = (int (*)()) GetProcAddress(hmod,"f");
if (!f)
die("GetProcAddress");
printf("f returned: %d\n",f());
return 0;
}
exe2.cpp:
extern "C"
__declspec(dllexport)
int
f()
{
return 314159;
}
int main()
{
return 0;
}
Create these two source files in your temp directory and compile
(compiler output elided):
D>cl exe1.cpp
D>cl exe2.cpp
D>exe1
f returned: 314159
Like I said in my earlier message, "There is no DllMain for
LoadLibrary to call, so various initializations won't be performed,
e.g. global objects won't be constructed, and the EXE startup code
won't be run. So your imported functions may be very limited in what
they can do in this context." I still suspect that's the wall he's
running into.
Doug Harrison [MVP]
>we can do return a value, we can do simple codes, e.g, we can do "1+1=2"
>operation. but we can not use any API...
Which API? Like I said in my earlier message, various initializations
aren't done when you LoadLibrary one EXE from another, so I would
expect any function that depends on these initializations to fail.
Allen
sorry for my poor English. but i want to say that you know me fully.
yes, LoadLibrary and GetProcAddress can work well. yes, your codes will
return values.
and yes, the problem is that"So your imported functions may be very limited
in what
they can do in this context".
the msdn about ""Differencds between applications and DLLs" maybe raw. i can
not find
more good message for me... humm, now i decide to give up and try to use the
com sever.
thanx.
--
Allen Zhan
az...@waytechinc.com
"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
news:qdktguk6p38v9mvvc...@4ax.com...
Michael (michka) Kaplan
> I don't think he's ever been talking about one process importing a
> function from another process. An EXE, on the other hand, is just a
> file. As I described in another message, it's certainly possible for
> an EXE to export functions which are imported using GetProcAddress by
> DLLs loaded into its process or by the process itself. As documented,
> LoadLibrary can map an EXE into another's address space, and in one of
> his replies, he stated he's using LoadLibrary and GetProcAddress. I
> can find no prohibition on using GetProcAddress on an EXE loaded this
> way, and I see no reason it wouldn't work, modulo the initialization
> issues I described in an earlier message.
Actually, since all EXEs load at the same base address -- and since they do
not have the facility to relocate function pointers, attempting to
LoadLibrary the EXE will fail.
<snip sample>
> Like I said in my earlier message, "There is no DllMain for
> LoadLibrary to call, so various initializations won't be performed,
> e.g. global objects won't be constructed, and the EXE startup code
> won't be run. So your imported functions may be very limited in what
> they can do in this context." I still suspect that's the wall he's
> running into.
And he still has not given a single reason for why he would try to do such a
thing? This is the sort of nonsense request that is genearlly indicative of
someone who is not clear on what they want?
Allen
a
> thing?
sorry, it is a commerce's secret. it is difficult to say the orignal design.
--
Allen Zhan
az...@waytechinc.com
"Michael (michka) Kaplan" <forme...@nospam.trigeminal.spamless.com> wrote
in message news:#0XVKOpFCHA.2552@tkmsftngp12...
Michael (michka) Kaplan
Use a flipping DLL, please. Have the two EXEs deal with the same DLL or
something.
--
MichKa
Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/
International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/
"Allen" <az...@waytechinc.com> wrote in message
news:u703QWpFCHA.2740@tkmsftngp13...
Doug Harrison [MVP]
>Actually, since all EXEs load at the same base address -- and since they do
>not have the facility to relocate function pointers, attempting to
>LoadLibrary the EXE will fail.
>
><snip sample>
My example demonstrated that it doesn't just "fail", but yeah, that's
a problem. I can demonstrate it by having my exported function return
a string literal. The program exe1 (suitably modified) then prints
gibberish. Thanks for pointing that out.
>And he still has not given a single reason for why he would try to do such a
>thing? This is the sort of nonsense request that is genearlly indicative of
>someone who is not clear on what they want?
At this point, I agree the LoadLibrary approach is unworkable. It's
even more restrictive than I previously described.