[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [h-e-w] DOS boxes and gnuclient vs. gnuclientw
From: |
Ludwig, Mark |
Subject: |
RE: [h-e-w] DOS boxes and gnuclient vs. gnuclientw |
Date: |
Tue, 2 Nov 2004 15:13:41 -0600 |
The "Windows way" would be to make the text that otherwise would go to
the console (stdout/stderr, I assume) go to a pop up of some sort.
Multiple-line stuff should go to a text box with scrolling, etc.
Mark
-----Original Message-----
From: Guy Gascoigne-Piggford [mailto:address@hidden
Sent: Tuesday, November 02, 2004 10:44 AM
To: Ludwig, Mark
Cc: address@hidden
Subject: Re: [h-e-w] DOS boxes and gnuclient vs. gnuclientw
The problem is that there is sometimes useful information returned by
gnuclient(w) or gnudoit and this goes to the console. If the app is
built as a windows app then this information gets lost. Even if the
windows app is run from a console, you still can't write to it.
From looking at the Windows APIs there actually might be a way to
improve this under XP or Server2003, there are now a couple of APIs that
allow for attaching to an existing console, so it might be possible to
work around this to a degree, but my concern is that this attachement
comes very late in the startup of the aplication, by which time any
inherited file handes (stdin/stdout/stderr) have been lost, if they were
ever passed in that is.
So there is an angle to look at here at least for newer OSs, but I've
only been reading the docs, I've not really delved into this much yet.
From a Windows app, either the shell or another application, I agree,
there is little need to use the command line versions, but from a
command line they still have their uses.
Guy
Ludwig, Mark wrote:
>One aspect of the Windows platform has been a gradual migration away
>from "console apps."
>
>Thus, if we want to be working in the direction Microsoft advocates, I
>suggest that gnuclient go away and that its ability to wait for a user
>to edit something be added to gnuclientw -- assuming it's possible to
do
>so.
>
>Put another way, I cannot believe anyone /wants/ those DOS boxes to
>appear -- minimized or otherwise. If we have to put up with them,
>that'd be different....
>
>Mark
>.
>
>
>