[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  VBscript
. . -> [Subject]  difference Active X EXE Standard EXE

difference Active X EXE Standard EXE

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


Posted by Seshagiri   (1 post)  [Biography] bio
Date Thu 05 Jun 2003 02:32 PM (UTC)
Message
hi,
Please send the differnces between Active X EXE and Standard EXE. also Active X DLL Standard DLL.

thanks
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #1 on Thu 05 Jun 2003 06:59 PM (UTC)

Amended on Thu 05 Jun 2003 07:01 PM (UTC) by Shadowfyr

Message
The simplest explaination is that ActiveX EXE and DLL files include a special interface called IUnknown. This provides a way for the operating system to allow other programs to talk to them directly without spcifically building the connections needed into the program that talks to them. In other words, ActiveX provides a swiss army knife of connections that will let any program use an EXE or DLL, as long as the tool actually exists in the EXE or DLL you try to talk to.

A normal EXE can use such ActiveX objects, but not respond to them. In other words, you can open a database and change things in it, which requires only that you tell the database to do something, but you would need to wait for a response, since your program can only see the direct result of a command, not respond to things the EXE or DLL does. An example would be something like POV-Ray, that produces 3D images. You could send POV-Ray a file, but you would then have to wait 4-5 minutes for it to finish. If it and your program where both ActiveX, then you could send it the file, it would start doing its thing and you could continue to do other things in your program while waiting for POV-Ray to tell you that it was done. Also, as far as other programs are concerned, there is no difference between an ActiveX DLL and an ActiveX EXE. Many will work as both, either running as a real program or 'inside' something else when you talk to them through ActiveX. This of course requires making them to do so, but an example it Windows Media Player. You can open the player on your computer as an EXE or when in a browser, it will simply play the movie you download inside the browser window. The same ActiveX EXE does both, but one version simply loads itsef, plays the movie and vanishes when no longer needed.

A normal DLL is 'hard linked' into the program that uses it. In other words, rather than being able to ask IUnknown if the DLL can do something, the assumption is you already know exactly what it does and when you create your program the compiler simply raplaces any reference to commands in that DLL with a command to run that specific part of the it. Its like filling a hole with cement. It fits perfectly into 'your' program, but for someone else to use it they would need to make an identical hole in their program. Such a DLL can be used to connect two programs together, and POV-Ray, which I mentioned before, and a design program called Moray use such. This kind of DLL is faster to respond, because IUnknown require Windows to get involved with making sure everything works. However, the advantage is that if you add or change something in the ActiveX DLL, your program doesn't care, it simply asks if the thing it wants to do exists and if so uses it. With a normal DLL you have to specifically describe every single command you plan to use to your program, before it can do anything.

Now this difference may not seem like much, but it means that to use a button, like you see in numerous programs, all I need to know is what that object is called and that I need to add, for instance, something like 'dim Button1 as Button' and 'sub OnButton1.Click()...' to my program to use it. Windows deals with all the dirty issues of making sure that such an object exists and handing a copy over for my use when I need it. For a normal DLL, I would be responsible for making sure it exists, making sure my program knew how to use it, making sure it acted like a button and making sure that all of them got cleaned up when I no longer needed them. Ugh!

What all this means in relation to Mushclient is that Mushclient 'is' and ActiveX EXE. Scripts can call DLLs and EXEs that use ActiveX, so you can build a second ActiveX DLL or EXE that can talk to Mushclient's ActiveX interface:

Mushclient --> Script
    ^          /
    |         /
    |       |/_
   You Program


This is more round about than normal, but is basically the same way Internet Explorer uses it, though it is rarely used, since only Internet Explorer supports it. Since ActiveX doesn't exist on Mac, Linux, OS/2 or literally anything other than Windows, web browser makers told Microsoft to stuff this feature of IE someplace uncomfortable. ;) lol Most programs that use it do this:

Your Program <------> ActiveX EXE or DLL
[Go to top] top

Posted by BIKRAM MOHANTY   (1 post)  [Biography] bio
Date Reply #2 on Thu 25 Aug 2005 11:29 AM (UTC)
Message
DLL ARE INDEED DYANMIC LINKED LIBRARIES BUT THERE IS MORE TO IT THEN JUST BEING THAT.
ACTUALLY THE MAIN DIFFERENCE BETWEEN AN EXE AND A DLL IS THAT THE DLL IS A IN PROCESS AND AN EXE IS AN OUT PROCESS.
WHICH MEANS THAT THE DLL IS CALLED FROM WITHIN A PROCESS AND THUS CAN CAUSES THE SYSTEM TO FAIL IF IT HANGS OR THROWS UP AN EXCEPTION.
BUT AN EXE IS AN OUTPROCESS WHICH IS A SEPARATE THREAD IN ITSELF AND THUS WE CAN KILL THE EXE FROM THE TASK MANAGER IN WINDOWS BUT NOT A FALTERING DLL.
......HOPE THIS EXPLANATION IS OF HELP FOR YOU........
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #3 on Thu 25 Aug 2005 06:05 PM (UTC)
Message
Umm. A) STOP WITH THE CAPS!
B) The request was for what makes an ActiveX EXE or DLL 'different' from the normal versions, not what makes and EXE different than an DLL.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #4 on Thu 25 Aug 2005 06:32 PM (UTC)
Message
Besides, a DLL fault won't bring the system down unless it's a system-critical-process DLL. A DLL fault will bring down the process that's running the DLL, that's all.

Also, DLLs aren't 'hard-linked' in the sense that they're statically linked. The DLL code is all loaded at runtime. I think that's what you (Shadowfyr) meant, but just making sure...

However, the bit about DLLs not being able to talk to non-activeX exes is wrong. You could quite easily specify call-back functions. That being said, the DLL gets to dictate the type of the callback function (return type + parameters), but, there can be bi-directional communication. Quite easily, at that. Callback functions are a very common technique for this kind of communication.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #5 on Sun 28 Aug 2005 05:53 PM (UTC)

Amended on Sun 28 Aug 2005 09:50 PM (UTC) by Shadowfyr

Message
"By 'dynamic linking', I meant specifically how you define what functions are going to be used and how to respond to them, not 'just' linking the application to the DLL and loading/unloading it. Sorry about that confusion.

As for DLLs being able to talk to EXEs, only in the same sense as any function 'in' the application itself. The point I intended to make was that you must describe such a callback 'before' you can use it, while ActiveX will inform an application of events, even if the application doesn't know to look for it. Specifically telling the application what event to catch is 'optional' not manditory, as it is with a standard DLL."
[Go to top] 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.


22,404 views.

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

Go to topic:           Search the forum


[Go to top] 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.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]