Its finding the winsock.h files fine, or it would have complained in the output.
A header file (winsock32.h) is like a table of contents, it just tells you what's out there.
A library (wsock32.lib) on the otherhand, is the book. All the compiled code to run the functions in the header are in there.
You need both inorder to utilize the functions. The header is included in the source file and the library is passed as an argument to the linker. VC has their gui to change these settings. For gnu it would be something like.
compile stage:
g++ -c -o devicelink.o -DDEBUG_OUTPUT devicelink.cpp
VC will do something very similar, all the arguments are passed from the gui setup.
link stage:
g++ -o dlc devicelink.o [all other object files] -lwsock32
In your VC project, you are missing the (-lwsock32), so it doesn't have the code needed to run the functions.
MSVC has what's called the Microsoft Foundation Classes (MFSC). They are well supported and there's loads of information about using them in books and websites. There are also wizards in MSVC that will create a skeleton application and help you put message handlers and build the gui visually. Its a bit bloated, but its easy to work with once you get the hang of it.
If you want to stick with the gnu compilers, you'll run into some rough road if you try to make a gui. All I've ever seen them support out of the box, is the c-style windows sdk. It works fine and has a lot of support/tutorials, but it undermines a lot of the advantages of the object oriented paradigm. Also a lot of the gnu graphic libraries will change the "look" of the window. Buttons and checkboxes will look xwindowfied. This will seem out of place on a windows desktop. If you are the annal retentive sort, this will drive you up the wall.
Another downside to gnu, is that you will need all the libraries to run it. These don't come with windows so sharing programs with people on windows becomes difficult. Most of the time people on linux already have these installed and its no big deal. However, if you only intend to use it yourself then its not really an issue.
The only two gui libraries for gnu that I know of are, gdk/gtk and qt. QT is the most like the microsoft MSFC classes. I've written a couple programs with it. You can find a free gpl licensed version here. If you're familiar with KDE desktop for linux, it was written mostly using this library. I believe that qt has a visual development environment and some wizards like Microsoft too.
http://www.trolltech.com/products/qt/downloads
Usually when I need a gui, I make something quick and dirty using tcl/tk (a script based language). Its simple and not as snazzy as a compiled interface, but its easy to make and gets the job done.
http://www.tcl.tk/software/tcltk/8.0.html#Download%20Binary
Most of the time I avoid GUI's all together. I've found that they are about 4x the work for the same functionality. In college, I had to write a lot of applications to size aircraft, compute lift coefficients and some rudimentary CFD. The were all commandline driven and output datafiles which I could import in to MatLab and make pretty graphs. A gui would have been nice to set up boundary conditions and intial values. I didn't because time at that moment was a very precious commodity.
However, when you're flying a WWII flightsim, entering a command like "engine on" is a real immersion killer.
This may be jumping the gun a bit, but I just thought you'd like to know the trade-offs between the two.
[/quote]
my bad
