Pausing screen?
Zach
Microsoft Visual Studio 8 Express it will flash a DOS window with the
results and then immediately close! How can I pause the screen?
Zach
Dr Malcolm McLean
The best one is to dig into the gubbins of your compiler and find how
to switch this behaviour off. I think there's a way but I've
forogotten it.
Another way is to put a
while(1); (note semicolon) at the end of your main(). This will hange
the program until you kill it with a control-C.
Another way is to put in
#include <conio.h>
getch();
This is slightly nicer, and will wait for a keypress, but is non-
standard.
Bill Reid
<malcolm.mcle...@btinternet.com> wrote:
> On 28 Mar, 19:39, Zach <net...@gmail.com> wrote:
>
> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
> > Microsoft Visual Studio 8 Express it will flash a DOS window with the
> > results and then immediately close! How can I pause the screen?
>
> There are several options.
> The best one is to dig into the gubbins of your compiler and find how
> to switch this behaviour off.
>
>
> I think there's a way but I've
> forogotten it.
>
>
> Another way is to put a
> while(1); (note semicolon) at the end of your main(). This will hange
> the program until you kill it with a control-C.
>
>
> Another way is to put in
> #include <conio.h>
> getch();
>
> This is slightly nicer, and will wait for a keypress, but is non-
> standard.
>
use a standard function call for getting command-line
input to "pause" the program until RETURN is pressed
(guess which function we can use?)...
However, the real issue is that under Windows(TM),
the program is run as a "console" program, which
causes a "console" to be created automatically for
program input/output, and then the "console"
disappears when it is no longer needed at the
exit of the program.
But guess what, you can run the program from a
MS-DOS window that you bring up by running the
"command prompt" program or whatever Microslop
is calling it these days. In that case, the
MS-DOS window will not disappear when the program
completes.
So there's the correct answer (both of them)...
---
William Ernest Reid
Keith Thompson
> On 28 Mar, 19:39, Zach <net...@gmail.com> wrote:
>> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
>> Microsoft Visual Studio 8 Express it will flash a DOS window with the
>> results and then immediately close! How can I pause the screen?
>>
> There are several options.
> The best one is to dig into the gubbins of your compiler and find how
> to switch this behaviour off. I think there's a way but I've
> forogotten it.
There's likely to be an option in the IDE (not in the compiler) to
keep the DOS window open after the program terminates, or perhaps
to direct the program's output to a window within the IDE itself.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Branimir Maksimovic
Bill Reid
> Dr Malcolm McLean <malcolm.mcle...@btinternet.com> writes:> On 28 Mar, 19:39, Zach <net...@gmail.com> wrote:
>
> >> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
> >> Microsoft Visual Studio 8 Express it will flash a DOS window with the
> >> results and then immediately close! How can I pause the screen?
>
> > There are several options.
> > The best one is to dig into the gubbins of your compiler and find how
> > to switch this behaviour off. I think there's a way but I've
> > forogotten it.
>
> [...]
>
> There's likely to be an option in the IDE (not in the compiler) to
> keep the DOS window open after the program terminates, or perhaps
> to direct the program's output to a window within the IDE itself.
>
Unless MICROSOFT provides such an option for their
"CONSOLE" (which, to the very best of my knowledge,
they DON'T), no IDE/compiler/whatever can change the
behavior...
This is equivalent to writing a Windows(TM) app
and asking if you can make the window oval instead
of rectangular, then people "advising" that the
IDE/compiler will "probably" have an option to do
that...
---
William Ernest Reid
Ian Collins
Avoid windows?
--
Ian Collins
pete
Open a dos window first,
and change directory to where the executable file is located,
and then run the program from there.
C:\Documents and Settings\pete>cd\Program
Files\DevStudio\SharedIDE\bin\debug
C:\Program Files\DevStudio\SharedIDE\bin\Debug>
--
pete
Richard Heathfield
If you're running in debug mode, simply set a breakpoint on main's
return statement. If you're wise enough to follow the one-entry one-exit
rule every time (i.e. don't have any exit() calls), this will work every
time - except in the case of an assertion, but that's okay because if
you get an assertion failure the IDE is already pretty good at getting
you the information you need.
If you're running in release mode, VStudio already retains the console
window until you press a key, so you don't get the problem in the first
place.
If you're running from the console, you still don't get the problem in
the first place.
Given the above options, putting a "press me to quit" into your program
is simply daft, so don't do it. If you *do* do it, you'll regret it when
you release your code - either you'll take it out, in which case you'll
be forever putting it in and taking it out whenever you have to maintain
the code, or you'll leave it in, in which case your users will curse
your name every time they try to use your program as a filter.
"Interactive" is just another word for "manual". Don't give the user
extra work.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Peter Nilsson
> Dr Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
> > Zach <net...@gmail.com> wrote:
> > > When I compile a C program in Dev-C++ (www.bloodshed.net)
> > > or in Microsoft Visual Studio 8 Express it will flash a
> > > DOS window with the results and then immediately close!
> > > How can I pause the screen?
> > Another way is to put in
> > #include <conio.h>
> > getch();
> >
> > This is slightly nicer, and will wait for a keypress,
> > but is non-standard.
>
> Another dumb one...but on a better track, you can
> use a standard function call for getting command-line
> input to "pause" the program until RETURN is pressed
> (guess which function we can use?)...
The problem with this is that many student programs use
scanf and there's often a trailing newline from the last
input that gets swallowed by a getchar. And so the program
disappears in a flash, just as before... [This is probably
a source of many 'how do I flush stdin?' questions.]
--
Peter
Richard Heathfield
In other words, "I'm doing something stupid, and I'm doing it in a
particularly stupid way. As a result, I need to do something else that's
even more stupid. Please help."
For some reason, though, such people don't normally appreciate the help
they get. Probably because it's insufficiently stupid.
Bill Reid
More "contributions" from the brain trust that is comp.lang.c:
On Mar 28, 2:38 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> Zach wrote:
>
> > When I compile a C program in Dev-C++ (www.bloodshed.net) or in
> > Microsoft Visual Studio 8 Express it will flash a DOS window with the
> > results and then immediately close! How can I pause the screen?
>
> If you're running in debug mode, simply set a breakpoint on main's
> return statement.
Hmmmm, probably will work as advertised, I'll give that one...
>
> If you're running in release mode, VStudio already retains the console
> window until you press a key, so you don't get the problem in the first
> place.
>
Too bad the original message said he was using "Visual Studio 8
Express" so it appears you don't know how it works but that didn't
stop you from posting...
> If you're running from the console, you still don't get the problem in
> the first place.
>
Here is everything you didn't want to know or are too
technically incompetent to understand about Windows "consoles":
http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
If you drill down you'll find that there is very clear
rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
LAUNCHED THE CONSOLE EXITS.
You are thinking of a separate program called the
"MS-DOS Command Prompt" or sumpin' that causes Windows
to create a console for IT, and any program you run in
it uses THAT program's console, so the console only
terminates when THAT program exits.
> Given the above options, putting a "press me to quit" into your program
> is simply daft, so don't do it.
No, not necessarily, since you don't know how the program
will be launched or exited, but you know (well, not you,
apparently) that you will get a warning from some versions
of Windows about trying to exit the program using the CONSOLE
exit control (something about "it is recommended that this
program be terminated from within the program and not from
the console").
> If you *do* do it, you'll regret it when
> you release your code - either you'll take it out, in which case you'll
> be forever putting it in and taking it out whenever you have to maintain
> the code, or you'll leave it in, in which case your users will curse
> your name every time they try to use your program as a filter.
>
> "Interactive" is just another word for "manual". Don't give the user
> extra work.
>
Since some versions of Windows will give them a confusing
warning if they launch the program anywhere but from the
command line, you might want to take THAT into consideration...
---
William Ernest Reid
Bill Reid
similar as we "guess" which function to use...
---
William Ernest Reid
Ian Collins
>
> Since some versions of Windows will give them a confusing
> warning if they launch the program anywhere but from the
> command line, you might want to take THAT into consideration...
Another reason to avid windows.
--
Ian Collins
123Jim
"Zach" <net...@gmail.com> wrote in message
news:9ef1c7e1-f2a2-4188...@15g2000yqi.googlegroups.com...
Assuming windows? ...
#include <stdio.h>
int main()
{
/* some program code*/
system("pause");
return 0;
}
Richard Heathfield
> More "contributions" from the brain trust that is comp.lang.c:
>
> On Mar 28, 2:38 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Zach wrote:
>>
>>> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
>>> Microsoft Visual Studio 8 Express it will flash a DOS window with the
>>> results and then immediately close! How can I pause the screen?
>> If you're running in debug mode, simply set a breakpoint on main's
>> return statement.
>
> Hmmmm, probably will work as advertised, I'll give that one...
>> If you're running in release mode, VStudio already retains the console
>> window until you press a key, so you don't get the problem in the first
>> place.
>>
> Too bad the original message said he was using "Visual Studio 8
> Express" so it appears you don't know how it works but that didn't
> stop you from posting...
Use the Debug menu, and click "Start without debugging". That's been a
feature of VS since forever, and it was retained in VSE.
It appears you don't know how to do that, but that didn't stop you from
posting.
>> If you're running from the console, you still don't get the problem in
>> the first place.
>>
> Here is everything you didn't want to know or are too
> technically incompetent to understand about Windows "consoles":
>
> http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
>
> If you drill down you'll find that there is very clear
> rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
> LAUNCHED THE CONSOLE EXITS.
If you read my post again, you'll find that there is very clear text to
the effect that "If you're running from the console", suggesting to all
but the densest amongst us that you start a console and then run your
program from within that console.
> You are thinking of a separate program called the
> "MS-DOS Command Prompt"
No, I'm thinking of the right answer. You, on the other hand, are not
thinking. I suggest you start.
<nonsense snipped>
Richard Heathfield
> On 03/29/10 12:55 PM, Bill Reid wrote:
>>
>> Since some versions of Windows will give them a confusing
>> warning if they launch the program anywhere but from the
>> command line, you might want to take THAT into consideration...
>
[IFYPFY]
No, it's another reason to avoid taking advice from people who shoot
their mouths off without thinking clearly about the issues.
Dr Malcolm McLean
>
> Here is everything you didn't want to know or are too
> technically incompetent to understand about Windows "consoles":
>
with all the details of Windows consoles. Essentially the system has
been hacked and hacked to retain backwards compatibility whilst
presenting what looks like a slick interface to the user, and no-one
with any sense would delve into its full horrors, unless they had to.
That doesn't mean these people are technically incompetent, or
incapable of doing this given sufficient motivation.
Zach
> Zach wrote:
> > When I compile a C program in Dev-C++ (www.bloodshed.net) or in
> > Microsoft Visual Studio 8 Express it will flash a DOS window with the
> > results and then immediately close! How can I pause the screen?
>
> If you're running in debug mode, simply set a breakpoint on main's
> return statement. If you're wise enough to follow the one-entry one-exit
> rule every time (i.e. don't have any exit() calls), this will work every
> time - except in the case of an assertion, but that's okay because if
> you get an assertion failure the IDE is already pretty good at getting
> you the information you need.
>
> If you're running in release mode, VStudio already retains the console
> window until you press a key, so you don't get the problem in the first
> place.
>
> If you're running from the console, you still don't get the problem in
> the first place.
>
> Given the above options, putting a "press me to quit" into your program
> is simply daft, so don't do it. If you *do* do it, you'll regret it when
> you release your code - either you'll take it out, in which case you'll
> be forever putting it in and taking it out whenever you have to maintain
> the code, or you'll leave it in, in which case your users will curse
> your name every time they try to use your program as a filter.
>
> "Interactive" is just another word for "manual". Don't give the user
> extra work.
Thanks Richard and everyone who helped me with this problem.
Zach
Bill Reid
> Bill Reid wrote:
> > More "contributions" from the brain trust that is comp.lang.c:
> > On Mar 28, 2:38 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> Zach wrote:
>
> >>> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
> >>> Microsoft Visual Studio 8 Express it will flash a DOS window with the
> >>> results and then immediately close! How can I pause the screen?
> >> If you're running in debug mode, simply set a breakpoint on main's
> >> return statement.
>
> > Hmmmm, probably will work as advertised, I'll give that one...
>
> >> If you're running in release mode, VStudio already retains the console
> >> window until you press a key, so you don't get the problem in the first
> >> place.
>
> > Too bad the original message said he was using "Visual Studio 8
> > Express" so it appears you don't know how it works but that didn't
> > stop you from posting...
>
> Use the Debug menu, and click "Start without debugging". That's been a
> feature of VS since forever, and it was retained in VSE.
>
> It appears you don't know how to do that, but that didn't stop you from
> posting.
>
mode" works the way you describe, since it wouldn't be a true
representation of how the code would actually work in real
life. In "real life" (Microslop "reality"), launching a
console application in any way other than from the "MS-DOS
Prompt" "console" causes Windows to create a console for
the application, and the console terminates when the
application exits (which makes a kind of twisted sense,
since why would you need a console solely for a single
program's input/output, then leave it there doing nothing
when the program exits?).
> >> If you're running from the console, you still don't get the problem in
> >> the first place.
>
> > Here is everything you didn't want to know or are too
> > technically incompetent to understand about Windows "consoles":
>
> >http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
>
> > If you drill down you'll find that there is very clear
> > rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
> > LAUNCHED THE CONSOLE EXITS.
>
> If you read my post again, you'll find that there is very clear text to
> the effect that "If you're running from the console", suggesting to all
> but the densest amongst us that you start a console and then run your
> program from within that console.
>
> > You are thinking of a separate program called the
> > "MS-DOS Command Prompt"
>
> No, I'm thinking of the right answer.
>
Nope, you're an idiot who doesn't know what he's talking
about. You keep slinging terms around like "console" without
knowing what they are, even after I provided a link to clear
documentation in plain English describing them...please
tell the entire class how you "start a console" OTHER
than starting the "MS-DOS Command Prompt" as I described
(hint: it's fully described in the documentation I provided
but absolutely doesn't solve the "problem")...
> You, on the other hand, are not
> thinking. I suggest you start.
>
> <nonsense snipped>
>
You know, just snipping out the truth doesn't make
it go away, any more than burning a book deletes the
information it provided from the minds of the people
who read it...
---
William Ernest Reid
Bill Reid
wrote:
> On 29 Mar, 00:55, Bill Reid <hormelf...@gmail.com> wrote:
>
> > Here is everything you didn't want to know or are too
> > technically incompetent to understand about Windows "consoles":
>
> Not all programmers, even those who use Windows, bother themselves
> with all the details of Windows consoles.
Well, in Microslop "reality", you either use WINDOWS, or
you use "MS-DOS"...
> Essentially the system has
> been hacked and hacked to retain backwards compatibility whilst
> presenting what looks like a slick interface to the user, and no-one
> with any sense would delve into its full horrors, unless they had to.
It's actually better now than it was...for a long time
"consoles" didn't work "as advertised", creating a strange
little market for "scrollable consoles", and they still
don't work exactly like you would think they should...
> That doesn't mean these people are technically incompetent, or
> incapable of doing this given sufficient motivation.
Look, Microslop wants you to develop any and all applications
using the Windows API, and punishes you in every way possible
if you persist in writing simple "character mode" applications.
The mistake is not recognizing this and pretending the problems
don't exist, and talking out of school if you haven't actually
dealt with the problems...
---
William Ernest Reid
jacob navia
> In "real life" (Microslop "reality"),
The name of the company is Microsoft.
>
>>>> If you're running from the console, you still don't get the problem in
>>>> the first place.
>>> Here is everything you didn't want to know or are too
>>> technically incompetent to understand about Windows "consoles":
>>> http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
>>> If you drill down you'll find that there is very clear
>>> rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
>>> LAUNCHED THE CONSOLE EXITS.
>> If you read my post again, you'll find that there is very clear text to
>> the effect that "If you're running from the console", suggesting to all
>> but the densest amongst us that you start a console and then run your
>> program from within that console.
>>
>>> You are thinking of a separate program called the
>>> "MS-DOS Command Prompt"
>> No, I'm thinking of the right answer.
>>
> Nope, you're an idiot who doesn't know what he's talking
> about.
One of the characteristics of the people that write things like
"Microslop" above, is that anyone that disagrees is an idiot, a
Microsoft slave, or whatever. Only THEY have the truth. All others
are stupids.
> You keep slinging terms around like "console" without
> knowing what they are, even after I provided a link to clear
> documentation in plain English describing them...please
> tell the entire class how you "start a console" OTHER
> than starting the "MS-DOS Command Prompt" as I described
There is no "MS-DOS command prompt" since windows-95 -and
windows98- are no longer supported since several years.
Maybe it is YOU that do not know what you are talking about?
Other ways to open a console are:
(1) system("cmd");
(2) AllocConsole()
(3) AttachConsole()
Conclusion:
Do not throw insults around.
This is valid in many circumstances other than in this
forum.
jacob navia
> On Mar 29, 3:02 am, Dr Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>> On 29 Mar, 00:55, Bill Reid <hormelf...@gmail.com> wrote:
>>
>>> Here is everything you didn't want to know or are too
>>> technically incompetent to understand about Windows "consoles":
>> Not all programmers, even those who use Windows, bother themselves
>> with all the details of Windows consoles.
>
> Well, in Microslop "reality", you either use WINDOWS, or
> you use "MS-DOS"...
>
You are completely wrong. There is no MSDOS since windows-95
and windows 98 disappeared. The command interpreter was renamed from
"command.com" to "cmd.exe" because the interpreter was rewritten in 32
bits and it is a full 32 bits application.
It is also completely wrong to say that you can't use windows or
the windows API from a console application. All console applications
have FULL access to the windows API and can open windows, close them,
use menus, etc.
>> Essentially the system has
>> been hacked and hacked to retain backwards compatibility whilst
>> presenting what looks like a slick interface to the user, and no-one
>> with any sense would delve into its full horrors, unless they had to.
>
It is, in any case, a widely used system. You can say that retaining
backwards compatibility is a stupid thing to do, it is your opinion.
I disagree. One of the reasons that I do not use Linux GUIs is that
you have to rewrite your program every 2-3 years. The new version of GTK
for instances, forces an application rewrite because the old programs do
not work anymore. Linux people like that, they rewrite and rewrite their
programs. I do not like that, that was the end of my attempt to use
Linux for an IDE.
> It's actually better now than it was...for a long time
> "consoles" didn't work "as advertised", creating a strange
> little market for "scrollable consoles",
That was under windows 3.1. Released around 19 years ago... Your
bad faith is evident. At that time Linux wasn't even invented.
What would you say if I would say that linux console were worst
thah windows ones? There weren't even INVENTED then.
> and they still
> don't work exactly like you would think they should...
>
They work perfectly well. Of course they aren't linux.
>> That doesn't mean these people are technically incompetent, or
>> incapable of doing this given sufficient motivation.
>
> Look, Microslop wants you to develop any and all applications
> using the Windows API, and punishes you in every way possible
> if you persist in writing simple "character mode" applications.
Sure.
That is why the "evil empire" has developed a full fledged console API
that allows you to read/write from the console buffer like under
"curses", using colors, blinking, and many other character attributes.
I will NOT say that you are lying since heathfield will start
complaining...
> The mistake is not recognizing this and pretending the problems
> don't exist, and talking out of school if you haven't actually
> dealt with the problems...
>
ANY program can have "problems". Can you specify?
Bill Reid
> Bill Reid a écrit :
>
> > In "real life" (Microslop "reality"),
>
> The name of the company is Microsoft.
>
masquerading as "software"...
> >>>> If you're running from the console, you still don't get the problem in
> >>>> the first place.
> >>> Here is everything you didn't want to know or are too
> >>> technically incompetent to understand about Windows "consoles":
> >>>http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
> >>> If you drill down you'll find that there is very clear
> >>> rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
> >>> LAUNCHED THE CONSOLE EXITS.
> >> If you read my post again, you'll find that there is very clear text to
> >> the effect that "If you're running from the console", suggesting to all
> >> but the densest amongst us that you start a console and then run your
> >> program from within that console.
>
> >>> You are thinking of a separate program called the
> >>> "MS-DOS Command Prompt"
> >> No, I'm thinking of the right answer.
>
> > Nope, you're an idiot who doesn't know what he's talking
> > about.
>
> One of the characteristics of the people that write things like
> "Microslop" above, is that anyone that disagrees is an idiot, a
> Microsoft slave, or whatever. Only THEY have the truth. All others
> are stupids.
>
Actually, that's the attitude of Microslop engineers...I
was having no end of problems using one of their applications,
so in a desperate Google(TM) to find solutions, I came
across the "blog" of the lead engineer for the program.
In short, he blamed the users for being stupid as to
how they used the program, and then went on with a big
sob story about how freakin' difficult it was to draw
bitmaps under Windows and that's why his software was
so crappy and they had so much other stuff to do yadda
yadda yadda...standard bad engineer crybaby wailings...
Problem is, the software he couldn't write properly
has been written dozens of times by other programmers,
and it works flawlessly like magic, for example, in the
little box sitting on my shelf to my right made in
Bulgaria that I paid $11 for, or the little USB plug-in
I paid $35 for (well, that's the price of the software
I actually use and the related hardware).
So don't you think it's fair to criticize somebody
for miserably failing to do something that others can
do in their sleep? I'd agree with your rant about
calling people "stupid" if I couldn't point to a
whole bunch of people who are demonstrably smarter...it's
all RELATIVE, innit?
> > You keep slinging terms around like "console" without
> > knowing what they are, even after I provided a link to clear
> > documentation in plain English describing them...please
> > tell the entire class how you "start a console" OTHER
> > than starting the "MS-DOS Command Prompt" as I described
>
> There is no "MS-DOS command prompt" since windows-95 -and
> windows98- are no longer supported since several years.
I originally stated that they've changed the name of
the "Command Prompt" over the years...a wilted rose by
any other name, eh?
> Maybe it is YOU that do not know what you are talking about?
>
Nope. Learn to read.
> Other ways to open a console are:
>
> (1) system("cmd");
> (2) AllocConsole()
> (3) AttachConsole()
>
Well, good for you, but then what? What's your
point?
> Conclusion:
> Do not throw insults around.
>
OK, everybody else in the world first...
> This is valid in many circumstances other than in this
> forum.
>
Yes, the world would be a better place if unwarranted
derogatory remarks did not occur, that's why I always
get irked when some bad programmer blames his bad
programming on "user error"...
Oh, just to stir another pot a little, that bad
programmer who works for Microslop is, as you could
probably presume, the most academically qualified
engineer in the friggin' world, with like multiple
Masters in Engineering from MIT and what not, like
virtually all Microslop engineers, and you'd better
believe if he was backed into a corner over his
blatant incompetence, he'd pull out his academic
"accomplishments" as his final secret weapon to
thwart legitimate criticism of his "work", just
like "spin-nosey"...
---
William Ernest Reid
Bill Reid
>> wrote:
>>> On 29 Mar, 00:55, Bill Reid <hormelf...@gmail.com> wrote:
>>>> Here is everything you didn't want to know or are too
>>>> technically incompetent to understand about Windows "consoles":
>>> Not all programmers, even those who use Windows, bother themselves
>>> with all the details of Windows consoles.
>> Well, in Microslop "reality", you either use WINDOWS, or
>> you use "MS-DOS"...
> You are completely wrong. There is no MSDOS since windows-95
> and windows 98 disappeared.
Sheesh, maybe that's why I put "MS-DOS" in SARCASTIC
quote marks, ya think? Several people in this thread
have used the term "DOS" or similar, including the
original poster, and I've said several times that
Microslop has "renamed" their...their...well, their
"thing" that is supposed to let you run old and new
"character mode" applications and use the old DOS
commands for directory browsing and suchlike, but
thank you for your significant contribution for pouncing
on that non-issue...
> The command interpreter was renamed from
> "command.com" to "cmd.exe" because the interpreter was rewritten in 32
> bits and it is a full 32 bits application.
Terrific, who cares...I think they were still using
the term "MS-DOS" 10 years ago even though you could
run "win32" apps in the "thing"...
> It is also completely wrong to say that you can't use windows or
> the windows API from a console application. All console applications
> have FULL access to the windows API and can open windows, close them,
> use menus, etc.
Careful there, Eugene, you're getting a little crazy and
overstating the case...although it's true that you can perform
some Windows actions directly from a console app, bottom
line is that Windows and console applications have two
distinctly different entry and exits from the operating
system...frankly, as somebody who has actually fooled
around working with Windows "controls" (or whatever they're
calling them this week) in a console app, I am perhaps
most bemused by the creation of the console itself
when it runs...
>>> Essentially the system has
>>> been hacked and hacked to retain backwards compatibility whilst
>>> presenting what looks like a slick interface to the user, and no-one
>>> with any sense would delve into its full horrors, unless they had to.
> It is, in any case, a widely used system. You can say that retaining
> backwards compatibility is a stupid thing to do, it is your opinion.
Maybe the best and truest thing to say is Microslop
implemented their backwards compatibility in that regard
in a kind of stupid way...but I'm betting you don't
agree with that...
> I disagree.
I win my bet!!!
> One of the reasons that I do not use Linux GUIs is that
> you have to rewrite your program every 2-3 years. The new version of GTK
> for instances, forces an application rewrite because the old programs do
> not work anymore. Linux people like that, they rewrite and rewrite their
> programs. I do not like that, that was the end of my attempt to use
> Linux for an IDE.
Well, by choosing Linux as your example you are obviously
just trying to make Windows look good by comparing it to
something even stupider...
Look, my particular frame of reference for Windows "consoles"
is coming from a Unix (NOT Linux!!!) environment. It is
particularly pertinent if you think about where Microsoft
(and Apple, for that matter) was coming from and where they
THOUGHT they were going to compared to where Unix was already
at.
Unix was already a multi-user, multi-process, client-server
type of operating system; Apple and Microsoft were just trying
to "pretty up" their SINGLE-user interface.
So when the folks at MIT came up with "X" (NOT "X Windows",
God forbid!), they came up with the concept of an "xterm",
a "window" that offered the same functionality as character-based
terminals. In a multi-user networked system environment, this
made perfect sense, and offered perfect "backwards compatibility"
for character-based applications as well. IT OPERATED
EXACTLY AS YOU WOULD EXPECT.
Now Microslop, with their concept of a "console", well,
not so much...but perhaps some of the probem was "benign
neglect", since they couldn't comprehend why people
wouldn't want to use their "new" Windows interface for
their single-user systems...
>> It's actually better now than it was...for a long time
>> "consoles" didn't work "as advertised", creating a strange
>> little market for "scrollable consoles",
> That was under windows 3.1. Released around 19 years ago...
WRONG!!! The problems were still in Windows 98 (but
oddly, not in Windows NT, perhaps again because of the
relationship between a networked environment and the
"console") as little as 10 years ago...
> Your bad faith is evident.
No, your's is, by adding at least 9 years to the time
that it you claim since Microslop had "fixed" their
"consoles"...
> At that time Linux wasn't even invented.
> What would you say if I would say that linux console were worst
> thah windows ones? There weren't even INVENTED then.
You're really gonna beat this "Linux" thing to death,
aren't you? Again, "xterms" existed for the Unix world
20 years ago, GAME OVER SPORT!!!
>> and they still
>> don't work exactly like you would think they should...
> They work perfectly well.
Nope, because they don't work like an "xterm".
At their best, Microslop "consoles" is dumb. Bring
up a "console" (generally a "command prompt"), and
you are offered a scroll control to allow you to scroll
DOWN through the "screen buffer", EVEN THOUGH THERE'S
NOTHING THERE, BECAUSE NOTHING'S BEEN WRITTEN THERE
YET!!!!
Now THAT'S dumb!!! And that's not the only thing
that is dumb about them...
> Of course they aren't linux.
Well, of course...again with the praising "dumb"
by bringing up "dumber"...
>>> That doesn't mean these people are technically incompetent, or
>>> incapable of doing this given sufficient motivation.
>> Look, Microslop wants you to develop any and all applications
>> using the Windows API, and punishes you in every way possible
>> if you persist in writing simple "character mode" applications.
> Sure.
>
> That is why the "evil empire" has developed a full fledged console API
> that allows you to read/write from the console buffer like under
> "curses", using colors, blinking, and many other character attributes.
You are wildly overstating the concept of a "full fledged
API", particularly given the fact that many of the functions
in that API were broken for most of their purported
lifetime...remember, I said there was actually a market
for Windows "consoles" that ACTUALLY WORKED PROPERLY
for years and years and years...hell, for MY Windows
applications I actually implemented most of the missing/not dumb
functionality in scrollable "memo" Windows "controls" so
I could printf() stuff from PORTABLE C programs to a
Windows window and have it behave like an "xterm",
giving me a nice separation between program and interface
for portability and a better user experience than the
dumb "console" Windows provides...if an idiot like me
can do that using the high-level Windows API calls,
why couldn't the idiots at Microslop do the same (hint:
they could, look at Notepad and others)?
> I will NOT say that you are lying since heathfield will start
> complaining...
As long as he doesn't sue, don't worry about it...
>> The mistake is not recognizing this and pretending the problems
>> don't exist, and talking out of school if you haven't actually
>> dealt with the problems...
> ANY program can have "problems". Can you specify?
Criminy, read the original post in the thread, THAT IS
A PROBLEM, BECAUSE A WINDOWS "CONSOLE" DOESN'T OPERATE
THE WAY A REASONABLE PERSON THINKS IT SHOULD.
I've already specified any number of other "problems"
with "consoles" in this post, including a completely-broken
"console" API for years that for some odd reason you
seem to think is the bee's knees...
Look, as you may have noticed, I AM officially
fed up with Microsoft...I used to defend them,
on issues where it was clear that other losers
were unfairly attacking them (such as some people's
idiotic inability to use the Windows API and
illogically calling that a "monopolistic practice"),
but after Vista came out, and then Microsoft itself
admitting that Vista was just a big bug-ridden
mistake to try to get people to buy Windows 7,
it's clear these people are just total chowder-heads
technically (and legally!) and not worth any
respect...
---
William Ernest Reid
Kenneth Brody
>
> More "contributions" from the brain trust that is comp.lang.c:
>
> On Mar 28, 2:38 pm, Richard Heathfield<r...@see.sig.invalid> wrote:
>> Zach wrote:
>>
>>> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
>>> Microsoft Visual Studio 8 Express it will flash a DOS window with the
>>> results and then immediately close! How can I pause the screen?
>> > If you're running from the console, you still don't get the problem in
>> > the first place.
>> >
> Here is everything you didn't want to know or are too
> technically incompetent to understand about Windows "consoles":
>
> http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
>
> If you drill down you'll find that there is very clear
> rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
> LAUNCHED THE CONSOLE EXITS.
Too bad that the program he's running didn't create the console, meaning
that the above statement is irrelevant.
The statement "if you're running from the console" means "open a console
window [typically by running cmd.exe] and run your program within it".
Since cmd.exe, which created the console, is still running, the console
window is still there.
> You are thinking of a separate program called the
> "MS-DOS Command Prompt" or sumpin' that causes Windows
> to create a console for IT, and any program you run in
> it uses THAT program's console, so the console only
> terminates when THAT program exits.
And, BTW, it's not "MS-DOS" any more. The console hasn't been MS-DOS since
Win9x (95, 98, Me) days. The NT-based systems (NT, XP, 2000, Vista, Win7,
etc.) don't have MS-DOS. (They do have MS-DOS emulators, however. But the
console that you get by running cmd.exe is a true Windows application.)
[...]
--
Kenneth Brody
Kenneth Brody
[...]
>> There's likely to be an option in the IDE (not in the compiler) to
>> keep the DOS window open after the program terminates, or perhaps
>> to direct the program's output to a window within the IDE itself.
>>
> Hmmmm, kind of like the dumb leading the dumber...
>
> Unless MICROSOFT provides such an option for their
> "CONSOLE" (which, to the very best of my knowledge,
> they DON'T), no IDE/compiler/whatever can change the
> behavior...
Then how do you explain the fact that when I run a program in Visual Studio
2005 and 2008 in non-debug mode, and I get "Press any key to continue . . ."
displayed in the console window? (Same thing for VS6, as I recall.)
Although it's not an available option (AFAIK) in VS2005 and 2008, there's
nothing stopping the IDE from doing the same thing when debugging the program.
> This is equivalent to writing a Windows(TM) app
> and asking if you can make the window oval instead
> of rectangular, then people "advising" that the
> IDE/compiler will "probably" have an option to do
> that...
Not quite. The IDE giveth the console window, and the IDE taketh it away.
--
Kenneth Brody
Kenneth Brody
> On Mar 28, 6:55 pm, Richard Heathfield<r...@see.sig.invalid> wrote:
>> Bill Reid wrote:
>>>> If you're running in release mode, VStudio already retains the console
>>>> window until you press a key, so you don't get the problem in the first
>>>> place.
>>
>>> Too bad the original message said he was using "Visual Studio 8
>>> Express" so it appears you don't know how it works but that didn't
>>> stop you from posting...
>>
>> Use the Debug menu, and click "Start without debugging". That's been a
>> feature of VS since forever, and it was retained in VSE.
>>
>> It appears you don't know how to do that, but that didn't stop you from
>> posting.
>>
> I don't use that IDE, but I'm skeptical that the "release
> mode" works the way you describe,
BTW, "start without debugging" is not the same as compiling for "release mode".
And be as skeptical as you wish, but I'm sitting in front of a system with
VS2005 and VS2008 (plus a VS2010 beta), and they all work as described by
Mr. Heathfield.
========== hello.c
#include <stdio.h>
int main(void)
{
printf("Hello, world.\n");
return 0;
}
========== Contents of console window when run as described
Hello, world.
Press any key to continue . . .
==========
(Sorry, but you'll just have to take my word on this.)
> since it wouldn't be a true
> representation of how the code would actually work in real
> life. In "real life" (Microslop "reality"), launching a
> console application in any way other than from the "MS-DOS
No MS-DOS here.
> Prompt" "console" causes Windows to create a console for
> the application, and the console terminates when the
> application exits (which makes a kind of twisted sense,
> since why would you need a console solely for a single
> program's input/output, then leave it there doing nothing
> when the program exits?).
And who says it works that way? Yes, it probably does work that way if you
run the program by double-clicking its icon in Windows Explorer, though not
necessarily. And the IDE may start the program in a completely different
manner.
And, BTW, Windows (used to?) have an option for "close window on exit" for
MS-DOS applications. Unchecking that box would leave the window open once
the program exited.
[...]
--
Kenneth Brody
Kenneth Brody
> On Mar 29, 3:02 am, Dr Malcolm McLean<malcolm.mcle...@btinternet.com>
> wrote:
>> On 29 Mar, 00:55, Bill Reid<hormelf...@gmail.com> wrote:
>>
>>> Here is everything you didn't want to know or are too
>>> technically incompetent to understand about Windows "consoles":
>>
>> Not all programmers, even those who use Windows, bother themselves
>> with all the details of Windows consoles.
>
> Well, in Microslop "reality", you either use WINDOWS, or
> you use "MS-DOS"...
Perhaps, but given that, as far as Microsoft is concerned, MS-DOS hasn't
existed since Windows Me. (Though they do include an MS-DOS emulator,
unrelated to the Windows command prompt.)
[...]
> Look, Microslop wants you to develop any and all applications
> using the Windows API, and punishes you in every way possible
> if you persist in writing simple "character mode" applications.
> The mistake is not recognizing this and pretending the problems
> don't exist, and talking out of school if you haven't actually
> dealt with the problems...
The only thing my console application "can't" do is GUI stuff. And that's
only because I don't use the Windows API call to create a GUI window.
There's nothing in Windows that prevents a console app from creating GUI
windows, and vice versa.
--
Kenneth Brody
Kenneth Brody
> Bill Reid a écrit :
>> Well, in Microslop "reality", you either use WINDOWS, or
>> you use "MS-DOS"...
>
> You are completely wrong. There is no MSDOS since windows-95
> and windows 98 disappeared. The command interpreter was renamed from
> "command.com" to "cmd.exe" because the interpreter was rewritten in 32
> bits and it is a full 32 bits application.
NB: My 64-bit Windows 7 system has a 64-bit cmd.exe executable. (In a
previous reply to Mr. Reid, I was going to say that cmd.exe was a "true
32-bit Windows app", until I double-checked, causing me to reword it as a
"true Windows app".)
:-)
[...]
>> It's actually better now than it was...for a long time
>> "consoles" didn't work "as advertised", creating a strange
>> little market for "scrollable consoles",
>
> That was under windows 3.1. Released around 19 years ago... Your
> bad faith is evident. At that time Linux wasn't even invented.
> What would you say if I would say that linux console were worst
> thah windows ones? There weren't even INVENTED then.
Hmm... I do have Linux distrib CDs from March 1995, which is pre-Win95.
They include Slackware 2.2, so I have to assume that Linux was around for a
while before then. (And I know I had earlier releases, since at some point
I had kernel 0.9something running.)
Clickity click, search search...
Linux was "announced" on 26-Aug-1991
http://groups.google.com/group/comp.os.minix/msg/b813d52cbc5a044b
And 0.99 was from December 1992:
ftp://ftp.kernel.org/pub/linux/kernel/Historic/v0.99/
So, just to finish picking that nit, Linux wasn't that far behind Windows 3.1.
[...]
--
Kenneth Brody
Kenneth Brody
> On Mar 30, 7:24 am, jacob navia<ja...@spamsink.net> wrote:
>> Bill Reid a écrit :
>>> Nope, you're an idiot who doesn't know what he's talking
>>> about.
>>
>> One of the characteristics of the people that write things like
>> "Microslop" above, is that anyone that disagrees is an idiot, a
>> Microsoft slave, or whatever. Only THEY have the truth. All others
>> are stupids.
>>
> Actually, that's the attitude of Microslop engineers...I
> was having no end of problems using one of their applications,
> so in a desperate Google(TM) to find solutions, I came
> across the "blog" of the lead engineer for the program.
>
> In short, he blamed the users for being stupid as to
> how they used the program, and then went on with a big
> sob story about how freakin' difficult it was to draw
> bitmaps under Windows and that's why his software was
> so crappy and they had so much other stuff to do yadda
> yadda yadda...standard bad engineer crybaby wailings...
URL, please.
[...]
>>> You keep slinging terms around like "console" without
>>> knowing what they are, even after I provided a link to clear
>>> documentation in plain English describing them...please
>>> tell the entire class how you "start a console" OTHER
>>> than starting the "MS-DOS Command Prompt" as I described
>>
>> There is no "MS-DOS command prompt" since windows-95 -and
>> windows98- are no longer supported since several years.
>
> I originally stated that they've changed the name of
> the "Command Prompt" over the years...a wilted rose by
> any other name, eh?
Do you call a Linux console windows an "MS-DOS command prompt"? If not, why
do you insist on calling a Windows console window an "MS-DOS command prompt"?
[...]
--
Kenneth Brody
Bill Reid
> On 3/28/2010 4:03 PM, Bill Reid wrote:
> [...]
>
> >> There's likely to be an option in the IDE (not in the compiler) to
> >> keep the DOS window open after the program terminates, or perhaps
> >> to direct the program's output to a window within the IDE itself.
>
> > Hmmmm, kind of like the dumb leading the dumber...
>
> > Unless MICROSOFT provides such an option for their
> > "CONSOLE" (which, to the very best of my knowledge,
> > they DON'T), no IDE/compiler/whatever can change the
> > behavior...
>
> Then how do you explain the fact that when I run a program in Visual Studio
> 2005 and 2008 in non-debug mode, and I get "Press any key to continue . . ."
> displayed in the console window? (Same thing for VS6, as I recall.)
>
> Although it's not an available option (AFAIK) in VS2005 and 2008, there's
> nothing stopping the IDE from doing the same thing when debugging the program.
>
special console for a "character mode" application,
that just raises the question: what happens when you
run the application outside of the IDE? Does it
behave the way you want, or the users think it
should?
> > This is equivalent to writing a Windows(TM) app
> > and asking if you can make the window oval instead
> > of rectangular, then people "advising" that the
> > IDE/compiler will "probably" have an option to do
> > that...
>
> Not quite. The IDE giveth the console window, and the IDE taketh it away.
>
Right. And if there is no IDE to giveth the console,
then the operating system will giveth it, and taketh
it away on program exit, even if there is some text
the programmer wanted the user to read and perhaps
study, copy, whatever...in those cases, the programmer
will want to implement his own user-controlled exit
routine. Simple enough, riiiiiight?
---
William Ernest Reid
Bill Reid
> On 3/30/2010 10:51 AM, Bill Reid wrote:
> > On Mar 30, 7:24 am, jacob navia<ja...@spamsink.net> wrote:
> >> Bill Reid a écrit :
> [...]
> >>> Nope, you're an idiot who doesn't know what he's talking
> >>> about.
>
> >> One of the characteristics of the people that write things like
> >> "Microslop" above, is that anyone that disagrees is an idiot, a
> >> Microsoft slave, or whatever. Only THEY have the truth. All others
> >> are stupids.
>
> > Actually, that's the attitude of Microslop engineers...I
> > was having no end of problems using one of their applications,
> > so in a desperate Google(TM) to find solutions, I came
> > across the "blog" of the lead engineer for the program.
>
> > In short, he blamed the users for being stupid as to
> > how they used the program, and then went on with a big
> > sob story about how freakin' difficult it was to draw
> > bitmaps under Windows and that's why his software was
> > so crappy and they had so much other stuff to do yadda
> > yadda yadda...standard bad engineer crybaby wailings...
>
> URL, please.
>
half-hearted attempt to find it via another Google(TM)
search on the topic but like Bill Cosby, "I've seen
enough of that..."
> [...]
>
> >>> You keep slinging terms around like "console" without
> >>> knowing what they are, even after I provided a link to clear
> >>> documentation in plain English describing them...please
> >>> tell the entire class how you "start a console" OTHER
> >>> than starting the "MS-DOS Command Prompt" as I described
>
> >> There is no "MS-DOS command prompt" since windows-95 -and
> >> windows98- are no longer supported since several years.
>
> > I originally stated that they've changed the name of
> > the "Command Prompt" over the years...a wilted rose by
> > any other name, eh?
>
> Do you call a Linux console windows an "MS-DOS command prompt"?
I don't call it anything since I don't use Linux...
> If not, why
> do you insist on calling a Windows console window an "MS-DOS command prompt"?
>
Microslop calls it a "Command Prompt" these days, so sue
me (popular activity here) for including the "MS-DOS" which
I qualified in my first post that you did the troll-snippy
thing on...
---
William Ernest Reid
Bill Reid
solve the problem of people complaining about their
"console" by creating a false impression of how it
works...you know my IDE says something similar for
all "character mode" applications I write that take
or present any user input/output, because I specifically
code it into the application...
> > since it wouldn't be a true
> > representation of how the code would actually work in real
> > life. In "real life" (Microslop "reality"), launching a
> > console application in any way other than from the "MS-DOS
>
> No MS-DOS here.
>
GOOD CATCH!!!
> > Prompt" "console" causes Windows to create a console for
> > the application, and the console terminates when the
> > application exits (which makes a kind of twisted sense,
> > since why would you need a console solely for a single
> > program's input/output, then leave it there doing nothing
> > when the program exits?).
>
> And who says it works that way?
I provided a link to the console API documentation
on the Microsoft web-site, but of course it's all
technical and stuff...
> Yes, it probably does work that way if you
> run the program by double-clicking its icon in Windows Explorer,
GOOD CATCH!!!
> though not
> necessarily.
Ever see it work differently? Provide all relevant
details, please...
> And the IDE may start the program in a completely different
> manner.
>
Of course...in all that annoying technical info that
Microsoft supplies, they are very clear that ANY application
with ITS OWN CONSOLE may start a "character mode"
application, then THAT application uses the existing
console for its input/output streams.
> And, BTW, Windows (used to?) have an option for "close window on exit" for
> MS-DOS applications. Unchecking that box would leave the window open once
> the program exited.
>
You know, I vaguely remember something like that; I
may check for it on an old system if I remember to or
actually care...
---
William Ernest Reid
Bill Reid
> On 3/28/2010 7:55 PM, Bill Reid wrote:
>
> > More "contributions" from the brain trust that is comp.lang.c:
>
> > On Mar 28, 2:38 pm, Richard Heathfield<r...@see.sig.invalid> wrote:
> >> Zach wrote:
>
> >>> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
> >>> Microsoft Visual Studio 8 Express it will flash a DOS window with the
> >>> results and then immediately close! How can I pause the screen?
> [...]
> >> > If you're running from the console, you still don't get the problem in
> >> > the first place.
>
> > Here is everything you didn't want to know or are too
> > technically incompetent to understand about Windows "consoles":
>
> >http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
>
> > If you drill down you'll find that there is very clear
> > rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
> > LAUNCHED THE CONSOLE EXITS.
>
> Too bad that the program he's running didn't create the console, meaning
> that the above statement is irrelevant.
>
to just pop up a "command prompt" window when you click
on a "character mode" application in Explorer, then this
whole issue would be moot...
---
William Ernest Reid
Bill Reid
>
> > More "contributions" from the brain trust that is comp.lang.c:
>
> > On Mar 28, 2:38 pm, Richard Heathfield<r...@see.sig.invalid> wrote:
> >> Zach wrote:
>
> >>> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
> >>> Microsoft Visual Studio 8 Express it will flash a DOS window with the
> >>> results and then immediately close! How can I pause the screen?
> [...]
> >> > If you're running from the console, you still don't get the problem in
> >> > the first place.
>
> > Here is everything you didn't want to know or are too
> > technically incompetent to understand about Windows "consoles":
>
> >http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
>
> > If you drill down you'll find that there is very clear
> > rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
> > LAUNCHED THE CONSOLE EXITS.
>
> Too bad that the program he's running didn't create the console, meaning
> that the above statement is irrelevant.
>
> The statement "if you're running from the console" means "open a console
> window [typically by running cmd.exe] and run your program within it".
> Since cmd.exe, which created the console, is still running, the console
> window is still there.
>
is imprecise use of Microsoft terms, which you are perpetuating
by attempting further obfuscation.
As I've pointed out repeatedly, Microsoft calls what you
call a "console" or "console window" the COMMAND PROMPT.
A "console" is NOT the "command prompt", rather the
"command prompt" uses a "console" for input/output. I
give you special bonus troll points for using the term
"running cmd.exe" to expertly muddy up the discussion
of something that is relatively clear (well, it IS
Microsoft, so it's not THAT clear).
> > You are thinking of a separate program called the
> > "MS-DOS Command Prompt" or sumpin' that causes Windows
> > to create a console for IT, and any program you run in
> > it uses THAT program's console, so the console only
> > terminates when THAT program exits.
>
> And, BTW, it's not "MS-DOS" any more. The console hasn't been MS-DOS since
> Win9x (95, 98, Me) days. The NT-based systems (NT, XP, 2000, Vista, Win7,
> etc.) don't have MS-DOS. (They do have MS-DOS emulators, however. But the
> console that you get by running cmd.exe is a true Windows application.)
>
Boy, what a friggin' treat...I can emulate MS-DOS in
a TRUE WINDOWS APPLICATION!!!
---
William Ernest Reid
Bill Reid
> On 3/30/2010 10:38 AM, jacob navia wrote:
> > Bill Reid a écrit :
> [...]
> >> Well, in Microslop "reality", you either use WINDOWS, or
> >> you use "MS-DOS"...
>
> > You are completely wrong. There is no MSDOS since windows-95
> > and windows 98 disappeared. The command interpreter was renamed from
> > "command.com" to "cmd.exe" because the interpreter was rewritten in 32
> > bits and it is a full 32 bits application.
>
> NB: My 64-bit Windows 7 system has a 64-bit cmd.exe executable. (In a
> previous reply to Mr. Reid, I was going to say that cmd.exe was a "true
> 32-bit Windows app", until I double-checked, causing me to reword it as a
> "true Windows app".)
>
> :-)
>
PROGRAMS IN A 64-BIT WINDOWS APPLICATION!!!
---
William Ernest Reid
Bill Reid
> On 3/30/2010 10:10 AM, Bill Reid wrote:
>
> > Well, in Microslop "reality", you either use WINDOWS, or
> > you use "MS-DOS"...
>
> Perhaps, but given that, as far as Microsoft is concerned, MS-DOS hasn't
> existed since Windows Me. (Though they do include an MS-DOS emulator,
> unrelated to the Windows command prompt.)
>
> [...]
>
> > Look, Microslop wants you to develop any and all applications
> > using the Windows API, and punishes you in every way possible
> > if you persist in writing simple "character mode" applications.
> > The mistake is not recognizing this and pretending the problems
> > don't exist, and talking out of school if you haven't actually
> > dealt with the problems...
>
> The only thing my console application "can't" do is GUI stuff. And that's
> only because I don't use the Windows API call to create a GUI window.
> There's nothing in Windows that prevents a console app from creating GUI
> windows, and vice versa.
>
Well, I seem to remember all kinds of problems trying any
and all of that stuff from the Windows 98 and earlier era,
and it DID seem as if Microsoft was trying to forcibly
discourage development of anything other than GUI-based
applications...but one of my favorite sayings is "never
attribute to conspiracy that which can more easily be
explained by stupidity."
---
William Ernest Reid
Richard Heathfield
> On 3/30/2010 9:55 AM, Bill Reid wrote:
>> On Mar 28, 6:55 pm, Richard Heathfield<r...@see.sig.invalid> wrote:
>>> Bill Reid wrote:
[...]
>>>
>>>> Express" so it appears you don't know how it works but that didn't
>>>> stop you from posting...
>>>
>>> Use the Debug menu, and click "Start without debugging". That's been a
>>> feature of VS since forever, and it was retained in VSE.
>>>
>>> It appears you don't know how to do that, but that didn't stop you from
>>> posting.
>>>
>> I don't use that IDE, but I'm skeptical that the "release
>> mode" works the way you describe,
>
> BTW, "start without debugging" is not the same as compiling for "release
> mode".
>
> And be as skeptical as you wish, but I'm sitting in front of a system
> with VS2005 and VS2008 (plus a VS2010 beta), and they all work as
> described by Mr. Heathfield.
I don't think he's overly interested in facts. If he were, he would not
have posted his initial reply in the first place.
<snip>
Richard Heathfield
> Bill Reid a écrit :
> I will NOT say that you are lying since heathfield will start
> complaining...
You're probably right - I probably would. But not terribly loudly in
this particular case.
Kenneth Brody
> On Apr 2, 12:18 pm, Kenneth Brody<kenbr...@spamcop.net> wrote:
>> On 3/28/2010 4:03 PM, Bill Reid wrote:
[... console windows closing after running a console app from IDE ...]
>>> Unless MICROSOFT provides such an option for their
>>> "CONSOLE" (which, to the very best of my knowledge,
>>> they DON'T), no IDE/compiler/whatever can change the
>>> behavior...
>>
>> Then how do you explain the fact that when I run a program in Visual Studio
>> 2005 and 2008 in non-debug mode, and I get "Press any key to continue . . ."
>> displayed in the console window? (Same thing for VS6, as I recall.)
>>
>> Although it's not an available option (AFAIK) in VS2005 and 2008, there's
>> nothing stopping the IDE from doing the same thing when debugging the program.
>>
> Yes, it would be possible for any IDE to create a
> special console for a "character mode" application,
> that just raises the question: what happens when you
> run the application outside of the IDE? Does it
> behave the way you want, or the users think it
> should?
The program behaves exactly the same, regardless of whether the console
windows disappears or not after the program exits. That behavior is not part
of the program's behavior.
And who says that a "special console" is being created in this scenario?
There is absolutely nothing "special" about this console to make it
different from any other console.
>>> This is equivalent to writing a Windows(TM) app
>>> and asking if you can make the window oval instead
>>> of rectangular, then people "advising" that the
>>> IDE/compiler will "probably" have an option to do
>>> that...
>>
>> Not quite. The IDE giveth the console window, and the IDE taketh it away.
>>
> Right. And if there is no IDE to giveth the console,
> then the operating system will giveth it, and taketh
> it away on program exit, even if there is some text
> the programmer wanted the user to read and perhaps
> study, copy, whatever...in those cases, the programmer
> will want to implement his own user-controlled exit
> routine. Simple enough, riiiiiight?
So, you're saying that the programmer should write a special version of the
program which waits for the user to do something before exiting, so he can
see the output when run from the IDE, and then make a new executable for the
end-users to use?
Why not just have the IDE cause a "press any key to continue" prompt to
appear after the program exits, and before the window goes away?
--
Kenneth Brody
Bill Reid
> On 4/2/2010 7:19 PM, Bill Reid wrote:
> > On Apr 2, 12:18 pm, Kenneth Brody<kenbr...@spamcop.net> wrote:
> >> On 3/28/2010 4:03 PM, Bill Reid wrote:
>
> [... console windows closing after running a console app from IDE ...]
>
> >>> Unless MICROSOFT provides such an option for their
> >>> "CONSOLE" (which, to the very best of my knowledge,
> >>> they DON'T), no IDE/compiler/whatever can change the
> >>> behavior...
>
> >> Then how do you explain the fact that when I run a program in Visual Studio
> >> 2005 and 2008 in non-debug mode, and I get "Press any key to continue . . ."
> >> displayed in the console window? (Same thing for VS6, as I recall.)
>
> >> Although it's not an available option (AFAIK) in VS2005 and 2008, there's
> >> nothing stopping the IDE from doing the same thing when debugging the program.
>
> > Yes, it would be possible for any IDE to create a
> > special console for a "character mode" application,
> > that just raises the question: what happens when you
> > run the application outside of the IDE? Does it
> > behave the way you want, or the users think it
> > should?
>
> The program behaves exactly the same, regardless of whether the console
> windows disappears or not after the program exits. That behavior is not part
> of the program's behavior.
>
> And who says that a "special console" is being created in this scenario?
> There is absolutely nothing "special" about this console to make it
> different from any other console.
>
It is a very "special" console because the IDE is creating
it for it's own purposes, rather than the operating system
creating it for the program itself...
> >>> This is equivalent to writing a Windows(TM) app
> >>> and asking if you can make the window oval instead
> >>> of rectangular, then people "advising" that the
> >>> IDE/compiler will "probably" have an option to do
> >>> that...
>
> >> Not quite. The IDE giveth the console window, and the IDE taketh it away.
>
> > Right. And if there is no IDE to giveth the console,
> > then the operating system will giveth it, and taketh
> > it away on program exit, even if there is some text
> > the programmer wanted the user to read and perhaps
> > study, copy, whatever...in those cases, the programmer
> > will want to implement his own user-controlled exit
> > routine. Simple enough, riiiiiight?
>
> So, you're saying that the programmer should write a special version of the
> program which waits for the user to do something before exiting, so he can
> see the output when run from the IDE, and then make a new executable for the
> end-users to use?
>
No, I'm pretty sure I was pretty clear that the programmer
should write the application the way he/she wants it to appear
to the user...to that end, the Microslop Whussual Stupido
is doing the programmer no favors by creating a "special"
console that creates a false impression of how the
program will actually work "in the field"...
> Why not just have the IDE cause a "press any key to continue" prompt to
> appear after the program exits, and before the window goes away?
>
It's fine, except to the extent it violates the above...
---
William Ernest Reid
Kenneth Brody
> On Apr 2, 12:13 pm, Kenneth Brody<kenbr...@spamcop.net> wrote:
>> On 3/28/2010 7:55 PM, Bill Reid wrote:
>> The statement "if you're running from the console" means "open a console
>> window [typically by running cmd.exe] and run your program within it".
>> Since cmd.exe, which created the console, is still running, the console
>> window is still there.
>>
> Actually, the statement "if you're running from the console"
> is imprecise use of Microsoft terms, which you are perpetuating
> by attempting further obfuscation.
Well, we're not Microsoft. Rather, we're referring to a statement made by a
previous poster, who stated something like "if you're running from the
console, the window won't close when the program exits".
> As I've pointed out repeatedly, Microsoft calls what you
> call a "console" or "console window" the COMMAND PROMPT.
Wrong. Microsoft calls what you get when you run cmd.exe a "command prompt".
However, the window in which the "command prompt", or for that matter, any
other character mode application, displays information is called a "console"
or "console window".
> A "console" is NOT the "command prompt", rather the
> "command prompt" uses a "console" for input/output.
True.
> I
> give you special bonus troll points for using the term
> "running cmd.exe" to expertly muddy up the discussion
> of something that is relatively clear (well, it IS
> Microsoft, so it's not THAT clear).
>
>>> You are thinking of a separate program called the
>>> "MS-DOS Command Prompt" or sumpin' that causes Windows
>>> to create a console for IT, and any program you run in
>>> it uses THAT program's console, so the console only
>>> terminates when THAT program exits.
>>
>> And, BTW, it's not "MS-DOS" any more. The console hasn't been MS-DOS since
>> Win9x (95, 98, Me) days. The NT-based systems (NT, XP, 2000, Vista, Win7,
>> etc.) don't have MS-DOS. (They do have MS-DOS emulators, however. But the
>> console that you get by running cmd.exe is a true Windows application.)
>>
> Boy, what a friggin' treat...I can emulate MS-DOS in
> a TRUE WINDOWS APPLICATION!!!
And, since Windows is no longer sitting on top of MS-DOS, you can't lock up
the entire system by modifying a single byte of memory from within an MS-DOS
application.
--
Kenneth Brody
robert...@yahoo.com
> No, I'm pretty sure I was pretty clear that the programmer
> should write the application the way he/she wants it to appear
> to the user...to that end, the Microslop Whussual Stupido
> is doing the programmer no favors by creating a "special"
> console that creates a false impression of how the
> program will actually work "in the field"...
Of course, having the console window disappear is exactly what usually
happens if you launch the program in such a way that a new console
window is created. For example, by double-clicking on the executable
in Explorer, or entering a command line from the Start/Run prompt.
But having the default (or at the very least optional) behavior to be
leaving the console window open, would definitely be more useful.
Bill Reid
something like printf() as a poor (read: "stupid") man's
debugger, thus you want to see output that you, the programmer,
never intends the user to see? Why not just set a breakpoint,
which, for even the most brain-dead IDE, is pretty simple
and straightforward, and look at the variable under
question in the debugger?
On the other hand, if you, the programmer, are using
the "console" as the user interface, you definitely
want to see how that appears to the user...and if the
IDE creates a "false" console that the user will not
experience, you, the programmer, have been severely
misled...
---
William Ernest Reid
Seebs
> To who? The programmer? Are you, the programmer, using
> something like printf() as a poor (read: "stupid") man's
> debugger, thus you want to see output that you, the programmer,
> never intends the user to see?
Having done both debugger-debugging and printf-debugging, I find them
suited to very different kinds of tasks.
For sporadic failures, comprehensive logging can be a lot more useful
than trying to step through things. If nothing else, it can give me
a very clear picture of where to start looking. I really like being
able to look at a log after the fact, without having to know in advance
that I want to run under the debugger.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
robert...@yahoo.com
> On Apr 5, 12:28 pm, "robertwess...@yahoo.com"
>
>
>
> <robertwess...@yahoo.com> wrote:
> > On Apr 4, 1:48 pm, Bill Reid <hormelf...@gmail.com> wrote:
>
> > > No, I'm pretty sure I was pretty clear that the programmer
> > > should write the application the way he/she wants it to appear
> > > to the user...to that end, the Microslop Whussual Stupido
> > > is doing the programmer no favors by creating a "special"
> > > console that creates a false impression of how the
> > > program will actually work "in the field"...
>
> > Of course, having the console window disappear is exactly what usually
> > happens if you launch the program in such a way that a new console
> > window is created. For example, by double-clicking on the executable
> > in Explorer, or entering a command line from the Start/Run prompt.
>
> > But having the default (or at the very least optional) behavior to be
> > leaving the console window open, would definitely be more useful.
>
> To who? The programmer? Are you, the programmer, using
> something like printf() as a poor (read: "stupid") man's
> debugger, thus you want to see output that you, the programmer,
> never intends the user to see? Why not just set a breakpoint,
> which, for even the most brain-dead IDE, is pretty simple
> and straightforward, and look at the variable under
> question in the debugger?
Leaving aside your judgment about the competence of programmers using
debugging tools and techniques other than the One True Method that
*you* know represents ultimate truth, whether or not said technique is
even possible to use in a given situation... I suspect if I'm
littering my program with printfs for debugging, I can probably manage
to add a pause of some sort at program termination.
> On the other hand, if you, the programmer, are using
> the "console" as the user interface, you definitely
> want to see how that appears to the user...and if the
> IDE creates a "false" console that the user will not
> experience, you, the programmer, have been severely
> misled...
Whether or not the disappearing console window presents a "false" view
of reality is an interesting question. As I said it *is* the default
behavior for numerous ways that a console application might get run.
Only when run from a cmd prompt (and only sometimes then), does the
window actually hang around by default. But as I said, it would
certainly be a reasonable option, and quite plausibly the default, for
the debugger. But not always - many non-GUI applications don't really
produce any console output either, having to always close a pointless
window whenever I try to debug a deamon of some sort would be annoying
as well.
Bill Reid
who use a lot of screen prints to debug were "incompetent",
just "stupid", because that's the way I feel when I
waste a lot of time typing "printf("%i\n",my_int);"
when all I had to do was just click in the margin
of the source file window to set the breakpoint,
compile/run, and then roll over the variable in question
to see the value...and I feel stupid even though
it is easy to set breakpoints in my stupid IDE,
it seems to be near-impossible to clear them (selecting
"Clear All Breakpoints" seems to make them immortal)...
> I suspect if I'm
> littering my program with printfs for debugging, I can probably manage
> to add a pause of some sort at program termination.
>
Well, yeah, there you go...
> > On the other hand, if you, the programmer, are using
> > the "console" as the user interface, you definitely
> > want to see how that appears to the user...and if the
> > IDE creates a "false" console that the user will not
> > experience, you, the programmer, have been severely
> > misled...
>
> Whether or not the disappearing console window presents a "false" view
> of reality is an interesting question. As I said it *is* the default
> behavior for numerous ways that a console application might get run.
> Only when run from a cmd prompt (and only sometimes then), does the
> window actually hang around by default. But as I said, it would
> certainly be a reasonable option, and quite plausibly the default, for
> the debugger. But not always - many non-GUI applications don't really
> produce any console output either, having to always close a pointless
> window whenever I try to debug a deamon of some sort would be annoying
> as well.
>
The only point was to do what makes sense for what
you are doing, but that would be the dreaded "common
sense", and you know what they say about "common sense",
and even more so in this group...
---
William Ernest Reid
Kenneth Brody
[...]
> On the other hand, if you, the programmer, are using
> the "console" as the user interface, you definitely
> want to see how that appears to the user...and if the
> IDE creates a "false" console that the user will not
> experience, you, the programmer, have been severely
> misled...
What is this "'false' console" of which you speak? The IDE has created a
console, just like the console in which it would run if run from the
"command prompt" or by "executing" the program's icon. There is no
difference in behavior while the program is running. The only difference in
behavior, if any, is that after the program has exited (which is of no
concern to the program itself), you get a "press any key to continue"
prompt, and pressing a key will close the console.
--
Kenneth Brody
Nick Keighley
> On 2010-04-06, Bill Reid <hormelf...@gmail.com> wrote:
> > To who? The programmer? Are you, the programmer, using
> > something like printf() as a poor (read: "stupid") man's
> > debugger, thus you want to see output that you, the programmer,
> > never intends the user to see?
>
> Having done both debugger-debugging and printf-debugging, I find them
> suited to very different kinds of tasks.
>
> For sporadic failures, comprehensive logging can be a lot more useful
> than trying to step through things. If nothing else, it can give me
> a very clear picture of where to start looking. I really like being
> able to look at a log after the fact, without having to know in advance
> that I want to run under the debugger.
yes. But I tend to write such logs to files rather thant he console.
Even knowing the last thing the program wes doing before it crashed
can be helpful. Some programs are supposed to run for days or weeks or
even longer.
Nick Keighley
does a linux console window have a superficial resemblance to a MS-DOS
prompt window? Does linux support a DOS-like shell? (knowing linux,
probably yes!)
Andrew Poelstra
In that case, I usually pipe the output from stdout to tee (and then
grep or sed or whatever, and then tee again) so that I can see the
data as well as having a capture, and also having a filtered capture
if I suspect I know where the problem lies.
--
Andrew Poelstra
http://www.wpsoftware.net/andrew
Alan Curry
Nick Keighley <nick_keigh...@hotmail.com> wrote:
|
|does a linux console window have a superficial resemblance to a MS-DOS
|prompt window?
Let's see... a console is a tty where kernel messages go. Normally that
wouldn't be in a window, but there is xconsole. However we don't normally try
to run a shell in it. So no.
| Does linux support a DOS-like shell? (knowing linux,
|probably yes!)
A shell that has no job control (including no support for "cmd &" syntax to
put a job in the background and leave it there), does no globbing encouraging
every command apply its own unique interpretation of wildcards, supports
neither functions nor aliases, has no syntax at all for redirecting stderr,
no command substitution, and a quoting system that nobody will ever
understand?
No I think we forgot to implement one of those.
--
Alan Curry
robert...@yahoo.com
> In article <963db6d8-3bac-41b3-9269-81bfde30a...@z3g2000yqz.googlegroups.com>,
> | Does linux support a DOS-like shell? (knowing linux,
> |probably yes!)
>
> A shell that has no job control (including no support for "cmd &" syntax to
> put a job in the background and leave it there), does no globbing encouraging
> every command apply its own unique interpretation of wildcards, supports
> neither functions nor aliases, has no syntax at all for redirecting stderr,
> no command substitution, and a quoting system that nobody will ever
> understand?
>
> No I think we forgot to implement one of those.
Well, just to be picky, "start" will start a background process, and
stderr can be redirected with "2>" (two, greater than). And the Unix
approach of globbing anything that looks like a filename is certainly
wrong much of the time (I'm not saying the DOS/Windows approach is
correct, just that the Unix one isn't either). And while batch files
(and some other stuff) do support a basic form of substitution, it
does, certainly leave a lot to be desired.
Kenny McCormack
robert...@yahoo.com <robert...@yahoo.com> wrote:
...
>Well, just to be picky, "start" will start a background process, and
>stderr can be redirected with "2>" (two, greater than). And the Unix
>approach of globbing anything that looks like a filename is certainly
>wrong much of the time (I'm not saying the DOS/Windows approach is
>correct, just that the Unix one isn't either). And while batch files
>(and some other stuff) do support a basic form of substitution, it
>does, certainly leave a lot to be desired.
Wrong on all counts. Do try to keep up.
You are talking about CMD.EXE, the command interpreter for NT-family
Windows systems. We were talking about the "MS DOS Command Prompt".
Note that you were almost, sort of, right about "start", in the context
of Windows 95/98 - but note that START is not a built-in command. The
functionality is implemented via an external command ("START.EXE").
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...
robert...@yahoo.com
wrote:
> In article <7a8efd47-f36a-42a1-8870-4717bd951...@r18g2000yqd.googlegroups.com>,robertwess...@yahoo.com <robertwess...@yahoo.com> wrote:
>
> ...
>
> >Well, just to be picky, "start" will start a background process, and
> >stderr can be redirected with "2>" (two, greater than). And the Unix
> >approach of globbing anything that looks like a filename is certainly
> >wrong much of the time (I'm not saying the DOS/Windows approach is
> >correct, just that the Unix one isn't either). And while batch files
> >(and some other stuff) do support a basic form of substitution, it
> >does, certainly leave a lot to be desired.
>
> Wrong on all counts. Do try to keep up.
>
> You are talking about CMD.EXE, the command interpreter for NT-family
> Windows systems. We were talking about the "MS DOS Command Prompt".
Perhaps you should try reading the thread... This subthread clearly
started with a discussion of the Windows command prompt often
misidentified as the "MS-DOS" prompt. And who's this "we" having this
discussion? I don't actually see a post from you in this thread prior
to the above.
Bill Reid
> Bill Reid wrote:
>
>
> >> Zach wrote:
>
> >>> When I compile a C program in Dev-C++ (www.bloodshed.net) or in
> >>> Microsoft Visual Studio 8 Express it will flash a DOS window with the
> >>> results and then immediately close! How can I pause the screen?
> >> return statement.
>
> > Hmmmm, probably will work as advertised, I'll give that one...
> >> If you're running in release mode, VStudio already retains the console
> >> place.
>
> > Too bad the original message said he was using "Visual Studio 8
> > Express" so it appears you don't know how it works but that didn't
> > stop you from posting...
>
> Use the Debug menu, and click "Start without debugging". That's been a
> feature of VS since forever, and it was retained in VSE.
>
> It appears you don't know how to do that, but that didn't stop you from
> posting.
>
Microsoft Visual C++ 2010 Express last night, and sure enough,
no such phony-baloney "console" option exists, and when a
console "solution" (BWHAHAHAHAHAHAHA!!!!) is built in "Release
Mode" and run from the "Debug" menu, the console is NOT
"retained"...
>
> >> If you're running from the console, you still don't get the problem in
> >> the first place.
>
> > Here is everything you didn't want to know or are too
> > technically incompetent to understand about Windows "consoles":
>
> >http://msdn.microsoft.com/en-us/library/ms682010(VS.85).aspx
>
> > If you drill down you'll find that there is very clear
> > rule that THE CONSOLE TERMINATES WHEN THE PROGRAM THAT
> > LAUNCHED THE CONSOLE EXITS.
>
> the effect that "If you're running from the console", suggesting to all
> but the densest amongst us that you start a console and then run your
> program from within that console.
>
And you still are so technically incompetent you can't
even comprehend what Microsoft calls a "console", even
when directed to a clear description of the beast...
> > You are thinking of a separate program called the
> > "MS-DOS Command Prompt"
>
> No, I'm thinking of the right answer. You, on the other hand, are not
> thinking. I suggest you start.
>
Yeah, sure, whatever, you know the difference between
stupidity and ignorance is ignorance can be cured except
for the stupid...but we already knew that, I just was
amused that Microsoft does NOT apparently offer a
special "console" to mislead both the stupid and the
ignorant, at least for their "freebie" (and apparently
worth every penny!) IDEs...
---
William Ernest Reid