DLLS ???

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Could someone possibly write a few sentences for me in a simple terms as possible about what DLL files are, and what they do.

The reason I ask is that I'm currently writing an introduction to programming in VB .Net, and I want to explain the advantages of using assemblies over dlls.

Many thanks!

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Source: wrightcolorgraphics.com

Even better: searchwin2000.techtarget.com

 

Thanks for that. So would I be right in thinking then, for example when working with a word processing application, that a DLL file or files would control the operation of the spell checker for example. Another DLL or DLLs would support the print preview feature or actual printing process. Hence if a dll file becomes damaged, the function within the program which is controlled by that dll file would cease to work.

 

I can't answer your question Phil, as I only pulled that info from Google, but going from what the links say, it would suggest that may be the case. I'll let others that know what they're talking about answer from here

 

I think you have it Phil. I look at them as sort of sub-routines that are called when a particular common function is needed.

 

Yes Phil.
Dlls are shared resources in a common library, so as in your example, both Word and Excel may use the same dlls to perform a certain function.
Before .NET is was a real headache as sometimes you would install a new version of software which would overwrite the old dll which would then stop other applications from working properly. This used to be referred to as 'dll hell' and was a major headache for developers.

 

Sounds completely logical. Looking at the concept from another angle then, I guess a particular application with a particular feature would have a dedicated dll file contained within its assembly which provides that function. However because no other applications use that dll file, any problems within it would restrict problems to the parent application.

Whereas a problem with a windows core dll file - such as the dlls that provide printing functionality - which would obviously be shared by all installed applications - would cause more general effects.