Add a manifest to control your application Vista UAC behavior

Try this on Windows XP or Vista (I don’t remember if manifests are allowed on Win2000: can someone confirm please? Thanks)

Start Notepad, then choose File->Open and navigate to c:\windows\system32\notepad.exe and click Open.

Hit Ctrl-F to find the text “assembly”

You’ve now found the embedded XML manifest file.

Try the same with VFP9.EXE, then an EXE that you have built with VFP9

On XP, this manifest can specify additional dependencies. For VFP9, it indicates which version of Windows Common Controls to use. For an EXE that VFP built the manifest is the same as VFPs.

On Vista, this manifest can further specify security requirements for an application.

For example, on Vista, applications are not allowed to write into “Program Files” or Windows directories. Similarly with the registry. Some applications will attempt to write these.

If there is no requestedExecutionLevel, then the registry and file virtualization will be turned on. The program “thinks” it’s writing to “Program Files”, but it’s really writing to C:\Users\<username>\AppData\Local\VirtualStore\Program Files. The registry redirects HKEY_LOCAL_MACHINE\Software to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys>

You can further control Vista UAC settings by running secpol.msc and navigating to Local Security Settings->Local Policies->Security Options

Try this on Vista: Start->Run->Cmd. Try to write a file to Program Files or Windows directories-> “Access Denied”

The MT.EXE tool that ships with Visual Studio or the Vista SDK can allow you to embed a manifest as a Windows Resource in an EXE file. Historically, only a Linker could build and manipulate a Windows Resource. Starting with Windows NT, the resources could be manipulated from within a program using the BeginUpdateResource family of functions.

Foxpro EXE files have been built the same way for about 18 years: using a Fox resource architecture. There is a stub loader, and 0 or more sections (such as the .APP) physically appended to the file. Windows tools that manipulate the EXE file format do not pay attention to any data appended to an EXE file, so when these tools write out the result, they do not write out any additional data. With no APP, the loader merely puts up a File->Open dialog requesting an APP to run.

These Windows Tools use the BeginUpdateResource family of functions, but Foxpro could not, because it still had to run on Windows 95 as well as NT

Starting with VFP8 (I think) VFP was able to add a generated Type Library as a Windows Resource inside a DLL, using the BeginUpdateResource functions. Now you know why this feature doesn’t work on Win 95.

When TestVista.exe is built with <requestedExecutionLevel level="requireAdministrator" />, an admin elevation prompt will show as expected when we issue the following the command in the VFP Command Window:

Run /n TestVista.exe

However, error will be got when the same command is issued inside another VFP EXE file. What makes the difference? Actually, calling any EXEs (e.g., a setup program) which require admin elevation within a VFP EXE (rather than the VFP Command Window) will result in the same failure, no matter the EXEs being called are VFP EXEs or not.

In order to successfully run such admin-elevation-required EXEs inside a parent VFP EXE, we have to use the following workaround. However we will get an annoying DOS window.

cCmd=GetEnv(‘ComSpec’)+’ /c TestVista.exe’

Run &cCmd

If an elevation-required VFP EXE can successfully be run within a parent VFP EXE (without the annoying DOS window), it could be a solution (although not a perfect one) to the problem raised by Olaf doschke.

The link "Creating a Manifest for Your Application" is broken. Use this one instead: http:/msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/e84fe257-5160-4537-a8ea-e780f8774d5c.asp

in order to better understand what’s up with VFP 9, manifests and Vista I ran some tests using your code above. Then I began to change the code and wrote some code of my own to export the standard manifest included in a VFP 9 exe. The results are called ExportManifest.prg, ClearManifest.prg and ImportManifest.prg. I wanted to share these ‘ManifestTools’ with the community and published them on my website: http://www.bingo-ev.de/~mw368/vfp9_vista.html I hope you don’t mind.

I have used you code to add a manifest to my VFP exe for several months with great success. The size of my exe has now increased to 17+ megabytes and now I am unable to use you code to create a manifest. It is crashing on the line asec[i]=FREAD(h,sz) with the error "function argument value, type, or count is invalid". At the time of crash, i=1, h=37, and sz=17,779,509. Any advice?

1- That I changed the version to match that of my application. It worked on Vista and Windows2003 and stopped working on XP with some "generic" message "The application cannot start because there’s an error in the configuration".

After two days of looking around on the internet thinking that it had to do with DLL dependencies, we found out that it was the "version" format. I changed it to something like 7.2.0 and the manifest expect 4 numbers, so making it 7.2.0.0 finally made work. I’m very disappointed that Microsoft considered that worth not running the EXE.

2- After signing the code (with authenticode) so that Vista doesn’t nag about "unknown publisher", the embedded manifest no longer worked, meaning, that it no longer considered the security in Vista to be "asInvoker". Instead, it assumed that it required Administrator privileges all the time. I read somewhere that’s the "default" for applications with no manifest. So this lead me to believe that the embedded manifest was no longer good (after signing the exe). So I had to just create the manifest and DON’T embed it with the exe, instead just send it side by side with the exe, by just changing the name to the name of the exe with .manifest at the end. For example if the exe was myapp.exe, the manifest was myapp.exe.manifest

If you embed the manifest and then sign the exe, the manifest no longer works in Vista.

There is currently a big incompatibility between MS FS X and Visual Studio. So how to create a manifest that FSX should use a specific version of mfd80.dll. The original one is replace by visual studio 2008. Any idea?