Regards,
I'm having a peculiar issue with a 32bit software program that is being migrated to a x64 environment (Windows XP SP3 towards Windows 7 X64. The application is question is a electronic register / till for our endpoint sales offices.
The application is located in:
"C:\Program Files(x86)\Q_Kassa"
We have configured all relevant acces for the user that'll run the software as a shell including all relevant read / write rights on the folders that the application needs. However, as long as we do not "Run As Admin" or as long as the user that'll load the program is not a member of the local admins groups the application will not load throwing the error that it can't find a file located in:
C:\Program Files\Q_Kassa\FileName
The thing is, all relevant config data, config files and register info tell the application that it's data is in the Program Files (x86) directory. For some reason it seems like, when the application is run using the "Run As Admin" option, or ran while the user is in the local admin group, that Windows is misinterpreting the folder it needs to get as Application folder.
So in summary:
As local admin / Run-as-admin option used:
the application is fed info from C:\Program Files(x86)\Q_KASSA\
--> as it should be.
When run as a normal user the application tries to get it's info from
C:\Program Files\Q_Kassa
--> wrong folder
Anyone able explain why which run-level the application has apparently determines which Program Files directory is used ?
Regards,
It could just be a legacy thing and a
%PROGRAMFILES%
mix-up. The easiest fix would be to use a symbolic link, like so:mklink /j "C:\Program Files(x86)\Q_Kassa" "C:\Program Files\Q_Kassa\"
This way, it'll work no matter where the program "thinks" it really is. Also, note that if it has to write to this program files folder, you'll need to be elevated for it to work properly. Windows does do redirection to a "VirtualRoot" folder, but it's messy at best.