From:	ian AT cygnus DOT com (Ian Lance Taylor)
Subject:	Re: Optimizing memset/memcpy/strcpy/etc.
18 Feb 1998 09:25:16 -0800 :
Message-ID:	<199802181439.JAA12522.cygnus.cygwin32.developers@subrogation.cygnus.com>
References:	<01BD3C5F DOT BDB1AEA0 AT gater DOT krystalbank DOT msk DOT ru>
To:	sos AT prospect DOT com DOT ru
Cc:	cygwin32-developers AT cygnus DOT com

   From: Sergey Okhapkin <sos AT prospect DOT com DOT ru>
   Date: Wed, 18 Feb 1998 11:24:12 +0300

   > I have realized that I was confusing hint numbers and ordinals.  The
   > hint numbers are not ordinals.  They are indexes into the export name
   > table.
   > 

   Ordinals are indexes in import table! Hints are checked to validate ordinals. Here is an extract from win32 sdk:

   Note that an optimization is available whereby each import library
   exports a 32-bit number that corresponds with each function in
   addition to any name or ordinal number. This serves as a "hint" to
   speed the fixups performed at load time. If the hints in the
   application and in the loaded DLL do not match, the loader performs a
   binary search based on the function name.

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.

   >    It's the same I wrote about some time ago! Unfortunately, the bug in g++ 
   >    parcer prevents from doing this changes :-(
   > 
   > I don't know what bug you are referring to.  I don't understand why a
   > bug in g++ would affect something like this.

   To declare a pointers to imported functions you should write something like

   #include <windows.h>

   int (PASCAL *socket) (parameter list);


   try to compile this with g++ :-) gcc compiles it fine (so you was able to compile lines like this in tcl. G++ parser fails on lines like

   type (__attribute__((attribute_name)) ....)

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);

Geoff, have you reported this bug to the g++ developers?

Ian

- Raw text -