Import Libraries

[hutch--]

Something that is being missed here, the size of the import library simply does not matter, it is only the size of the code entry that matters. You may save a small amount of disk space but it ain't like it matters with terabyte sized drives. The size of the binary is not effected by the library size.

[dedndave]

it may matter for someone on a laptop   :P

[hutch--]

Then why not spell out how trivial it is to save disk space instead of the inference that it somehow effects the binary.

[dedndave]

we never said the larger format doesn't work
somewhat obvious that it does - lol

however, if given a choice between a file that is 10 kb and one that is 100 kb...
if they both provide the same functionality, i'll take the one that is 10 kb

the reason we need terabyte drives is some people like to bloat whenever they can   

[dedndave]

let me provide a realistic example where it is nice to have a smaller import library....

one of the masm32 import libraries is missing a function that i want to use
in this example, i will use ntdll.lib, because i know there is a desired function missing - NtOpenKeyEx

now, i can use GetProcAddress
which is ok, but it is an unneeded call and a lot of text to set up a prototype

or - i can create an import library and add it to the project - yielding a cleaner, more consistent result
now - do i want a big file or a small one ?

when i want to share the project with others, a smaller file is better...
less server storage space and bandwidth
less user bandwidth everytime someone downloads it
i don't know that the guy at the other end isn't using a laptop, where file space is treasured

this is just an example, of course
there may be cases where many functions and/or libraries come into play

[dedndave]

i am inclined to ask the opposite question

why not replace Inc2L with Def2Lib ?
Erol probably would not object
inc2l is 16 kb
Def2Lib is 5.5 kb

but, here's the real pay-off
the propensity for build errors should be reduced
building the libraries during masm32 installation is somewhat processor intensive
by reducing the file sizes, you reduce the build time and, thus, the likelihood of resulting errors

Def2Lib is flawless and fast   :t

[qWord]

the propensity for build errors should be reduced
building the libraries during masm32 installation is somewhat processor intensive
by reducing the file sizes, you reduce the build time and, thus, the likelihood of resulting errors

that implies Software should take care of unstable systems? - does not sound logical.

[japheth]

Def2Lib is flawless and fast   :t

Since I'm generally rather sceptical when I hear such claims I downloaded the current version ( v1.1 ) and did a brief test.

Result: found 2 errors:

1. field timestamp in the import entries is fix 1.
2. the module name always ends with ".dll", even if the module name in the LIBRARY statement ends with ".exe".

error 1 looks minor, but these days you never know - some AV programs might find it suspicious if they don't find a valid timestamp.

[dedndave]

well, the os is what it is   :P
we aren't going to fix it - we want to use it
but, that doesn't mean we have to stroke it's fur backwards, either

i understand why Hutch uses Inc2L
for one thing, it translates from INC to LIB without the intermediate step of a DEF file
this probably reduces the time spent building the libraries, as well
for another thing, it's his own tool, so he has control over it

due to the newly supported unicode prototypes, it needs a little update, anyways
(refer to the threads on Process32First, et al)
i am sure Hutch is aware of it, and probably has a plan to update things, as time permits

Erol also has a tool called Inc2Lib
for whatever reason, it does not appear on his download page - probably an oversight
http://vortex.masmcode.com/files/inc2lib14.zip
it appears to suffer from the same little issue with regard to parsing the newer unicode prototypes
and, it uses PoLink to create the import libraries
not quite as nice as his newer Def2Lib, which creates them directly, but still creates the smaller libraries

i seem to recall Erol saying something about an upgrade of the Def2Lib tool into a newer Inc2Lib
so, we can look forward to that

my point was, that there are advantages to smaller files that go beyond disk space

[dedndave]

Japheth,
i believe Hutch fixes problem 1 with a little program called "Touch.exe"

his Inc2L program also allows for exe's, drv's, etc

Code Select Expand

inc2l ntoskrnl.inc exe
i don't see that Erol's tool has a switch for that one

[japheth]

i don't see that Erol's tool has a switch for that one

I'm still surprised a little because the ".dll-instead-of-.exe" problem was already reported by nidud a few months ago ( with ntvdm.lib / ntvdm.exe ) - and the bug still isn't fixed in def2lib? Vortex, there's a job to be done! What are you waiting for?

[dedndave]

he probably plans to fix that issue with the newer Inc2Lib
address all the problems at once   

but, i wasn't going to poke the crocodiles with a pointy stick
i will let these guys fix things at their own pace
otherwise, they have no reason for not expecting me to do it - lol

the main point i was trying to make was with regard to the unmentioned advantages of smaller files

[Vortex]

Hi Dave,

def2lib does not depend on other tools and it's able to build import libraries from a .def file. inc2lib depends on an external tool, a linker to output the libs. This is why I stopped worked on inc2lib. Maybe, I can reconsider creating a new version of inc2lib

Both of the short and long format for import libraries are usable. def2lib adopts the short format.

Hi Japheth,

nidud already tested the correct version of ntvdm.lib :

http://masm32.com/board/index.php?topic=1086.msg10209#msg10209

A quick fix solved the dll / exe issue. I will have to release a new version of def2lib.

[dedndave]

many thanks for all your great tools, Erol   :t