I''m programming in Win32 MSVC++6.0 and used always WinMain as an entry point. But I can''t resist the idea of making multiplatform apps so I should use main() instead of WinMain(). What is the difference. If I use for example CreateWindow(...), I need the hInstance that is given in WinMain(...). Can I create a window using CreateWindow(...) in main(...) and get the hInstance using GetModuleHandle(NULL)? How does multiplatform apps (for example glut library) create window? Also if I make a glut program and add there DirectSound implementation. I think I need the HWND handle to create DirectSound, but how can I get it out from glut window?

So if I make a Console app, I can''t use any Win32 functions? I can''t use DirectX? How can I create a window in console app?

Ok, I made a simple app that creates a window, using CreateWindow in console app. So it works. Thank me

If you want to make multiplatform apps, what are you doing then with win32 API functions? These only work on, surprise surprise, win32. Not much crossplatform, is it?

If you really want crossplatform apps, develop your progs with crossplatform libraries, like glut. To do the sounds, you''ll have to find another lib, glut and opengl only do gfx.

I use glut myself, not that much because I want multiplatform development, but because I don''t want to learn win32 api. In the dev phase, I use main(), because it allows me to easily print debug messages to the console. When I think it is ready to be tested by other people, I will change main() to WinMain(), just to get rid of the console.

Well, my point was for example to support DirectX in Win32. I know there is OpenAL for sounds. What good they are? I heard tey are scrap? If you know a list of multiplatform libraries, give me the url. Thanks.

You don''t need multiplatform libraries to create cross-platform applications. As long as you have enough abstraction, you should just be able to replace your Win32Sound class with your LinuxSound or MacSound class and compile under those other platforms. Of course, that means you''ll have to learn a different API for each platform, but the chances of a single-person project getting past the tech. demo stage and still being multiplatform are pretty slim anyway (simply because it''s very difficult to keep your code cross-platform, plus I personally don''t think it''s worth the trouble).

Note that I said "pretty slim" and "very difficult", not "zero" and "impossible". It is of course possible for a single person to write a complete multiplatform game, but I''ve never heard of anyone actually doing it to completion.

I just want to reassert what Dean said. Abstraction! It is what makes C++ and OOP so great.

Using truly crossplatform libraries will cut down on development time a little bit, maybe. But at the cost of performance. You will never get the speed from cross-platform libraries that you will from dependent libraries. There is a reason the are platform dependent i.e.: They use specific features of the platform in the way they were meant to be used.

Normally APIs are not a whole lot different between platforms. And they should take up only a small portion of the code you write for your game. If you encapsulate sound, graphics and input in your own classes, and only call API methods from those classes, it is only a matter of rewriting the wrapper classes to port them to the next platform.

I will tell you from lots of experience that people who write cross-platform applications do not do so using cross-platform libraries. Atleast most don''t. There are a few oddballs who have the hair in the wrong place, but most will use abstraction and then port the platform dependent classes. It''s just a happier marriage that way.

Seeya
Krippy