Gammon Forum : MUSHclient : VBscript : Difference between exe and dll file

Log on

Gammon Forum

Entire forum

MUSHclient

VBscript

Difference between exe and dll file

Difference between exe and dll file

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Mahesh Sharma (1 post)

bio

Date

Thu 12 Jun 2003 08:54 AM (UTC)

Message

please send me the difference between exe and dll

top

Posted by

Loki (44 posts)

bio

Date

Reply #1 on Thu 12 Jun 2003 08:49 PM (UTC)

Message

A .exe is an executable file. I DLL file is a Library File
which supports a executable file. But then again I might be wrong.

-LºKi_
Founder
Endless Dreams

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #2 on Thu 12 Jun 2003 09:33 PM (UTC)

Message

Yes pretty close. DLL stands for Dynamic Link Library - it is a library file which is linked at runtime (ie. dynamically) rather than at compile-time (ie. statically).

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Ravi (1 post)

bio

Date

Reply #3 on Wed 14 Feb 2007 03:21 AM (UTC)

Message

an exe has its own individual address space, whereas a dll have one address space, thus it can be shared

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #4 on Wed 14 Feb 2007 06:20 PM (UTC)

Message

Minor quibble. A dll can be "dynamically" loaded and unloaded from memory, allowing an application to take up less space than it normally would when its not using the functions in that dll. Static vs. Dynamic linking is something else entirely. ActiveX uses dynamic linking because the application doesn't know the specific internal addresses needed *prior* to creating the object that they need them for. It has to ask the dll for them. Normal dlls have "static" entry points, which are at fixed locations. This is why you can take a dll like MyActiveX1.0 and replace it with MyActiveX2.0 without changing your application at all, except to add support for new features, but with "static" libraries, replacing 1.0 with 2.0 will actually crash the application. The internal locations have changed, but your application is still trying to use the "original" locations, which are no longer valid.

There are ways around that, but in general, a standard dll has *no* internal table to show its entry points and *no* way to dynamically link at runtime, since the table that does exist has to be added "directly" into the application when its created, so new versions of the dll will "break" the application, useless you also have a new version of the program to go with them. This used to be extremely common, especially before ActiveX was created.

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #5 on Wed 14 Feb 2007 06:32 PM (UTC)

Message

Minor quibble. :-)

What you are describing with ActiveX is a different kind of dynamic linking, not dynamic linking as performed by the operating system.

ActiveX DLLs also have static entry points, namely the functions to enumerate capabilities and so forth. It so happens that you can request further functions from the DLL by using the information that the entry points give you. But, that's no longer dynamic linking per se, it's returning function pointers. You could do the exact same thing in a fully statically linked system.

You are using the term static linking in a very misleading sense. You seem to be referring to proper DLLs, in which the application expects very specific entry point(s). And even then, it's ok to switch DLL versions as long as the ABI (application binary interface) remains the same.

In fact, upgrading system dynamic libraries is one of the major reasons why dynamic linking is (sometimes) more appropriate than proper static linking.

Real static linking is when, at compile time, you include the entire library with the application. The whole point of static linking is that you do not need to distribute separate libraries. However, if you want to upgrade the library, you can't without recompiling the original application.

You are incorrect about DLLs having no tables to show entry points. Every DLL has a table to show its entry points; that's what the exported symbols are all about. You're thinking of entry points as a larger concept than they actually are, e.g. ActiveX exported functions which are not part of the proper DLL system.

Basically ActiveX is an entire system built on top of DLLs, to let you do dynamic linking on top of dynamic linking, and so you are right about that. But your description of DLLs is misleading at points and unfortunately simply wrong at others.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #6 on Thu 15 Feb 2007 06:40 PM (UTC)

Message

Sigh. Well, it all depends on *what* you are talking about when you say dynamic. You can't, for example, take a standard dll and link it during runtime, it must be done during design, because there is no way to *get* the table at that point. The compiler itself has to take the table you give it and figure out where the entry points are, so that it will link correctly. There is no mechanism to handle that with standard dlls at runtime. So, no, its only misleading in the sense that I was perhaps not clear enough. Yes, there are tables for all types of dlls, but only ActiveX dlls generally include that table "internally", in a way that is requestable by something trying to link to it. For standard ones, if you don't know the entry points and you don't have a .h or .tbl file describing the interface for a compiler, you can't use it *period*.

Fact remains that the main difference is *when* you can link them. And I know of no case where its possible to link a non-ActiveX dll into an application *after* the application is already compiled and running. Possible? Maybe. Very, very difficult? Definitely. Supported *at all* as a valid method of using one? No.

It all hedges on your meaning of "static". In this case you are implying dynamic as *both* how its connected and if its in memory all the time as part of the application. My point is that its more like this:

ActiveX dll - Loading = Dynamic, Linking = linkable at runtime.
Normal dll - Loading = Dynamic, Linking = generally must be defined and hardcoded into the application during design.

What is confusing is saying that both work exactly the same, without qualification as to why runtime linking is generally not done with a standard dll.

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #7 on Thu 15 Feb 2007 06:44 PM (UTC)

Message

Oh.. One other distinction. ActiveX supports having an exe function in two modes, either as a dll for another application, or as a stand alone application. While I suppose it may also be possible to create entry points for an application that isn't ActiveX, and thus do the same thing with that, I have never heard of anyone doing so. It would be quite a bit more complicated to manage and the compilers themselves flat out do not support it.

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #8 on Thu 15 Feb 2007 07:46 PM (UTC)

Message

Quote:
Well, it all depends on *what* you are talking about when you say dynamic.

I am talking about the definition of dynamic linking.

Quote:
You can't, for example, take a standard dll and link it during runtime, it must be done during design, because there is no way to *get* the table at that point.

That is incorrect. You need to know the name of the entry point ahead of time, but you can load and unload dynamic libraries as much as you want at run-time.

Quote:
The compiler itself has to take the table you give it and figure out where the entry points are, so that it will link correctly.

No, the operating system takes care of getting the function addresses based on the DLL's symbol export table.

Quote:
There is no mechanism to handle that with standard dlls at runtime. So, no, its only misleading in the sense that I was perhaps not clear enough.

In the sense that you are making false statements about dynamic linking, it's quite misleading. :-)

Quote:
For standard ones, if you don't know the entry points and you don't have a .h or .tbl file describing the interface for a compiler, you can't use it *period*.

No... you do need to know the symbol names, so that you can request them from the dynamic library, but you don't need to have a full compiler interface and so forth.

Regardless, the linking happens at runtime, not compile time.

Quote:
Fact remains that the main difference is *when* you can link them. And I know of no case where its possible to link a non-ActiveX dll into an application *after* the application is already compiled and running. Possible? Maybe. Very, very difficult? Definitely. Supported *at all* as a valid method of using one? No.

I'm sorry, Shadowfyr, this is plain and simply wrong. You link into dynamic DLLs all the time. Load up Lua and do a require statement of a C library. What do you think that is doing? It's opening up the dynamic library at runtime and looking up the appropriate symbols.

And Lua didn't even need to be compiled to be at all aware of that library! All it needs is the symbol name.

What do you think the SMAUG dlsym functions are for? ... loading up libraries at runtime.

What do you think happens when programs load and unload plugins at runtime? ... dynamic linking and unlinking.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #9 on Thu 15 Feb 2007 10:29 PM (UTC)

Message

Quote:
No, the operating system takes care of getting the function addresses based on the DLL's symbol export table.

To quibble with myself, I'm not sure if it's the OS itself, or the C runtime library. The OS does part of the dynamic loading by moving around addresses and the like (virtual address spaces and so forth), and is responsible for loading the DLL into memory, but I think the C runtime library might be the one responsible for actually looking up the symbol name in the exported symbol list.

Regardless, it is not the responsibility of the compiler to do this stuff.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #10 on Fri 16 Feb 2007 04:40 AM (UTC)

Amended on Fri 16 Feb 2007 04:41 AM (UTC) by Nick Gammon

Message

Quote:

You can't, for example, take a standard dll and link it during runtime, it must be done during design, because there is no way to *get* the table at that point.

Actually, MUSHclient loads in the Lua and spellchecker DLLs at runtime. That is, if they are not present there is a warning message, but it continues.

I am not sure if you mean "link" or "load".

However even in the case of linking, the recent change to allow you to make transparent windows borrowed some code that checked if an entry point (by name) existed in one of the operating system DLLs, and if it did exist, get the address of the routine, and then call it.

Thus it is possible to write code that calls a module in a DLL, whose name is determined at runtime.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #11 on Fri 16 Feb 2007 04:54 AM (UTC)

Message

In fact, DLLs let you grab essentially arbitrary symbols from within, as long as one of the entry points provides a well-known interface for doing so. That is essentially what things like ActiveX let you do: you are given a well-known interface for requesting more symbols, along with their information (parameters, return types, etc.) and then you can pick one and obtain it as a function pointer.

So really, you don't need to export a function explicitly to let other people access it. You just need to give them a way to get at the function address -- and they have to know the type of the function, too, of course. But you can get around that by making a runtime type information system of sorts, where you pass a list of "objects", where an "object" is a structure that has e.g. a type name (like "int", "string", etc.) and, say, a void* to the actual data. So you need to know the prototype, yes, but you don't need to know anything more specific than that it takes one of these runtime-type-specified object lists as a parameter and returns a similarly runtime-typed value.

Dynamic libraries are really, really powerful.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #12 on Fri 16 Feb 2007 06:55 PM (UTC)

Message

Sigh.. He is talking about loading and table supporting dlls, I am talking about dlls in general, which *only* expose their entry points at runtime if you explicitly tell them at compile time that those locations *are* available. System libraries are set up to allow such checking and contain an internal table to look up the entry points by symbol. Some proprietary dlls for specific application hide "all" of there interfaces (which is the default state), so that no one can use them other than the developer. All you have to do is use the application "Dependency Walker" that comes with C++ to look at a few DLLs. All ActiveX dlls will show there list of entry points, so will system libraries, but you will sometimes find dlls with entry points missing in the list (i.e. hidden) and others which *only* show those interfaces explicit to properly communicate with the OS, but none of the entry points for the application layer. This is far less common today than it used to be, but back during the 95-98 period, many people used staticly linked dlls, where the entry points are only definable in the symbol table supplied to the compiler at design time. They still worked, you just couldn't trade them out with ones that had different entry point locations, because the physical location "in" the code was pre-written into the compiled code. For one that supports lookup of the entry point, this address is not pre-written, so it can be checked for and pointed to dynamically. Loading and linking **are not the same things**.

Ok.. Looking things up on Google, it seems I am using the term differently.... Personally, I don't think theirs makes any damn sense at all. The main difference between APIs and standard dlls is where the entry point table is placed.

APIs - In the API, to be looked up *as needed*.
standard dll - In the application, using fixed locations relative to the dlls main memory address.

Both load and unload dynamically, but imho, its misleading to claim that both of them "link" the same way. The problem with the terminology is that they refer to "linking" as the means by which one places the "locations" into the application for accessing as well as how the code gets there. When *they* say static, they mean cramming the entire library into the main application, not letting you load it as needed. This is imho, a bloody stupid definition of what static means, since the locations *remain* static relative to the libraries load location in *either* case. Unlike those that use their own lookup methods, which can change their entry points relative to the start of the memory used from version to version.

But I am going to stop arguing this. They want to use the term I don't agree with the definition of, fine, who am I to complain? Its not like its the first time I have come across some situtation that the terminology didn't make any damn sense. And I am 90% certain that I read *precisely* the argument I was making about this in a book on ActiveX, which was describing the difference between how the two types of dlls are implimented.

top

Posted by

Shadowfyr USA (1,786 posts)

bio

Date

Reply #13 on Fri 16 Feb 2007 07:10 PM (UTC)

Message

Hmm. And just to be clear:

Quote:
One way this can be assured is by loading the code for the library routines into the executable file during the linking phase. This approach is called "static linking." One disadvantage of static linking is that the code for various library routines is redundantly stored in the executable files of many different programs and utilities. This wastes a lot of disk space.

Another approach is to defer loading until the program is run, at which time routines are loaded from libraries on the fly. This is called "dynamic linking."

http://www-acs.ucsd.edu/info/subroutines.php

So, I am right, if you read the correct definition. If you read a different definition, then I am wrong. Some things are about as easy to pin down accurate definitions for in the computer world as trying to catch goldfish with a cargo net. No two people use the same bloody definition. Its only made more complex by the fact that half the time if you go from Unix systems, like Unix, which the above definition comes from, to Windows, you get an even more absurd set of redefinitions in some cases.

It is possible, and I have had, conversations where three people where all using the same terminology, arguing about various issues with them, but it turned out that none of them where *actually* talking about the same same thing, or in one case, even vaguely related, thing. Unless by related you mean, "It had something to do with computers." lol

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #14 on Fri 16 Feb 2007 07:15 PM (UTC)

Message

I dunno, the difference between static and dynamic makes perfect sense to me, if you think about it in terms of when the linking really takes place. You're trying to add all these extra notions into the mix that don't really belong in the fundamental definition, hence all the confusion of terms. If you read up on compilers and operating systems it might make more sense. I can explain it a bit more if you want.

Quote:
For one that supports lookup of the entry point, this address is not pre-written, so it can be checked for and pointed to dynamically

Again, this isn't quite right. The address is "pre-written", except that the dynamic library exports a symbol table saying giving the address of the entry point(s).

Quote:
The main difference between APIs and standard dlls is where the entry point table is placed.

This is a little bit of apples and oranges, here. API is a concept: the application programmer interface. It means the prototypes of functions, how you call them, what they return, and so forth. A dynamic library is a collection of functions.

Quote:
So, I am right, if you read the correct definition. If you read a different definition, then I am wrong.

Sorry, but no -- the definition you gave is the one I have been using, and is not the one you have been using. (You might want to refer to one of my posts on this thread in which I discuss static linking sticking the code into the executable.) The definition you just provided is the standard one, and I have never seen another definition.

I am not trying to be obtuse, stubborn or anything of the sort. It's just that you are simply not using the concepts correctly, and you are saying things about dynamic and static libraries that just aren't true.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

63,142 views.

This is page 1, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.