I remember a long time ago RickO made a post regarding Tribes. There was a discussion about what console applications were used for most often, and stuff like that. He mentioned that Tribes uses a console application, so that if the user runs a dedicated server instead of the full game, they could just run it in that text based mode. I''m trying to figure out how they did that, exactly. When you run from a console application, you use the normal old int main(int argc, char **argv), right? How then do you manage to get ahold of the hInstance that''s normally passed to you through WinMain. You need this thing to start up DirectInput, and under Win 9x, to create windows. Does anyone know how to get this handle without getting it passed to you through WinMain? Now that I think about it, I''m sure GLUT does the same thing. Maybe I can dig through the source long enough to find it. Anyone that might know though, feel free to reply, so that I don''t waste hours digging through unfamiliar code Jonathan

Hmm.
Would AfxGetInstanceHandle() work here? I haven''t really done any console app stuff.

-fel

HINSTANCE hInst = GetModuleHandle( NULL );

Technically, it''s an HMODULE, but it can be used interchangably with an HINSTANCE wrt GetProcAddress, etc.

MSN

Thanks a bunch, that works beautifully.

Jon

Why not create a Win32 App that don''t create a window? You can still output to the console window with cout. And you get the HINST parameter without any hassle.

I never could understand why to use a console app. If someone can enlighten me, please feel free to do so.

in MSDN 6.0 theres an article about this stuff
"The C/C++ Compiler Learns New Tricks"
it also explains where to get hInstance from.
"Getting to hInstance" topic.

-kertropp
krt@jot.ee

quote: Original post by Spellbound
I never could understand why to use a console app. If someone can enlighten me, please feel free to do so.

Biggest reason I can think of is utility programs such as sed, awk, and grep. Then you can just use chains of pipes on the commandline. Or lightweight programs like nslookup. Basically anything generated by lex will want to run in console rather than as a windows app, and for small utilities, it isn''t worth the extra effort to convert it.

Yes, but after reading the article mentioned by kertropp (the anonymous poster) I see that a Win32 app can still use the old fashioned main() entry function, where the commandline is more easily accessible. You don''t have to create a window so I still don''t see the reason to use console instead of Win32.

Perhaps I didn''t express my question correctly. I can see the reason of why you don''t want to create a window to do something simple that don''t need any GUI. But why compile it as a console app and not a win32 app?

Now I just don''t understand where you''re coming from.

The article (dated in 1992/1993) related to MSC 7, not any of the Visual C++ versions. If you try using main as the entry point for a Win32 app, the linker will give you errors. (Just tried it.) If you try to use the extern const tricks as described in the article, you also get errors. (Just tried that too).

As for why you wouldn''t want to bind your entry point to WinMain for a non-windowed application: portability.

Thanks for clarifying this for me. I only did a quick readthrough of the article and I guess I misinterpreted it.

I will continue to compile my console applications as console app, as I have always done. I just never understood the differences between the two builds, except that one was for non-window applications.