With an installtion of BR 4.2 on a Windows 7 system all my shell calls to .exe files are returning 4320 - syserr$="Network Path not found" and Ctrl+] will not pull up a command prompt. In BR! a dir of the network path shows that the file does exist.
On the same system with 4.18, the shell calls are working and the Ctrl+] is working.
Has anyone experience this type of problem or have any ideas on how to fix it. It seems to me that the problem is in the shell mechanics of 4.2, cause the Ctrl+] does nothing.
I wonder if there's some additional security issues with Windows 7 on network shares.. it might be that the shell call uses different security permissions then other BR commands.
Most likely the reason the CTRL ] is failing is because its getting error 4320 when it tries to open the shell call too.
Strange that it works in 4.18 but not 4.2, they may have changed something about shell calls.
I have a lot of shell calls to exes and I'm running BR 4.2. These work fine on my Win7 netbook. But are you running as an admin? That might be the problem. I have had various issues (err 4203, rather than 4320 as you stated) when I run as a limited user.
I can't test it with 4.18/Win7 to compare because my programs are all compiled for BR 4.2 (Option 60 off)
Ed Singer mentioned that there may be a special type of drive mapping under Windows 7 that is required for compatibility. He said he would research it further and get back to me.
Are you running as an admin or a limited user? Try running as admin and see if it goes away. I have played with this a little bit, and although my errors aren't exactly the same as yours, they go away when I run as admin, so it appears to be a permission issue.
-- Susan
P.S. I have not done extensive testing with Win7 since the only computer I own that is running it is my little Toshiba netbook, but I can experiment a bit if you need another person to try it.
unfortunately running as an admin is not an option - I believe next year after luis and i both have finished our vacations we can give it a shot for testing purposes, but long term that isn't an option - though beefing up the user's rights may be.
John- The idea here is not that "Admin" is a solution. This is only to confirm that it is a Windows security issue that maybe we have to work around in BR.
Surely TESTING as Admin is an option, is it not?
We are establishing a Windows 7 test environment, but it is in conjunction with several other infrastructure changes. It would be useful to know what is causing this.
well it's a big deal but it's not impossible. I'll be able to do this test during the first week of next year. But if we come across any other ideas, than we can try them. It's strange that other BR! systems on the same machine are executing shell calls fine... It seems like it simply must be the configuration of this one system. But which part it is I cannot deduce.
-john
P.S. Why not till next year: our system administrator is on vacation this week, next week I am on vacation... While we have the system admin name/password, we still need to install novel network drivers onto that system (and those I don't know where are). and then map all the drives, set up a new shortcut and then we'll be on our way to testing it under admin.
