XP: space in pathname to exe. Works on one PC, not on another.

[#1]

I have 2 PC's running XP SP2.
If I double-click on an exe file in explorer it runs on both machines fine if there are no spaces in the pathname.
But if I introduce a space into the pathname on both machines (by changing the name of the folder from say c:\XY to c:\X Y) the program runs on one machine but not on the other.
The machine that fails says "Can't run 16-bit program".
What must I change in XP to make the program run on the PC that reports the error? In other words - how can make XP run an exe with a space in the pathname when it refuses to.

[#2]

So much for long file name support 
How long is your full pathname - I think there is a (small) limit.
In a command line you can enclose the path/program name with double quotes.

[#3]

Hi JB thanks for your help,
The full path I tested is literally as described, with setup.exe on the end.  That is ;-
c:\x y\setup.exe
I tried various things like quotes and win95 comaptibility mode, but to no avail.
The problem is why are the machines different - in this particular behaviour - so I can make them the same, since I already know how to make the exe work, just make sure there are no spaces in the path it is run from, it seems such a simple question yet it stumps everybody I ask - so far.

[#4]

so it is a folder called "x y" 

[#5]

Are your running the application from a Shortcut, or direct from Explorer and double clicking the EXE?
Ideally you should be making sure the shoirtcut is actually using "c:\x y\setup.exe" and not just c:\x y\setup.exe as the value (the quotes make a world of differance).

[#6]

but surely the point is the inconsistency between the behaviour on the two machines, not whether a short cut has quotes.
the OP clearly states that he's clicking on the exe from an explorer window

[#7]

Is it possible that your directory is not "X Y" but X followed by a some non-displayable character followed by a Y?

[#8]

I thought I had read that myself, but didn't spot it when checking again.
Have to admit, I don't see any reason.
Does the computer have now or previously had security software?
Anyt seoftware recovery or monitoring utilities?

[#9]

Thankyou all for going out of your way to help - much appreciated.
Indeed the crux of the problem is the inconsistency between PC's as paulh says.
And yes the executable is in a test folder that for just brevity is called "c:\x y" that I create on all machines from explorer in the same way. I use the space-bar for the character between x and y in each case that works and fails. There is nothing mystical about what I am doing as far as I know.
It seems like a good idea to check for an over eager virus checker - thanks.
I would be interested to know if anyone can repeat the error. Especially since I wont have access to the PC with the problem til tomorrow morning. All my home PC's are fine, one is XP pro the others XP home edition.
For what its worth the program is 'any' 16-bit application running direct from explorer (not from a shortcut).

[#10]

Open Regedit
Navigate to HKEY_CLASSES_ROOT\exefile\shell\open\command
the Default key should read:
"%1" %*
check that it does.
Also, navigate to:
HKEY_CLASSES_ROOT\.exe
and check that the Default value is:
exefile

Don't change anything, just report back what you find.
B.

[#11]

Unsuprisingly - for the PC that works - I can report that the registry settings are correct, but can't confirm til tomorrow if the pc that fails is also OK.
I'm not inclined to try reproduce the problem incase I end up teaching XP how to never find any executable ever again.
I would be interested to know what you're expecting to see - if that's not too dangerous.

[#12]

I'm expecting to potentially see that the command has been altered - it's an old-style way of a virus propagating and when running antivirus to remove it, it often used to leave the registry in a 'broken' state (probably missing the ""s)
If it is that, simply restoring the Default keys to what I've outlined above may solve it.
Fingers crossed that it is that simple
B.

[#13]

If you are running it on pc a the the path will be c:\ x y\setup.exe if you haven't mapped a drive the path for pc b could be \\ sons games pc\x y\setup.exe
So it could be to long depending on the name.
Second problem if you set it up as c:\xy logged on fred the permissions may be every one. Now changing the dir name may then change the permissions on the file as the user has now taken ownership of it so you may not have .
You need to logon to both pcs using the same username and password on both pc's (you may have to create an new account) then map a drive by typing at a cmd prompt
net use p:\\ remotepcname or ip\c$ password /user:username on remote pc
and then try and run the file from p drive 

[#14]

for the PC that didn't like the space in the pathname ;-
1)  The registry settings were fine - thanks Barry.
2)  C: is not a mapped drive. It is not an alias for a longer path - thanks samuria. The PC is not even networked.
Experience nags : I am missing something obvious.

[#15]

Hmm,
I wonder if one copy of XP is trying to interpret the shortcut using COMMAND.EXE and the other machine is trying to use CMD.EXE.
The difference being of course that COMMAND.EXE only supports filenames of up to 8chars and does not permit spaces in the filenames.
CMD.EXE is happy with much longer filenames, and does allow spaces in the filenames.
I'm not entirely certain of how you would force XP to use one over the other though, perhaps examining the properties of the shortcuts might yield some differences.
I think you need to make sure that the 'start in' box is blank to get it to use CMD.exe by default.