Win7 64Bit 1

[newtofoxpro]

myapp (VFP8) is running on xp. Today at remote site I installed myapp having os win7 64bit. Sorry I could not note complete error message. But I immediately go#ogle error message and I found solution.

http://www.activehelper.com/Common-...les-x86-access-is-denied-second-solution.html

I setup in OS as described, and problem solved. But, is this problem can be solved it-self VFP8.0 ?

Anybody face this problem or I am installing runtime files / config.fpw wrongly ?

Thanks
Best Regards

 

[DSummZZZ]

So much depends on where and why you're getting the error. If you're installing files there, you probably shouldn't be, other than certain registered .DLLs or something. You shouldn't be installing anything there that needs to be updated regularly.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Olaf Doschke]

The article you link to decribes how you turn off UAC, which in clear text means how you lower security. You need administrative privileges, and if you have them in your app, you wouldn't need to turn down the UAC level, but then your app and it's process would be a honeypot for viruses seeking higher priviledges.

The solution is to not write into program files. For example the start of a foxpro generated EXE creates a foxuser.dbf, you can solve that by installing it in the first place, or have RESOURCE=OFF in your config.fpw. You should not write data to Program Files, this is purely for executables, and they won't change, therefore the whole system folder is setup, so users can read and excute files inside, but not write.

You should put your data into user specific or allusers applicatiodata system folders and if you want to support foxuser.dbf can also put that into such system folders users are allowed to write to. There are many ways to determine such system folders. The main API changed from since VISTA from CSIDL to KnowfolderIDs, but the principle is the same and in both OS versions you can eg use Foxpros GETENV("USERPROFILE") to get the root folder of the current user and GETENV("ALLUSERSPROFILE") for the allusers profile. Indeed on Vista/Win7 that does not return C:\Public, but C:\Programdata, which is for all users app data. It's an unwritten law you add your company or application name as subfolder and only put further files there, see yourself how Microsoft themselves and other vendors create what folders in there.

Bye, Olaf.

 

[newtofoxpro]

As I installed myapp.exe at remote users computer (win7-64bit). I don't have access after installation. Please give me time to experiment advised information.
Thank you & Best Regards.

 

[Olaf Doschke]

Well, this is something you do in your setup, you can add system folders to the seup project in a node called "destination computer" or similar. and then can put foxuser.dbf or anything like that there. The GETENV("ALLUSERSPROFILE") would be code you need to find that folder in your application.

Bye, Olaf.

 

[newtofoxpro]

Well, this is something you do in your setup"

Inno setup script.

Source: C:\Program Files\Common Files\Microsoft Shared\VFP\GDIPLUS.DLL; DestDir: {sys}; Flags: regserver uninsneveruninstall sharedfile onlyifdoesntexist noregerror
Source: C:\Program Files\Common Files\SureThing Shared\MSVCR70.DLL; DestDir: {sys}; Flags: uninsneveruninstall onlyifdoesntexist
Source: C:\Program Files\Common Files\Microsoft Shared\VFP\VFP8R.DLL; DestDir: {cf}\Microsoft Shared\VFP; Flags: regserver sharedfile onlyifdoesntexist
Source: C:\Program Files\Common Files\Microsoft Shared\VFP\VFP8T.DLL; DestDir: {cf}\Microsoft Shared\VFP; Flags: uninsneveruninstall onlyifdoesntexist
Source: C:\Program Files\Common Files\Microsoft Shared\VFP\VFP8RENU.DLL; DestDir: {cf}\Microsoft Shared\VFP; Flags: uninsneveruninstall onlyifdoesntexist
Source: C:\WINDOWS\System32\mscomct2.ocx; DestDir: "{sys}"; Flags: regserver sharedfile restartreplace

At my main.prg
1'st line is set reso off

 

[Olaf Doschke]

>At my main.prg
>1'st line is set reso off

That's too late, already.

VFP's runtime writes the foxuser.dbf before you get control in your first line. What is evaluated before that is config.fpw, and so you have to put that in there, if you don't want to support foxuser.dbf features (for example the runtime stores windows positions in there, you could add data for intellisense at runtime, a modified printer preview menu and much more).

It's okay, if you don't want or need foxuser.dbf, but then you need RESOURCE=OFF in a config.fpw, either you put it in the setup or even include it into compilation and thereby include it in the EXE.

Bye, Olaf.