New install of VFP 9.0, can't edit config.fpw or PRGs in HOME() folder

[dmusicant]

I made a fresh install of VFP 9.0 SP2 this afternoon on a machine I just acquired.

I don't recall having difficulty doing this before. After installing VFP 9, I typically do this:

MODIFY COMMAND SYS(2019), but this time I'm denied the ability to save. Same thing happens when I try to change a PRG, also existing in the home directory, which is where I like to keep my configuration files (config.fpw, a single PRG that sets my path), and a certain memory variable file.

Is it because I let VFP set itself up in the default directory C:\Program Files (x86)\... ???

Usually I change this to my own directory, perhaps C:\Programs\...

I went into security and the files allow full access to administrators, I'm the only user and I'm an administrator. Yet, I cannot change the files either with VFP or by opening with a different program. Access is invariably denied.

The only workaround I've found for this is to have the files elsewhere, edit them there and copy them back into the home directory after deleting their former versions. Of course, this sort of thing is quite cumbersome. Worse, perhaps, is the fact that my application changes the contents of the .mem file and I anticipate errors when this is attempted.

This machine is running Vista Business 64bit.

Thank you for help.

 

[Olaf Doschke]

This is Vista and higher. Even if you are admin there is UAC only allowing changes with confirmation and when you edit a prg or compile it and create an frx nmo uac dialogs prompting for confirmation pop up, but files are written redirected to the users virtual store instead of HOME(). Look into %USERPROFILE%\AppData\Local\VirtualStore\Program Files (x86) and you'll see all things already having been written redirected.

The best idea is really to install into C:\users\public\vfp9\ to avoid that problem.

Bye, Olaf.

 

[Mike Lewis]

One option would be to manually create the Config.fpw in another folder, and then to reference that folder from the -c switch in the shortcut that launches VFP. Once you have done that, you will no longer need to be aware of it, since VFP will automatically pick up the Config file each time you launch it from the shortcut.

Another option would be to dispense with the Config file entirely (in the development environment), and instead set the various paths, etc. in the Tools / Options dialogue. This wouldn't affect your compiled applications; these could still have their own Config files if necessary.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

OMG... well, I finally got the machine doing pretty much what I want it to do in terms of Foxpro, but it might be nice to be able to change those files more easily. I may not bother to alter the current setup, this is just a machine to use a couple of apps and they are running OK now... I think. But for future reference, these ideas are appreciated. I don't know why I didn't have these problems, at least to this extent, on my Win7 machines. For instance, the machine I'm using right now is Win7 Home Premium 32bit and VFP is launched at "C:\Programs\Visual FoxPro 9.0\vfp9.exe"

Is that launch point less subject to the UAC warnings than C:\Program Files (x86)\ ???

 

[Olaf Doschke]

If you mean this literally, you installed into a user created folder with a name quite similar to the system folder. Still C:\Progams\ is not C:\Progam Files\. That is not under the influence of UAC, which still exists in Win7, 8 and 8.1

Bye, Olaf.

 

[dmusicant]

Aha, so my system of installing in my own-created folder has served another purpose than my original intention, which was just to segregate programs initially installed in Windows from ones that I installed personally.

The UAC's, I suppose they have their purpose, their value, but AFAIK, they haven't helped me. When I go to install or update something I'm not in doubt about what/why I'm doing it. That's not to say I'm a security guru, so far from it. I now regret having installed VFP 9.0 in the default folder. However, I may leave it be for the time being, that machine shouldn't need changes often if at all in its intended usage.

Thanks for the information, it's been very helpful.

 

[Olaf Doschke]

The thought behind UAC prompts in short: Computers don't have an awareness. Windows can't really tell if you or some remote hacker or a malware you have is causing some setup, so it asks you to confirm your action.
You'll be glad in a moment you did nothing but such a prompt appears and you can deny something to happen.

Back in the 90ies every install had full access during install and could give all rights to its own exe as it wanted and there simply was automatic trust and though there already were hackers and viruses and spyware, there was no doubt a boxed program version from a vendor is trustworth.

Nowaday on smartphones app installations tell users which features they access and ask to confirm. A music player wanting access to microphone and camera would be suspicious. Most people still simply confirm the features and don't care.

If you want, you can turn UAC off. You have that freedom, MS doesn't force its security upon you.
You can also run your computer without a virus scanner.
You can keep your house door open and you can replace a burnt fuse with a screw.

It's all up to you.

Bye, Olaf.

 

[dmusicant]

Olaf, thanks for the patient and very interesting explanations. The last part had me laughing! I don't leave my doors open often, especially the front door! There are very often peculiar people roaming my neighborhood, and crime is a problem locally, so it's best to be wary, sad to say, but let's be realistic. Fortunately, the fuse boxes we used to have were replaced by circuit breakers!

I leave UAC's on. Yes, they are a bit of an annoyance, but as you say the day may come when I see one that prevents real problems. I like your description of allowances you wouldn't want (microphone and camera for music player). The UAC's I've been seeing when installing apps for my Nokia Lumia 520 have pretty much all been for location. I usually think "why would they want or need to know my location?" But I allow it anyway. I frequently check out the daily freebie available with MyAppFree. I've gotten some very good ones there and a bunch I haven't even opened and investigated (as of yet). Today's is Battery Indicator, which I figure I will download. I already have several battery apps on the phone (I use one of them usually more than once daily), but this is free, so why not have a look, I might like it. I can always delete it.

 

[dmusicant]

I should have known better than to install VFP 9.0 in the default location. I'd noticed mind boggling security features before when installing there and stopped doing so. But it was quite some time ago and the other day when installing, I let Windows put it where it wanted to go (did a bit of research first, found out that 32 bit applications are put in \Program Files (x86), so figured that would be OK. Next time I'll install in my own directory like I used to.

 

[Olaf Doschke]

Just one thing, even though you don't want to turn off UAC: If you do some of the redirections mean loss of files.

In detail: If you write to system folders the redirection of writes does not only mean the write operation generates a file copy in your user profile VrtualStore folder, read operations also read from there. Turning off UAC means you don't read from virtual store anymore. So either you would need to manually copy back VirtualStore files to the real location or you lose these changes (if there was an original file) or the whole file (if it was written/created in software usage, not initially).

In the end once you install software in some UAC mode you better stay with it. You get all kind of wird effects when playing with the setting.

As Mike noticed you don't need config.fpw for most things settings are written to registry, but a similar redirection as for files also applies to registry settings.

Bye, Olaf.

 

[craigber]

One other big consideration. If you write software for others and you use a different folder for application or run with UAC off, the application may not work correctly on another PC. You should never require that other users install your app somewhere other than Program Files or Program Files (x86) or that other users run without UAC.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog