delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/02/18/12:07:01

From: sos AT buggy DOT prospect DOT com DOT ru (Sergey Okhapkin)
Subject: RE: Optimizing memset/memcpy/strcpy/etc.
18 Feb 1998 12:07:01 -0800 :
Message-ID: <01BD3CBA.BCC9D750.cygnus.cygwin32.developers@sos>
To: "'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:
> Here is my current understanding, which does not contradict the
> paragraph you quote.  Ordinals are indexes into the import table.
> Hints are indexes into the export name table.  When the loader comes
> to a symbol, it looks at the hint, and uses it to index into the
> export name table.  If the name at that position in the table is the
> symbol which it is looking for, it gets the ordinal from the
> corresponding ordinal table.  If the name at the hinted position is
> not the symbol which the loader is looking for, it does a binary
> search through the export name table.

I spent a lot of time digging thru hundreds of articles on MS web site 
about dll internals. My understanding is the following: ordinals are 
indexes into the _export_ table. Every import contains the ordinal number, 
hint and name. Loader compares the hints of the ordinal in the export and 
import tables and performs linking if the hints are equal. If not, loader 
does name-based binary search.

> Ah, I see.  This is a bug, but there is an easy workaround.  Write
>     int (*fn1) (int) __attribute__ ((stdcall));
> for the equivalent of
>     int (PASCAL *fn1) (int);
>

Hmm... If this will work, I'm ready to begin with implemention of dynamic 
loading of wsock32.dll. Definitely, the changes are not for b19.

--
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia
Looking for a job

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019