Here is the context of my question:
I did a layered (semi-transparent) window. Ok, I admit it's not that impressive, but hey, I did it all by myself :)

Anyway... To get a rid of those "undefined symbols" messages I previously got, I found that some functions and equates was effectively not defined in the USER32.LIB and USER32.INC files.

So I added some equates in my source code... and I used the USER32.LIB from the platform SDK I just downloaded. After this, my file was assembled successfully, and a nice semi-transparent window popped on my screen.

My main concern is about that USER32 lib file. Ok, it's a newer one, but it's also a smaller one (133K instead of 557K)

Do this new lib miss some functions? Or maybe MicroSoft have optimized thier code :eek:
Posted on 2001-09-18 20:41:31 by dotCODE
I remember reading somewhere something about changes to the lib files sometime back - I think your safe? :) Oh, cool avatar!
Posted on 2001-09-18 22:38:00 by bitRAKE
You know "HAL 9000" ?
"He's" in one of my favorite movie (2001: a space oddyssey)

My avatar is a scaled down version of a desktop background I made a while ago. If anybody wants it... just ask. The original is 1600x1200 in size.

...and for now, every things I do using the "new" LIBs seems to work fine. I still wonder why the new LIBs are smaller in size
:confused:
Posted on 2001-09-18 23:02:05 by dotCODE
The lib files have undergone a lot of changes from time to time :).
Their basic format is still the same, as far as I remember. Now, the
reason they are smaller...

older library files are very "explicit". For each exported symbol, they
have a lot of coff object files inside (3 or 5, can't remember). These
files define the various sections, and the section data, necessary
to create the import section. The reason each import generates
three or five files, is the complicated matter of only including the
symbols you use, and make this include the dll file, but only if at least
one of the symbols are used ...

The "new" format is a short format, which... is different :). Here's
what MSDN has to say:


In an import library with the long format, a single member contains the following information:

Archive member header
File header
Section headers
Data corresponding to each of the section headers COFF symbol table
Strings

In contrast a short import library is written as follows:

Archive member header
Import header
Null-terminated import name string
Null-terminated dll name string

This is sufficient information to accurately reconstruct the entire contents of the member at the time of its use.
Posted on 2001-09-19 04:45:12 by f0dder
Oh yes, a little thing... if you use API calls that are win2k/me/xp-only,
like transparency, don't link to the directly, it is "polite" to use
GetProcAddress, so that your programs *can* run under 9x, but
will just get enhanced features under win2k and later.
Posted on 2001-09-19 04:46:38 by f0dder
dotCODE,

Fodders idea is a good one but if you want to be able to code directly with later windows versions, get the set of libraries for that version and then run the l2inca utility that comes with MASM32 to create a set of includes that match the libraries. This means for each library, you have the correct include file available.

Regards,

hutch@pbq.com.au
Posted on 2001-09-19 05:54:20 by hutch--
F0dder:

Thanks for the info; I guess if I pay more attention to the MSDN library (i.e: read it), I won't need to post that much "useless" messages :)



hutch:

Ok... now I know the use of this "l2inca" utility. Again, I realize that I'll have to be more careful and read before I ask something...

BTW, is it normal that the l2inca crash while it process some directX-related libs ?! I removed them from the folder, and all the other libs was processed without any problems.

More precisely, it's d3dx8 / d3dx8dt / d3dx / d3dxd libs who crash at the 2nd pass of l2inca...

It's not a "big" problem; I'm really not close to the day I'll have to use them anyway!



Again, thanks to you guys!
Posted on 2001-09-19 10:09:47 by dotCODE