Problem with SET DEFAULT TO 2

[Bryan - Gendev]

In my app ( written 10+ years ago and now being revised and checked) I have a need to change the default folder on a number of occasions. I use SET DEFAULT TO (cNewfolder) and this works on every occasion except one which I am now trying to resolve. I need to be placed in a certain folder in this instance to make a backup of an ini file before changing the current ini in a certain way - allowing the current ini to be restored later.
I don't know if this is the problem but the path required is like
C:\Users\username\AppData\Roaming\the_target_ini_appnameI am unable to set my default to this folder to backup the ini file which resides there using COPY FILE (file1) to backupfile1.txt.
Can anyone advise me on this?

GenDev
Adelaide
South Australia

 

[Bryan - Gendev]

Chriss,
Some answers to your questions etc
1
C> TMG9.exe is still also the old software and nothing could have changed? Are you sure it has no self updating mechanism?
No -the last exe produced is way back on 03/12/2014.Shown in properties of tmgv9.exe

2
c>I guess we're at a point where - at least as of today - your backup works,
Well, I have to disagree with that. Wizfile finds a requested file right across all drives as soon as it is created and I don't see the bak file anywhere. This takes wild cards and is hugely useful when looking for a particular file on the PC. I tested it on a file I see in a roaming folder and it finds it OK.

3
C> ? FileToStr(lcVirtualStore+"\vfpgenerated.bak") - this line in your test program generates an error.'File does not exist'

4 I have UAC on 'Never notify' - maybe I should change it to a higher setting? I don't know when this was set.

5 In your previous test code I can't get past the SET DEFA line = when I force it in the debugger I get an error on the COPY command.
6 In my folder C:\Users\bryan\AppData\Local\VirtualStore\Program Files (x86)\BeeSoft - I only see 2 entries both made some years ago.
7 In C:\Users\bryan\AppData\Local\VirtualStore - I only see folder entries from some years ago.
Regards
GenDev

 

[Bryan - Gendev]

Chriss,

On further inspection when running your code

* Files will not be seen here <<<<<<<<<<<<<<<<<<<<<<<<<<<they are
Run /n explorer.exe "&lcProgramFiles"
* As redirection put them into your VirtualStore folder<<<<<<<<<<<<<<not visible here
Run /n explorer.exe "&lcVirtualStore"
and the end result message is

GenDev

 

[Chris Miller]

Do you have UAC off?

Chriss

 

[Bryan - Gendev]

See 4 in my post above.

GenDev

 

[Chris Miller]

I'd like to know which line errors.

So rerun this:

#Define CONTENT 'test'

On Error ? Lineno(),Error(),Message()
lcSafety = Set("Safety")
Set safety off

Local lcProgramFiles, lcNewFile, lcBackupFile, lcVirtualStore

lcProgramFiles = GetEnv("ProgramFiles")
lcNewFile = lcProgramFiles+"\vfpgenerated.txt"
lcBackupFile = ForceExt(lcNewFile,"bak")

If StrToFile(CONTENT,lcNewFile)=Len(CONTENT)
   ? 'File created'
   Copy File (lcNewFile) TO (lcBackupFile)
   ? 'File copied'
EndIf

If FileToStr(lcBackupFile)== CONTENT
   ? 'Copy verified Ok'
EndIf

? File(lcBackupFile)

lcVirtualStore = GetEnv("LOCALAPPDATA")+"\VirtualStore\"+JustFname(lcProgramFiles)

* Files will not be seen here
Run /n explorer.exe "&lcProgramFiles"
* As redirection put them into your VirtualStore folder
Run /n explorer.exe "&lcVirtualStore"

* nevertheless redirection also works when reading from the path where the redirected file doesd not exis:
? lcBackupFile
? FileToStr(lcBackupFile)
? lcVirtualStore+"\vfpgenerated.bak"
? FileToStr(lcVirtualStore+"\vfpgenerated.bak")
Set Safety &lcSafety

And then it would also help to see a screensahot of the outputs until that error happens for you.

There are other open questions, too, gendev.

Chriss

 

[Bryan - Gendev]

Chriss,
Please see my post in the other thread.

GenDev

 

[Bryan - Gendev]

Chriss,

I did not get an error.
Here is the output

Dinner now.

GenDev

 

[Chris Miller]

Gendev,

you did get the same error, just this time it triggered the ON ERROR Code and printed the line
36 1 Flie does not exist.

Line 36 is

? FileToStr(lcVirtualStore+"\vfpgenerated.bak")

So file redirection doesn't happen. I guess because you start the IDE/VFP9.exe itself elevated, which means it can write into Program files and writing files there is not redirected.

Okay, but forget about that. After all the suggestions made not only by me to find your problem, I think it's better to see what you actually need and trash your old code in favor of something that works. I'll make a suggestion in a separate answer, though.

Just some final pointer about that to

https://learn.microsoft.com/en-us/w...ion-control/user-account-control/how-it-works

Besides explaining essentially all effects of UAC, also the ones not of interest, in the section Virtualization states that:

Virtualization doesn't apply to apps that are elevated and run with a full administrative access token

That's also part of the problem that I subsumized by saying

There are more situations this is unhelpful than this is helpful, if you ask me.

One of the reasons is that when you run a setup that is not effected by file redirection as setupüs run elevated. When the application later runs under normal permissions it may be affected by redirection and having no access to files the setup successfully managed to place where the developer intended them to be, but not where an unelevated process can access them.

Don't get me wrong, I'm not saying setups shouldn't have these privileges, of course even since way before MS invented the UAC mechanism to fool help us all, the setup needs to write into Program Files, of course, besides other usually restricted places. There's an obvious way to make use of that to solve your problem, and maybe I/we should have suggested what makes your necessary code as simple as it can be: Set permissions during setup.




Chriss

 

[Chris Miller]

OKay, as I said in my previous post, here's a suggested solution which could do away with all previous suggestions and questions and analysis of problems.

What would make your code a few lines that work withjout problems is simply setting permissions to files as necessary during the setup process of your software. As you are using Inno for that, I assume it's not a big deal to figure out how to script setting permissions to both files your setup puts into the installation directory of your software and also to already preexisting files like the INI of TMG9.exe, during setup you have all the power necessary to do that.

For already installed systems, this could still be done by a setup you generate as a kind of service pack. Plus: You need an upgrade setup for the new EXE with code changes, anyway.

Okay, here's what I collect from the thread you need:

1. Make a backup of the INI of TMG9.exe
2. Modify the INI
3. Start TMG9.exe while the INI has been changed
4. Reinstate the backed up INI so the next TMG9.exe start is uneffected.

All that is essentially simple code, once you have all necessary permissions:

COPY FILE (fullfilenameofINI) TO (backupfilenameofINI)
* Code to modify the INI
* Code top start TMG9.exe
COPY FILE (backupfilenameofINI) TO (fullfilenameofINI) 
[s]COPY FILE (fullfilenameofINI) TO (backupfilenameofINI)[/s]

If you want to stick to your old ways, you can add changing directory and setting that back instead of simply using full names. Note that the limitation of VFP to access directories with too long names applies no matter if they are fully qualified or you split up changing to a directory. As far as I see this limitation is not the reason of failing anyway.

Of course the code to modify the INI surely are a few more lines, but starting TMG9.exe likely also is just a RUN command, isn't it? So besides the INI modification it's a three liner.

And it works as long as you have write permissions to the directory and the INI file, which you can either do manually or let a setup add those permissions to the group of standard users, for example, or simply to everyone. Giving that permissions to the directory where TMG stores its INI is, of course, a bit excessive and outside your own territory, but I don't see how you can get around that anyway, even if we find out how to let UAC mechanisms do what is intended to solve the problem of legacy software without changing the software or permissions, even then you need write acccess to the INI of a third party software. No matter if you package it within your own setup or recommend users to install it alongside your application, that's strictly speaking out of your own territory, but you restore the INI anyway and you do it as a comfort function to make it easier for users, so why not.

If that idea still fails, then it may be your INI modification isn't working anymore, because TMG uses other keynames, sections or other changes of the INI meaning. That's something we didn't even get to until now.

I think that's the simplest solution, give your software the permissions it neesds during your setup/update.



Chriss

 

[Bryan - Gendev]

Chriss,

Thanks for your assistance.
I lost my last post before posting <sigh>
C> TMG uses other keynames, sections or other changes of the INI meaning.
G>TMG ini hasn't changed since 20??.

C> Of course the code to modify the INI surely are a few more lines, but starting TMG9.exe likely also is just a RUN command, isn't it? So besides the INI modification it's a three liner.
G>Thats right - in my code.

C> give your software the permissions it needs during your setup/ - and
And it works as long as you have write permissions to the directory and the INI file,
G>Well I don't know how to do that in INNO - I'll research. But as I showed above I seem to have complete access/full control to the Roaming/TMG folder.
PS I am user bryan as an administrator on my dev PC.

GenDev

 

[Chris Miller]

Bryan, a user of the administrative group on a system since Vista does not have all access permissions anywhere all the time, that's what UAC changes. You likely start VFP elevated and your EXE not, that's making a big difference.

Your exe only works, as if you where a normal user, not a user of the admin group. And that's the way since Visa.

Chriss

 

[Bryan - Gendev]

Chriss,

C>that's making a big difference
I expect that the individual user would choose to run a program as an administrator rathger than a normal user. I am not sure how that would impact on what we are dealing with in relation to the Roaming folders?

GenDev

 

[Chris Miller]

I expect that the individual user would choose to run a program as an administrator rathger than a normal user.

I already told you that that doesn't help.

The deal with administzrative permissions since Vista is, it's not eniough to be Admin.

You can embed a manifest with an essential information, that an EXE require administrative elevation, that's described, for example, here:

https://west-wind.com/wconnect/weblog/ShowEntry.blog?id=890

I think there's a whitepaper or blog post fromn Rick Strahl that describes this for the special usecase of easily embedding a changed manifest. What I remember is that having a file your.exe.manifest within the soma folder as the PJX and side to side by the EXE that's generated by a build, this manifest is embedded into the final EXE without needing tools like mt.exe to postprocess an EXE.

The normal manifest embedded into a VFP9 built excecutable is this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity 
	version="1.0.0.0" 
	type="win32" 
	name="Microsoft.VisualFoxPro" 
	processorArchitecture="x86"
/>
<description>Visual FoxPro</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
	<security>
		<requestedPrivileges>
			<requestedExecutionLevel level="asInvoker" /> 
		</requestedPrivileges>
	</security>
</trustInfo>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            language="*"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
        />
    </dependentAssembly>
</dependency>
</assembly>

And what you need to enforce an EXE to run elevated is a changed manifest in the security section:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity 
	version="1.0.0.0" 
	type="win32" 
	name="Microsoft.VisualFoxPro" 
	processorArchitecture="x86"
/>
<description>Visual FoxPro</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
[highlight #FCE94F]	<security>
           <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
             <requestedExecutionLevel level="requireAdministrator"
                                      uiAccess="false" />
             </requestedPrivileges>
        </security>[/highlight]
</trustInfo>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            language="*"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
        />
    </dependentAssembly>
</dependency>
</assembly>

Either that, or you create a shortcut to the EXE that runs it "as Adminsitrator", which means an elevation dialog will appear at the start.
Notice: This will not automatically give the process with that manifest an elevated status, the requireAdin means Windows will ask the user to allow this, if he's a user of the administrative group or show a login, with which a user could switch the invoker of the EXE to be an adminstrative user, which also requires the password for that administrative user, so the minfest is not elvation in itself or a free ticket. I don't know from the top of my head if the EXE would run anyway, without elevation and with all limits that has or whether it would then not start at all.

But to get to the essntial point of the reason such manifest and their security tags were introduced: An admin is not running anything as an admin anymore, that's a changed security concept since Vista. If you don't believe me, than I can't help you. Let me see if I can find it explained in mopre detail and officially from MS:

https://learn.microsoft.com/en-us/w...ion-control/user-account-control/how-it-works

Hm, well, this is the link I posted earlier, already. I don't know why you ignore so much that's already told to you. I think you can't believe it since you know otherwise. Yes, it was otherwise before Vista, but not since Vista, and Vista was released 2006.

You have configured your UAC setting to "never ask", so you're suppressing some things, but you can't expect anybody to have your setting. And your setting also doesn't make the admin exyperience 100% as it was befrope Vista, you just don't realize when you're elevated and likewise when not.

You should always program in a way a normal user can use your application, otherwise you're undermining the security of the users system. So I explicitly tell this here: While I show how you can embed a manifest that will make it easy for adminstrative users, this should only be foreseen within executables that have an adminstrative nature, not for a normal application. You can set permissions on just the one INI and its folder and thereby also act in foreign territory of TMG, but limit your intrusion into the security decisions of a user or MS to an acceptable level. So I'd still recommend that.

In short: I wouldn't use an application that asks me to elevate it at the start, other than a setup I verify by signature or at least checksum to be a trustworthy unmanipulated setup. Other things like sysinternal tools or other adminstrative tools, but not a normal application. Get it done in a way a normal user can use your application.

Chriss

 

[Chris Miller]

One more thing: You can easily determine the elevated status of an EXE (or also for the VFP IDE, for what it's worth) with an easy call af a Windows API function IsUSerAdmin (part of shell32):

If you google for it you see it mentioned in a white paper by Doug Hennig and in blog posts of Rick Strahl, too, with added checks whether the function exists in the shell32 system DLL. Well, since Vista it does and I don't see a reason to check for XP or earlier anymore. But OS() could help with that, too.

Anyway, the core thing this would help with is verifying that an EXE with a manifest requiring administrative elevation actually is elevated. So if you need to ensure you, you can be double sure about it.

There's another way to manually see this in the task manager process list, you can add a column "Elevated" besides "UAC virtualisation":

Here you can see I started two sessions of VFP9.exe with the same user account, once elevated and once not.
Executing this in both sessions I get the following result:

Declare Integer IsUserAnAdmin In shell32
? _vfp.processid, IsUserAnAdmin()

This shows:
1. IsUserAnAdmin() reflects the elevated status of the current process (0=No, 1=Yes, also compare the processid=PID from task manager and VFP screenshots).
2. IsUserAnAdmin() differs and is not just telling whether the user (in both cases my user account ChrissM) is in the admin group or not.
3. Obvious from both 1 and 2: A process does not automatically gets the users' privileges.

Chriss

 

[Bryan - Gendev]

Chriss,
I see the results shown above in your post when I open vfp 2 ways however I don't see the Task Manager/Details column on UACsettings.
So using the vfp9.exe process in the Task Manager and selecting Properties/Compatibity - I can see Run as Administrator but no option to add UAC settings.
From all of your excellent content above I have the following questions
. Should I normally run vfp9.exe as administrator?
. Should I normally use UAC to the full?
.Should I add your manifest file when compiling?
.Can I really set INNO to allow me to read and write into the Roaming/TMG folder?

As an 82 year old I am doing my best to follow your writings.
Regards
GenDev

 

[Chris Miller]

0. I don't see the Task Manager/Details column on UACsettings.

I said you can add a column "Elevated" besides "UAC virtualisation". Right click on the column headers and pick "Select columns" from the context menu. then check the columns you want to see.

1. Should I normally run vfp9.exe as administrator?

You can, you don't need to. One advantage is olepublic classses will be registere, when you compile. One disadvantage is, you can't test under real conditions as an elevated process can do things an unelevated EXE can't. So there will be a discrepancy from testing vs later EXE functionalities.

2. UAC is your decision, For security you have it at it's default or stricter, you loosened it. Make what you want of it. Just like 1 it adds to the discrepancy of test vs reality, not on your development computer, but in comparison to the rest of the world.

In summary to both 1 and 2. All settings can make sense, why would they be configurable if only one option or combination nmakes sense? It depends. Make everything with an awareness. Your questions indicate you don't want to decide and get a recommendation instead, I have to disappoint you, depending on what you do and want to test all things make sense.

3. Should I add your manifest file when compiling?
I alread answereed that question, please jhust reread.

4. Can I really set INNO to allow me to read and write into the Roaming/TMG folder?

Yes, setting permissions on files is a normal feature of any setup tool. Again, I already told everything about this in my recommendation to not use the modified manifest, even though I showed it to put all the options on the table and get into your head that an admin account isn't the same thing as it was previous to Vista, the manifest is also a new feature that - again - was introduced with the major changes MS mnade to Windows with Vista.

Chriss

 

[Bryan - Gendev]

Chriss,
Task Manager in WIN 11 does not offer the UAC info column - I wonder why? I see it on wife's WIN 10 Task Manager.

I have added the IsUserAnAdmin output to my log file -
(extract from log)
21:23:08 Starting PathWiz! ver. 11.0.0 20240611_at_21-23
21:23:08 Operating System - Windows WIN64 bit
20:59:27 Computer details
20:59:30 CurrentClockSpeed: 3101
20:59:30 Manufacturer: GenuineIntel
20:59:30 MaxClockSpeed: 3101
20:59:30 Name: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
20:59:30 Current Display Resolution : 1920 x 1080
20:59:30 PID 2676 User <<<<<<<<<<<<<<<<<<<<<( Note other option Administrator)
21:23:09 C Local hard drive
21:23:09 D Local hard drive
21:23:09 I Local hard drive
21:23:09 P Local hard drive
21:23:09 T Local hard drive
21:23:09 U Local hard drive
21:23:09 Z CD ROM drive
21:23:09 Strings Date is 06-Apr-10
21:23:10 Splash screen closed
21:23:13 Log File View


I see no change whether PathWiz is started elevated or not.

GenDev

 

[Chris Miller]

Whoi talked about PathWiz?

Chriss

 

[Bryan - Gendev]

Chriss,

I have mentioned Pathwiz before in this thread. It is my application which ideally can access the roaming/TMG folder to modify the tmg.ini file.
FYI The WIN 10 version of Task Manager is available in WIN11 at C:\Windows\SysWOW64\Taskmgr.exe - to get the UAC virtualisation state on a process under the Details tab.

GenDev

 

[Chris Miller]

Gendev, thanks for the clarifications.

You mentioned Pathwiz before, yes, but that's the first time I hear this is the name of your own application. Also, I confused it with WizFile, the tool you mentioned somewhere and showed a screenshot.

Okay, so you tried to use your own application elevated and this doesn't solve access to files.

Still, the now golden final idea of creating a setup that sets permissions on the folders and files you need to access to a) backup the tmg ini b) change the TMG ini will neither need elevation nor admin permissions, because giving the permissions to normal users will cover any situation. You don't seem to realize that I consider this suggestion the straight forward solution as it makes everything independent of several other settings, it also won't matter then, whether UAC is on or off, strict or loose. You simply have permissons on the files and folders, SET DEFAULT, copy and change the INI.

Anything else afterwards is just to teach you how things changed. And that wasn't just in recent years, but since Vista. So it does not explain why your 10 year old state did work 10 years ago and not now. I have given up on finding out why. One last thought: You storer paths in a DBF char field, which has trailing spaces you need to remove, but that's also something that would have not worked 10 years ago.

Anyway, it's much more important to get your application going now, isn't it? So finally, the straight forward solution is to set permissions and make that work comlpetely wwindependent on elevation or UAC settings.

Chriss