James Kanze wrote:
[..]
I know this is off topic, but the issue comes up so often: what
the hell is a "console application"? How does it differ from
any other application, other than, perhaps, it doesn't use
certain libraries? (In which case, of course, you don't need to
click anything. Just don't include the appropriate headers, nor
link against the corresponding library.)
It's specific to Windows OS, and how the hosting environment tries
to provide (or exclude) certain features we're so used to in some
other environs. E.g., even if you start a "normal" Windows app
from the command line, no output is going to appear. 'std::cout'
and 'std::cerr' are essentially "black holes". Same for the input
'std::cin', it just doesn't exist in a "normal" Windows app. In
order to have those elements, the app has to "create a console"
(in Windowese) and connect it to the standard I/O streams. In
a "console application" this is done automatically.
Unless I've misunderstood something greatly, in the end, an
application is an application.
Actually, a Windows application is not an application at all.
It's a dynamically loaded library (DLL). It cannot execute
without many other things from the system (compared to some true
executables in some systems that contain all the code necessary
to be run, except for BIOS, maybe).
If it invokes some system
function which opens a window, and plays around in it, then it
is a GUI (or Windowing) application, but that's a result of the
code the programmer wrote, and nothing else. The applications I
write don't normally do this: are they automatically console
applications (even if they are started by a cronjob, or at
system start-up, with cin, cout and cerr connected to
"/dev/null")?
No, they are not.
Is the application start point called "main" or "WinMain" in the
apps you write? What subsystem do you tell the linker to use?
If you don't tell, what does it use by default?
MS Windows can be viewed as a bit more sophisticated than other
systems we've encountered just for having those "subsystems".
I don't really care much about digging too deep into them, and
use "console" for "command-line I/O" and "windows" for the rest.
They do differ a bit in the ways to acquire the command-line args,
for example. But beyond that it doesn't matter for what most
folks do. Unless it does, of course, and then they learn about
those things.
bit... :-)
Windows programming one "must" use non-standard language extensions.
discussed in this thread).
2. Contrary to what's stated above, a Windows GUI app does have
standard input, output and error streams, i.e. yes you can use
std::cout in a Windows GUI app, e.g. for tracing.
3. Contrary to what's stated above, there's no difference between
arguments.
I once wrote up the basics about this in two PDF documents.
See <url: http://home.no.net/dubjai/win32apitut/01.pdf>.
A: Because it messes up the order in which people normally read text.
A: Top-posting.