Re: How to get a .lib from .dll

From: Madhur (a_madhur_at_vsnl.net)
Date: 12/30/03 

Date: Tue, 30 Dec 2003 19:28:01 +0000 (UTC)

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
Beth <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message
news:lY2Ib.197$Rx5.146@newsfep3-gui.server.ntli.net...
> Madhur wrote:
> > Hello
>
> Hi :)
>
> > 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.
>
> 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,
> 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...
>
> > Will the same library work for both c/c++ and assembly.
>
> 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 problems...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 :)
>
>

Relevant Pages

  • Re: How to get a .lib from .dll
    ... LIB utility provided with MASM to get the library in COFF format. ... >> There is a file in windows directory called crtdll.dll. ... >> How can I get the list of functions contained in the DLL. ... > IMPDEF and then delete it afterwards;)...what "IMPDEF" does is ...
    (alt.lang.asm)
  • Re: How to get a .lib from .dll
    ... >> There is a file in windows directory called crtdll.dll. ... >> How can I get the list of functions contained in the DLL. ... > Using the Borland tools, you should first run "IMPDEF" on the ... > IMPDEF and then delete it afterwards;)...what "IMPDEF" does is ...
    (alt.lang.asm)
  • Re: win32api.GetFileVersionInfo - error
    ... xytho33 wrote: ... > I need to be able to programatically get the version info from a windows ... > DLL preferably in the same format as what is displayed in the properties ...
    (comp.lang.python)
  • winapi32.GetFileVersionInfo() - problem
    ... I need to be able to programatically get the version info from a windows ... DLL preferably in the same format as what is displayed in the properties ... little demo program "filevers.py" distributed in the win32api download ... DLL compiled with MS Visual Studio .NET 2003. ...
    (comp.lang.python)
  • win32api.GetFileVersionInfo - error
    ... I need to be able to programatically get the version info from a windows ... DLL preferably in the same format as what is displayed in the properties ... demo program "filevers.py" distributed in the win32api download that does ... DLL compiled with MS Visual Studio .NET 2003. ...
    (comp.lang.python)