ok, what is Win32 programming used for in games and how much is it used?
i know that to get a game up and running, you can use Win32 to create a window and display your game in it, but what else is it used for? do tools use Win32, or is something else used?
basically, give me the run down on game dev and Win32...
Well you can either use the "raw" Win32 API functions, or use some sort of library such as GLUT (shudder) or other game type library.
If you're going to use Win32 you might as well then use all of the functions containted within the API instead of the standard C functions since it'll all be the same thing and you can do extra things if you just use the Win32 API.
To create a window you'll need to use the RegisterClassEx and CreateWindowEx functions (tho you might not want to use the extended versions right away, they are the ones with the Ex at the end), you'll need to fill out the WNDCLASS structure etc. You will also be requried to create a function that processes window messages.
Some other funky things that could be done with Win32 functions are: using memory mapped files, for which the OS can handle most of the work for you, using sleep so that your program uses only as much CPU as it needs to, and handling the minimisation and maximisation of your window properly - so like the user can alt-tab in and out of your game with no worries.
Yep, basically just go have a scan of the Platform SDK on msdn.microsoft.com - or if you have Visual C++ have a look in the help.
Memory mapping files is funky stuff, but it's not like other OS's can't do it. If you want to see how to create a window using Win32, check out the NeHe OpenGL tutorials at http://nehe.gamedev.net - they take you through everything you need to know and then some.
Also, a little self plug here, but I have an example of the funky stuff you can do with Windows on my site at http://shplorb.ods.org/develop/icqnobanner/ - it's a little program that starts icq and injects some code into it that hijacks the window and prevents it from displaying the ad banner at the top of the contact list. The Win32 API has loads of stuff to let you do almost anything imaginable with Windows. If you're really interested in learning all that you can do then I'd suggest buying one of Microsoft's books on it.
Just to through in my 2 cents. On the last couple projects we always kept a distinction between where we used Win32 and where we didn't. The theory is, when porting the game to another system (like macs... shudder....) to make the life of the porting company easier we had a strict line between device dependent and not. We created virtual classes that we would then inherit Win32 specific classes off of that. That way our code will only deal with the virtual base class and when the game is ported, the only changes that need to be made is to derive a new class from the base class. Of course we also split the project into os dependent directories. Everything that is os independent go into a common location and every device dependent item goes in its own directory. When dealing with two, three, even ten thousand files for a game, this is the only way to do it :)
In terms of is it worth learning win32? Like was said before, things like registry, file io and of course DirectX (if you want to get into graphics) are all you need to know. Occasionally a game will use Window's Widgets for their UI and in that case a decent knowledge of Ownerdraw is usefull. (Yuri's used all owner draw widgets where as Generals we used our own UI system... and man was that a pain in the butt!)
Anyway, just have fun, focus on what's fun, and the rest will follow :)
Yeah, using your own isn't too difficult it's just a pain in the butt when 2 weeks before you ship, they tell you they want all the functionality of a windows widget, right after they told you that they're scrapping the look of the UI and it will all be programmer generated/animated and you have no systems for this in place. Ahhh I loved the feature creep that happens post beta...
Win32 is the Windows API, it provides access to all OS functions such as window creation, file i/o, process management, etc. Many of the ANSI C functions in MSVC are wrappers to the Win32 equivalents. eg. fopen() wraps CreateFile(). Likewise, on a Unix system you would use the POSIX API, or Carbon or Cocoa on OS X.
In reality, you shouldn't need to use it much, just little bits to handle all the interfacing with the OS. This is why it's good to use cross-platform libraries and design your application so that it is abstracted from the OS-dependent things. If you do that then you won't need to completely re-write the program if you need to run it on a different platform - you just re-write the little bits of platform-interface code and recompile.
Hope that helps.