Prev: Application Error, The memory could not be "read". How to debug?
Next: IOCTL_DISK_ONLINE on longhorn
From: Pops on 20 Nov 2007 12:26
Martin Irman wrote:

> Actually, you can always see the console window appearing for a short
> moment. That's okay. The problem is that the first time after login the
> console window stays ... indefinitely.

Ok, I wondered if this was your main issue. :-) Old Problem dating back
to Windows 95 which many solutions depending on our OS including one of
the strangest recommendations from Microsoft ever. :-) More below.

>> One way to do this programmically is to compile your application
>> without a console, i.e, link it as a GUI but without a window :-) The
>> only thing that will change is your entry point.
>
> Unfortunately, the application has to be able to run in a legacy command
> line mode. Similarly to MS Visual Studio which is able to run with a GUI
> but also as a command line utility (they solve it by having to
> executables ... devenv.com (command-line) and devenv.exe (GUI) ... we
> didn't opt for this solution).

The problem is old with many possible solutions. It will serve me no
justice to try to remember all the finer details since Windows 95, but I
will try to summerize the solutions:

1) Make sure you clear the screen first (Microsoft's answer <g>)

2) Depending on the OS, it might offer "[X] Close On Exit" for the
short cut property.

This 2nd one use to be done with old PIF files that you can create to
describe certain attributes about the application.

Lets see what else? Ok...

3) Call the program using CMD /K

CMD /K yourprogrampathexe

4) If you can start a batch file to start the application, then your
batch file can call EXIT to exit the window. This might or may not
work depending on the OS. I forget the details. You can also try using
CLS to clear the screen here too before calling EXIT.

The problem is odd and dates back to 95 with Windows related to keyboard
handling and "idleness" of legacy console applications. Again I don't
remember why, but clearing the screen was part of what it was it looking
for, otherwise it kept the Window open.

I seem to recall this was an issue for 16 bit applications only and
batch files, so I believe the new windows (since 2000) offered the CLOSE
ON EXIT stuff for these.

For us, we offered a server system since the 80s that supports 3rd party
developers and operaters that can hook in 3rd party application. So this
use be a major issue not just for us, but when the operator installed a
3rd party applicaiton, that our server would start and it use never
close the window. We eventually solved it and if I remember, it was
using answer #3, but it used the COMPSPEC to determine if it should use
CMD.EXE or COMMAND.COM

If you type SET COMSPEC in a dos window, you will see the command line
processor that will used for that shell.

That was important because in the old days (and maybe still today), tons
of people use to use a very popular improved shell called 4DOS that
offers tons of new command line commands and batch file scripting power.
So you might have to check the COMSPEC environment string before using
the /K option.

> Thanks for the answer.

My pleasure.

--
HLS
From: Martin Irman on 20 Nov 2007 13:20
Pops wrote:
> Martin Irman wrote:
>
>> Actually, you can always see the console window appearing for a short
>> moment. That's okay. The problem is that the first time after login
>> the console window stays ... indefinitely.
>
> Ok, I wondered if this was your main issue. :-) Old Problem dating back
> to Windows 95 which many solutions depending on our OS including one of
> the strangest recommendations from Microsoft ever. :-) More below.

Oups! Sorry, I think I've misled you! I shouldn't have said
"indefinitely" ... the console window IS closed when our application
exits but it remains open for the whole time our application is
running. This is what we are doing:

+ if our application is called from the shell with a special
command line option (let's say 'app.exe --command-line') the
application has to operate as a console application with no GUI to
support legacy use in batch files.
+ if our application is started, let's say, using a shortcut on the
desktop, the application starts in a different mode - GUI mode - and
does not send any output to the console. In this case, explorer.exe
(which manages the desktop, if I'm not mistaken) creates a console
window for our application (because the app is flaged as a console
application to support use case #1). We don't want this console
window to be displayed because we don't send any output to it and
more importantly, clicking on the 'X' button of the console window
would instantly and relentlessly kill our application. Thus, we hide
the window while our app is running. And this 'hiding' part does not
seem to work on Windows Vista the first time after login.

The problem seems to be caused by the fact that the console window is
shown asynchronously by the OS (Vista) as I've already mentioned in my
previous e-mail to Remy. I thought that I could solve the problem by
flagging the application as a GUI application and using
AttachConsole() to reconnect to the console in the command line mode
.... but this would not work because then a call such as 'app.exe
--command-line', if used in a batch file, would not be blocking.

Thanks for the help.
Martin.

From: Remy Lebeau on 20 Nov 2007 16:12

"Martin Irman" <imartin(a)inro.ca> wrote in message
news:u7ZLpa5KIHA.5360(a)TK2MSFTNGP03.phx.gbl...

> our app has to work as a GUI application (while hiding the console)
> but also in a legacy command line mode.

At startup, once the app has determined that it needs to run in GUI mode, it
can use CreateProcess() to start a second copy of itself, specifying SW_HIDE
in the dwShowWindow member of the the STARTUPINFO structure, and then the
first instance can exit immediately without doing anything else.


Gambit


From: Norman Diamond on 20 Nov 2007 21:25
Maybe try the following ugly workaround.

No, wait a minute. First make sure you haven't eaten lunch yet. Set that
coffee cup down in a safe place. Get some goggles. Then try the following
ugly workaround.

Definitely not guaranteed. If it doesn't work, you have to pay me double.





hWndCons = GetConsoleWindow();
ShowWindow(hWndCons, SW_SHOWNA);
ShowWindow(hWndCons, SW_HIDE);

From: Pops on 21 Nov 2007 00:12
Yes, I believe I understood the issue. It is very common for
applications like this dating back to Windows 95.

I will give you two examples that covers both kinds of the same problem:

- for one of our products, the main server has the same need
as your of running modules and/or batches,

- For an add-on tool, it has console vs desktop usage too.

First the add-on - a Node Manager called WCNODE.EXE which everyone knows
about, documented, etc. This is want they run from a console.

WCNODE.EXE is a console compiled application so it has command line
options to do console related display information. People may use this
in batch files as part of an automated shutdown maintenance batch file
event.

If no switches is provided, then WCNODE.EXE spawns WCNODEW.EXE which is
the GUI version of the Node Manager, and silently exits.

The "Node Manager" shortcut installed on the desktop or in the
application's Start folder uses WCNODEW.EXE.

Of course, to make our development life easier, they both use the same
reusable node management code.

Second, the server, among its many features, it allows operators to run
batch files or any module which are normally out of our control. We
can't control what they will do as far as opening dozens of console
windows, etc. So it looks UGLY and sometimes, the stupid windows will
stay open!!

So to control this, we detect 16bit or 32 bit application, we include
extension consideration, BAT, CMD, COM, EXE, we use the COMSPEC with the
/K switch with specific CreateProcess flags and ShowWindows structure
information. If the OS is Window 2000/XP/2003/VISTA, then its easy - we
use the DETACHED_PROCESS flag when spawning the operator supplied
process hooks.

The end result they run passively in the background.

Overall, without the OS providing some kind of "DETACHED_PROCESS"
property option for the short cut, and off hand, I have not seen that
long time desired desktop launching option ever offered, there is really
no other clean solutions for this very common need.

--
HLS

Martin Irman wrote:
> Pops wrote:
>> Martin Irman wrote:
>>
>>> Actually, you can always see the console window appearing for a short
>>> moment. That's okay. The problem is that the first time after login
>>> the console window stays ... indefinitely.
>>
>> Ok, I wondered if this was your main issue. :-) Old Problem dating
>> back to Windows 95 which many solutions depending on our OS including
>> one of the strangest recommendations from Microsoft ever. :-) More below.
>
> Oups! Sorry, I think I've misled you! I shouldn't have said
> "indefinitely" ... the console window IS closed when our application
> exits but it remains open for the whole time our application is running.
> This is what we are doing:
>
> + if our application is called from the shell with a special
> command line option (let's say 'app.exe --command-line') the
> application has to operate as a console application with no GUI to
> support legacy use in batch files.
> + if our application is started, let's say, using a shortcut on the
> desktop, the application starts in a different mode - GUI mode - and
> does not send any output to the console. In this case, explorer.exe
> (which manages the desktop, if I'm not mistaken) creates a console
> window for our application (because the app is flaged as a console
> application to support use case #1). We don't want this console
> window to be displayed because we don't send any output to it and
> more importantly, clicking on the 'X' button of the console window
> would instantly and relentlessly kill our application. Thus, we hide
> the window while our app is running. And this 'hiding' part does not
> seem to work on Windows Vista the first time after login.
>
> The problem seems to be caused by the fact that the console window is
> shown asynchronously by the OS (Vista) as I've already mentioned in my
> previous e-mail to Remy. I thought that I could solve the problem by
> flagging the application as a GUI application and using AttachConsole()
> to reconnect to the console in the command line mode ... but this would
> not work because then a call such as 'app.exe --command-line', if used
> in a batch file, would not be blocking.
>
> Thanks for the help.
> Martin.
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Application Error, The memory could not be "read". How to debug?
Next: IOCTL_DISK_ONLINE on longhorn