I agree that MinGW would be the best way to go. It's more useful for our
needs than the visual studio compiler, and best of all visual studio can
be made to work with it for people who want to use that.
I've had experience, during my short time as a Productive Member of
Society, porting a big unix database server to windows (with visual
studio) while keeping it fully compatible with unix. I used native
windows threads for the windows version and native pthreads for the unix
version, using a set of wrappers I wrote and lots of #ifdefs. It wasn't
fun, although it did work and was easy to use once written. If there's a
windows port of pthreads, that would, I think, be a much nicer solution.
I would prefer to go with GTK 2 over an older version if at all
possible. I know that gtk2 also supports just putting the DLLs in the
program's directory as I'm using a program that does that right now.
Paul Osmialowski wrote:
> On Mon, 10 Apr 2006, Brian Gerkey wrote:
>> On Apr 10, 2006, at 2:43 PM, Reed Hedges wrote:
>>> I build and use libstage in MinGW with MSYS and the Windows ports of
>>> pthreads and GTK and it all works great.
>> What do you have to distribute? Are there any installation
>> requirements for the user, beyond your package? If I were to build
>> the client libs with MinGW, would Visual Studio users be able build
>> and link against them?
> The good thing about MinGW is that final .exe binary doesn't require any
> MinGW-related dll's (comparing to Cygwin with its nasty cygwin1.dll and
> its nasty licensing issues). I've ported player-1.6.5 client libs to
> MinGW few months ago (see http://king.net.pl/playercontrib/win32) with
> playerv and videoplayer. All I had to do in libplayerc was to replace
> BSD sockets with winsockets. Porting playerv was little tricky. To use
> app copmiled with glib/gtk+, you would have to install gtk-2.8 (or
> gtk-2.6 for pre-2000 windows versions) which is quite easy with provided
> installer (see http://gimp-win.sourceforge.net/stable.html) (another
> good thing comparing to Cygwin: no X-server is needed, the one provided
> with Cygwin is much too slow!).
> Unfortunately, things that need to be installed aren't welcome in some
> environments with paranoid security policy (schools), so I didn't choose
> that path. Instead I've taken old glib/gtk+-1.3 which was experimental
> version somewhere between glib/gtk+-1.2 and glib/gtk+-2.0. Some programs
> written for gtk+-2.0 works fine with it, and playerv became one of them
> (just had to do some changes in rtk2 and playerv Makefiles). The good
> thing about this glib/gtk+ version is that it doesn't need to be
> installed, all required dll's can be put just into directory with
> Native Player server would be more problematic. I'm not a Windows
> developer, I've never tried to write server apps with winsockets. Also
> I've never touched pthreads-win32. Instead, I did Player compilation on
> Cygwin (with all OpenCV drivers, but I don't know if OpenCV can be used
> that way on MingW, I guess not since Linux version is used on Cygwin,
> see http://king.net.pl/playercontrib/cygwin/player_on_cygwin.txt there
> is actually native OpenCV for Windows but I've heard it's much different).
> I've seen proposal of writing Player in Java to make it fully portable.
> I see two problems with it:
> 1. It may work too slow. I guess for sure, camera interface,
> blobfinders, opencv related stuff will be too slow.
> 2. Java isn't used everywhere. I don't know how it is now, but when I
> was developing QNX applications I've realised that there's no Java for
> this real-time UNIX system. I guess Java and real-time aren't good friends.
> Also I was considering running player on handheld PC with arm CPU and
> Linux installed. I can't imagine running JVM on it.
> In my opinion, Perl is more portable than Java, you can find it on
> Windows, OS/2 and all Unixes, it provides threads, sockets, GUI
> libraries (perl-tk works everywhere, also on ActivePerl for Windows),
> and I guess, perl interpreter can be somewhat faster than JVM.
> If there is a plan to rework player totally I would rather stay with
> C/C++ and choose SDL library for everything (native GUI, sound, network,
> threads, synchronization, even things like joystick). Few months ago I
> was compiling on MinGW my simple SDL program firstly developed on Linux
> and it was working fine.
> Having MinGW we don't need to touch MSVC. Compiling on MinGW we don't
> insist users of our binaries to install MinGW on their computers.
Robotics research group, University of Auckland