0

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,

EEAA
  • 109,363
  • 18
  • 175
  • 245
Entity_Razer
  • 475
  • 1
  • 5
  • 17
  • Have you tried running the application in Compatibility Mode? http://windows.microsoft.com/en-gb/windows/make-older-programs-run#1TC=windows-7 – BlueCompute Sep 24 '14 at 12:04
  • Yes, no avail, we keep getting the same error being that it can't find the file in C:\Program Files\filename – Entity_Razer Sep 24 '14 at 12:06
  • 1
    The software is probably accessing the %PROGRAMFILES% environment variable. Check the output of `set` from a command prompt opened as admin vs. normal user. You may be able to resolve it by changing the variable. If not, can you just copy the software to C:\Program Files? I don't think there is any enforcement of 64-bit binaries for that directory. – dartonw Sep 24 '14 at 12:39
  • @dartonw The value of that variable changes depending on if the program is running in native 64-bit mode, or in WoW 32-bit mode. This program is probably *not* checking that variable correctly and has it hardcoded somewhere in the program (likely in a place of no significance, and simply doesn't care if the folder doesn't exist, but throws red flags if it can't access the non-existent folder) – Chris S Sep 24 '14 at 14:23

1 Answers1

3

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.

Nathan C
  • 15,059
  • 4
  • 43
  • 62