Re: linker error
* James Kanze:
On Jul 24, 3:09 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
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.
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.
Not quite. The difference between services provided for GUI versus
console subsystem isn't that great: just that a console program gets a
console window by default. Other subsystems are drivers, and earlier
Windows supported OS/2 and Posix 0.9 console subsystems, the latter
providing a Posix compatibility box. The Posix compatibility subsystem
is now replaced with a distinct *nix environment called Windows Services
For Unix, SFU, which ironically bundles the g++ compiler...
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.
You're right. If you start a GUI app that produces stdout output,
whether that output appears in a console depends on whether stdout is
hooked up to the console window. The old Windows command interpreter
doesn't hook up stdout for a GUI app by default, but you can pipe it
through cat or more or findstr or whatever, or redirect it to a file.
'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.
Right, 100%.
[snip]
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).
Right, but I suspect it is because you didn't know that you produced
console programs. If you build the same source as a GUI app, you'll
need to either use some other command interpreter than Windows' old one,
or else redirect stdin and stdout explicitly.
And that, really, is more or less what I was asking: are these
programs "console applications", or something else?
Probably, yes.
Depends on how you build them.
[snip]
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.)
A Windows application isn't a DLL, but has the same executable format as
a DLL (Portable Executable, PE).
Do read the PDF I linked to, <url:
http://home.no.net/dubjai/win32apitut/01.pdf>.
Follow-ups set to [comp.os.ms-windows.programmer.win32].
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?