I was having Link errors - "Missing export blah-blah in Shell32.dll ..." errors. I searched my SDK header files and found that the following functions (defined in Shell32.inc) - are actually not in Shell32.dll but are in Shlwapi.dll:

StrChrA, StrChrIA
StrCmpNA, StrCmpNIA
StrCpyNA
StrNCmpA, StrNCmpIA
StrNCpyA
StrRChrA, StrRChrIA
StrRStrA, StrRStrIA
StrStrA, StrStrIA


Hutch, am I missing something here or is this .inc file in error?

P.S. I commented the faulty lines in Shell32.inc & now all is ok.


G. Falen
Posted on 2001-08-03 16:56:20 by gfalen
Greg,

Thw way it works is that the include files are produced directly from the Microsoft import libraries and what you have in the include files is in the Microsoft import libraries.

Each API function is stored in the library in the form of a decorated name _Function@24_ or similar. The utility that creates the include files scans the entire library and gets the full set of decorated names from each one and filters out duplicates of a number of types and then expands up the decorated names into function prototypes.

Some of the string functions in shell32.lib are also in shlwapi.lib so if calling them from shell32 does not work, use shlwapi instead. Duplicates are common in the Microsoft libraries but normally MASM handles this as long as they are not redefinitions with different parameter counts.

These things also change with different version of the libraries, I have just produced a tool that lists the library used for every API function in the current Whistler edition of the SDK, (about 11000 functions) so it will probably save you some time if you download it.

Regards,

hutch@pbq.com.au
Posted on 2001-08-03 20:31:35 by hutch--
Perhaps the lib files you used to build the masm32 package were older ones which did have these functions in Shell32 (ie. before the release of Shlwapi).

I have the Jan 2001 Platform SDK installed. The help says they are in Shlwapi. The strings "StrStr", "StrCmp" etc, don't even appear anywhere in Shell32.h or Shelll32.lib (SDK release).

Including Shlwapi.lib before Shell32.lib will work. This however is not a good solution. It seems they really don't belong in Shell32.inc.

If you want I could work with you on rebuilding the necessary stuff from my SDK files.

G. Falen
Posted on 2001-08-03 21:48:37 by gfalen
Greg,

Thanks for the offer but it amounts to running the utility L2INCA on the library files that best suit the operating system you are using, I have the later Whistler edition set of libraries myself installed and they are different to the set from MASM32 which were from the win98sdk. SHLWAPI was an upgrade for win95 as from memory the later versions of windows already have it.

Regards,

hutch@pbq.com.au
Posted on 2001-08-04 02:35:01 by hutch--
Hutch,

The problem is that most people will probably includelib shell32 before shlwapi. So link will look 1'st in shell32 - which is missing these exorts!

Try it. invoke StrStr ... and put the includelib for shell32 before shlwapi. I think you will find you get the same errors!

That's because they actually are'nt exported there. I think your proggy (ltoinc or whatever) accidentally grabbed these IMPORTS from shell32!


Regards
Posted on 2001-08-04 09:09:55 by gfalen
What I meant was that link will faithfully bind them to shell32.dll because the lib says they're there. But you'll get "Miissing export..." runtime errors because they really do not exist in shell32.dll.
Posted on 2001-08-04 09:19:27 by gfalen
Boy I hope this is'nt an omen - lol

I mean they're not EXPORTED from shell32 they exist as imports.
Posted on 2001-08-04 09:22:43 by gfalen
Greg,

Its simply a matter of using the libraries that best suit you OS, in the whistler edition of the SDK, the string functions are not in shell32.lib but ONLY in shlwapi.lib.

I supplied the utility so that people could build the set of includes that matched the libraries that they use, all that happens when MASM32 is installed is that it builds the set from the libraries that are supplied with it which are technically from win 98.

Now if you have a better solution that producing the include files that the technique I use of getting the data from the import libraries, lets hear it but if you have in mind converting them from the SDK include files, you will need to write a C++ compiler front end to read and convert them. The other alternative is to do the conversions manually which would be finished by about the year 3000.

The whistler edition of the SDK has about 11 thousand API calls in it so I think you can forget trying to convert them manually. I produced the API to library utility so that finding out which library a function was in was no big deal. The format of Microsoft libraries is not a matter that is within my control, perhaps you could send an email to Bill Gates and complain to him but I would not hold your breath waiting for an answer.

Regards,

hutch@pbq.com.au
Posted on 2001-08-04 20:56:43 by hutch--
Hutch my good man, please bear with me. I'm only trying to help you improve you're package (which BTW I use all the time - excellent piece of work).

You don't seem to follow what I am saying here. The reason for these redundant references in Shell32 (I suspect), is because the "utility that creates the include files" is faulty. It grabbed a few IMPORTS by mistake from your original DDK (or SDK) libraries. Namely the functions I mentioned which were actually imports (from Shlwapi). I don't think they ever were exported from Shell32 to begin with. This "faulty conversion" may have reared it's ugly head elsewhere too which might explain why your new l2extia utility is behaving unexpectedly with certain functions.

I found a file just this morning in my zip archives. Don't know where I got it but it has an alternative converter which creates both kind of .inc files - the original and the new __imp__Function@N style. The author seems to conclude as I do that your original utility had grabbed imports by mistake. It's very small (< 8k) and I have attatched it here for your inspection.

I hope you see what I mean. I don't think these protos belong in shell32 at all. I think this is a "mistake" made in the original lib to inc conversion. And other .inc / .lib files might have been affected too.


Highest regards.
Posted on 2001-08-05 08:48:00 by gfalen
oops - forgot to attach the file. Here it is.


G. Falen
Posted on 2001-08-05 10:50:47 by gfalen
Greg,

Its an interesting utility, it appears to read the data in a different way to the ones I have used. Mine read every decorated name in the library, sorts them, filter out duplicates, performs the equate expansion if the function ends with "A", removes the "W" versions and then filters out the second set of duplicates before expanding up the parameters to the correct count.

I have opted for this approach because Microsoft have been known to change the internal format of their libraries in the past so I did not trust their published format. Now the risk is that Microsoft are not particularly consistent with their libraries and you can pick up duplicates. The win98 libraries have a number of them but MASM handles identical duplicates with no problems. Only when you get identical function names with different parameter counts do you get "non benign redefinition" problems.

If you can find the author or the source code, it would be a lot more useful if you could select which format you were going to end up with instead of having all three and choosing them with equates. The code appears to be picking up more information with some functions, it appears to handle normal libraries where mine will only handle import libraries so it may be worth pursuing.

The inclusion of the INCLUDELIB directive would work OK but with the format of MASM32 being different, it would break a lot of code so it would be handy to be able to remove the line to keep it compatible. I opted for the symetrical INCLUDE / INCLUDELIB so that people who were coming into MASM programming would understand that you need both.

If you have been email bombed enough times with questions about setting up a programming package, you would take the approach that I do and try and reduce the error margin with programmers who are starting in assembler.

Regards,

hutch@pbq.com.au
Posted on 2001-08-05 19:35:06 by hutch--
Somewhere I used to have a copy of the current Microsoft format COFF libraries specifications but I cannot find it and wotsit.org has nothing on the Microsoft format at all so after wasting an hours or so this morning looking for it, I gave up.

If anyone has a set of specifications for the current Microsoft COFF library format, I would appreciate a copy as I just cannot find it at the moment.

Regards,

hutch@pbq.com.au
Posted on 2001-08-05 22:15:39 by hutch--
hutch, the coff object format used by ms is the standard coff format
(except they handle IP-relative relocs differently), so I guess their
library format is the standard coff format as well.

The following link, although formatted pretty funkily, might prove
to be of help: http://www.iecc.com/linker/linker06.txt . Seems to
have information on the file format. A google for
+coff +archive +format

gave a couple of interesting links as well. Don't trust wotsit for anything
but *very* wellknown or *very* strange formats :). And mostly
it's format that are tied to the x86 and dos.
Posted on 2001-08-06 03:09:34 by f0dder