Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!kodak!uupsi!sunic!fuug!tuura!risto
From: risto@tuura.UUCP (Risto Lankinen)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Passing data to a DLL; strange problem!
Message-ID: <1154@tuura.UUCP>
Date: 25 Apr 91 12:37:05 GMT
References: <1991Apr22.173022.8930@javelin.sim.es.com>
Organization: Nokia Data Systems Oy
Lines: 105

lwallace@javelin.sim.es.com (Raptor) writes:

> ... so I want to pass it [a function in a DLL] my application's
>top-level window handle to feed FindWindow().

>First, if you've got a better technique to do this, I'm interested in
>hearing it.

Hi!

You can import the data *itself* without *calling* the DLL at all:

*** in DLL.C ***
// as static data, ie. before any functions:
HWND ParentHandle;

*** in DLL.DEF ***
DATA     PRELOAD NONDISCARDABLE ...

EXPORTS  ...
         PARENTHANDLE NODATA
         ...

*** in EXE.H ***
extern HWND FAR ParentHandle;

*** in EXE.C ***
...
ParentHandle = hWnd;
...
hWhatWasIt = ParentHandle;
...

*** in EXE.DEF ***
IMPORTS  DLL.PARENTHANDLE

******

A few words of explanation:

At the time Windows loads your DLL (or your application, in case there's
already an instance of your DLL loaded) it patches all references to the
imported objects in your application, to point to their true locations in
memory.  This patching has two stages:

 - All offsets are copied from the DLL's table of exported objects (which
   you can study from a DLL with the EXEHDR.EXE).
 - All segment addresses are copied from Windows' internal tables, which
   keep track of which selector has been allocated for any given segment
   of a module.

(In case Windows later moves or discards a segment, objects in which have
'active' exports, then only the latter stage will be rerun).

In real mode this is a bit different, because the export is first made
a procedure call thunk for.  Fortunately, this can be prevented by using
the NODATA with the exported data object (we sort of pretend, that it is
a function, which will not need the Dseg in AX, and therefore no thunk)
after which the SEG:PTR used to patch external references truly point to
the object itself.  The thunk is also used to reload any discarded code,
which is why the segment that contains the object must be NONDISCARDABLE .

When we refer to the data object, the only thing we need to provide for
the Windows' loader is a place, where it can patch its segment selector.
This is done with 'extern <typeofdata> FAR <nameofdata>;', upon which
the compiler places a word in the CONST segment, and a message to linker
to place its address into IMPORT table (also seen with EXEHDR.EXE using
switch '/v').  Subsequent references to the object each have preceding
'mov es,WORD PTR CONST:<segofdata>' and use it via ES:BX (normally).

For an additional point, if the data is referenced in both sides of, say,
SendMessage() or GlobalAlloc(), it surely is safest to set it 'volatile'
because the optimizer of the compiler may make assumptions either of the
actual value (which might have been changed by another process handling
the SendMessage() et al.) or its address (which might have been changed
because Windows moved the segment during GlobalAlloc() et al.).

This is, btw. closely related to how the __AHINCR, __AHSHIFT and other
non-function data have been exported from Kernel.  Haven't seen it, but
I guess that somewhere in KERNEL.ASM there,s ...

   PUBLIC __AHINCR,__AHSHIFT

   __AHINCR = <absvalue>
   __AHSHIFT = <absvalue>

They're probably exported in KERNEL.DEF, and referred to from an other
(assembly language) program as EXTRN, which is sufficiently to make the
Windows' loader put the actual values 08h and 03h wherever programmer
of a C program accesses an array declared 'huge' (in this case).  But
because they're not actual data, but absolute values instead, it seems
that the LINK 5.10 reserves the segment #254 for them.

Terveisin: Risto Lankinen

Disclaimer:  The author of this article assures, that best possible
care has been taken to prevent errors and provide accurate facts.
However, the reader alone, of this article is responsible for any
possible problems, losses or damages arising from actually making
use of the information contained therein.
-- 
Risto Lankinen / product specialist ***************************************
Nokia Data Systems, Technology Dept *  2                              2   *
THIS SPACE INTENTIONALLY LEFT BLANK * 2 -1 is PRIME!  Now working on 2 +1 *
replies: risto@yj.data.nokia.fi     ***************************************