Windows XP doesn't recognize "&" in path names for DOS apps?

By planetearth ·
My client is trying to use a DOS-based app under Windows XP SP3 that worked fine under Windows 98. The app has most of its files in the c:\$opsmg folder. The app has hundreds of files; many of them are batch and configuration files.

Under Windows 98, the program ran properly with the "default" .PIF file. Under XP, it won't run at all unless I edit every batch file and put quotes around the path name. Unfortunately, there are other files which I can't access and which have the path name hard-coded into them.

Not one of XP's "Compatibility Modes" helped with this problem. As long as I put quotes around the path in every batch file, I don't even need to worry about a Compatibility Mode.

Putting c&opsmg in PATH statements in the AUTOEXEC.BAT and Environment Variables didn't help, either.

Here's the batch file that starts the app:

echo off
if exist \&opsmg\opspace.exe if exist \&opsmg\opca03.exe goto opms
goto end
opspace 56

There are dozens more like this, and if I miss one, the app crashes.

Any ideas on what I can do to "force" XP to accept a directory that starts with "&"? (I know this is supposed to be allowed, but I've found no mention of how DOS apps work with this under XP.) I figure if I can force/trick XP, then the DOS app's batch and .SYS files won't need to be modified.



This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

What you are describing is a very common thing

by OH Smeg Moderator In reply to Windows XP doesn't recogn ...

With apps that where moved from 98 or earlier to XP. They simply are unsupported and will not work.

It's the same as when you try to run some apps on Vista/7 that where written for XP even in Compatibility Mode they do not run or fail to run correctly.

The only real solution for this if you have to use XP here is to rewrite everything involved and is part of the reason why there was so much resistance to XP when it was first released.


Collapse -

Reponse To Answer

by planetearth In reply to What you are describing i ...

Thanks, but rewriting the code is not an option. My client didn't develop the software; he's only trying to keep it running under XP because he's, "cost-conscious" to buy a new version (or at least, one that was written in the last 10 years).

Collapse -

Reponse To Answer

by markp24 In reply to What you are describing i ...

thats funny, "cost conscious" to buy somthin made with in 10 years,"
I have a guy who is retired stock/financial expert" and absolutly refused to upgrade from his Lotus 123 (vers 3.x for dos) . He has soem special formulas and macroes he wrote in there that would not fully convert to the new "windows based Lotus 123". It took me 2 years to finally get him to switch and guess what. he likes it better and it only took him 2 days to reqork his special formulas/macros.
so i sorta know what you may be dealing with, i feel for you!

Collapse -

How did you try to use environment variable?

by robo_dev In reply to Windows XP doesn't recogn ...

EG: set Folder = c&opsmg
cd %Folder%

not sure if this helps, but XP has both the CMD prompt and the COMMAND prompt, one handles 8.3 filenames different than the other....

Collapse -

Reponse To Answer

by markp24 In reply to How did you try to use en ...

Good point, your right is the old 16bit style and cmd is the 32 bit style of a command promt, and they handle long filenames and special characters differently.
It will be interesting if this solves his issue.

Collapse -

Reponse To Answer

by planetearth In reply to How did you try to use en ...

Hmmm.... Well, while I was testing what to put into the batch file, I used the CMD prompt and manually entered commands. (And with that, I found I had to use the quotation marks just to get the app to load.) Otherwise, all I did was put a "PATH" statement into the environment variable and AUTOEXEC.BAT: PATH=c&opsmg. That didn't help, and I ended up using the quotation marks. Should I try the "SET" command you noted above? (It's been a loooong time since I had to use DOS, so please forgive my ignorance.)

As far as the batch file itself, I just created a shortcut on the desktop from the one that's in the actual "&opsmg" folder. Does that use CMD or COMMAND or voodoo or what?

I'd actually read Wikipedia's entry on DOS file names, but I didn't see anything that might help with this issue--especially since it said that ampersands were allowed in file and folder names. I didn't see anything in the article about how CMD and COMMAND are different, either. That's interesting (and by "interesting", I mean "annoying").

Hope this helps...thanks!


Collapse -

Quotes will be required no matter what you Set.

by seanferd In reply to Windows XP doesn't recogn ...

You are not going to eliminate the need for them. Any path with spaces or special operators needs to be in quotes.

So: What about using find & replace instead of manually adding quotes to each path statement in your files? What about removing the ampersand from the directory name?

Collapse -

Reponse To Answer

by planetearth In reply to Quotes will be required n ...

If I remove the ampersand from the directory name, then all the batch files that refer to that directory will no longer find it.

I thought about editing all the batch files at once and using a Find/Replace, but that doesn't take into account all the compiled files and other, non-batch files that I could edit in Notepad but that either have no extension (or no consistent extension). If any one of those is critical for the app to run, it will still fail because I couldn't find and edit the file.

If I can't trick XP into ignoring the ampersand, then it looks like my client is stuck.


Collapse -

Reponse To Answer

by planetearth In reply to Quotes will be required n ...

Maybe I've missed something, but how can "any path with spaces or special operators" need to be in quotes if the special characters are allowed in Windows XP and DOS?



Collapse -

2 Options

by TheChas In reply to Windows XP doesn't recogn ...

I see 2 options here.

Set up a specific computer with DOS or Windows 98 on it specifically to run this program.

Or, try a DOS virtual machine configuration. You might even get by with a Win 98 VM.

We have similar issues supporting applications on systems that are older than DOS itself that would cost way too much to move to new hardware. We just keep finding parts to keep the older hardware running.

Still, that only delays the inevitable. The company needs to start on a project to replace the software. Consider it planning or disaster recovery. A plan needs to be in place for when (not if) the DOS app can no longer be supported.


Related Discussions

Related Forums