gnupic@linuxhacker.org

gnupic@linuxhacker.org


Subject: Re: Probably the right place for this Windows question.
From: Charles Lepple
Date: Wed, 30 Apr 2003 18:25:04 -0400 (EDT)


Aaron said:
> On Wed, 30 Apr 2003 16:23:35 -0400 (EDT)
> byron@cc.gatech.edu (Byron A Jeff) wrote:
>
>> As I pointed out eariler, I found the answer. It's in the io.cpp and
>> io.h files included with the package. It shows LoadLibrary,
>> FreeLibrary, and  GetProcAddress. That's what I needed to know. It
>> looks like I can simply  incorporate those files directly into
>> picprg2.3 and use the calls to control the port.
>
> I think that you need to generate a .def file also, or something
> similar. It's been a while since I played with dll's, but the mingw faq
> mentions how to use DLLs, and how to pull the neccesary info out of the
> DLL in order to use it. I skimmed over it a couple days ago, but wasn't
> paying much attention unfortunately.

While it's a little different than just linking a .lib/.a file, using
LoadLibrary etc. could allow picprg to be more robust to user
configuration problems. You can print a better error message (including
pointers to documentation/FAQs), for instance.

You could even get crazy and make an abstraction layer that would allow a
user to use one of the several general-purpose port I/O DLLs out there.
picprg could iterate over a list of recognized DLLs and their respective
inb/outb function names, and pick the first one that works.

Of course, I'm not volunteering to write the patch for that functionality
:-) but doing your own dynamic linking (on a small scale) can have some
advantages.

-- 
Charles Lepple <clepple@ghz.cc>
http://www.ghz.cc/charles/



gnupic@linuxhacker.org