VC 6.0 Linker/Compiler problem

Hello,
I have the following question:
I am trying to create two win32 console applications with MFC support First.exe and Second.exe. Second.exe is exporting a function to First.exe using "__declspec(dllexport)" and First.exe is calling the exported function
Code snippet Second.exe:

Code:

---

int global;
__declspec(dllexport) int a()
{
    unsigned int dummy;
    dummy = 0xFFFFFFFF;
    dummy = 0xFFFFFFFF;
    dummy = 0xFFFFFFFF;
    .
    .    /*-> Hundreds  of "dummy = 0xFFFFFFFF;"*/
    .
    dummy = 0xFFFFFFFF;

  global = 1;
  return 1;
}

---

Code snippet First.exe:

Code:

---

__declspec(dllimport) int a();

int _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) {
  // initialize MFC and print and error on failure
  // ....
  a();
  return 0;
}

---

Depening on the number of "dummy = 0xFFFFFFFF;" used in Secound.exe; First.exe is running normal or is crashing at runtime with eror message: "Unhandled excepton in FIRST.exe(Second.exe): 0xC0000005: Access Violation.". First.exe is running fine if only few dummy instructions ("dummy = 0xFFFFFFFF") are used and is crashing when hundreds of dummy instructions are used in Second.exe.

When the program crashes then it always crash at instruction "global = 1;" that is translated in disassembly to:
"mov dword ptr ds:[416668h],1" where 416668h is the address of variable "global" out of the map file of Second.exe"
When the program runs without errors the instruction "global = 1;" is translated in disassembly to:
"mov dword ptr [Secound_NULL_THUNK_DATA+34Ch (00415668)],1" where 415668 is the address of variable "global" out of the map file of Secound.exe

Does anyone know why I'm having this problem and how could I fix it ?

Thanks

As far as I know you can't export functions from exes the way you can from dlls - __declspec(dllexport). A dll is maped into the memory of the calling process, whereas another exe is a seperate process. There are methods of inter-process communication, but exporting functions from exes isn't one of them. Related to that, all windows addresses aren't actual physical addresses. They are entirely virtual. In that sense, they aren't addresses at all but 'handles' to memory, and only the OS itelf knows where the physical memory is at. So if you want to share memory or functions between exes, you are going to have to find another way to do it, such as memory maped files. You might want to look at Post #31 in this thread...

32 bit dll in 64 bit language - Page 3 - PowerBASIC Peer Support Forums

Ok thanks for the response. I was somehow expecting such a response.

Quote:

---

Originally Posted by hanniball

Ok thanks for the response. I was somehow expecting such a response.

---

That and the matter that your source code itself makes no sense whatsoever...

I'm going to suggest three things and I hope you will receive it as helpful advice (as intended)...

1) Get a good book on whatever language you are trying to learn... take it in as a study project, type up and compile all the examples, work with them play around with the code until you understand it, then move to the next section... page by page.

2) Learn your way around the Microsoft Developer Notes library ... MSDN Library

3) Find a good tutorial on MFC and windows GUI programming and treat it like a study project.

You'll be glad you did!

Quote:

---

Originally Posted by CommonTater

That and the matter that your source code itself makes no sense whatsoever...

---

The scope of the posted code was to prof a point not to be compilable or to do something useful.

I was able to export using "__declspec(dllexport)" a function from a executable file ("*.exe") to another executable file.

The idea of the posted source code is to show that it is possible to export a function from a executable file when the executable file is small. When the exporting executable file (second.exe out of my example) get's bigger it is no longer possible to export functions from it.
The whole idea of the dummy instructions is to make the output file bigger.

My question is why isn't it possible to export a function from a exe file when the exe file get's bigger?

Ok you can export a function... but what are you going to do with it?

There's no way you're going to call a function in another EXE file because the addressing is virtual and you can't get the correct address at run time.
It works with DLLs because the DLL is loaded into the main executable's address space, creating a known address at run time.

There are other and far better ways of doing interprocess communication... memory mapped files, interprocess messaging, etc.