[ ... ]
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.
They all show up as .exe files. The 'optional header' in a PE file
(which isn't really optional for a PE file) contains a field that
specifies the subsystem for which that executable was compiled.
For Win32 programs this makes _very_ little difference: it mostly just
governs how the program is started up (i.e. whether it gets a console by
default or not). Though I believe they've been removed now, Windows NT
originally supported POSIX and OS/2 subsystems as well -- and those did
NOT have access to Win32 functions.
[ ... ]
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).
Most Windows linkers set the console subsystem field based on what they
find as an entry point for your program -- if it contains a function
named "WinMain", they set it to use the Windows subsystem. If it
contains a function named "main", they set it to use the console
subsystem (they also recognize a few variants like 'wmain'...)
That means portable code that uses 'main' will become a console
subsystem program unless you specify otherwise.
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?
See above -- if they start as portable code, they'll produce console
applications by default. That gives them a stdin, stdout and stderr, but
what they're connected to depends entirely on how they're invoked -- if
you start them from a normal command line you can leave them connected
to the screen/keyboard or you can redirect them about the same way you
would under a typical shell.
If they're started by something like cron, they'll typically be started
as a "detached" process -- the streams all exist, but output goes to a
black hole, and input always yields EOF.
[ ... ]
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 looks to me like he's just trying to be confusing here. Executables
and DLLs use identical file formats (PE files in both cases).
Effectively, however, there are significant differences -- the OS knows
to create a new process when you try to load an executable, whereas a
DLL is normally loaded into some existing process.
[ ... ]
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.
WinMain has nothing to do with any framework beyond Windows itself. If
your program contains a WinMain, it normally will NOT contain any
function named 'main' anywhere. Whether you write a main or a WinMain,
your program will, however, contain some other function as it's actual
entry point from the OS -- Windows doesn't do anything like collecting
comand line arguments to supply to the program. Its entry point gets the
command line, parses it, and then passes the results to main or WinMain.
There's a different entry point for each, because they expect different
arguments, but either it's there -- supplied in the runtime library.
[ ... ]
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.)
Unix (per se) doesn't have subsystems in the Windows sense. Windows NT
was originally conceived as (at least sort of) a microkernel. It has a
native API that most people never use. Originally, it had (on top of
that) subsystems for Win32, Win32, POSIX and OS/2.
Nowadays, they've removed the POSIX and OS/2 subsystems, so Win32 is all
that's left. Both windowed and console applications run under the Win32
subsystem. For a _few_ purposes, they're (sort of) treated as separate
subsystems, but for most purposes, it's just the Win32 subsystem either
way.
As far as sophistication goes, I suspect it's a much a matter of
viewpoint as anything else -- when I run Unix (or Linux, BSD, etc.) I
get the feeling of having just stepped back 10 or 15 years as well...
[ ... ]
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.
This _is_ somewhat different: Windows only provides on way to start a
program, but it does NOT map to much of anything. The real entry point
for a program always has the signature 'unsigned int entryPoint(void)'.
It's (always) up to some code in the program itself to do things like
retrieving and parsing its command line, if it chooses to do so at all.
I believe this is largely because Windows was originally designed around
the idea of using wide character strings throughout, but they realized
that most existing code was designed around the interface to the system
being narrow character strings.
Rather than attempt to decree how this gap should be bridged, they left
it to the program to decide what to do. OTOH, they provided enough to
make it pretty easy to build that bridge (e.g. a function to take a
command line a split it into arguments) but also give enough flexibility
that (for example) it's fairly trivial to receive command line arguments
as UTF-16, UTF-8, UTF-7, etc.
. But the article is excellent.