From:	sos AT prospect DOT com DOT ru (Sergey Okhapkin)
Subject:	RE: New import library format proposal.
16 Apr 1998 00:27:53 -0700 :
Message-ID:	<01BD6928.F5A7DFF0.cygnus.cygwin32.developers@drs>
To:	"sos AT buggy DOT prospect DOT com DOT ru" <sos AT buggy DOT prospect DOT com DOT ru>,
	"'Ian Lance Taylor'" <ian AT cygnus DOT com>
Cc:	"cygwin32-developers AT cygnus DOT com" <cygwin32-developers AT cygnus DOT com>

Ian Lance Taylor wrote:
> Besides the function name, you can include a pointer to a structure
> holding the DLL name and the static variable holding the library
> HANDLE.  Then we don't have to have separate do_call$dllname
> functions, and can instead have a single one in libcygwin.a.

Don't do it... This will make new-style import libraries cygwin-specific. 
Separate do_call functions in each library will allow to use the libraries 
with non-cygwin code (mingw32, for example, or with other compilers). I 
talk about system dlls mainly.

>
> However, before checking this in, I'd be interested in hearing what
> kind of performance improvement you get.
>

I didn't try it :-) It's just my crazy dreams... But we have now a good 
example - 20% increase of speed due to on demand loading of wsock32.dll in 
cygwin. The next thing I want to think about, is an access to dll-exported 
datas.

> It seems to me that we could change the linker to set up the import
> address table with the DLL timestamp.  That should reduce symbol
> resolution time to zero, and might well be faster still.
>
This will work for cygwin-compiled dlls, but what to do with a system dlls? 
The slowness of process startup is mainly in linking cygwin.dll with a 
system dlls. System dlls on NT and W9X have different timestamps, updated 
dlls in service packs have a different timestamps too... It's a MS way :-)

--
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia.

- Raw text -