Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Jonathan

Win32 question

This topic is 6646 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
HINSTANCE hInst = GetModuleHandle( NULL );

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

MSN

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!