Re: linker error
On Jul 25, 6:47 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1185357899.165163.158...@57g2000hsv.googlegroups.com>,
james.ka...@gmail.com says...
[ ... ]
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.
What's a PE file? And what do you mean by "optional header"?
I'm sure that .exe file have a specific format, just as a.out
files do under Unix; do you mean a header section in this
format?
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.
I got that from Alf's paper; it's an attribute which is
associated with a .exe. (Presumable, there is a system API with
which I can read the attribute, so if I wanted to start a
program from one of my programs, I could also test and handle it
differently.)
[ ... ]
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).
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.
But I can specify otherwise. Why not?
BTW: I wouldn't have understood what was meant by "subsystem"
here, either, if I hadn't read Alf's paper. From what I
understand, it's really just an attribute associated with the
..exe file (something in a special secion of the .exe, perhaps);
it's not really what one would understand by "subsystem"
normally. (If I understood Alf's paper correctly, Microsoft
linkers do also link in an additional library if they decide
that my program is a "windows" application, but that is, again,
still another issue.)
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.
Just like Unix. (In Unix, "/dev/null" is the name of a device
which simply throws away anything output to it, and returns EOF
if you attempt to read it.)
[ ... ]
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 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.
That's what I'd always thought. (On the other hand, there are
significant differences between the way Windows handles .dll's,
and Unix handles .so's. My impression, in fact, is that they
are much like the differences between how the systems handle the
way you start a program. Under Windows, the decisions are
handled upstream, by the person who provides the program/DLL;
under Unix, they're made by the user, when he uses it.)
[ ... ]
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.
OK. Now I see where the name comes from, as well.
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.
Which is doubtlessly why the use of the name subsystem seems so
strange to me in this case. Still another historical anomaly.
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...
With regards to what? I don't have the applications that I have
under Windows, or they don't look as sleek, but at the system
level, I've got a lot more functionality: multiple desktops,
windows on many different machines, etc.
[ ... ]
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.
All of which is transparent to the C++ programmer, of course:-).
If I'd have thought about it, I would have realized that this
was probably the case; that's the way it worked on every system
I've seen except Unix. But the concept of a "command line" is
still there; if program A starts program B, it still can provide
the equivalent of a command line somewhere. If I associate a
program with a file type, I specify a "command line" which is
used to invoke the program. There is some sort of mapping
between command line and what the program can see and use.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34