DLLs?

[Dak]

is my understanding of dlls correct?

 

(note - my grasp of programing is a tad basic to say the least, the examples of coding that i give are written in strangebasic and may need to be parsed into an actual programing language within your head)

 

basically, rather than, say, MSword having something to the effect of

 

if font = arial, gosub arial

 

and

 

ARIAL

{programing to display arial font}

 

buried somewhere within its programming so that it can display arial fonts, it will instead have something along the lines of

 

if font = arial, run arial.dll

{tell arial.dll what words have been input}

 

and arial.dll will bascally consist of

 

{programing to display arial font}

{tell word.exe what to draw on screen}

 

so that the arial font can be used by more than one programe, and more fonts can be added without having to change the actual programs, to update the arial font you have only to update the dll rather than all the programs which use the arial font etc etc.

 

is that correct?

 

also, id guess that dlls can be used kinda like scripts? in that java is an .exe and its scripts are the instructions for what the java.exe should do, is it the case where random.exe can use dlls as instructions for what that .exe should do?

 

soz if that was worded a tad confusingly

[Dave]

I'm not entirely sure about your reasoning there, so I'll post what I know about DLLs so that you can get the general idea

 

A DLL (Dynamic Link Library) is basically a collection of functions and subroutines organised and put into a single file. They're quite useful for a number of reasons:

1) When you're programming, it helps to keep things seperated in the code, and this is one way of doing this.

2) Writing the same code for many different applications is quite a boring job; having libraries helps you re-use the same code.

3) You can load/unload libraries dynamically in most cases, helping you manage system resources.

 

I'm sure there's more, but this is the general idea. So Word, in your example, might call a function in a library to get a list of the system fonts and populate the pop-up list with the list of names.

 

They aren't the same as scripts though. Libraries contain a load of compiled code that's added into memory as and when it's needed. Scripts are run through an interpreter; you don't compile the code, but each line is parsed and executed seperately.

[Dak]

so dlls actually act as if they were part of the program (when theyre in use that is)?

 

so, is there any difference between a program using a dll that codes for function x, and a program that actually has the coding for function x built into it?

 

the reason i ask is that im trying to learn about malware removal/repair; basically, if a programe runs a viral dll, then is that effectively the same as if that program had the viral code written into it (except for the fact that its easyer to delete a viral dll than it is to remove the maliciouse coding from within a program)?

[5614]

A .dll file is a library containing data that can be used by any application which is compatable with it (so any windows app. maybe some others, not sure).

 

Now normally a single .dll can be used by several programs, removing a .dll could result in multiple programs crashing, but then as you say, its hard to remove a bit of malicious coding from a complex program.

 

But then detecting malicious file isn't that hard, detecting the .dll files it is accessing is quite a lot harder, and why would malicious programs use .dll files anyway? I didn't think they did, but then I'm mainly thinking of viruses, unless the virus is a .dll file, that's different.

[Ndi]

Dak, DLLs are quite complex to understand, but once assimilated, they have tons and tons of advantages and uses versus a few problems.

 

At the most basic level, imagine this:

 

procedure MakeTea(TeaType: TTeaType)

begin

GetTeaStatus;

...

...

end;

 

Above is pesudopascal, but it has been chosen because of clarity. Now assume this is your Life.exe:

 

Wakeup;

MakeTea;

DrinkTea;

 

Instead of carrying the actual implementation of tea making in a program, one can cut it and move it (literally) into a DLL.

 

library Tea;

 

procedure MakeTea(TeaType: TTeaType)

begin

GetTeaStatus;

...

...

end;

 

export MakeTea;

 

So what this does is embed the procedure. Above EXPORT line adds the tea making into a list in the header of the dll, allowing for more than one procedure to be stored in. You could have, for example, TEA.DLL that would embed MakeTea, DrinkTea.

 

When writing a program, one does not have to actually code any tea. Just say you want to use tea.dll and when tea needs making, use MakeTea in Tea.DLL. The operating system will look into the header, find procedure MakeTea and execute it for you.

 

Hope you followed so far. Back to your Word question.

 

In particular, rendering (drawing) a font-faced text on a canvas (screen), takes the following steps:

 

<select font>

<get text>

<render to a temporary canvas>

<drop that where needed>

 

Word already knows what and how it looks like, so rendering and dropping is needed. So it's down to the coder to choose an implementation:

 

a) Render+drop

 

Dll exports a DrawArial procedure that takes a string as a parameter, along with x and y of where it should be on the screen. Dll renders it and then adds it to the screen at x,y

 

b) Render only

 

Dllexports a RenderArial that takes a text and returns a bitmap (will not bore you further). Word will then take that and add, wrap, size that for you.

 

Basically, a DLL is a collection of procedures. There are rare and odd cases in which a DLL takes a call back into an executable, usually it carries procedures that take fixed parameters and return fixed parameters.

 

Think of it in terms of a book, an encyclopedia with a definition on each page. Or, as the name suggests, a library with special books, each teaching people how to do something.

 

In your case, the simplest model (in real life) would be to have a library called Arial.dll. When Word sees a font it can't understand, it looks for a library with the same name and if it finds one it loads it and calls it's exported Render method.

 

This is a dedicated way of coding extensions. In the future, Arial might support something not in the font directly, like right-to-left or features nor previously supported, like shadows. In this case, the Arial.dll can be replaced with a version that checks to see if the Arial font has shadow ability and if so, drops a shadow.

 

This is never the case with fonts since compatibility would be dreadful. But it is the case with -say- format plugins.

 

Assume your image viewer supports bmps but not jpgs. It has a BM6.dll that reads a .BMP and draws on screen. The main executable opens the file, reads header and looks for an addon. For BMPs, header is BM6, so it would look for BM6.dll.

 

You need no update, all you need is a JFIF.dll. It will get called when the header is JFIF (Jpeg header) and that would draw the jpeg to your screen.

 

Get any modular viewer and you will see it has loads of DLLs with format names or extension names.

 

Sorry about the long post, but as i've said, once one gets past "ermm, i guess .." and to "oh, like this", DLLs can improve your life considerably.

 

Your generic example of DLLs is not wrong generally speaking, except:

 

* DLLs are not like EXEs. An EXE does something specific, it has a purpose, a direction. A DLL just holds code. It can't be "run" (it can, but that's not basic approach), it holds pieces of code that do things.

 

They get "loaded" by means of once loaded the OS has a list of what it holds so you can call it directly. Loading a DLL is like entering a library. Once in, you can list the books and grab one. If not in, you can't just grab a book.

 

* They are not "scripts" even though from the user point of view the behave exactly the same. They work more like the lines of code compiled into the dll get inserted where you call the procedure. Except that they do so at runt time, not at design time and they are already compiled so they can be in any other language.

 

So the general techinque is like this:

 

MakeJam.exe

 

LoadLibrary "Jam.dll"

Call MakeJam in "Jam.dll"

Call BottleJam in "Jam.dll"

LoadLibrary "Sales.dll"

Call SellJam in "Sales.dll"

FreeLibrary "Sales"

FreeLibrary "Jam"

 

I don't do Basic, but you can find loads of examples in the help and on the net. Try LoadLibrary and Basic as keywords. Maybe adding "Tutorial" would help.

 

Long post.

[Dak]

hey, thanx you three, i (think i) understand what dlls do now.

 

But then detecting malicious file isn't that hard, detecting the .dll files it is accessing is quite a lot harder, and why would malicious programs use .dll files anyway? I didn't think they did, but then I'm mainly thinking of viruses, unless the virus is a .dll file, that's different.

yeah, i meant a malitiouse dll, which is desighned to get the program that runs/uses it to perform a crappy operation. (i believe svchost runs dlls at start-up? in that case, the malware will appear on the running prossesses list as 'svchost', as svchost will be doing the dirty work)

 

malitiouse dlls are quite common, mainly in slyware (adware and spyware) as opposed to viruses (CoolWebSearch springs instantly to mind, but there are many, many others which use crappy dlls, either installling their own malitiouse ones or by making changes to existing dlls)

 

hence why i wanted to know what dlls actually are. it all makes a tad more sence now. cheers guys.

[5614]

The common analogy would be an actual library...they are book with effectively anything in them that are there for anyone to access, a malicious .dll would be like a child chemistry book where H2O has been crossed out and replaced with H2SO4 or some such.