James said:
[..]
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.
To the OS, or to the development environment? If I look at my
Windows system, I don't see any difference between applications;
they're all .exe files, regardless of what they do. As far as I
can tell, all of the facilities of the OS are there for all
programs to use, if they want.
E.g., even if you start a "normal" Windows app
from the command line, no output is going to appear.
I'm not sure what you mean by a "normal" Windows app.
Something that isn't a console app? I just started Netscape
from a "command prompt" window (the Windows equivalent of a
terminal window, I think), and it started exactly like it does
when I click on the icon. No output appears in the terminal
window, of course, for the simple reason that netscape doesn't
output to standard out.
'std::cout'
and 'std::cerr' are essentially "black holes".
"/dev/null". Again, that's not a characteristic of the program,
but of the way it is invoked. In most of my application
software, cout and cerr are also connected to "black holes" (and
cin returns end of file immediately). Not because they do
something special, but because that's the way they're started;
they aren't started from a terminal window, but as a cronjob, or
on system startup. (I'm sorry if the terminology here is very
Unix specific, but that's what I know. I know that Windows has
the same possibilities, because I've seen them used, but I don't
know what they're called there. And also, my applications do do
a little bit special, to ensure that even if they are started
from a terminal window, they are disconneted from it, so that a
control-C in that window won't terminate them. But they can
still write to std::cerr, for example; if they program was
started from a terminal window, that's where the text ends up,
and it was started normally, the text ends up in a black hole.)
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.
Now that can't be true. I often write little test programs in
Windows, to see what happens with VC++, and I've never created a
console in any of them. I just compile them and run them.
Almost exactly as I do under Unix (and the sources are
identical, since it is the same remote mounted file).
And that, really, is more or less what I was asking: are these
programs "console applications", or something else? And would
my real applications be "console applications" if I compiled and
ran them under Windows, or something else, even if they are
normally started automatically by the system at a certain time
each day, and they're standard output is to a black hole?
In a "console application" this is done automatically.
So what I'm writing aren't "console applications", because I've
never seen anything that automatically opened a window, without
my demanding it (by means of a special library call, which
doubtlessly at the lowest level ends up in some kind of
communication with the windowing system).
Actually, a Windows application is not an application at all.
It's a dynamically loaded library (DLL).
But it still has a .exe suffix, and can be invoked from the
command line. (Or is Netscape not a Windows application? I'm
getting more and more confused.)
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).
On any modern large scale system, code cannot execute without
any number of system services. The system starts the code; the
system recovers the return code, and does something with it; the
system takes care of all of the IO, memory mapping, threading,
and who knows what all else. Almost always, too, there are
additional objects which are dynamically loaded to provide
higher level services: access to Oracle or Sybase, for example.
(Under the Unix I'm familiar with, access to the basic C
standard library is normally also via a dynamically loaded
object, although you can request it be linked statically when
generating the program.)
Sorry, but I DO know how my applications run.
Is the application start point called "main" or "WinMain" in the
apps you write?
"main", obviously. I'm coding in C++, and I'm not using some
third party application framework. That's also true for the
little code I write under Windows. It's C++, and I'm not using
any third party application framework.
I've vaguely heard about "WinMain", but from what little I
understand, it's basically just part of an application
framework. It's a function, rather than a class, because the
application framework is designed to support a C API, but it's
basically the same thing; the application framework contains
main somewhere, sets itself up, and then calls this other
function. But of course, you don't have to use this framework,
and you'd only use it if its services corresponded to what you
need.
What subsystem do you tell the linker to use?
If you don't tell, what does it use by default?
I usually specify about twenty different libraries (many written
in house) when I link my real application. By default, I get
libc.so and the C++ standard library (which depends on the
compiler I'm using), and nothing else---even the math functions
in standard C are missing.
MS Windows can be viewed as a bit more sophisticated than other
systems we've encountered just for having those "subsystems".
What subsystems? And what does this have to do with "console
application"? Every modern OS has a number of subsystems; I'd
say that the split was stricter (and the sophistication higher)
under Unix. (At least, every time I use Windows, I get the
impression of going back 10 or 15 years in time.)
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.
If it doesn't matter, why do people here always mention it?
VS does invoke the compiler with some command line, as well,
and captures its output, and then displays it in a window. Nothing
out of the "ordinary". It does have plenty of other tools to help
set up a project and navigate the source, and... But that's all
it does.
That's my impression, and that's the way similar tools work
under Unix. In general, the OS only has one basic way to start
a program, which can be mapped more or less directly to a
command line. The more evolved tools provide a fancy interface,
but in the end, don't do anything different that what the shell
does to start the command. So at the OS level, there's no
distinction---an application is an application. (There is code
which is handled differently, for example, device drivers. But
surely you don't mean to say that anything that isn't a device
driver is a console application.)
Note that most of the above is really off topic here. And also
has very little to do with what I asked: what do posters here
mean when they use the expression "console application"? And
what else is there (except kernel code and device drivers)? As
far as I can tell, an application is an application: if it's
written in C++, we can discuss it here, and if it's not, we
shouldn't.
I