Java app calling Java app through command.com loses env vars

Java app calling Java app through command.com loses env vars

Post by David M. Ka » Tue, 11 Mar 2003 04:06:11



I'm starting to use a product that has one step of its installation/setup that
is a cmd script that calls a Java application that ends up using command.com to
call another Java application.  The last Java application needs to references
environment variables set in the cmd script.

In Windows 2000, this process works fine.  The last Java application sees the
environment variables fine.  In Windows XP, however, the last Java application
seems to have no environment variables (I've only tried several, but I haven't
checked to see if there are any at all).

I wish they had written this process better (as the second Java application has
a relatively easy-to-use API that they could have just called directly from the
first Java application), but they didn't.  I don't expect them to re-architect
this any time soon.

The question I have is, is there something that changed between Win2k and WinXP
in the area of calling other applications through command.com, such that a
downstream called application wouldn't be able to get any environment
variables?

Is there something they're supposed to use instead of "command.com" for this
sort of thing?  I know there's "cmd" and "command", and "cmd" appears to be
much more functional, but I don't know a lot about the differences between
them.

--
===================================================================
David M. Karr          ; Java/J2EE/XML/Unix/C++

 
 
 

1. DOS app, CMD.EXE vs COMMAND.COM, video trouble ----HELP!!!----

I hope someone out there can help me out with this problem.

Here is the situation:
Windows NT 4.0 workstation (Service Pack 3)
DOS terminal emulation program that uses COM port to connect to our old
mainfram

Now for the most part this all runs fine, the terminal emulation itself
even KERMIT file transfers.  However, I run into a problem when I send
escape sequences to the emulation program from the host.  The escape
sequence tells the emulation program to shell out to DOS and run a batch
file.  This part works fine.  My problem is when the batch file finishes
and hands control back over to the emulation program the emulation's screen
stops updating.  The emulation itself is still working, ie. it lets the
host know that the DOS command has finished and the host continues its job.

This procedure worked fine in Win95.  The only thing I can think of is that
it is a problem with the shell to DOS that somehow relates to the Video
Mode that the emulation program is in.  But the emulation program is a text
mode program and the batch file that I run simply using FTP to connect to
our new system and pulls a file back using the /s switch on the FTP command
with output redirected to a log file that I can check for errors using the
find command.

My questions:
What is the difference between CMD.EXE and COMMAND.COM, the way I
understand it is that CMD.EXE is 32-bit, and COMMAND.COM is 16-bit.  Do all
DOS apps use COMMAND.COM?  Can you use CMD.EXE?  If I start CMD.EXE via the
'RUN' command on the start menu, and go into my DOS app from the resulting
command prompt.  What is my DOS app using CMD.EXE or COMMAND.COM?  How does
all this relate to the ntcmdprompt command in the config.nt file?

What PIF properties have an effect on the VIDEO emulation of the DOS apps?
What effect does the 'Compatible Timer Hardware Emulation' switch have?

Any other ideas on what I should try?

Sorry this is so long, but any help would be greatly appreciated!

Thanks in advance

--
Charles Wilt
Miami Luken, Inc.
Springboro, OH.  45066

--remove the .no.spam

2. My posts seem to be disappearing on msnews.microsoft.com's news server

3. Java Java Java

4. Thomas-Conrad Arc-Card/MCA

5. 4.0b2 multiple users?

6. Call to WinInet InternetOpen Works on Emulator and Sample App but not in My App

7. Something special!

8. Netscape 2.0 & Java at java.sun.com

9. Tues,Apr 7:Java GUIs;Java/COM/ActiveX courses

10. dragging an app's debug window locks the app (COM)

11. Capturing Batch File or Command Line apps output in *my* app....

12. calling eVC COM DLL from eVB app