gnupic: Thread: Probably the right place for this Windows question.

I found the answer to my question before I finished the message. However I
figure that someone else may be interested in the process.

For those of you who know (or may not know) me, I'm a long time (10 years!)
Linux user. I'm on this list because most gnupic projects are Linux related,
if not Linuxcentric.

For several years now I've been developing and maintaing the Trivial Low
Voltage Programmer. In fact I'm quite proud to say that my 16F628 vs. 16F84
page is now #1 on Google (search for '16F84')!

In my continual effort to eschew all things Microsoft, I've relied on other
developers, such as David Tait and Nigel Goodwin, to develop Windows software 
for my programmer designs. But I'm fast approaching the realization that
Microchip's explosion of chip offerings along with the expansion of programming
algorithms, requires an Open Source programming application to keep pace.

So this week I decided to tackle the project. I've made amazing swift progress.
The first decision was simple: NO NEW SOFTWARE! It doesn't make sense to 
develop and maintain two completely different applications. So I started 
looking fore environments that would allow minimal changes to my picprg2.3
app, in order to run on a Windows box. 

The answer quickly popped up: MinGW (http://www.mingw.org) which I believe is
used for the gputils software port. The best thing is that it has a cross
compiler that I downloaded and started testing with on my Slackware laptop. I
also located pdfcurses compiled into a MinGW library. So with just a couple
of compilation conditionals, temporary removal of the parallel port access,
and commenting out one curses function (attron), I had a working console
application running under Windows 2000. It's really quite amazing.

Of course I stubbed the parallel port access routines, so my next task is
restoring that access. Of course none of the NT systems (NT,2000,XP) allow
for direct port access. So a kernel driver was in order. I checked out the
GIVEIO.SYS that David Tait used for FPP. But it seemed quite cumbersome.

After some searching I came across IO.DLL here: 

http://www.geekhideout.com/iodll.shtml. 

While not Open Source, it is freely distributable. Also is has a consistent
interface to both 95/98/ME and NT/2000/XP machines by incoporating the NT
kernel driver within the library.

So I get to the end with my dumb question: How in the heck does one interface
with a DLL in a MinGW application? Everything I read refers to building and
linking in a .lib, but IO.DLL doesn't seem to have any such interface.

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'll let you know how it turns out once I'm finished.

BAJ

On Wed, 30 Apr 2003 16:23:35 -0400 (EDT)
####@####.#### (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.

So, I'm not much help, but the faq at the mingw site will definite get you moving in the right direction if you run into any hitches.

Aaron

Aaron said:
> On Wed, 30 Apr 2003 16:23:35 -0400 (EDT)
> ####@####.#### (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 ####@####.####
http://www.ghz.cc/charles/

On Wed, Apr 30, 2003 at 06:25:04PM -0400, Charles Lepple wrote:
> 
> Aaron said:
> > On Wed, 30 Apr 2003 16:23:35 -0400 (EDT)
> > ####@####.#### (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.

I read it a couple of times. I do see that pexports and dlltool will build
an import library from a raw dll. It's making a bit more sense now.

> 
> 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.

Plus to be honest it makes sense to me. It's more akin to dlopen and dlsym
in the Unix shared library world.

> 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.

No need. My game plan is to bundle the DLL with the program. The other nice 
thing about LoadLibrary is that you can specifically pick the one in the 
current directory.

> 
> 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.

I agree. BTW I'm not going to implement it either! ;-)

BAJ