environment variables and CMD window

[Vic]

Can someone help resolve this:

I have certain DOS programs which need to run in XP1pro. These programs were setup originally to make extensive use of environment
variables in BAT files. Some of these BAT files have SET= variables as long the DOS environment allows (120 characters). Also some
of the command lines with the files are quite lengthy (up to 120 characters). I've noticed XP's cmd window will not accept a string
in BAT files over 40 characters long!! If I recall, the BAT file hauls with an error stating the line was >40. That's quite a curve
ball.

Tried using DOSBox and the same restriction exists. Are there any work arounds?

Thank you for your help
Vic

 

[David Candy]

What has Dos programs and batch files got to do with one another in XP. Answer NOTHING.

 

[Pegasus \(MVP\)]

Can someone help resolve this:

I have certain DOS programs which need to run in XP1pro. These programs

were setup originally to make extensive use of environment

variables in BAT files. Some of these BAT files have SET= variables as

long the DOS environment allows (120 characters). Also some

of the command lines with the files are quite lengthy (up to 120

characters). I've noticed XP's cmd window will not accept a string

in BAT files over 40 characters long!! If I recall, the BAT file hauls

with an error stating the line was >40. That's quite a curve

ball.

Tried using DOSBox and the same restriction exists. Are there any work arounds?

Thank you for your help
Vic

I don't know where you got your numbers from - perhaps you
ran command.com instead of cmd.exe for a Command Prompt
(which you incorrectly call a "DOS box". DOS is an operating
system - there is no DOS under WinXP).

I wrote this little batch file:

Line1 @echo off
Line2 set string=I have certain DOS programs which need to run in XP1pro.
These programs were setup originally to make extensive use of environment
Line3 echo string=%string%

I then ran it and got this on the screen:

string=I have certain DOS programs which need to run in XP1pro. These
programs w
ere setup originally to make extensive use of environment

It's clearly a lot more than 40 chars!

Try to run my batch file yourself!

 

[Vic]

Hi Pegasus,

You might be right regarding having run command.com, not sure if I did that or not. The issue here ultimately goes back to one you
addressed in a W2K NG, re:environmental variables.

I have multiple DOS EXE's which are the engine of a DOS menu system. These EXE's work by setting a variable based on user input.
When the user (me) exits, the variable STAYED in the environment in DOS (as oppossed to W2K and XP which wipe out variables set by
an executable when it exits).

BTW, DOSBox is a DOS emulator which works in Win 32bit systems (there seemed to be confusion about that).

Also, tried your BAT simuation in a CMD window and you are right ... no error message about a line which is too long. In fact, I
cannot duplicate the >40 character error message but I'm bouncing between OS's (w2K & XP) so perhaps came up in 2K.

Well, if I have not lost you I'm still confronted with a dilema because these 32bit OS's wipe out variables set by an EXE when it
terminates. (I'm assuming it was done for 'security', but that stuff has become a nusance to me)

If anyone has a work-around for this I'd REALLY appreciate it.
BTW: the variable set by the EXE does NOT have to be written to the master environment, just needs to stay in that session.

Lastly, I took your suggestion of possibly recompiling the (one of the) EXE's to have it write a batch file with the variables etc.
I cannot recompile it but may be able to edit the EXE to make it work as you suggested. Never the less there is still another
program which writes variables (again part of a DOS menu system) which I cannot alter to work, so I NEED to have variables *stay* in
a CMD session even after an EXE exits.

Work arounds?

Thanks
Vic
___

 

[Pegasus \(MVP\)]

You write "When the user exits, the variable STAYED in the environment in
DOS (as oppossed to W2K and XP which wipe out variables set by an executable
when it exits)."

This is not correct, as mentioned in the other thread. A child process
***inherits*** the environment from the parent. When the child process ends,
it does ***not*** pass its environmental variables back to the parent. This
is so in DOS and it is also the case in Windows. However, by writing
directly into the memory space, it was possible under DOS to modify a parent
environmental variable from within a child process. Your executable had
specific code to do this - it did not just happen by itself! This sort of
thing is not permitted under Windows XP. There are ways around it, and some
were suggested in the other thread.

I realise that it is a nuisance for you not to be able to write directly
into any memory location. However, the whole integrity of Windows hinges on
this restriction. Cast your mind back: Windows 3.11 had no such restriction
and it kept crashing. Windows 9x has some restrictions and it became a lot
more stable. In OSs based on WinNT, the restrictions are strictly enforced
and crashes are very rare. The price you pay for the improved stability is
that "dirty" legacy applications can no longer pull their funny tricks. They
must be replaced by clean-up versions.

Hi Pegasus,

You might be right regarding having run command.com, not sure if I did

that or not. The issue here ultimately goes back to one you

addressed in a W2K NG, re:environmental variables.

I have multiple DOS EXE's which are the engine of a DOS menu system. These

EXE's work by setting a variable based on user input.

When the user (me) exits, the variable STAYED in the environment in DOS

(as oppossed to W2K and XP which wipe out variables set by

an executable when it exits).

BTW, DOSBox is a DOS emulator which works in Win 32bit systems (there

seemed to be confusion about that).

Also, tried your BAT simuation in a CMD window and you are right ... no

error message about a line which is too long. In fact, I

cannot duplicate the >40 character error message but I'm bouncing between

OS's (w2K & XP) so perhaps came up in 2K.

Well, if I have not lost you I'm still confronted with a dilema because

these 32bit OS's wipe out variables set by an EXE when it

terminates. (I'm assuming it was done for 'security', but that stuff has become a nusance to me)

If anyone has a work-around for this I'd REALLY appreciate it.
BTW: the variable set by the EXE does NOT have to be written to the master

environment, just needs to stay in that session.

Lastly, I took your suggestion of possibly recompiling the (one of the)

EXE's to have it write a batch file with the variables etc.

I cannot recompile it but may be able to edit the EXE to make it work as

you suggested. Never the less there is still another

program which writes variables (again part of a DOS menu system) which I

cannot alter to work, so I NEED to have variables *stay* in