forum.vdsworld.com

jwfv · Posted: Fri Jul 11, 2003 2:44 am Post subject: Programs not running hidden

I have an application that runs various DOS utilities. It runs them via the RUNH command so they will be invisible to the user.

Today I had a user who mentioned seeing the DOS command prompt boxes pop up when the utilities were run, instead of them staying hidden. I watched it and confirmed this is what was happening.

He was running Windows 2000 Professional. But on another machine on his network running Win 2000 Pro also, the programs ran hidden.

Any ideas?

Thanks in advance -

CodeScript · Posted: Fri Jul 11, 2003 4:03 am Post subject:

when U run a dos program it may not run as desired on all paltforms.
that U see a dos screen inpite of RUNH means some error is occuring. Run normally ie. RUN and try to see what error is occuring.
Mostly related to path or dos shortname.
You can use @path(%0) to specify the path as current directory and @shortname for using dos short names. May be on the computer where error is fired directory depth may be greater. Also give the wait command if using multiple commands - else second one may fire error.
Lastly very rarely runh doesnot work due to unknown reasons - I think unlikely in Ur case.

jwfv · Posted: Sat Jul 12, 2003 12:06 am Post subject:

It doesn't have any error - I can see the program complete and then it closes. It just doesn't run hidden. It runs in visible mode.

Thanks for the reply - maybe I'm just one of the unexplained cases of RUNH not working ....

CodeScript · Posted: Sat Jul 12, 2003 2:22 pm Post subject:

You can try something like this example which open console lists the files and closes:
this should work unless your app opens secondary windows.
this code will not work on win 9x. also if the user opens console for some other work simultaneously.
You can check the users operating system by using @SYSINFO functiom and use this if users OS is win 2k and above.
one more option is to run a shorcut to the app configured to run in minimised mode. You will see the app in taskbar - atleast no ugly black windows.

The other option is try using "Console IO Extension for Visual DialogScript" by PGWARE.

jwfv · Posted: Mon Jul 14, 2003 2:02 pm Post subject: Anyone else encountered this?

Thanks for the reply and sample code, Codescript. I guess I will leave the application as is for now. It runs the utilities hidden on 99% of all computers I run it on - don't know why this particular machine is different.

If anyone else has ever encountered this problem and has any ideas, please post them.

Thanks again -

Garrett · Posted: Mon Jul 14, 2003 7:49 pm Post subject:

I think I almost know exactly kind of sort of maybe what's the problem.....

A few years ago I had this problem on my system. What I had done,
unintentionally was change the settings of the main pif file used by the
system to run dos windows. The pif file is either in the win directory, or
maybe the command directory, or ?.

Solution? I don't remember exactly. It was either adjust the settings of
the main pif used, or replace it with a backup from the installation cd.

-Garrett

jwfv · Posted: Mon Jul 14, 2003 8:45 pm Post subject:

Well, if you think of it, let me know. By the way, what are the different executables that different versions of windows uses to run command prompts?

cmd.exe?

command.com?

command.exe?

Thanks

FreezingFire · **Admin Team** Joined: 23 Jun 2002 Posts: 3508

I think COMMAND.COM is for Win 9x, and CMD.EXE is for Win NT+.

bbelcher · Contributor Joined: 30 Jul 2002 Posts: 172

Your right FF. cmd.exe is for a nt based OS and command.com is for a 95/98 based OS. Also command.com is included with a NT based OS's but it runs very slow.

what about using

%P = @ENV(ComSpec)
info %P

this will give you the path to what ever command path on what every os.
Just a thought

CodeScript · Posted: Tue Jul 15, 2003 2:51 am Post subject:

I think even in NT Cmd runs command.com for a dos application. I just interfaces between the user and command.com and supports long file names etc (actually speaking even dos supports LFN but it is other env limitation which avoids this).

I may be wrong ?

FreezingFire · **Admin Team** Joined: 23 Jun 2002 Posts: 3508

I don't know, CMD.EXE seems a lot more stable and faster than COMMAND.COM Smile

Skit3000 · Posted: Tue Jul 15, 2003 11:50 am Post subject:

I believe CMD.EXE is an emulator. That might explain it... I think that if you run command.com in Windows XP, it will be started through cmd.exe... Confused

bbelcher · Contributor Joined: 30 Jul 2002 Posts: 172

http://www.computerhope.com/issues/ch000395.htm

Chekck this out. command.com vs cmd.exe

CodeScript · Posted: Tue Jul 15, 2003 3:04 pm Post subject:

jwfv · Posted: Tue Jul 15, 2003 3:12 pm Post subject:

All this is interesting. Back to my original question - I tend to think that the properties for the problem computer's cmd.exe or command.com are set to run in full screen, which may negate the hiding part of RUNH.

I think I looked for command.com, but not cmd.exe ... or the other way around.

Thanks for the replies.