madhur

Hello
There is a file in windows directory called crtdll.dll. I want to
use functions contained in it.
How do I build Import library for this file.
I have heard about Borland Implib, Can this be used to build the
library.
How can I get the list of functions contained in the DLL.

Will the same library work for both c/c++ and assembly.


--
Winners dont do different things, they do things differently.

Madhur
India
email : madhur<underscore>ahuja<at>yahoo<dot>com

pavel.srubar

ALIB crtdll.dll http://alink.sourceforge.net/download.html


PEEXPORT crtdll.dll
http://rs1.szif.hu/~tomcat/win32/packs.htm

or many other PE tools, e.g. Dependency Walker by Microsoft,
PEview by W.J.Radburn
http://www.magma.ca/~wjr/

Bye,
v
Sr.

beth

Using the Borland tools, you should first run "IMPDEF" on the DLL file
(note that for important system DLLS like Kernel32.dll, they are
always in use and, thus, you may encounter a sharing violation...if
so, then simply _copy_ the DLL file to some other directory, run
IMPDEF and then delete it afterwards ...what "IMPDEF" does is create
a ".DEF" file for the library, containing a list of all the functions
in the DLL (".DEF" files are able to contain other pieces of
information and you might want to check out some documentation on all
the various options available...but that's only if you're interested,
as the ".DEF" file IMPDEF spits out can just be treated as a "black
box" to pass on to the next process...but as you mentioned being
interested in the "list of functions" too then that's what "IMPDEF"
does: reads a DLL and then creates the corresponding ".DEF" file for
that DLL, which lists the functions...if you were writing your own
DLL, you see, then you'd probably - using Borland tools, anyway -
create your own ".DEF" file manually as part of making that DLL to
"export" all the functions you want to be "visible" outside the
DLL...well, as Microsoft or someone else actually created the DLLs you
want to use, then "IMPDEF" is there to "plug the gap" for you by
automatically creating a basic ".DEF" file that's got enough
information in it to create ".LIB" import libraries with ...

Once you've got your ".DEF" file out of "IMPDEF" then feed this into
"IMPLIB" to get the final "import library"...this ".lib" file can then
be used exactly like you'd use Borland's own "import32.lib" or
whatever, by supplying its name on the linker command line...

One important thing about "IMPLIB" here - which caught me out the
first time I tried this, so I'll mention it here to save you going
through the same confusions I did - is that you should specify the
"-f" ("force imports by name") option and, really, also specify the
"-c" ("case sensitive names") option too...the reason being that,
well, all the standard Windows DLLs (supplied by Microsoft) are
certainly going to have "case sensitive" names because Microsoft uses
C++ compilers to do everything and that's a case sensitive
language...and you should specify "import by name" because the
"ordinals" (numeric "names" for the functions that can also be used as
"quick shorthand" for each function aren't necessarily the same
from Windows version to Windows version...so, the system DLLs are also
designed to expect all imports to be made by "name" rather than
"ordinal"...

So, for example, if you'd prefer Microsoft's "one LIB file per DLL
file" scheme rather than Borland's "stuff everything into
Import32.lib" scheme, then you can actually create the "import
libraries" yourself, straight from those DLLs...at the command prompt
(in some sort of "working directory" you've created for the purpose,
such as a "lib" folder inside your project's folder ...

---------------- 8< ------------------------

copy C:\Windows\System32\Kernel32.dll .
impdef Kernel32.def Kernel32.dll
implib -f -c Kernel32.lib Kernel32.def

copy C:\Windows\System32\User32.dll .
impdef User32.def User32.dll
implib -f -c User32.lib User32.def

copy C:\Windows\System32\GDI32.dll .
impdef GDI32.def GDI32.dll
implib -f -c GDI32.lib GDI32.def

implib -f -c Import32.lib Kernel32.def User32.def GDI32.def
---------------- >8 ------------------------

This is a bit of a contrived example but it shows roughly how to get
it to work...note that you _don't_ always need to necessarily copy the
DLL file before using "IMPDEF", it's just that for the "biggie" DLLs
like Kernel32, User32, etc. they are constantly in use that copying
them avoids any "sharing violation" problems (this could happen under,\0
if I recall correctly, Windows 98 and may not happen under NT
Windows...so, it might not be applicable if you try it out, but it
_can_ be a problem under at least one platform - because I had this
problem before - so it's best that I demonstrate the "safe" way that
ensures you won't get any problems...but you might, indeed, find that
"IMPDEF" will happily work directly on even these files when given a
"full pathname" to where they reside...also, of course, another reason
to mention this method is that you might copy a DLL file with a newer
/ older version and list of functions than what you actually have
installed...for instance, delibrately using a Windows 95
"Kernel32.dll" copied off an older Windows 95 installation you have
(remembering, of course, the terms of your EULA, so it is _your_
legitimate copy of Windows 95 and you're going to delete it off and
not do anything but use it for "IMPDEF", right? Wink, wink ...in
order to delibrately create an import library for an older version to
make absolutely sure you only link in Windows 95-compatible functions
for "compatibility reasons" (if you try using a function that was only
included with the XP version, it won't be found in the special "import
library" you've created and the link fails...which acts a bit like how
".386" in some assemblers can be used to delibrately "cripple" the
instruction set to only 386 instructions to ensure proper 386
"compatibility"...same idea, basically ...there's more than one
handy use for making your own "import libraries" with IMPDEF and
IMPLIB, you see, if you're creative about things ...

Of course, as the other post mentions, there are other ways...and
other tools can do the job in one go or whatever...but as you
mentioned Borland in your post, that _could_ be a hint that you use
Borland development tools (or took advantage of that "free download"
offer they had that these tools are already handy on your system
...so, this is the "Borland way" of doing things for you, if you're
specifically interested in that...


Basically, yes; The "import library" is for the linker...your compiler
/ assembler never looks at these at all...and, as you may have noticed
from being able to link C object code and ASM object code with no
problems using your linker (because, basically, there is no such
difference as "C object code" and "ASM object code" ...there's only
"object code", full stop (US: period)...hence, the linker happily puts
C with ASM with PASCAL and doesn't blink an eyelid at this...it, in
fact, has no real idea whatsoever that they happened to come from
different tools with different languages...the "object code" format is
delibrately the same for all of them exactly to help out the linking
process...this is, in a sense, the whole concept behind "object code"
and a separate "linking" stage to permit many different "modules" to
all be put together in any old order from any old compiler or
assembler with no problems ...

Not that I have a Pascal compiler myself to actually try this but I'm
sure that the "import library" will also work for that too...or any
other compiler or language...what counts at this point in the "chain"
of processes is that the _object code_ format is the same (or, in the
case of ALIB or GCC's LD linker, that it's one of the _multiple_
formats it understands...which is why these linkers can be very handy
as they make things easier still by simply being able to understand
more than one object code format...GCC's approach is very clever, in
fact, because it has a "superset" format that it uses internally and
merely "converts" any other format it encounters into the internal
format so that you can have a project with files in all different
object code formats and GCC's LD linker doesn't blink an eyelid at
this, because it simply converts all of them into a "compatible"
format and then works with that ...

And, on this score, this is where you will start to encounter your
real problems...basically, Borland tools use the "OMF"
format...Microsoft tools used to use the OMF format but Microsoft
changed to their version of the "COFF" format (I say "their version"
because COFF - Common Object File Format - is actually from the UNIX
world and is "standard" - hence, it should be "compatible" - except
that, unfortunately, MS's implementation of "COFF" interprets some
fields differently to other COFF implementations...which only makes it
"sort of compatible" but not 100% so...you'll find that some linkers -
like NASM or ALIB, for example - list "COFF" and "WIN32" as separate
formats because though only a minor difference of interpretation, it
does mean that they often have to be treated as "different" to avoid
problems...those who are unkind to Microsoft would challenge whether
this "interpretation difference" was actually accidental or just
another one of MS's "decommoditising" strategies to try to
_delibrately ruin_ and . or take over an "open standard" so it ceases
to be a rival to them...whatever it is, this is as "dubious" as their
concept of what makes a "compliant" Java implementation ...and, MS's
LINK.EXE will "convert" OMF format files to ("their") COFF format
automatically (although, this works with "import libraries" but is
NOT - I was interested to discover - a solution for all types of
OMF -> COFF poblems...it's not happy to convert all OMF handed to
it...but, we're okay in this instance, as "import libraries" _IS_ the
conversion from OMF to COFF that it _does_ manage to do okay without
complaint...meaning that, technically, you should also be able to use
a Borland-type import library with MS's LINK.EXE too...although,
"mixing and matching" your tools like this tends to be ill-advised -
if you have any alternative options - because this is _always_ the
place where you'll run into all your problems ...

Also, as more general useful information, a couple of things are
useful to know...unlike other things under Windows, the file extension
".LIB" or ".OBJ" _doesn't_ actually refer to its file format...that
is, it could be OMF or COFF...and, also, for libraries, there's
actually two different types...ordinary libraries aren't actually the
same thing as "import libraries"...you _USE_ them in much the same
way...but whereas traditional ".LIB" libraries actually contain code
and data to be directly linked into a program, an "import library"
actually _ONLY_ contains the basic information (DLL name, function
name, etc. for telling the linker how to fill out the executable
headers with the right information for loading in the right DLL and
linking to it...

Hence, if you see ".LIB" as a file extension then you, unfortunately,
can't immediately jump to any conclusions...it's a "library",
sure...but that could mean at least: OMF code library, COFF code
library, OMF import library, COFF import library, etc...either keep
track of which libraries are what, use some "dump" utility to find out
before using or take the "throw it at the linker and see what errors I
get, if any" approach...it's a bit of a silly situation but, well, the
".LIB" file extension is "overloaded" (much like ".DOC" is similarly
overloaded...it usually means "Microsoft Word" - of _some_ version -
but is also uses as a file extension on simple plain text files too
and not only Microsoft fancied ".DOC" as their application's file
extension that some not-Word-compatible DTP package on the Apple
probably uses it too ...

Anyway, "IMPDEF" your "crtdll.dll" file...have a look inside the
".DEF" file to see what functions are in it (just guessing totally by
the filename, this is - I'll hazard a guess - the "C Run-time
DLL"...which means the functions are likely to be "strlen", "printf",
"fopen" and all the "standard" C library functions...the idea here
being that as many C applications will all be using these same
functions then statically linking "printf" to each and every C program
is a bit of a waste of disk space...so, instead, link the C functions
into a "C run-time library" DLL file that they can all link to at
run-time to save disk space (only one file has these functions and
then multiple files can "share" the DLL...there's also the possibility
for OSes that actually bother to do something like this for the DLL to
also be shared in RAM too, saving RAM space as well...whether Windows
actually does this or not, I've had conflicting messages about...I've
read MS documentation that suggests it does but also had people say
that, in fact, it doesn't do this...not sure what actually does happen
with Windows, I'm still investigating ...this has the advantage of
saving space but the disadvantage that these programs aren't "stand
alone" and, therefore, require the DLL to be available to work (as MS
themselves call it: "DLL hell" could be unleashed by having more DLLs
than common sense on your hard drive ...it's of no advantage at all,
mind you, if only one program ever uses these DLL functions because
all that does is split up a program that would be much easier to deal
with as one file rather than seven hundred files...but try telling
either Microsoft or ICQ about that and it'll land on deaf ears ...

Although, with something like a "C run-time DLL", it's almost certain
to be available on your system...this is especially true with the
"mscrt" DLLs, which is Microsoft Visual C++'s DLL to do this run-time
stuff because Microsoft themselves use it for parts of the OS itself
and you're _BOUND_ to have some "msvcrtXXX.dll" (where XX is the
version number already sitting in your Windows directory...but, in
my case, it actually tends to be useless because I tend to either code
something like "strlen" myself in ASM (well, it's hardly complicated
to write your own version and doing it yourself almost always beats
these "run-time DLL" versions into the ground with all their
"overhead" and "hardly optimal" implementations and needless HLL
"fluff" surrounding them or I'm using the Windows API directly or
something, where such a DLL is a bit useless...so, I never use these
things myself but that's the theory behind them, anyway, in case _you_
decide that it could come in handy for what you're doing...

Oh, if the "crtdll.dll" isn't a "C run-time library", then it could be
a "Cathode Ray Tube" DLL instead, for controlling monitors or
something; Another one of those "issues" in computing...so much
"overloading" of acronyms and everything..."COM" being my favourite
example of such mindless overloading: a type of executable, an
object-orientated binary standard, a communications port, shorthand
for "commercial" in internet addresses (which is universally ignored
because far too many people saw URLs end in ".com" and wrongly thought
that all websites should be ".com" addresses...when it _should_ _only_
be "commercial" sites...mandating, amusingly, that despite already
having the ".com" top-level domain for businesses to ply their trade,
they had to come up with ".biz", which implies basically the same
thing as ".com" but is a way for _real_ businesses to finally describe
what they are without being confused for "John's website" which is, in
fact, in no way "commercial" at all, despite the ".com" domain name
, etc....and I'm sure there are more "COM" overloaded uses than just
this because the last time I mentioned it, other people managed to add
more to my list (but which I've now forgotten again, oops! ...

Anyway, that's how the Borland tools work for you...Hope that's useful
to someone wanting to make their own "import libraries"...it's very
easy to do (two command lines with simple and obvious parameters
and it really does have many handy uses...for example, when Microsoft
reveal "DirectX v17.03a" then you can make the "import library" for
that yourself rather than have to go out and buy the latest MSVC++ in
order to get the files or anything (MS VC++ files for such things are
always a "free download" in the SDKs as well ...and it is, in fact,
this little facility (make your own "import library" from DLL files
and grabbing the "include files" for free off MS's website that
permits me to use actually a very, very old Borland C++ compiler (the
_first_ one capable of outputting PE files, no less...but it _can_
manage PE and that, in fact, is all you actually need once you learn
how to use the tools like "IMPDEF" and "IMPLIB" to keep your "import
libraries" up to date as new things turn up ...and yet make programs
using the latest DirectX API or whatever (when "DirectX" didn't even
exist (!!!) when my very old compiler first appeared ...so, next
time someone says that you "must" keep following the "upgrade cycle"
all the time, don't believe the hype so readily, as - at the
"low-level" - practically _NOTHING_ of any significance has
changed...I know I go on about this but it is, basically, _THE_
biggest scam around that thousands - if not millions - buy into day
after day...it's _KNOWLEDGE_ that's power...only having a 386
reference manual, an assembler, a decade old C++ compiler, a Windows
95 reference and - if you have "the knowledge" (like cab drivers do
- then you can _still_ easily kick the arse out of anyone with
their latest version of Visual Bullcrap or whatever it's called...in
fact, the joke here is that it's _getting easier_ to do this all the
time because all the newer versions just make things "interpreted"
(JAVA, .NET, etc. or add seven extra layers of "visual component
abstraction" (MFC, VCL, etc....which, on occasion, can actually make
things _more complicated_, not easier than if you'd "gone direct" with
the API itself...really...some API and libraries begger belief on
occasion that they make things _worse_ and you don't even get "easier"
out of the deal...they only go and complicate things while helping an
application slow to that now trademarked "Microsoft snails crawling
along with a heavy anvil on its shell over a frictionless surface that
the snail is having great difficulty getting a grip onto" pace...in
fact, competition time: I nominate Outlook Express for "the slowest
loading program" award (ten whole seconds with an unpainted window
just hanging there...and it takes this long when not connected to the
internet so it's got nothing to do with waiting for servers to
reply...it just really is taking that long to load itself up into RAM
from a hard disk ...anyone know of anything worse? Although, it
wouldn't be worth properly setting up such awards because the winner
is a foregone conclusion: Microsoft across the board: "slowest loading
program award", "most needless waste of disk space award", "most
bug-ridden pile of crap jokingly called software award", etc....worst
of all, it would be the _operating system_ itself that's winning most
of these awards too...help!!! ...

Beth

madhur

Implib produced OMF format which cannot be used in MASM. I used
LIB utility provided with MASM to get the library in COFF format.

--
Winners dont do different things, they do things differently.

Madhur
India
email : madhur<underscore>ahuja<at>yahoo<dot>com


run-time

itself

the

directory...but, in

either code

complicated

beats


HLL

directly or

these

case _you_

could be

favourite


shorthand

ignored

thought

_only_

already

trade,

same

describe

is, in

name

than just

to add

...


useful

very

parameters

Microsoft

for

MSVC++ in

things are

fact,

files

that

compiler (the

_can_

learn

"import

programs

even

next

cycle"


day


Windows

drivers do

with

called...in

all the

"interpreted"

component

make

direct" with

on

"easier"

helping an

crawling

surface that

pace...in

slowest

window

to the


into RAM

it

winner

loading

"most

etc....worst

winning most

beth

Yes, I did say that Borland tools only use OMF but that MS's linker
can convert it for you (should do it automatically with the right
options, actually...a message comes up to mention that it's done the
conversion while it's linking ...

Oh, and if you're thinking "but LIB is the librarian, not the
linker!", try typing "LINK /LIB" at a command line to have the hidden
truth revealed...yup, they are the _same program_, in fact...MASM32
just provides a shortcut that invokes the program in different "modes"
for convenience...I tend to think and refer to them all as "the
linker" because LINK.EXE is the actual _real_ program that does it all
and any "LIB.EXE" you have is merely a "shortcut" that automatically
specifies "/LIB" before passing the rest of the command line to the
librarian...it's a "mode" of the linker rather than a different
program in and of itself...hence the comment...

Sorry if I didn't make that clear enough in my last post (I should
have mentioned the LINK / LIB connection to make it clear...and people
wonder why I go into such detail...but when I don't and forget
something, look what immediately turns up as the problem...exactly the
details I accidentally ommitted to mention...which is why I try not to
omit any relevent or useful details at all, if I can help it and
remember them myself at the time of writing that you were expecting
something else but that was actually what I'd expected to happen and
what I was trying to explain in my post about the OMF / COFF stuff...

Microsoft did originally use OMF themselves but switched to COFF with
Win32, at the same time when they changed the executable format to a
COFF-inspired "PE" format (making the object code and final executable
very close indeed that linking was much easier, as some parts can
almost be copied straight from the object code into the final
executable "as is" without much or any modifications at all ...

Well, I did warn that all your "real problems" would actually turn up
because of OMF / COFF and, by that, tool "incompatibilities"...they
are far from irresolvable (LINK itself does conversion automatically
for you, as you've discovered and there are other tools that convert
or happily accept either format but it can be a pain when you use
Borland stuff but also need to use Microsoft stuff too...because, even
if the conversion is usually easy, it always has to be done and that's
an extra annoying step...
Anyway, if you've discovered this "OMF -> COFF conversion" thing then
you must have mastered all the other stuff about using IMPDEF and
IMPLIB and so forth that I mentioned...so, sure, you're welcome for
that...hehehe

Beth

madhur

Thanks for clearing that *LINK /LIB* think. I wonder why link
doesnt shows
LIB as an option while doing *link.exe /?*. How did you come to
know about
*LINK /LIB* then.


--
Winners dont do different things, they do things differently.

Madhur
India
email : madhur<underscore>ahuja<at>yahoo<dot>com

automatically

convert

you use

too...because, even

that's

thing then

and

for

nudge

Please try to trim the original message down (you quoted 300+ lines)
and only keep the parts which are relevant to your answer.

Also, could you try not top-posting?

Thanks :-)

tim roberts

Dumpbin.exe and editbin.exe are also just shortcuts that call link.exe to
do the real work.
lib => link /lib
dumpbin => link /dump
editbin => link /edit


Through forums like this, I suppose...

Actually, when 32-bit Visual C++ first came out, the curious among us were
intrigued to note that lib.exe, editbin.exe, and dumpbin.exe were all just
16k bytes long (as they still are). It only took a bit of digging to
discover that they were just shells that redirected to link.exe.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

beth

Magical psychic powers given to me by the magical amulet of the
ancient gods of Egypt discovered by an explorer in the nineteenth
century while opening a tomb in the Valley of the Kings and passed
down to the generations until I become its guardian from the evil
forces of Annubis, sending his zombies from the underworld to attempt
to retrive it in a series of mystical and exciting adventures driving
around Stonehenge and a "permanently in fog" London in a magical Mini
car that's able to come alive and talk, helping to solve crimes using
high-tech gadgets, perhaps?

Nah, that's more like the plot of a bad Hollywood movie...

Nope, it's in one of the "read me" files or the WinHelp file or
something...can't remember where but the information is in the package
itself, hidden in some documentation file somewhere...despite
accusations to the contrary from Ed, I _do_ like to read through all
the documentation and stuff...RTFM and all that: you discover little
useful tid bits of information like this in doing so, so it's never a
bad idea to at least skim over such things ...

Beth

beth

Yes, very good point; I advise that people should _always_ trim my
posts in reply because I write a heck of a lot that not trimming it
off, even starts to annoy me...and I was the one who originally wrote
of all the crap in the first place! ...

It's generally good practice to trim out anything that's not relevant
to what you're replying to and to slot your answer underneath the
quote you're replying to...this makes it much easier to read and
follow for other people...and, to be honest, I think you'll also tend
to find it makes things easier to _write_ for _yourself_, as well

Beth