Exported data needs to be treated specially by the application; the
compiler must construct the program to access the data indirectly.
This is different from functions, which can be indirected through the
import library. The linker cannot adjust the program to fix such
data references if the compiler doesn't.
That being said, any tool which automatically exports data in a dll
without adjusting the program that uses the dll (normally by editing
the headers to explicitly mark such data items as being imported)
creates a situation where the user could create a program which links
successfully but mysteriously dies or produces inappropriate results.
By making the dll writer deal with marking exported data, we increase
the chances that they'll fix the headers also, which would result in
more working programs and less subtle failures (i.e. less FAQs and
better overall confidence in the tools).
Even if the tool automatically exports *only* the _imp_ variant, to
avoid the subtle link problems, the dll developer *still* needs to
deal with each and every exported data item in the headers. This is
the hardest part of dealing with data imports, and any tool that falls
short of solving this problem is not a complete tool. I'm not against
the idea of a partial tool, but I foresee many "why don't you finish
this" type questions, and added partial functionality which creates
user confusion is bad.
However, any patches that *prevent* data items from inadvertently
being exported as functions would be welcome.
> On Mon, Sep 04, 2000 at 09:34:12PM +0300, Paul Sokolovsky wrote:
> >Mandatory data imports marking: I *hate* this feature and develop
> >libtool re-implementation which frees programmer from it. But when I
> >mentioned it on cygwin maillist, DJ Delorie was rather sceptical about
> >it, saying they will support MS way.
>
> Do you have a URL for this skepticism? I hate marking data imports
> also. It would be interesting to see what DJ's reasons are. I've
> never known him to be resistant to good ideas.
