You can't have WinMain as a method of a class. Your best bet would be either to call your framework's main function from within main/WinMain or use the ctor of the class.

I hide WinMain in a platform specific file (mswindows.cpp). All it does is call my own main function (and it assigns the hInstance) which is placed in another file.

int WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR, int){
Platform::hInstance = hInst;
return Framework::My_main();
}

int Framework::My_main()
{
new Platform();
Platform::createWindow(640, 480);
//etc.
}

Also note that WinMain can't be placed inside of a DLL. This can be solved by creating a macro that's invoked from within the executable's project.

The previous ap post was mine, Here's a new one with (hopefully.. ) proper line continuations in the macro.
edit: For some reason forum decides to eat my line continuations (why?), so just pretend that they're there.

Also note that WinMain can't be placed inside of a DLL. This can be solved by creating a macro that's invoked from within the executable's project.



[Edited by - doynax on August 26, 2004 5:58:21 AM]

Clicky!

Nica article about a Window wrapper class by Oluseyi Sonaiya. Covers that problem and how to properly handle window messages.

I assume that you're going to be exporting a lot of functionality to DLLs, etc. Anyway, you can't get by without having a WinMain or main function for your program, you can't put it in a DLL and you will encounter problems when trying put your WndProc into the DLL (as you've found). What you need to do is create a static library project containing your WinMain and link this to the exe. Most projects create an abstract platform interface to ensure that above the platform layer, the platform implementation is hidden from the user. You will probably want to create a IRenderWindow interface, which again features implementations under Linux, Windows, MacOS X, etc. The instances of the RenderWindow classes are platform specific and generally sit in the same project as your platform interface implementation. In this case, the Win32RenderWindow would contain the WndProc, which in turn is initiated and created by implementing the respective init() / create() calls derived from the interface.

The role of WinMain or whichever platform's main would simply be to create the game window and perform other platform relevant tasks and then create a game instance and launch into a loop which calls the game loop and render each frame.

To be fair, it does sound as if you're reinventing the wheel and probably adding a lot of complexity which could be avoided through the use of libraries such as SDL and GLFW - OGRE also has decent platform management capabilities worth looking at too. It'd be good if you investigate such libraries if only to examine how other people do such things, after which you can begin implementing your own way if you feel the need. I used to do what you are trying and started implementing a platform basecode, although I was fairly successful with the Windows implementation, I still decided to use an Open Source framework to remove all headaches and aim for maximum portability prospects.

I urge you to check out the resources above, even Code on the Cob is useful to read in this subject. If you still can't figure it out, post again or message me and I'll send you some of my old code.

Good luck!