Kinda a big subject.....

I have been coding for almot 10 years now and believe it or not, never figured out how to write a Dll properly. I used MFC to create MFC Dll's but thats cheating, haha

Anyone have any insight on how to create a good/proper Dll using Masm? Also, the differences between writing a static Dll and a Dynamic Loading Dll? I know they are different and why their different , just don't know if you code them different internally.

One subject also that I have always been interested in is making an application with the ability to use Plug_ins. Have no idea how to do this one. I assume using Dynamic Loading Dll's but that the limit of my expertise, lol

If anyone knows of any resources that show this and/or code samples of these things that would be awesome

Posted on 2002-01-08 18:43:04 by Rockinronstar

The difference between "statically loaded" and "dynamically loaded" DLLs is in how you call them. If they are set in the build as most languages do, the compiler does the work, if you want to build a plugin interface, you would normally use LoadLibrary, GetProcAddress, FreeLibrary on the same DLL.

Basically all you need is some method of setting the path and filename of the DLL into your application and just pass this to LoadLibrary, get the proc address and directly call the function in the DLL.

Posted on 2002-01-08 19:07:10 by hutch--
for plug-ins, do you create a Function in the Dll that "has to be there". And your App calls this. And if it finds it then its a valid plugin and then this function gives the App what it needs to know about the Dll?

Also, I guess you would need to implement an "API" in your application that the Dll can use to manipulate the program?

Wondering what and how much work is involved in making an application "plug-in supportable"

Posted on 2002-01-08 20:22:07 by Rockinronstar
Also Hutch, do you know of any resources that I could get hold of that shows you how to write Dll's? I am only familiar with MFC Dll writing. I would like to be able create Dll's that I can use in my ASM apps and also be able to use in Hll's if the need arises

thanx again
Posted on 2002-01-08 20:23:35 by Rockinronstar
Writing a dll isn't very hard, just takes a few tricks:

1) You need a dllmain proc so windows has one place to start and stop your lib. It also does a few other things here.

2) You need an export definition file. This names the resultant dll, and defines which procedures will be exported.

3) Finally, you need the build settings:

\masm32\bin\Link /DLL /SUBSYSTEM:WINDOWS /DEF:%1.def /LIBPATH:c:\masm32\lib %1.obj rsrc.obj

(drop the 'rsrc.obj' if you don't have any resources)

I do alot of dll's in my COM stuff, perhaps my MyCom tut would help (as it has the least 'COM' stuff in there). Even better, Icz has a nice tut on building them, look for "Dynamic Link Libraries" (Not just "DLL") in his tuts.
Posted on 2002-01-08 22:22:32 by Ernie
cool stuff, thanx Ernie..

Didn't even think to check Icz's tutorials. Should have checked those first!!

I have searched the net on writing Dll's but its pretty sparse. I have written Dll's using MFC on a number of occasions but they are MFC specific Dll's.

thanx again
Posted on 2002-01-08 22:27:34 by Rockinronstar

The current distribution of MASM32 has 2 DLLs to have a look at. One is a very simple one and the other is a plugin DLL for the editor.

Once you dynamically load a DLL with LoadLibrary/GetProcAddress, all you need to do is call the address with the correct number of parameters pushed onto the stack.

A plugin interface in a program needs to be a standardised interface that more than one DLL can be called with. In QE, it reads the data from the INI file which is the name and path of the DLL, then it passes all of the relevant handles from the editor to it. In the DLL you do whatever you need with the handles, insert text, process text etc ...

There are many other things you can do as well and this of course depends on you app.

Posted on 2002-01-09 03:33:33 by hutch--
thanx guys. I successfully Created and Loaded a Dll last night and was able to call its functions. I learned some very new last night(thanks to Icz tutorial) that you need to compile a Dll using a .def file. I thought they were files that had to be in the directory with the Dll file, and not compiled with the Dll. So in my past trys the Dll loaded fine but I could never call the functions and I know why, haha

Also, when you compile a Dll with RadASM you have the ability to create a .lib file as well. Just wondering the proper usage for statically linking the Dll. I guess you use includelib for the library file, but do you also need to create a .inc file for it as well. If so then I don't see to much benefit of using statically linking over dynamic linking other than being able to call then functions earier and more intuitively.

And I guess that if a single .lib is missing the entire program will not load.

I guess both methods have their ups and downs

also, Hutch,
you mentioned passing Handles to the Dll from the app. That makes perfect sense, but how do you suggest you handle setting up messages that the Dll should handle? ie. If the Dll is supposed to replace a message that the App used to handle, for example, when you resize the window it does something different. How can you override what the main app's MsgProc and then direct those messages to the Dll? Or can you, haha - maybe I'm dreaming here

Posted on 2002-01-09 06:24:29 by Rockinronstar
The advantage of using statically linked .lib? To not pass a DLL around
with your application. A (very very very) little faster invocation of
the code in the library. And again, not having to pass a DLL around :).
In my opinion, you have to reach "some size" before a DLL makes
sense - or have a special use, like plugins or hooks.

Also, you ought to call the "automatic loading of DLLs" implicit binding
instead of static binding - otherwise it's too easy to confuse "statically"
linked DLL with a statically linked .lib ... and the differences are quite
huge ;). Unless you need to (pluing architecture), don't LoadLibrary / GetProcAddress,
it's better/faster to depend on the PE loader to handle DLL loading.

Posted on 2002-01-09 07:40:39 by f0dder
Hmm.. Hello.
I am also trying to create plugins for my program, but they won't work the way I want them to.

What I want to happen is the function PluginInit is executed..
This is the code for that:
(after I loadlibrary and getprocaddress)

push MDIClienthWnd
push ApphInstance
call eax

The DLL creates a new MDI child window, but I am not sure if the hInstance of that child window is supposed to be the same as the hInstance from the main program?
Also, the created window - it's WNDCLASSEX.lpfnWndProc is set to the address of a function within the DLL, but it doesn't seem to call that function. How do I get that to work? Pass it through to the main app then have the main app call a function from the dll with the sent params?? :P I'm only 15, sorry if I confused you.

Posted on 2002-01-09 17:33:30 by DamnedMoose
Concerning Dll's again... I have been successful in creating them alright but one thing seems a mystery to me.

I have a menu on the main app called tools. I think it should be easy for the Dll to add a menu command to this menu with the AppendMenu API call, but how do I get that option on the menu to use a Message Handler within the Dll itself, since the main app by default will handle the WM_COMMAND message and the if statement can't check this new ID since it never existed before in the application?

I know I can change the MsgProc of the main Window to use another Message Proc. Is this maybe what you are supposed to do? Can I change the MsgProc to the New Dll and handle the messages the Dll uses and then call the Old MsgProc to handle everything else? This sounds like it may work for a single Dll, but fall apart for multiple Dll's. Can't have the Apps Main Window set to use multiple MsgProcs at the same time, can you?

Thats my biggest issue with the Dll thing right now. How can you get the Main App to direct certain Message to the Dll? Especially if the Dll justs overrides something in the host app or just add more functionality to the host app?

signed, Mr. Dll Confused Guy
Posted on 2002-01-09 18:22:43 by Rockinronstar
You could add a list/array of dll hooks that get passed unhandled
messages - or perhaps all messages (and are then responsible for
passing them down to the main app (or further down the "hook chain")
if they are unhandled).

A double-linked list is probably the best way to handle this - you
can dynamically unlink DLLs, and you still have an order to pass
message up/down.

Dunno, just a thought.
Posted on 2002-01-09 20:54:04 by f0dder
that is a good idea.
Posted on 2002-01-09 21:40:11 by Rockinronstar