libraries & dlls some questions

[Rainstorm]

hi,

in the MASM programmer's refrence it says under 'entry procedure

DS contains the library's data segment address

an address is a dword value right ? so how can it fit in the 16 bit DS register ?

here's the link http://webster.cs.ucr.edu/Page_TechDocs/MASMDoc/ProgrammersGuide/Chap_10.htm

how much stuff in this DLL chapter has meaning & is relevant to 32bit Windows ? or is a lot out dated ? - if possible would be nice if someone could mention what stuff there doesn't hold ground in 32bit Windows code.
--------

can someone confirm whether am getting this right about Procedures - One mustn't write more than one procedure in an (.asm) file, but one can bundle a number of procedures together in a single .lib file & when a procedure is called from that .lib only the code for the called procedure is written from the .lib into the calling program. - is this right ?

-----
in the code for the bare asm model(in Qeditor) the include/includelib lines aren't commented out but in the proc model the  lines are commented out. can someone explain exactly the impact of this.

many thanks...

Rainstorm

[Tedd]

That document is referring to Windows 3.0 -- which ran in 16-bit mode (basically on top of DOS.)
The segment registers are actually descriptors to segment table entries - it's just that in 16-bit mode these entries are set to look the same as the addresses they reference (for legacy compatibility.) In 32-bit mode, the segment entries are whatever the OS says, so you shouldn't consider them as 'addresses' at all - but they're still descriptors and they still look 16-bit (they're actually 24-bit, but the top is hidden.)


You can write as many procs in one file as you like - most people put their whole program in one file.
In the case of building libs though, it's usually a good idea to do one-per-file, because of the way the object-files are linked together - so that when you use one function from the lib you only get that function and not every other function in the lib as well (what you'll get is every function that was in the same asm file as the function.)


Commenting out lines means they're ignored - they may as well be deleted. The significance is that somebody commented them out instead of deleting them (though they may have done so to remind you to include them elsewhere; or simply because they chose not to delete them.) You can delete them, or simply not type them in your own libraries.


{P.S. a procedure is just another name for a function - whether it's in a 'normal' program, or a library, or anywhere else.}

[Rainstorm]

tedd, that cleared it up for me.
about the lines being commented in the 'Proc' files, just to know,  would leaving them uncommented degrade the performance of the proc ? - also is there any set way to know what  includelibs i'd need for my proc , other than just having the bare knowledge of it.

thanks.

[Tedd]

They're only commented in the source, they're not included when assembled (they're commented out!!) so it makes little difference whether you leave them in or not (except that it may take a few extra cycles for the assembler to skip over these lines; but they're not included in the executable.)

The libs you need to include depends on which external functions you use. If you need to find out which these are, you can try assembling and watch for the error messages :lol Since the assembler has no way of knowing which libraries these appear in, there's no way it can tell you either. You should generally know which libraries you have to include (once you get used to the functions you're using), and for the rest you can check on msdn or in the win32api.hlp file, or search through the .inc files to see where the function names appear :wink

[PBrennick]

Rainstorm,
Mark Jones wrote a program called incfind that will search all include files in up to 5 directories for specified APIs. It is a good addition to any toolbox. You should be able to find it on this forum. If not, just drop me a note and I will send it to you.

Paul

[Rainstorm]

thanks all .

[ic2]

{P.S. a procedure is just another name for a function - whether it's in a 'normal' program, or a library, or anywhere else.}

Ted, I don't question your expertise when it come to assembler in any kind of way but for a minute i thought this was settled.  I DO think a procedure can/will be called a function but i feel that Timbo conclusion carry some weight because it would seems that a procedure main FUNCTIONALITY is to be reused by other code with-in a program that require the same type subroutine.  And it also seems what makes a function a function other than what other assembler and programming languages choose to call them at the head of a procedure may not mean it is a TRUE FUNCTION technically with-in the language that we write but was only accepted to be what other langages called it  while we continue to skip the details. (Example: GoAsm, Fasm and others) I think they do that just to be difference from masm syntax, and no one has ever questioned the difference.

Timbo statement seem to shed some light on that.

You basically have 2 types of procedures.  Function and subroutine.

A function is a procedure with an anticipated return value (in eax, for example, or other register).  Subroutines do not have an anticipated return value.

So basically there is some difference and someone has finally broke it all down the best way he see fit.  Not for a war of words but can you comment on this.

I'll take this time out to say Thanks Timbo.  I stopped my questions and comment on threads that seems to make good points instead of re-Thanking everyone at the end of such great comments.  I have a bad habit of going on and on at times ...

Thanks Timbo 3x...

Why all of this... because i for one need to know for sure.  For now in my head the word FUNCTIONALITY don't mean a PROCEDURE is a FUNCTION if we're specking of Assembler.

[Tedd]

Well, in all honesty it makes little difference :lol The different names have appeared from different langauges and were then adopted/stolen from.

So we have: function, procedure, subroutine, method...

Function originally comes from mathematics - an equation that returns a value. As programming was originally based upon this, it seemed the correct name to use for groups of instructions (that calculate equations and return a value.)
Procedure was used at some point to indicate a group of statements in a 'procedural' language.
Subroutine is named to indicate that it contains a set of statements forming a sub-routine, to differentiate it from the main routine.
Method comes from the object-oriented paradigm, trying to indicate that they are part of the objects, not just groups of statements.

Some languages choose to differentiate between functions and procedures, saying that functions return a value but procedures don't.

Masm uses 'proc' for defining procedures, so that is why they are generally referred to as procedures. Masm procs do not, in the definition, return a value -- if you choose to leave some meaningful value in eax then that is your choice, but it is not enforced.

It we're trying to be correct, then calling them functions is wrong - a function must return a value, and must not have side-effects (i.e. not modify any external variables, or machine state.)

My point was not to tell you which to use, just that there is nothing 'special' about lib procedures compared to 'normal' procedures. Choose a naming convention and stick with it - the point is to make other people understand you, so as long as you're clear and consistent it doesn't matter whether you call them functions or procedures or subroutines or whatever the next fashion is.