New to windows programming.

[amitapm]

Hi Everyone,

I am totally new to C++, Windows programming. I am good at C++, Unix/Linux programming, however I am a novice when it comes to windows programming. I have never written any code in VC++, so dont even know how to compile a code in VC++. I would like to know a few things to get started with programming in C++ on windows -

Firstly, how different it would be than the unix environment.

Secondly, can someone please suggest me good reference to started with it? I am not looking for the syntax and the constructs as I believe that would be the same irrespective of the target environment
.
Thirdly, this question is somewhat similar to the first one, but not the same. I would like to know what C++ on windows can do that it cannot in unix and vice-versa.

Thanks.
amitapm

[zdenekkrejci]

Hi
Well I would say there is no difference in c++ on Linux and Windows. The only differences would be for example with communication with your system. So for example accessing ports, files etc... is done differently but basically is all about different includes :-)
And there are some things that you can do differently when you moving from Linux... But cant, if you moving from Windows to Linux, its for example naming your *.h and *c/cpp files.
In windows is no different for Header.h or header.h but in Linux its a big different...
And also ports have different names so in Linux etc/ttyUSB* nut in windows the classics COM and than also their prefix....
Also in Windows when specify a path to some files Directory\... in Linux Directory/... but some compilers takes also /in Windows... and in Windows to say THIS directory its ...\ not .\ as in Linux...

[S6k9GNh0]

C++ itself is meant to be platform-independent. Anything that is within the standard should work wherever there is a compiler, including the standard libraries. There are also general libraries that help to provide optimized and cross-platform solutions (which provide a universal interface to the given platform) such as the libraries from Boost. If you are familiar with POSIX libraries, there are compatibility layer libraries that allow you to use the POSIX API directly as if you were in a POSIX environment. Although some may disagree, I would try and avoid using the Windows API directly. This may not be possible at some point in time and even then, I suggest you create a wrapper around the API to use indirectly.

Also, as far as VC++, you don't have to use VC++. As a matter of fact, you can still use GCC with GNU make/automake/autoconf. There are several projects that provide ready-to-go environment installers such as Cygwin/GCC and MinGW (most commonly used). I personally use CodeLite (IDE) with MinGW/GCC v4.5.2.

As far as I know, there is nothing that C++ can do on Windows that it can't do on a *nix OS. Like I said before, C++ is meant to be platform-independent and available wherever there is a compiler. The compiler and linker is generally the layer between C++ and the platform. Windows does, however, have there own symbolic mangling for things like DLLs and static libraries. A DLL can be linked against (similar to an .so file) using a stub file which is simply a bunch of generic unresolved symbols resolved by the shared library automatically loaded on runtime. You cannot use a VC++ library with GCC directly.

A quick note on the confusion on C++0x facilities: Some people seem to think these aren't cross-platform (I have no clue why...). They will work wherever there is a compiler from Linux to MacOS to the original Xbox.

[Computergeek01]

@ OP: As has been said the language remains the same, although the Win32 API is actually C but made to feel like C++ while leaning toward support for the MS languages as well. This just makes it feel different, but it's still C.

Windows likes to rename data types, it especially likes to use void pointers to make psuedo-objects. Things like this:

- HANDLE and HWND are both void pointers and both refered to as handles in the documentation but they are not compatible with one and other. Come to think of it, virtually everything in Windows in a typedef of a HANDLE, which is itself a void pointer, just keep in mind that you can't always interchange them.

- BOOL is NOT the same as bool, BOOL is an integer.

When a datatype in a function definition has an 'LP' prefix, then they want you to pass the data type by reference. Again this is Win32 pretending to use objects, always remember it is C not C++.

Overall you will feel limited at first, but you'll love MSDN, there is simply nothing in the *nix world as well documented and friendly to use. It makes picking up Win32 development as painless as possible.

Save this link: http://msdn.microsoft.com/en-us/library/aa383751(VS.85).aspx

[freddie1]

Although some may disagree, I would try and avoid using the Windows API directly. This may not be possible at some point in time and even then, I suggest you create a wrapper around the API to use indirectly.

Don't want to start a flame war over this, and I do respect computerquip's preferences, but I personally love coding against the Windows Api directly. But then, in the limited *nix coding I did, I preferred using XLib to anything else, although GTK+ wasn't too bad. So yea, I'm a low level coder.

In my opinion the Windows Api is truely elegant. There is nothing like it in *.nix, to the best of my knowledge. If there is, I simply never found it in my various explorations of XLib, Motif, GTK+, etc., What's really different about it is that the 'Window Manager' component is an irreducible part of the core Api - unlike in *.nix. Also, its very object based, even though its implemented in C - not C++. I think this throws a lot of C++ coders off when they first encounter the Windows Api. The end result is that most seem to immediately then gravitate to a C++ class framework that wraps the underlying Api. Depending on your needs, this may save you a lot of work, if functionality is wrapped that would take a long time to learn to implement oneself out of lower level code. The downside is you'll be lugging around a large runtime enviropnment, and to become truely expert one needs to understand the low level Api anyway.

Within the past few months I've posted some code here showing command line compiling of Windows Api based GUI programs using GNU mingw and MS C++. If you are interested I could hunt the links up for you.

[amitapm]

Thanks for the insight everyone.

I need to start on professional projects in a months time. What would be the starting point?

As Freddie has correctly pointed out, to understand how things work at the lower level code one should use the windows API. Start experimenting with Win32 API directly?


@computergeek01, thanks for the link.

[z05DSL3A]

I need to start on professional projects in a months time. What would be the starting point?

Buy a copy of Petzold^* and read fast. ;0)


* Programming Windows 5th Edition by Charles Petzold

[Lamblion]

Since nobody has mentioned it, you should also give this Win32 API tutorial a good look --

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

Look on the far left side of the page for "Beginning"

[freddie1]

That Petzold book is really, really important. Last time I checked it was expensive. His circa Win95 book costs next to nothing used and is almost as good (missing wide char string stuff).

[z05DSL3A]

FYI, Windows via C/C++ 5th Edition by Jeffrey Richter is a good follow up to Petzold.

[Lamblion]

FYI, Windows via C/C++ 5th Edition by Jeffrey Richter is a good follow up to Petzold.

Yeah, I might even buy that one myself if Bill Gates will front me the money for it. Talk about expensive!

And I can rememeber seeing it in my local computer bookstore several years ago for about $50.00. Oh well.