From: cgf AT cygnus DOT com (Christopher G. Faylor)
Subject: Re: New import library format proposal.
16 Apr 1998 11:12:45 -0400
Distribution: cygnus
Message-ID: <6h575d$3g0$1@tweedledumb.cygnus.com>
References: <01BD6928 DOT F5A7DFF0 DOT cygnus DOT cygwin32 DOT developers AT drs>

In article <01BD6928 DOT F5A7DFF0 DOT cygnus DOT cygwin32 DOT developers AT drs>,
Sergey Okhapkin <sos AT prospect DOT com DOT ru> wrote:
>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.

Ok, then just have one handler function per import library.

>> 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.

I've been dreaming about this for a while, too.  Is there any reason,
other than speed, that dlltool couldn't emit C code to generate its
import library?  That would make this slightly easier to play with.
-- 
cgf AT cygnus DOT com             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada