Jitu
asked on
Dll Vs exe...(definition...)
What is the difference between a dll and a Exe ?
Is the ordinary Exe same as static linked library ?
I read that 'Dll is loaded in the memory only when required', same way we could also have an exe called only when we require it, so where is the advantage ?
What about unloading the dll ?
Is the ordinary Exe same as static linked library ?
I read that 'Dll is loaded in the memory only when required', same way we could also have an exe called only when we require it, so where is the advantage ?
What about unloading the dll ?
The most important difference is that an EXE is a program that can be run by the user or by another program. When you run an EXE it loads it into memory and then loads any DLLs it uses and calls the EXE's main procedure. Although EXEs and DLLs share the same format, the OS will not allow a DLL to be executed.
A DLL is not meant to be run. It is a library. It is a collection of procedures and data that can be used by other code modules (by EXEs and other DLLs).
>>Is the ordinary Exe same as static linked library ?
Not at all. An EXE is not a library in any sense. A library is a collect of code ot data that can be used by other code. An EXE cannot be used in this way. A DLL can, thus a DLL is a library, but not a static linked library.
>> read that 'Dll is loaded in the memory only when required',
>> same way we could also have an exe called only when we
>> require it, so where is the advantage ?
An EXE is loading into memory when somone wants to run it. That could be the user, or another program. A DLL is loaded when an EXE or DLL is loaded that uses it (or when loaded with LoadLibrary). When the DLL is loaded it does not "run" like and EXE runs. It sort of just "sits there" and waits for other code modules to use the procedures and data it provides.
>> so where is the advantage ?
There is no advantage, they serve different purposes. The EXE is a program It is the ultimate goal of programming. it is something useful to the user. A DLL is a library that can be used to make useful EXEs but by themselves they are useless. In the end an EXE is necessary to make the the DLL do userful things.
>> What about unloading the dll ?
What about it?
A DLL is not meant to be run. It is a library. It is a collection of procedures and data that can be used by other code modules (by EXEs and other DLLs).
>>Is the ordinary Exe same as static linked library ?
Not at all. An EXE is not a library in any sense. A library is a collect of code ot data that can be used by other code. An EXE cannot be used in this way. A DLL can, thus a DLL is a library, but not a static linked library.
>> read that 'Dll is loaded in the memory only when required',
>> same way we could also have an exe called only when we
>> require it, so where is the advantage ?
An EXE is loading into memory when somone wants to run it. That could be the user, or another program. A DLL is loaded when an EXE or DLL is loaded that uses it (or when loaded with LoadLibrary). When the DLL is loaded it does not "run" like and EXE runs. It sort of just "sits there" and waits for other code modules to use the procedures and data it provides.
>> so where is the advantage ?
There is no advantage, they serve different purposes. The EXE is a program It is the ultimate goal of programming. it is something useful to the user. A DLL is a library that can be used to make useful EXEs but by themselves they are useless. In the end an EXE is necessary to make the the DLL do userful things.
>> What about unloading the dll ?
What about it?
Nice answer neitod, but one more thing. A DLL is basically a repository for shared code. The benefit of using DLL's is that if 8 programs (EXE's) use the same function, with a DLL, the binary code is only loaded into memory once and all 8 programs attach to the DLL, so it reduces the memory footprint some. As an example, the common dialogs (File Open, File Save, etc.) reside in a DLL. If these were statically linked, each program would have its own copy of all of the common dialogs, and would increase its memory footprint accordingly.
Actually, there are only 2 differences between DLLs and EXEs:
The first one is how Windows manages the memory used by the DLL. Bard has already explained that.
The second difference is that the EXE contains 1 bit that tells Windows that its Entry Point should be executed right away (once loaded in memory). Entry point is a part of the EXE/DLL that contains executable code and tells Windows where in the program the code actually starts.
Other than those two differences, THERE ARE NO OTHER DIFFERENCES between a DLL and EXE. Both can import and export functions, procedures and resources. Both have the same format of executable file (put CPL and SCR files in that group too).
A DLL can also have executable code. Take for instance a Control Panel applet. It's a DLL. However it's entry point is not explicited and must be called manually (there are standards for that). Screen Savers are also DLLs and fall in the same group as the CPL files. They contain executable code, but as their entry point is not explicited, Windows must call a specific location (procedure) inside the DLL.
So, in this sense, an ordinary EXE can be a library. An example of that is USER.EXE and USER32.EXE, in your Windows\System directory. It's an EXE, but it exports functions to several other DLLs and EXEs.
When a DLL is being built by a compiler, a header is written to disk. The difference between this header and an EXE's header is only 1 bit. 1 single bit!
You can use a EXE like a DLL and a DLL like an EXE, but that's not standard. The difference, I repeat, is that the DLL cannot 'auto-start' its executable code once it's loaded in memory. Another process must do it.
The way DLLs are used nowadays is more of a convention than a restriction. A nietod pointed out, a DLL is more used to export stuff, while EXEs imports and uses stuff from the DLL.
Yours,
Alex
>> A DLL is basically a repository for shared code
And also data. For example font files (I can't remember which kind) are simply DLLs with a different extension that export the font data.
>> The way DLLs are used nowadays is more of a convention than a
>> restriction. A nietod pointed out, a DLL is more used to export stuff,
>> while EXEs imports and uses stuff from the DLL.
It is a little more than a convention. While an EXE can be used as a DLL (LoadLibrary() will load a DLL explicitily, although I don't think there is a way to load it implicitily) there is no reason to do so (other than convention). The case of the OS EXEs/DLLs being an exception to that. In addition, a DLL cannot be used as an EXE. CreateProcess will not execute a DLL, only an EXE, thus there is more than just convention to this.
And also data. For example font files (I can't remember which kind) are simply DLLs with a different extension that export the font data.
>> The way DLLs are used nowadays is more of a convention than a
>> restriction. A nietod pointed out, a DLL is more used to export stuff,
>> while EXEs imports and uses stuff from the DLL.
It is a little more than a convention. While an EXE can be used as a DLL (LoadLibrary() will load a DLL explicitily, although I don't think there is a way to load it implicitily) there is no reason to do so (other than convention). The case of the OS EXEs/DLLs being an exception to that. In addition, a DLL cannot be used as an EXE. CreateProcess will not execute a DLL, only an EXE, thus there is more than just convention to this.
It will not execute a DLL because a DLL has no defined entry-point, as I have said before.
If a DLL cannot be used as an EXE, what about Control Panel applets, screen savers, etc? They are all DLLs. The difference is that their entry points is at a non-standard location (as opposed to EXEs).
EXEs and DLLs can BOTH hold data. That's what I meant by resources, which is the technical term for the data stored in a DLL.
I suggest you read Petzold's book.
Yours,
Alex
If a DLL cannot be used as an EXE, what about Control Panel applets, screen savers, etc? They are all DLLs. The difference is that their entry points is at a non-standard location (as opposed to EXEs).
EXEs and DLLs can BOTH hold data. That's what I meant by resources, which is the technical term for the data stored in a DLL.
I suggest you read Petzold's book.
Yours,
Alex
BTW, you can load a DLL either implicitly (using LoadLibrary) or explicitly (using LIB files). You got things mixed up.
You can load an EXE either way too. In order to load an EXE implicitly without having the kernel execute its entry point is by using LoadLibraryEx. By doing so, you can bypass the difference that Bard pointed out, because the EXE's memory will also be shared across multiple processes that use it as a library.
Yours,
Alex
You can load an EXE either way too. In order to load an EXE implicitly without having the kernel execute its entry point is by using LoadLibraryEx. By doing so, you can bypass the difference that Bard pointed out, because the EXE's memory will also be shared across multiple processes that use it as a library.
Yours,
Alex
>> If a DLL cannot be used as an EXE, what about Control Panel applets, screen savers, etc?
Those cannot be run as programs. An already running program must load them into its address space and call a procedure in them. They will then execute that procedure within that program's process. They are not seperate processes. An EXE runs by itself in its own address space as a seperate process. No program--other than the OS--is required to run them. That is a huge difference.
>> BTW, you can load a DLL either implicitly (using LoadLibrary)
>> or explicitly (using LIB files). You got things mixed up
I said DLL when I meant EXE. An EXE can be loaded using LoadLibrary, but a DLL cannot be run using CreateProcess. Thus an EXE can be made to function like a DLL in some cases, but there is no reason to do so. A DLL cannot be made to function like an EXE (without turning it into one.)
>>EXEs and DLLs can BOTH hold data.
I'm not arguing that, I was just pointing out that bard hadn't made that clear. (I tried to in my answer.) And what is the difference between data and code? nothing, really. Our 16 bit accounting system stores all of its code in data segments. It is easier to write that way. But under protected mode you can't do that...
>>I suggest you read Petzold's book
A joke?
Those cannot be run as programs. An already running program must load them into its address space and call a procedure in them. They will then execute that procedure within that program's process. They are not seperate processes. An EXE runs by itself in its own address space as a seperate process. No program--other than the OS--is required to run them. That is a huge difference.
>> BTW, you can load a DLL either implicitly (using LoadLibrary)
>> or explicitly (using LIB files). You got things mixed up
I said DLL when I meant EXE. An EXE can be loaded using LoadLibrary, but a DLL cannot be run using CreateProcess. Thus an EXE can be made to function like a DLL in some cases, but there is no reason to do so. A DLL cannot be made to function like an EXE (without turning it into one.)
>>EXEs and DLLs can BOTH hold data.
I'm not arguing that, I was just pointing out that bard hadn't made that clear. (I tried to in my answer.) And what is the difference between data and code? nothing, really. Our 16 bit accounting system stores all of its code in data segments. It is easier to write that way. But under protected mode you can't do that...
>>I suggest you read Petzold's book
A joke?
Nope. No joke or no offense meant. I just think it's a must-have reference when it comes to this kinda argument.
> Both can import and export functions, procedures and resources.
An executable can export a function, but it's risky business. First, an executable needs to be very carefully crafted in order to have its functions called asynchronously. Next, a function exported in such a way can't possibly use any static objects in C++, and won't be able to use the runtime libraries.
What do you think the difference is between a function and a procedure, BTW?
.B ekiM
An executable can export a function, but it's risky business. First, an executable needs to be very carefully crafted in order to have its functions called asynchronously. Next, a function exported in such a way can't possibly use any static objects in C++, and won't be able to use the runtime libraries.
What do you think the difference is between a function and a procedure, BTW?
.B ekiM
>> First, an executable needs to be very carefully crafted in
>> order to have its functions called asynchronously
Not that I'm advocating using executables in this way, but why would there be a difference between an EXE and a DLL in this respect? In what way are the calls asynchronous? Do you mean like having the EXE mapped into multiple processes? (I was thinking of a single process) If an EXE were mapped into multiple processes using loadlibary(), would the copy on write mechansim function?
>>Next, a function exported in such a way can't possibly
>> use any static objects in C++, and won't be able to
>> use the runtime libraries
I don't think this question pertained to C++ in particular, but since you bring it up. I assume the problem here is the fact that the EXE's entry point is not called so globals and the RTL don't get initialized. Local statics should still be fine.
The way I've seen exports uses from EXEs is like a callback sort of mechansim where the EXE is loaded and run normally but has exports that other modules can access using GetProcAddress(). (Why? I don't know.) In this case I would think there would be no problems with globals, the RTL, or asynchronous calls. I still can't image a good reason why one would want to do that.
>> order to have its functions called asynchronously
Not that I'm advocating using executables in this way, but why would there be a difference between an EXE and a DLL in this respect? In what way are the calls asynchronous? Do you mean like having the EXE mapped into multiple processes? (I was thinking of a single process) If an EXE were mapped into multiple processes using loadlibary(), would the copy on write mechansim function?
>>Next, a function exported in such a way can't possibly
>> use any static objects in C++, and won't be able to
>> use the runtime libraries
I don't think this question pertained to C++ in particular, but since you bring it up. I assume the problem here is the fact that the EXE's entry point is not called so globals and the RTL don't get initialized. Local statics should still be fine.
The way I've seen exports uses from EXEs is like a callback sort of mechansim where the EXE is loaded and run normally but has exports that other modules can access using GetProcAddress(). (Why? I don't know.) In this case I would think there would be no problems with globals, the RTL, or asynchronous calls. I still can't image a good reason why one would want to do that.
A function is a procedure that returns a value. I do 99% of my programming using Delphi, so I got used to discriminating functions and procedures. Putting it in terms of C/C++ :
Function:
UINT MyFunction(void);
Procedure :
void MyProcedure(void);
From a view point of a Delphi programmer they are different things. For C/C++ programmers they are basically the same thing.
Yours,
Alex
I am getting tired of this discussion, since we are no longer discussing the differences, but what words to explain those differences. We've come to common sense.
How one uses or not a EXE is a matter of circumstances, and I do not think this is the point of the question. What they mean and their general purpose, I believe, has been already covered.
Nietod, you're free to answer this question if you want, since I'll refrain myself from engaging further technical discussion on the subject.
BTW, I actually enjoyed the discussion!
Yours,
Alex
How one uses or not a EXE is a matter of circumstances, and I do not think this is the point of the question. What they mean and their general purpose, I believe, has been already covered.
Nietod, you're free to answer this question if you want, since I'll refrain myself from engaging further technical discussion on the subject.
BTW, I actually enjoyed the discussion!
Yours,
Alex
I refer you to my previous comment
ASKER
Thanx all of you gurus - nietod, bard, simeonet, mikeblas, PinTail for this extremely useful discussion. Especially nietod and simeonet. I got the relevant information and most importantly enjoyed reading it all.
Nietod, the points r yours for the taking.
Thanx - Jitu
Nietod, the points r yours for the taking.
Thanx - Jitu
> In what way are the calls asynchronous
Because DLLs and EXEs are different in a way that nobody here has decided to mention. A DLL is loaded and touched by multiple processes, and will have multiple threads enter it. It has no control over when its entered and left.
An EXE is used to being entered by a single thread, and if it has multiple threads enter it, it will do so only because it knows about those threads itself. Beforehand, at design time.
Further, an EXE is initialized by a well-defined entry point. The entry point sets up static data, and initializes runtime libraries associated with the image. If you call LoadLibrary() or LoadLibraryEx() on an EXE, you don't get a shot at performing such initialization.
.B ekiM
Because DLLs and EXEs are different in a way that nobody here has decided to mention. A DLL is loaded and touched by multiple processes, and will have multiple threads enter it. It has no control over when its entered and left.
An EXE is used to being entered by a single thread, and if it has multiple threads enter it, it will do so only because it knows about those threads itself. Beforehand, at design time.
Further, an EXE is initialized by a well-defined entry point. The entry point sets up static data, and initializes runtime libraries associated with the image. If you call LoadLibrary() or LoadLibraryEx() on an EXE, you don't get a shot at performing such initialization.
.B ekiM
> From a view point of a Delphi programmer they are different things.
Oh, yes. I remember that, now; VB programmers make the same distinction. It's really an artificial distinction.
> I am getting tired of this discussion,
You can unmark the "Check here if you'd like an email notification" button, below, and quit your involvement in the thread at any time--you don't even have to provide a comment or answer at the time you do that.
> we are no longer discussing the differences
I, for one, am certainly not done. Ya'll haven't touched on at least one very important difference, and I raised it.
.B ekiM
Oh, yes. I remember that, now; VB programmers make the same distinction. It's really an artificial distinction.
> I am getting tired of this discussion,
You can unmark the "Check here if you'd like an email notification" button, below, and quit your involvement in the thread at any time--you don't even have to provide a comment or answer at the time you do that.
> we are no longer discussing the differences
I, for one, am certainly not done. Ya'll haven't touched on at least one very important difference, and I raised it.
.B ekiM
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
If there was a way to give points to more than one person for a question, I would give them to all other's who participated too.
:-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-))
This discussion deserves more points anyway, but I am running out of points, and soon i will not be able to ask more questions..sob.
Thanks-Jitu
:-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-)) :-))
This discussion deserves more points anyway, but I am running out of points, and soon i will not be able to ask more questions..sob.
Thanks-Jitu
You can always purchase points. I believe they are ten cents a piece and the money helps to keep this site running.
thankx for all gurus..... It really gave a lot of inputs for my decisions to choose between Dll and Exe
There are of course differences ( relatively minor, really) in how the linker generates the image, and in how the Operating System treats the image (which is operaitng system dependant.)
You are correct that an exe can be loaded only when required, and in fact this is part of what makes an out-of-process OLE server so useful. It can be treated as a stand-alone application, or as a support library.
Your question about an EXE being the same as a statically linked library is too general. An exe may call a dynamic library, in which case it cannot possibly be fully statically linked.
What about unloading the DLL ??