Board index » off-topic » Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?


2004-02-25 08:26:01 PM
off-topic17
Hi Rudy,
[...]
Quote
>I do tell you ;-) Tlink32 takes it from your .LIB file.
If that's so, should not *all* DLL-functions get imported by Ordinal, and
not just one here-and-there ?
The method of importing is separately specified for each function.
Quote
I'm not sure what I'm looking for, so I took two functions outof the same
program. One that does keep it's name(DestroyWindow), and one that
changes to an Ordinal-imported one (PathFindExtensionA)
[...]
Imported by: ordinal
[...]
Imported by: ordinal
[...]
Nothing strange that I can see.
1. You seem to have the library created without "-f" option.
2. Your linker may work incorrectly. I've just tried mine in
similar situation but couldn't get such results.
[...]
Quote
This is what I found :
[...]
Imported by: ordinal
[...]
Imported by: ordinal
[...]
For as far as I can see there is nothing really different in either of
them!
The same story as in the previous example.
Quote
I have absolutily *no clue* to why the first get's imported by Ordinal,
and the second by it's name. Any suggestions ?
1. Use a _normal_ library (e.g. import32.lib). Or recreate yours
with "implib -f ..."
2. Throw your linker away (and take version 2.5)
 
 

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Vasya Pupkin < XXXX@XXXXX.COM >schreef in berichtnieuws
XXXX@XXXXX.COM ...
Quote
Hi Rudy,
Hello Vasya,
Quote
[...]
>>I do tell you ;-) Tlink32 takes it from your .LIB file.
>If that's so, should not *all* DLL-functions get imported
>by Ordinal, and not just one here-and-there ?

The method of importing is separately specified for each function.

>I'm not sure what I'm looking for, so I took two functions
>outof the same program. One that does keep it's name
>(DestroyWindow), and one that changes to an Ordinal-
>imported one (PathFindExtensionA)
[...]
>Imported by: ordinal
[...]
>Imported by: ordinal
[...]
>Nothing strange that I can see.

1. You seem to have the library created without "-f" option.
I've not sat still today, and have sought & tried quite a few things to see
if I could explain what was happening. You're right, I created my LIB-files
without the "-f" option, as well as without the "-c" option (case
sensitivity). I just took it for granted that "import by name" would be the
default (did not really know anything about ordinals at the time :-)
Quote
2. Your linker may work incorrectly. I've just tried mine in
similar situation but couldn't get such results.
Something I did not think of (until this afternoon, after regarding the
results of more experimenting) is that I use the standard "import.lib" (as
provided by the Tasm 5 package), as well as libraries I created myself
(using IMPLIB). I'ts just possible that TLink uses, in reaction to the "/o"
switch, the "best fit" if both "by Name" and "by Ordinal" versions are
available. But I'm not really sure about it yet.
Quote
>I have absolutily *no clue* to why the first get's imported by Ordinal,
>and the second by it's name. Any suggestions ?

1. Use a _normal_ library (e.g. import32.lib). Or recreate yours
with "implib -f ..."
What do you call "normal" ? One of the tests I did was trying to use the
StrStrIA function. I took a clean, very basic skeleton program for it, and
it only contained a reference to the Import32.Lib. Assembling & linking
went quite allright, so the function-name was present in the .Lib-file. But
when I tried to execute the program a window popped up complaining that the
function could not be found :-\ I checked Import32.Lib, and the
function-name was there alright, imported by name, and linked to
Kernel32.dll !. I than checked the Kernel32.dll, and could not find the
function-name *at all*
I just did convert the libraries to inport "by Name" this afternoon :-)
Quote
2. Throw your linker away (and take version 2.5)
I will first experiment/test some more, as it is good possible I just get
confused because I just do not recognise what is happening ...
Thanks for your help.
Regards,
Rudy Wieser
 

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Hi Rudy,
[...]
Quote
What do you call "normal" ? One of the tests I did was trying to use the
StrStrIA function. I took a clean, very basic skeleton program for it,
and it only contained a reference to the Import32.Lib. Assembling &
linking went quite allright, so the function-name was present in the
.Lib-file. But when I tried to execute the program a window popped up
complaining that the function could not be found :-\ I checked
Import32.Lib, and the function-name was there alright, imported by name,
and linked to Kernel32.dll !. I than checked the Kernel32.dll, and could
not find the function-name *at all*
And it shouldn't be there ;-) Here is the record from import32.lib:
01D041 COMENT Purge: Yes, List: Yes, Class: 160 (0A0h), SubClass: 1 (01h)
Dynamic link import (IMPDEF)
Imported by: name
Internal Name: StrStrIA
Module Name: SHELL32.DLL
But this is only present on NT-line. And M$ recommends to call
the function from "Shell Lightweight Utiliy APIs", i.e. Shlwapi.dll.
 

{smallsort}

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Vasya Pupkin < XXXX@XXXXX.COM >schreef in berichtnieuws
XXXX@XXXXX.COM ...
Quote
Hi Rudy,
Hello Vasya,
Quote
[...]
>What do you call "normal" ? One of the tests I did was trying to use the
>StrStrIA function. I took a clean, very basic skeleton program for it,
>and it only contained a reference to the Import32.Lib. Assembling &
>linking went quite allright, so the function-name was present in the
>.Lib-file. But when I tried to execute the program a window popped up
>complaining that the function could not be found :-\ I checked
>Import32.Lib, and the function-name was there alright, imported by name,
>and linked to Kernel32.dll !. I than checked the Kernel32.dll, and
could
>not find the function-name *at all*

And it shouldn't be there ;-) Here is the record from import32.lib:

01D041 COMENT Purge: Yes, List: Yes, Class: 160 (0A0h), SubClass: 1 (01h)
Dynamic link import (IMPDEF)
Imported by: name
Internal Name: StrStrIA
Module Name: SHELL32.DLL
I do seem to mix-up my DLL's a lot :-(( You're right, Import32.lib told me
its in Shell32.
Quote
But this is only present on NT-line. And M$ recommends to call
the function from "Shell Lightweight Utiliy APIs", i.e. Shlwapi.dll.
Yes, that is where I found the function too :-) Actually, that was where
I expected the function to be, but an error-box at load-time told me it was
bound to another DLL.
I tested the functions named in Import32.lib against the DLL's named in it,
and found a rather large group of functions in Import32.lib that where not
present in the mentioned DLL. I allready decided that it would be the
result of different DLL versions used when Import32 was generated, but could
not put my finger on how that could have happened. Your mentioning NT
solves that riddle :-)
It looks like I will have to remove/replace Import32.lib totally ...
By the way : I think I have solved the riddle of DLL-functions switching
from being imported by name to being imported by ordinal : My own
library-files where all created "by Ordinal". TLink seems to ignore this
ordinal-information if the "/o" switch is not specified. But when the "/o"
*is* specified, it will *try to* use the ordinal of the function. As my
lib's where loaded after Import32 (which has got *all* functions imported by
name), only functions that where not named in it would come outof *my*
lib-files, and would be imported by ordinal ...
In short : it's a mixup of the understanding of the function of the
"/o" -switch, together with having "by Name" and "by Ordinal" references.
It looks like that the "/o" -switch means import the function "by Ordinal"
*if such information is available*, otherwise just use it's name.
Regards,
Rudy Wieser
 

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Hi Rudy,
[...]
Quote
It looks like I will have to remove/replace Import32.lib totally ...
Hmm... The library is good enough for me... But if you need more
functions, IMHO it would be better to take M$ import libraries and
convert them with Borland COFF2OMF utility. This can allow you
to avoid a lot of possible mistakes.
[...]
Quote
It looks like that the "/o" -switch means import the function "by Ordinal"
*if such information is available*,
Yes, exactly.
Quote
otherwise just use it's name.
But that can cause errors in some cases :-( For example, when
you assign the "name" yourself.
BTW, this is why Micro$oft development tools _always_ try to
import functions by ordinals "if such information is available" ;-)
 

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Vasya Pupkin < XXXX@XXXXX.COM >schreef in berichtnieuws
403ede7d$ XXXX@XXXXX.COM ...
Quote
Hi Rudy,
Hello Vasya,
Quote
[...]
>It looks like I will have to remove/replace Import32.lib totally ...

Hmm... The library is good enough for me... But if you need more
functions, IMHO it would be better to take M$ import libraries and
convert them with Borland COFF2OMF utility. This can allow you
to avoid a lot of possible mistakes.
It's not more functions I'm after, but being able to use some functions at
all.
Currently I have to load the SHLWApi.lib before I load Import32.lib,
otherwise when I use a function like StrStrIA it will be linked against
shell32.dll (generating an error at Load-time), not against SHWApi.DLL, as
needed with Win98.
Quote
[...]
>It looks like that the "/o" -switch means import the function "by
Ordinal"
>*if such information is available*,

Yes, exactly.
The same goes for possibly added .DEF-files. I think that I can now use
.DEF -files to import certain functions "by Ordinal" : Using the "/o" switch
will have no effect on library-imported functions, as they currently only
available by name, but will on .DEF -file imported ones, to which
Ordinal-information is added.
Quote
>otherwise just use it's name.

But that can cause errors in some cases :-( For example, when
you assign the "name" yourself.
??? In the below you mention that MS actually works without named
functions, which means that every version of a certain DLL *must* have *all*
functions at the same place. Functions can be added to the end, but not
replaced or sorted (on function-name).
It should allso mean that adding a name to an Ordinal-only function should
not create any problems. That is, unless MS decides to change a certain
function, thereby breaking "old" programs (of themselves ?) depending on it.
Quote
BTW, this is why Micro$oft development tools _always_ try to
import functions by ordinals "if such information is available" ;-)
That would mean that all functions ("by Name" ones too) in Windows DLL's are
fixed in their positions. If not, is there a way to mark/recognise
fixed-position (Ordinal or Named) functions ? (I don't think so, but I have
to ask ...).
Regards,
Rudy Wieser
 

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Hi Rudy,
[...]
Quote
Currently I have to load the SHLWApi.lib before I load Import32.lib,
That's correct way. I also write custom libraries _before_ import32.lib.
[...]
Quote
Using the "/o" switch will have no effect on library-imported functions,
as they currently only available by name,
Not always. Some functions in import32.lib _have_ their ordinals
specified. Using the "/o" switch _will_ affect them. But that's OK,
because M$ also imports those (particular) functions by ordinals.
[...]
Quote
??? In the below you mention that MS actually works without named
functions, which means that every version of a certain DLL *must* have
*all* functions at the same place.
No! ;-))) I just told you that M$ works _with_ named functions
_if_ there are _no_ ordinals of the functions specified in .LIB files.
This is why I wrote "if such information is available" (your words ;-)
[...]
Quote
That would mean that all functions ("by Name" ones too) in Windows DLL's
are fixed in their positions.
No! I mean "Not all functions". Just the few of them.
Quote
If not, is there a way to mark/recognise fixed-position (Ordinal or Named)
functions ? (I don't think so, but I have to ask ...).
Unlike names, ordinals are _always_ present in .DLL files.
But we are talking about .LIB files, aren't we? ;-)
 

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Vasya Pupkin < XXXX@XXXXX.COM >schreef in berichtnieuws
XXXX@XXXXX.COM ...
Quote
Hi Rudy,
Hello Vasya,
Quote
[...]
>Currently I have to load the SHLWApi.lib before I load Import32.lib,

That's correct way. I also write custom libraries _before_ import32.lib.
Thanks. Too bad that (the documentation to) my assembler did not bother to
tell me :-\ It would have saved me precious hours ...
Quote
>Using the "/o" switch will have no effect on library-imported functions,
>as they currently only available by name,

Not always. Some functions in import32.lib _have_ their ordinals
specified. Using the "/o" switch _will_ affect them. But that's OK,
because M$ also imports those (particular) functions by ordinals.
:-) If that's so, Borland forgot to include them into the Import32.Lib . It
only contains functions exported by name.
Quote
[...]
>??? In the below you mention that MS actually works without named
>functions, which means that every version of a certain DLL *must* have
>*all* functions at the same place.

No! ;-))) I just told you that M$ works _with_ named functions
_if_ there are _no_ ordinals of the functions specified in .LIB files.
This is why I wrote "if such information is available" (your words ;-)
Which is quite different to the way Tasm works, as it tries to access
functions as much as possible by their names (180 degrees opposite the MS
way)
Quote
[...]
>That would mean that all functions ("by Name" ones too) in Windows DLL's
>are fixed in their positions.

No! I mean "Not all functions". Just the few of them.
Actually, it does not matter. If you import as much as you can by Ordinal,
little places will be left to be used by "by Name" at all (if any). Just
as an after-thought : why does *any* function get exported by name, as MS
only wants to export them by Ordinal (it just does not compute ....)
Quote
>If not, is there a way to mark/recognise fixed-position (Ordinal or
Named)
>functions ? (I don't think so, but I have to ask ...).

Unlike names, ordinals are _always_ present in .DLL files.
Yes, ofcourse. But not every Ordinal is accompanied by a name.
The ones *with* a name could change index (ordinal) positions (as they are
found by their *name*, not by their index). The ones that are only known by
their Ordinal-positions can't change their positions.
Quote
But we are talking about .LIB files, aren't we? ;-)
No. Definitily no. LIB-files are only support files, there to enable
other programs to call certain functions in certain DLL-files. As such they
are not important *at all* (but for their translation capabilities (which
are also present in .DEF -files :-) )
Regards,
Rudy Wieser
 

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Hi Rudy,
[...]
Quote
Too bad that (the documentation to) my assembler did not bother to
tell me :-\ It would have saved me precious hours ...
You could save much more time with the libraries taken from
M$ Platform SDK and converted by Borland into OMF format:
www.ols-lab.com/devcorner/psdk.zip (154 kb)
BTW, they can be used _instead_ of import32.lib ;-)
[...]
Quote
:-) If that's so, Borland forgot to include them into the Import32.Lib .
It only contains functions exported by name.
[...]
%-\ Hmm... Perhaps you use too old version of the library...
 

Re:Re: Provided a .DEF-fille to my TLINK32. Still need to add the /o -switch. Why ?

Hi Rudy,
[...]
Quote
You could save much more time with the libraries taken from
M$ Platform SDK and converted by Borland into OMF format:
www.ols-lab.com/devcorner/psdk.zip (154 kb)
I'm sorry! :-( Those are actually .OBJ files (but with .LIB extension ;-)
In order to create _real_ libraries, enter the following command line:
FOR %i IN (*.LIB) DO TLIB /C LIB\%i +%i