Sign in to follow this  
paul23

win32 programming?

Recommended Posts

Well I started C++ programming a few days ago. And I think I understand the basic concepts now. - However upto now I only programmed using dos-applications, yet it's much more fun when you're able to create win 32 interfaces etc. So I'm wondering, how do you do this? - Is there any tutorial that explains the basics of those applications? I tried creating a win32 application with msvc++ (that's the abbriviation for microsoft visual c++ right?) - However it generated so much code that I completely lost where to program.. Also I didn't see any 'main()'. So is there any tutorial that explains how to create those games from scratch?

Share this post


Link to post
Share on other sites
One word. Don't. [wink]

There is really no magic in it. First, in Windows applications, the main function is replaced by WinMain for historical reasons. That should allow you to create a win32 application although without any windows or graphics.

However, creating windows and all that is just a matter of calling a bunch of functions defined in the windows.h header.

In other words, it's nothing special, and not conceptually different from writing to std::cout defined in the iostream header, or using std::vector defined in the vector header, or......

The point is, it's not some secret extension to the C++ language. You just call some predefined functions, and they do all the magic for you.

At the same time, it is a huge distraction, because you need to focus on things that have nothing to do with programming, and when it doesn't work, you have to browse through Microsoft's documentation of their 20 year old and hugely inconsistent API, instead of learning to fix your programming errors.

That is why people are generally advised to start with text-based applications, and stay with them until they've learnt programming. Which means you'll have to spend more than "a few days", especially in C++.

If you start messing with graphical applications now, the only thing you'll achieve is to slow down your own progress.

You'll be able to make a graphical game much faster if you accept to stay with command-line programs for now, where you can focus on the program logic, on actual programming without needless distractions.

I've got a very simple rule of thumb for when to start poking around with windows/graphics.

Google for win32 tutorials, find an example of how to set up a window, look at the code, and ask yourself it it makes sense. Does it look like complete black magic?
Does it look like the C++ you know? Does it look like it's written in the same language as you're using?

If not, you need to go back and practice programming for a month or two longer.

If you can follow the program flow, even if you don't know what each function does exactly, you might be ready to start playing around with windows.

But don't rush it. You won't lose anything by staying in the text-based world a while longer. The big sticking point is always how well you know programming, and that's the same whether or not you have a graphical component to your programs.

Share this post


Link to post
Share on other sites
Thanks for the advice: the problem is that I can't really think of much to program with only the command line (and files) output (cout,cin). Made a few small things already: like a sorting algorithm of data in files (only using arrays/made my custom bubble sort), some string modify functions (well character-array - modify functions) and a small guess-the-number game. So I wanted to go for a "tetris clone", and I read the example in the stickied topics [url=http://www.gamedev.net/community/forums/topic.asp?topic_id=192483]here[/url], a problem with those is that those guides only say: you need to use this function! - But they never really explain what the functions do. Also I seem to get everytime the same error when following a tutorial:
Quote:
1>...\test_main.cpp(175) : error C2440: '=' : cannot convert from 'const char [17]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>...\test_main.cpp(184) : error C2664: 'CreateWindowExW' : cannot convert parameter 2 from 'const char [17]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>...\test_main.cpp(238) : error C2664: 'BitMapObject::Load' : cannot convert parameter 2 from 'const char [11]' to 'LPCTSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

looking up the lines gives:
first error:
wcx.lpszClassName=WINDOWCLASS; 
where "WINDOWCLASS" is definded by: #define WINDOWCLASS "FallingBlockGame". Another [url=http://www.functionx.com/win32/Lesson01b.htm]tutorial[/url] I googled also said the same "thing"... So I understand that the variable type is wrong, it should be "LPWSTR", but is it strange I have no idea what LPWSTR is (apart from some obscure class) nor how to convert those?

The other 2 problems were actually almost the same: they couldn't convert a "string" to LPWSTR (and LPCTSTR) type. Can anybody explain me how these conversion problems seem to work? - Ow and maybe what those things are/do :P..

Sorry for asking so many questions, but it seems now that the more tutorials I read the more questions I get lol.


EDIT: well I now tried to create an explicit conversion doing things like:
(LPWSTR)WINDOWTITLE - where WINDOWTITLE is a character-string. It didn't give a compiler error, yet the runtime results weren't really satisfying (it actually didn't show any good "marks" in the caption).

Share this post


Link to post
Share on other sites
I recommend that you stay away from the Win32 API as it will just give you a lot of headaches. If you want to use "real" graphics and program 2D games, I recommend that you take a look at SDL which is much easier to use than Win32. There are many nice tutorials for it here.

Share this post


Link to post
Share on other sites
If you are following a book to learn C++, try doing the exercises. All of them. They will reinforce what you know, but also point out what you don't know. Being aware of what you can and can't do (yet [grin]) is a vital part of being a programmer.

To put it bluntly, a few days is insufficient practise before jumping into something complex like graphics.

Share this post


Link to post
Share on other sites
Agreed.

If you're still learning C++ (and believe me... you NEVER stop learning C++... The language takes years to master and you'll find that there's ALWAYS more tricks to learn!) then getting to grips with the HUGE number of Win32 system calls will only get in the way of that vital progress.

However... I would recommend getting to grips with the Win32 API (and perhaps the DirectX API) once you've really covered all the main areas in C++ and then some.

Also... Since the Win32 API is all C based anyway, this will add to the slow down of your C++ development.

I was quite content to develop console applications as I got to grips with C++. After a couple of months, I too had an eagerness to go straight into Win32, but found that it was probably best I learned C too (you DON'T have to of course... But it helps!). After having some experience with C++, getting to grips with C was a bit more straightforward, but I sure did get my fingers burnt here and there LOL!

Once I had gone through a couple of books on C++ and C, it was only then that I delved into the Win32 API (and then eventually DirectX). And believe me, you WILL learn a lot from this experience but it sure takes time.

For future reference, may I recommend "Programming Windows by Charles Petzold". It's an uber book BUT, once you've seen the size of the damn thing, you'll realize that Win32 is quite a BIG nut to crack.

But hey... Take your time dude... No need to rush.

Happy Coding!

Share this post


Link to post
Share on other sites
Quote:
Original post by paul23

EDIT: well I now tried to create an explicit conversion doing things like:
(LPWSTR)WINDOWTITLE - where WINDOWTITLE is a character-string. It didn't give a compiler error, yet the runtime results weren't really satisfying (it actually didn't show any good "marks" in the caption).


Don't feel bad about this (it's a common rookie mistake), but "jamming in" a parameter by casting is a bad bad bad thing to do unless you're 100% sure you know what you're doing. In this case you're just covering up a compiler error and trading it for a much harder-to-debug runtime error.

At any rate, the problem here is related to how the Windows API handles character sets and strings. You can see my last journal entry for some explanation as to what's going on here and what you need to do to fix your errors. However I can't guarantee that you'll 100% grasp everything if you don't have a decent working knowledge of C/C++.

Share this post


Link to post
Share on other sites
Quote:
Original post by paul23
Also I seem to get everytime the same error when following a tutorial:
Quote:
1>...\test_main.cpp(175) : error C2440: '=' : cannot convert from 'const char [17]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>...\test_main.cpp(184) : error C2664: 'CreateWindowExW' : cannot convert parameter 2 from 'const char [17]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>...\test_main.cpp(238) : error C2664: 'BitMapObject::Load' : cannot convert parameter 2 from 'const char [11]' to 'LPCTSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

looking up the lines gives:
first error:
wcx.lpszClassName=WINDOWCLASS; 
where "WINDOWCLASS" is definded by: #define WINDOWCLASS "FallingBlockGame". Another [url=http://www.functionx.com/win32/Lesson01b.htm]tutorial[/url] I googled also said the same "thing"... So I understand that the variable type is wrong, it should be "LPWSTR", but is it strange I have no idea what LPWSTR is (apart from some obscure class) nor how to convert those?

The other 2 problems were actually almost the same: they couldn't convert a "string" to LPWSTR (and LPCTSTR) type. Can anybody explain me how these conversion problems seem to work? - Ow and maybe what those things are/do :P..


I heartily agree with all the comments above. However, just in case you are curious about the errors you describe...

[EDIT - MJP got there first, and the journal entry he links to looks like a far better and more detailed explanation than mine below].

The reason you are getting these errors is that, by default, Visual Studio creates your projects set to use UNICODE rather than the single-byte character set you are more used to using. However, since C++ is a bit archaic, a quoted string "like this" is always single-byte, regardless of your project settings.

The quick and dirty solution is to set your project to use single-byte character sets. This will allow you to compile most of the older sample code on the internet with VS.

Go to Project->Properties, then in Configuration Properties, and click on General. In the right hand box, under Project Defaults, change Character Set to Not Set.

If you are really interested, the header file <tchar.h> gives a bunch of macros designed to write code that can compile under either configuration. Also, searching the help for 'UNICODE' will give a lot of information.

Or you could take the far more sensible option of using a modern language and library like C#.NET to write Windows applications where stuff like the above is irrelevant.

Share this post


Link to post
Share on other sites
best win32 resources i've seen


http://www.stromcode.com/

http://www.winprog.org/tutorial/

http://www.functionx.com/win32/

http://www.catch22.net/tuts/

http://msdn.microsoft.com/en-us/library/aa383749.aspx

but SDL works alot better for game stuff, alot simpler

Share this post


Link to post
Share on other sites
unicode is a big pain in the butt sometimes, at least compared to ascii. hopefully the new c++ standard will fix many of the problems with character strings. They've even got it in the works to extend STL strings with unicode support.

I believe there is something in the new standard that will get around this headcahe once and for all, at least in terms of string literals:
u8"I'm a UTF-8 string."
u"This is a UTF-16 string."
U"This is a UTF-32 string."
"Regular ascii string."

I believe windows api uses "wide characters" (wchar)... which is basically their own version of unicode.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ultimape
I believe windows api uses "wide characters" (wchar)... which is basically their own version of unicode.


Win32 uses UTF-16. A wide character is a datatype which is more than one byte and is meant to store a character.

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
One word. Don't. [wink]

There is really no magic in it. First, in Windows applications, the main function is replaced by WinMain for historical reasons. That should allow you to create a win32 application although without any windows or graphics.

......

But don't rush it. You won't lose anything by staying in the text-based world a while longer. The big sticking point is always how well you know programming, and that's the same whether or not you have a graphical component to your programs.


Well said. It took me much more than a few days to come to grips with C++ itself.

Think of libraries and windows and graphics as merely things done with C++, not functions/features of C++.

The core thing here is to know C++ first. Experiment with bitwise operations, pointers, learn templates and try out some of your own template classes and functions. Learn a bit about function pointers, references, complex math; teach yourself about pointer arithmetic, using logic operations in equations, virtual classes, inheritance, function overloads, string manipulation such as concatenation, splitting up strings, learn how to use STL and all of the different types of containers that C++ can help you create and use in your programs. Read articles on slimming down code (especially logic and function calls), optimising operations and memory usage, refactoring large chunks of code, when and how to use dynamically allocated memory, how to track the memory you use and how to diagnose problems with the performance of your code.

One other thing if you haven't learnt it yet is the actual physical layout of memory in all your integers, floats and strings. Understanding the binary layout of computers will greatly help you down the track with more complex areas such as optimisation and memory reduction.

Thats a little hint to the scope of what the language is all about without delving much into what to use it for. Don't ride a bike without knowing how it works!

Share this post


Link to post
Share on other sites
NT isn't really UTF-16. In normal Microsoft fashion they decided to only implement parts of the standard encoding. I know the earlier versions of Windows didn't support surrogate pairs. NT4 doesn't support them at all, not sure if with 2000 surrogate support is enabled by default, XP GDI also had issues with surrogates and may still? There's probably other differences as well but I've been fortunate to not venture outside of the western range. Probably the reason why they decided to call the encoding wide character encoding.

Share this post


Link to post
Share on other sites
Quote:
Original post by Gage64
I recommend that you stay away from the Win32 API as it will just give you a lot of headaches. If you want to use "real" graphics and program 2D games, I recommend that you take a look at SDL which is much easier to use than Win32.


Is it a joke ?
SDL is for kids only, who don't know anything about programming .
With win32 api, you can do *everything*
"real graphics" has no sense at all. SDL is just a wrapper !
With GDI/GDI+ tou can do everything in 2D.
With DirectX, you can do everything in 3D.
Read the Petzold and MSDN.

Share this post


Link to post
Share on other sites
Quote:
Original post by paul23
Thanks for the advice: the problem is that I can't really think of much to program with only the command line (and files) output (cout,cin). Made a few small things already: like a sorting algorithm of data in files (only using arrays/made my custom bubble sort), some string modify functions (well character-array - modify functions) and a small guess-the-number game

Could make a hangman game. Or an app that prints out the name of every .txt file on your harddrive. Or a database of all your CD's. Or any of a million other things. Or just go back and read some more about the C++ language. There's plenty you still don't know. Learn new features, then try to use them.

Ultimately, input and output (whether it's cout and cin, or file streams, or in GUI apps, the current mouse position, or the "you just clicked the 'ok' button" event) aren't all that interesting. They're just ways of getting data into your application.
The hard part is in the logic for working with that data. And that's what you need to practice.

Share this post


Link to post
Share on other sites
Quote:
Original post by george135

Is it a joke ?
SDL is for kids only, who don't know anything about programming .
With win32 api, you can do *everything*
"real graphics" has no sense at all. SDL is just a wrapper !
With GDI/GDI+ tou can do everything in 2D.
With DirectX, you can do everything in 3D.
Read the Petzold and MSDN.


I sure hope you aren't serious...

Share this post


Link to post
Share on other sites
I must be the only person here who's going to suggest learning Java. Java is great for making Win32 applications with real GUIs. The best part of Java is that it's platform-independant, so the exact same code will run in Windows, Linux, MacOS, Solaris, or any other OS with Java on it. Java's not all that difficult to learn if you've learned the basics of C++. Also, if you're going to create Win32 apps in Java, use Eclispe with the proper GUI Editor. It gives you a simple drag-and-drop interface for making GUIs. All you have to do is add listeners so you can interact with the objects.

Share this post


Link to post
Share on other sites
Quote:
Original post by jalexbrown
I must be the only person here who's going to suggest learning Java. Java is great for making Win32 applications with real GUIs. The best part of Java is that it's platform-independant, so the exact same code will run in Windows, Linux, MacOS, Solaris, or any other OS with Java on it. Java's not all that difficult to learn if you've learned the basics of C++. Also, if you're going to create Win32 apps in Java, use Eclispe with the proper GUI Editor. It gives you a simple drag-and-drop interface for making GUIs. All you have to do is add listeners so you can interact with the objects.
No, I'll agree with you. One thing, though:

Quote:
Java is great for making Win32 applications with real GUIs.
Then, by definition, they're not Win32 programs.

Had I made the recommendation I'd say C#, as the tools are generally more enjoyable to use and I consider the language itself, if not the BCL, a little more straightforward, but they're close enough to be recommended in the same breath. C#'s WinForms GUI support is far, far better than anything Eclipse has, too, and the GUI process is, I think, conceptually easier with events/delegates than with listeners.

Starting with C++ kind of sucks. When you should be learning the concepts, instead you're stuck fighting with syntax. It generally seems to be a lot easier to start with a more modern language and work backwards.

Good luck to the OP!

Share this post


Link to post
Share on other sites
Quote:
Original post by EasilyConfused
Quote:
Original post by jalexbrown
The best part of Java is that it's platform-independant, so the exact same code will run in Windows, Linux, MacOS, Solaris, or any other OS with Java on it.


Fair point, but so will the .NET languages eventually [smile].
.NET has many problems on other operating systems that Java does not (I vastly prefer .NET/Mono, to the point of working for Mono this summer, and I'll still admit that).

-Sockets are full of Win32isms. (They return Winsock error codes, among many other leaky abstractions.)
-System.Management? Really? Ahoy there, Win32isms...
-Basically about a third of the System namespace should be in Microsoft.* but isn't, and makes for some pretty gnarly programming off Windows.

If you're using Windows, and expect others to do so, C# is a smart choice because it maps very well to Win32. Otherwise, C# loses a lot of its appeal (both in having APIs that are more than a little bent and in not having an IDE as good as Visual Studio; MonoDevelop is progressing, but I don't think it's there yet).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this