difference between win32 and console programming

the subsystem linker option.

For Win32 , the subsystem is WINDOWS
For console, the subsystem is CONSOLE

That's it. Note, that in a WINDOWS app, you can still use the console and in a console app, you can still use Windows related functions. The subsystem identifies if the application will be given a console to start with when it launches.

Anyways, the one effect of this is , when CONSOLE is the subsystem, the linker shall look for main , _tmain
For windows, it shall look for WinMain entry point

Actually, the startup code source file defines the real entry point, the linker looks for mainCRTStartup for consoles, WinMainCRTStartup for windows applications. The startup code file defines these entry points, and they (depending on projects settings) will call the correct entry point.

mainCRTStartup looks for _tmain, which maps to main or wmain (I think) WinMainCRTStartup looks for tWinMain which is either WinMain or wWinMain.

what james said, is compiler implementation, it has nothing todo with C++ itselve.

win32 and console programming are the same thing.

Compiler documentation is going to be of some help, particularly on getting either a win32 or console application projected started, appropriate options, include file prerequisites, etc.

While it's true that writing console applications and win32 applications have common practices (identical with respect to C++), what differs is how the application is expected to operate.

I've generated a few console applications as test suites for object libraries. As a practical rule I don't generate console applications much myself, but I used to more frequently in the past, especially when I wrote more for Unix.

The subject veers off into a tangent here. Console mode applications are generally expected to take input from the command line, possibly with some text based interaction (when asking for more parameters), can be command driven interfaces, and can even use a library that allows direct cursor placement and therefore a formatted text interface, much like was popular on Unix machines with 'dumb terminals' and old fashioned DOS applications. Many have confused console applications with DOS applications, the latter being a 16bit build, whereas consoles are 32 bit (for Windows, possibly 64 bit for 64bit versions of Windows).

Win32 is available, if the proper includes and initializations are performed, but generally the application opens a console window (text mode) to begin. With win32 functions available, even in a console build, the distinction of what makes a console application breaks down into how the program was initialized, rather than what it does. It may seem intellectually curious to create a console application that can launch common dialogs or windows, but personally I find that confusing and perhaps limiting against what console applications are generally expected to be able to do. One most typical use of console applications is that they can be included in batch files. If the console application starts sprouting windows, it's not exactly what one expects from a batch process.

Sometimes we field requests for making console applications without a console window, but a better design choice is to make a Windows application without a window, more in the practice of an OS service.

Win32 applications are generally expected to be Windows programs, with a GUI interface or, if the design dictates, a services interface, perhaps a tray icon. They are generally not expected to be used from within a batch file (though this point, and it's earlier inclusion, are certainly not part of any formal definition).

One glaring issue that comes up with console applications is threading. Under Windows, starting a thread uses a function that's generally associated with Windows (win32), and as such begins the blurring of any strict distinctions. Launching threads in a console application would be more common in the current era of multiple core machines than was ever the case just a few years ago. Launching threads generally invokes further win32 requirements for critical sections, mutexes, events and similar functions defined is windows headers. My point is that it is more common to witness a console application invoking portions of win32, especially in recent years, that it is for a win32 application to invoke console modes of behavior.

Beyond these points, there's hardly much to study on the point of your original question, I think. Once the application shell is created, you have a main starting point, what happens after that can blur the distinction, and your study has veered into the realms of CRT, win32, the operating system and it's services, features, and the requirements of your application.

However, to think more on console applications you would naturally work toward Unix/Linux command line usages, and their counterparts in batch files and the legacy of DOS command lines. Particularly the notion of pipes in the command line, the way in which common usage in Unix would be to send the output of one 'console' application as the input to another, then again to a third, etc. As a simple example:

type file.txt | sort > sortedfile.txt

This is a Windows version of a command that uses the built in type command which streams the text in file.txt to the stdout device. The | symbol redirects that stdout to the input of the sort program (a console application), which could accept other parameters to describe how the text file's contents should be sorted, then the > symbol directs the stdout stream, now coming from the sort program, to a file called sortedfile.txt.

Unix did this same thing (and is probably the origin of this concept, with respect to DOS, then Windows). The Unix commands would differ ( cat instead of type, for example), but essentially the notion is similar. They all depended on standard text input and output to operate, and used the operating system's ability to connect outputs and inputs according to command line content.

This is the essence of command line operations, and the original intent for console mode applications (and most un-GUI like, at that).

My own recent use of console mode applications has been simply to test containers, object families or to investigate ideas, when I needed something very quick that I could just 'jump into' and try. I keep a 'shell' project just for that, which could as easily been a GUI Windows application, I suppose, so my use of a console build wasn't an important choice.

It would be important if the application was expected to function with other applications in a command line construct.