Re: [Hamlib-developer] hamlib

[Stephane F. <f8...@fr...>]

Hi Colin,

First of all, thanks for your interest in Hamlib. The idea behind this
library is to serve as an abstraction layer, kind of "driver", and not
having to reinvent the wheel each time someone write some Amateur
software.

So far, Hamlib is rather POSIX oriented, mainly from the developpers
culture (hence the unfamiliar downloaded file format you downloaded :). 
However, we are very willing to see Hamlib in use on Win32 systems, 
as well as Mac OS. All in all, the protocol handling code is quite
portable, the build environment isn't.

Actually, I've started some porting work with cygwin (POSIX environment
under windows), and Mac OS X. The sourceforge compile farm helps a lot
on the Mac OS X front, and provided libltdl has the right patch, this
should be okay for this platform. 
Talking about Windows, the port is not complete. The problem is I don't need
myself Hamlib under Windows, and also I don't use VC/VB, just cygwin. 
That's why there's no DLL in the download section. But I'm still ready
to work on this port, as long as there's some beta testers for this
platform. And it looks like you're the one (with the good number of
users world-wide). So let's do it.

I have a question. What are OCX used for? To my (limited) understanding,
this is VB only stuff. Am I wrong? Would a DLL be enough for what you
need?
As you can see, I don't know anything of VB. I guess the DLL file is not
enough. Do you need anything else like header files? or some API entry
list as XBasic do?

So far, using cygwin, I've been able to generate a DLL. Having applications
be able to use it is another story. DLL is such a mess. Why everything
has to be so much complicated under this platform?
My test program can access the frontend, not the backend.
Anyway, Hamlib is a bit tricky too. This is a shared library, the frontend, 
that should be able to load "plugins" (again shared libraries, the backends).
Imagine the nightmare it can be when you want to support multiple
platforms. Trust me, C code portability is nothing compared to compile 
and linking issues. Anyway, thanks to autoconf/automake/libtool, we
should be able to get away with it.
To make it simpler on win32, we may choose to obtain a single DLL,
embedding all the backends (> 1MB). This DLL would be generated by
cygwin tools. However, I'm wondering if VC++/VB will be able to grok it.
If it's not working okay (and you will tell me), I think we'll have to 
not use the autotools for generating the DLL, and use VC to compile it
instead. This will have to be sorted out.

And don't worry, even though you have no rig to test Winlog32 with,
there's a dummy backend that just logs traces of calls, which is very useful
for debugging.


As a conclusion, I would say Hamlib is not yet usable on Win32, 
but if you're willing to, we can do the last mile together to get it working.

Are you interested in?


Regards
Stephane - F8CFE