can a refered dll have main()

[chiwing]

i have a idea that write a dll which have main();
but it is refered dll, which means it called by a exe.

why i think have this idea -->because if it can have a main , then it can use global variables to replace formal parameter, local variables, so that it is easier to get other functions' variable in other functions ~ ~



Thanks

[jeffbmartinez]

I'm not 100% sure what you're trying to hide, bu it's possible to look into a dll just like it's possible to look into an exe, so I'm not sure what you want is going to be realized.

Secondly, if you plan on maintaining this code at all in the future, or want to avoid annoying bugs, you should try to keep from using global variables. It's usually better to pass values into functions only as you need them.

[chiwing]

hi, jeffmbartinez

but I don't Understand why u say it will have bugs??

do u mean that when global variable go into function from main(), their value may be change?
or
do global variables' value will not be the same when from function to other functions

don't global variable represent a actual memory address (e.g. 0x21F11001)

i used to to use global variable, so we don't need to know what is argument, formal parameter, local variable

am i wrong?

if so , please amend

[kbw]

More more places a variable is visible, the more difficult it is to be sure of program correctness.

As programs get larger more and more partitioning is needed to seperate parts in order to understand it, how it works and reduce error.

Along the way, parameterised procedures, modules, abstract data types, objects and tiers have all been developed to this end.

Why on earth would you want to rename a library to have the same name as an executable program? The load rules are different.

[chiwing]

hi, kbw
do you mean that the conflict is my mother exe have a main(), and the son dll also have a main()

actually my main program main body is name as "start()"

[kbw]

A DLL is a library that contains (potentially) shared code between programs. It is just code and does not have an execution thread of its own. The thread execution starts in the program with main() (or WinMain). The program can choose to do all sorts of things, like loading a DLL and calling functions in it, or spawning other threads, or starting other programs and so on.

A DLL is just code and data, there is no thread of execution.

[chiwing]

thanks for kbw your reply

i am now have a question that can a dll call other exe function?
i mean the control sequence : 1.exe --> 2.dll--> 3.exe--> 2.dll--> 1.exe

what the code is ?

thanks

[kbw]

I'm not clear on what you mean by

2.dll--> 3.exe

I take it you mean by 1.exe --> 2.dll, a program calling a function in a DLL. Well, an example is:

#include <stdio.h>
int main()
{
    puts("hello world\n");
    return 0;
}

This program calls puts in the C runline library (libc, glibc, ... on *nix, msvcrt.dll for Visual Studio on Windows).

You can load DLLs (Windows) and Shared Libraries (Unix) at runtime, lookup a function by name and call it, then unload the library. But that doesn't change anything here.

[Duthomhas]

Both a DLL and an EXE are a PE32 file, which is basically an organized collection of code and data. Whether or not they get their own thread of execution depends on what you mean by that.

The Windows operating system itself is just a collection of DLLs. Every program that runs is automatically linked to kernel32.dll, which is the core of the operating system.

As part of a DLL, there are (1) import and (2) export sections which list the routines it (1) needs to work and (2) what routines can be imported for use by other PE32 modules, whether EXE or DLL.



However, what you are trying to do sounds fishy. When you use LoadLibrary() to access a DLL's (or EXE's) routines, it gets loaded into your process's address space. Hence, you achieve no data-access advantage by splitting stuff up like that. (In fact, it makes it messier.)

What exactly are you trying to write? Perhaps we can suggest a better structure to help you out than a bunch of global variables.