[RESOLVED] Writing to %program files%, UAC, Manifests, Windows Styles

Windows seven won't let me write text files to the program files directory (without virtualisation), so I need to find an alternative.
I was thinking of a common area, although the file should not be able to be changed by the user, only a member of the admin group...

This link shows that CSIDL_COMMON_APPDATA might work to allow any file created to be read only by users and updateable only by those with admin rights.

http://msdn.microsoft.com/en-us/library/ee419001.aspx

http://www.vbforums.com/showthread.php?t=564256

Folders created under CSIDL_COMMON_APPDATA default to "owner access" which means whatever user creates a new file there has full rights and others have read-only access.

A file created there by whatever "special user" you want won't be alterable by others.


However, and this is a big however, the actual operation will vary depending on whether your program has a manifest with a trustInfo section in it. This is required in order to declare your program "Vista aware" (and Windows 7 is really just an updated Windows Vista, make no mistake about it).

If you create a folder and a file under ProgramData (the new name for the CommonAppDataFolder) as an administrator your legacy (non-Vista aware) program run by a non-admin will be able to read and write to it. However writes will result in a virtualized copy of the original file, which is what then gets altered. From then on that user will always see their own private virtualized copy... or at least until it is removed.

You also don't need the half-page of code shown in the FAQ to retrieve special folder paths.

Just set a reference to Microsoft Shell Controls and Automation to get the Shell Special Folder constants and use a late-bound Shell object:

Code:

---

    With CreateObject("Shell.Application").NameSpace(ssfCOMMONAPPDATA).Self
        strProgramData = .Path
    End With

---

Late binding is recommended because the Shell32.dll did not maintain binary compatibility across all Windows versions.

Hmmm I just tested writing to CSIDL_COMMON_APPDATA by running my app without a manifest file in Windows seven, and while I was logged into an account with admin rights it could create and modify files in C:\ProgramData\My App directory without virtualisation, and regular users cannot modify or delete this file, which is the functionality I was looking for.
The strange thing was when I added another admin account, it was able to delete the files my app created even though it could not modify these files directly and as a result any changes resulted in a virtualised copy instead.

According to MS (http://msdn.microsoft.com/en-us/library/ee419001.aspx) all accounts with admin rights should have read/write permission.

It seems to me that:
Admin accounts cannot directly modify any textfiles in c:\ProgramData unless they are also the creator of the file (it results in virtualisation instead), although they can still delete any files stored here.

When I ran the my app as a compiled exe with a manifest file it allowed both members of the admin group to directly modify the text files stored in C:\ProgramData\My App directory without virtualisation (and prevented users from changing the file), and it had the same effect on files stored in C:\program files.
I was hoping that CSIDL_COMMON_APPDATA would allow me to avoid having to include a manifest file soley to alter text files linked to my application.

There are several things going on here.

• The "owner security" that folders created under ProgramData inherit.
• User membership in the Administrator group.
• Running as an elevated user vs. as a standard user.
• Having an application manifest that specifies executionLevel.
• Having an application manifest specifying executionLevel = requireAdministrator.

To make things work as you wish you need to use an "asInvoker" manifest. Then to perform administrative actions (like altering your ProgramData files) you need to run the program requesting elevation.

When run without elevation your program will encounter security exceptions (errors 70 and 75 if not others) so you'll want to trap and handle those.

It is also possible to have your program run without elevation but have certain actions (via menu, command button, etc.) that request elevation "just in time." This can be done by having the main program start a separate elevated program or even another copy of itself elevated (passing a command line parameter to tell it what it is to do this instance).

But you aren't going to get away from needing an application manifest if you want anything besides the legacy behavior - such as file and registry virtualization.

Although I can see how a virtualised ini file allows a single file to be customised for each user, most of the time it is just annoying and non virtualised folders would be a much more preferable default.

The only way I could get around virtualisation was to include a manifest file with a <trusted info> section and then a "requireAdministrator" requested execution level. Seeing as it is such a pain to get working I am thinking about using the &#37;program files% directory which is where most admins would first look for such information.

Is there no other way for all members of the admin group to read and write directly to a textfile without virtualisation?

Quote:

---

Originally Posted by Witis

Is there no other way for all members of the admin group to read and write directly to a textfile without virtualisation?

---

What do you mean by "directly" though? Are you asking about using Notepad or something?

If a program has any trustInfo level defined there will be no virtualization. In most cases asInvoker should be used. Only programs that only perform administrative functions should have requireAdministrator.


The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC) is one of the intro articles on these topics, and it has a link to a download of a CHM Help file that covers more.

Note that this article a growing old fast and some of the links are broken now. This is old information developers are supposed to know by now. There was once a whole Web site covering these topics but it is entirely gone now. It had white papers, PowerPoint presentations, videos, CHM Help "e-Books" and so on as well as links to different tools.

I can see how anyone who waited this long to start developing for Windows after XP would be frustrated. Not much to be done about it though, it's been 5 years since these materials became available.

yep, I avoided vista mainly due to all of these UAC changes - I even sold my copy of Vista, although windows seven feels more like an updated XP, so it is easier to work on.
To summarise the articles so far combined with my testing (in relation to virtualisation and UAC (user account control)):

1. Any 32bit exe running in Vista/Seven will run in legacy mode ie all vb6 exes - this means all writes to locations such as %program files% and registry sections such as HKEY_LOCAL_MACHINE will be virtualised. Virtualisation means each user gets their own virtual copy of the files/registry keys stored in these locations, making it difficult for programmers to update the files or keys for all users, as this would mean updating all the virtualised versions as well.

2. To avoid/disable virtualisation every exe, not just exes that need admin rights to perform admin tasks such as writing to %program files% or HKEY_LOCAL_MACHINE, must include a manifest files (which includes a requested execution level) in the same directory as the exe.
- For applications designed to be run by regular users this means including a text file which has been renamed: myapplication.exe.manifest which contains the following XML text designed to set the requested Execution level to "asInvoker" (minimum requirements):

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
                <ms_asmv2:security>
                        <ms_asmv2:requestedPrivileges>
                                <ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
                        </ms_asmv2:requestedPrivileges>
                </ms_asmv2:security>
        </ms_asmv2:trustInfo>
</assembly>

---

After the manifest has been created and placed in the application's directory recompile your application.
When the manifest is incorporated it tells Vista/Seven that the application is designed to run in Vista/Seven as a standard user (even for members of admin group), and legacy virtualisation is disabled.

- For applications that need to perform admin functions, change the corresponding line from above by altering one word -> change "asInvoker" to "requireAdministrator", the altered line should then be:
<ms_asmv2:requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Then place the manifest file in your applicatons directory, then recompile your application, and when it is finished there will be a blue and yellow shield displayed on the bottom right side of the icon representing your application's executable file indicating your app is now set so that only user with admin rights can run it.
Although as such an application can only be run by a user who is a member of the admins group, this manifest is therefore not suited for regular applications.

3. Even the application common data folder (CSIDL_COMMON_APPDATA = &H23) requires a manifest containing requestedExecutionLevel level="requireAdministrator" in order to write to files stored there.

4. As a result, just about every application needs to contain at least two exes:
- one for regular users with a manifest containing "asInvoker" security section,
- and one for performing admin tasks such as writing files to C:\Program or c:\AppData with a manifest containing a "requireAdministrator" security section.


Now the only issue is: which directory allows all users (both regular users and admins) to read and write to the same file in an exe using the asInvoker security tag ie where do regular data files go - perhaps CSIDL_COMMON_DOCUMENTS ("All Users\Documents")?

Well let's see what I can add to help out here. I'm surprised nobody else chimed in yet, because a ot of people have already had to deal with the issues.


1. Doesn't apply to just VB6 programs, but all 32-bit EXEs.


2. Manifests should really not be in an external file, that was originally a hack in Win XP to allow administrators (as in people administering the machines and software, not as in access rights) to override the program's compiled-in manifest. On modern versions of Windows this override doesn't work anymore, the internal manifest takes precedence.

Manifests should normally be internal. They can be compiled in just like other resources or added to the EXE after compiling through use of appropriate tools.

A program with asInvoker in its manifest runs with the invoker's token by default. For normal sessions this is a standard user token no matter what group membership the user has. Such a program can always be run as administrator by users or other programs.

A program with requireAdministrator must always run with elevated rights. Canceling the UAC prompt means the program will not run.

There is a third option: highestAvailable. This means if an admin user runs it it should request elevation, if a non-admin runs it then it is run without elevation. This is considered a hack and not meant for use when it can be avoided.

These are discussed at Step 6: Create and Embed an Application Manifest (UAC).


3. Not for users who have proper rights to access the file(s) in the desired manner. As I mentioned a number of times above, you should create your folder under ProgramData in your installer. Your installer should generally set the rights your application needs on this folder or on individual files it places in this folder.

With the proper rights (for example write rights if you want to write to a given file) no virtualization will take place with or without a manifest. In many cases you end up giving full access on the folder to the Everyone group, and any files created there after you do this will also have those rights. There are lots of different rights: read, write, update, excute, delete, etc. so "full access" is often simpler than struggling over fine granularity.


4. Very rarely should you need two separate programs.

You can either rely on highestAvailable, or ask users to run as administrator when they want to run the program for administrative purposes. The program can detect which mode it is running in and hide options that unelevated runs cannot do. This works fine but isn't the recommended practice.

Or in the preferred approach you can use asInvoker and mark admin functions in the program (buttons, menus, etc.) with the UAC shield icon. When a user requests these functions (clicks on the button, etc.) the program will perform the function by starting a separate elevated process (which triggers a UAC prompt at that point).

This separate process can be another EXE, the same EXE with a command line parameter passed to tell it what mode it is running in, an ActiveX EXE, or an ActiveX DLL invoked via the COM Elevation Moniker (which runs it in a system-supplied surrogate process).

Usually the cleanest solution is to run that second copy of the same EXE, passing it a command line telling it "perform admin function X and then go away."


As for CSIDL_COMMON_DOCUMENTS, it has the same sort of "owner" based security as CSIDL_COMMON_APPDATA. This means the same rules apply there.

There is another new with Vista special folder that does what you're asking for but (a.) it isn't really meant for what you want to do, (b.) it doesn't exist in Windows XP or earlier, and (c.) there is no CSIDL value for finding it - you have to use new Shell calls that don't exist before Vista.

Quote:

---

dillettane wrote
I'm surprised nobody else chimed in yet, because a ot of people have already had to deal with the issues.

---

You used to point out that MS had since long prepared the developers to face the new arrangements starting from Vista, but isn't it reasonable for us to expect that at the same time MS should also have a good mechanism such as a particular API for the developers to tell whether the current program user is with the elevated status ("Run As Administrator")? From the earlier threads/postings, frustrating people here seem to be just running around seeking an answer to this point, but still to no avail yet.

Not sure what you're asking for there.

IsUserAnAdmin Function always tells your program whether it has admin rights or not.

Thst was covered in the "Vista for Developers" documents that came out in 2006. It's also been mentioned around here many times.

Thank you. (I had even added an ordinal 680 for safety purpose in case Win2000). What is borthering is that MS explicitly stated that:

Quote:

---

Note This function is available through Windows Vista. It might be altered or
unavailable in subsequent versions of Windows

---

(http://msdn.microsoft.com/en-us/library/bb776463.aspx).

With a statement like that, the situation appears to be ambiguous (one tends to be reluctant to use a function in a program anticipating it might fail soon).

Yes, they don't really want you to program in ways where you'd need that call. I don't expect it to go away very soon though.

At least they offer an alternative if you want to write a few lines of code to be sure.

Hmmm, I am not so sure about the validity of the IsUserAdmin api function. In order to test it I created 3 accounts:
1. Network Manager with Admin rights
2. User with standard rights
3. A second Network Manager with Admin rights
In Windows Seven The IsUserAnAdmin function returned the correct boolean value only for accounts 1 and 2 i.e, it returned false for account 3 (the second network manager account). By contrast the IsUserAnAdmin function returned the correct boolean values for all three accounts in windows XP. I double checked these outcomes, and would thus look for an alternative function.

dilettante, I have worked my way through your post regarding manifests, uac and virtualisation, and I think you have finally answered my question.

Firstly
It was possible to include a copy of the manifest in the compiled vb6 exe by using the resource editor and following these steps:

0. Create the manifest file.
1. Critical: Make sure the size of the manifest file (in bytes) is divisible by four. If not append spaces at the end of the file and save it.
2. Select the Add-Ins menu (to the right of the Tools Menu) -> then select add-in manager -> scroll down and double click the VB6 Resource Editor (or check the load/unloaded check box).
3. Click on the green resouce editor button now displayed in on the toolbar.
4. Select the "Add custom resource" (button on the far right) then browse to the manifest file and select it.
(There should now be folder called "custom" and a file with the number 101 displayed in the resource editor.)
5. Double click (or right click -> properties) the file called 101.
6. Change the type to #24 (Critical: make sure you include the #) and set the Id to 1.
7. Then click the Resource Editor's save button.
8. Compile your application.

Secondly
I tried adding a manifest containing a security section requesting the highestAvailable execution level. As you indicated this automatically elevated members of the admins group, while regular users do not run with admin elevation unless they right click and select "Run as Administrator" and then supply admin credentials. This would allow my app to unenable or hide the admin features from regular users while allowing any admins to use the "run as administrator" functionality to gain access within a user session, or to display an "admin button" which if clicked launches an admin elevated version of the app. So why is the use of highestAvailable requested execution level considered a hack?

Thirdly
The reason for this thread was due to having difficulties regarding the permission attached to folders such as CSIDL_COMMON_APPDATA, and you indicated the easy way to deal with this problem was to allow the installer to set the directory permissions. I use inno setup and so the process was relatively painless.
In order to set folder permissions on the CSIDL_COMMON_APPDATA directory it is:

[Dirs]
Name: "{commonappdata}\test"; Permissions: everyone-modify

Where:
admins Built-in Administrators group
authusers Authenticated Users group
everyone Everyone group
powerusers Built-in Power Users group
system Local SYSTEM user
users Built-in Users group

full
Grants "Full Control" permission, which is the same as modify (see below), but additionally allows the specified user/group to take ownership of the directory and change its permissions. Use sparingly; generally, modify is sufficient.

modify
Grants "Modify" permission, which allows the specified user/group to read, execute, create, modify, and delete files in the directory and its subdirectories.

readexec
Grants "Read & Execute" permission, which allows the specified user/group to read and execute files in the directory and its subdirectories.

I tested this and it works to allow all users access to read and write without virtualisation and without any manifest, and was thus a solution to my problem, thank you. The same solution applies to writing to the HKLM section of the registry. The question then becomes: is there even a need for a manifest file at all (perhaps they are still useful for something else such as visual styles)?

IsUserAnAdmin reports the rights of the process, not the user. As far as I can tell it is always correct. "Admin" means the same thing as "elevated." Feel free to look for another function, but the preferred way is also given (with a C code sample) and does exactly the same thing.

I think you're looking at the issue wrong maybe? It means "am I running elevated?"


Of course you still want a manifest. Just to begin with it avoids virtualization, and this means that when a user specifies to write a file someplace they can't you'll get expected behavior (errors 70, 75, etc.) instead of succeeding but putting the file in a vistualized location. You need a manifest with trustInfo unless you want appcompat behavior. Another example is to avoid inaccurate legacy installer detection. This is a just do it option for development these days.

Beyond that a manifest does many other things. Visual styles are actually a byproduct of one of the things you specify in manifests: Side by Side assembly selection.

They can also be used to specify High-DPI awareness of an application, OS compatibility among current versions of Windows, registration-free COM and application isolation to help free you from DLL Hell, DLL relocation for non-COM DLLs, and many other things.


I agree that granting full permissions on a folder is usually overkill. It was just the most "eyes shut make this work" example.


As far as highestAvailable goes, it's a hack because you're expected to write applictions so they never need elevation until the user wants to perform a specific function requiring elevation. These functions should be marked with the UAC Shield icon, and request elevation only to perform that function.

In other words elevating the entire application is considered bad form. The main reason for this is that Microsoft knows darned well a lot of home users are going to always log on with an admin account. Writing programs the "right" way means they'll only see UAC prompts when required.

dilettante are you sure that IsUserAnAdmin reports the rights of the process, not the user, as according to the link you provided:
"IsUserAnAdmin Function Tests whether the current user is a member of the Administrator's group."
I feel I should reiterate my findings after checking again, in Windows Seven the IsUserAnAdmin returned false when I logged into the second network manager's account with administrator rights. If you have any code that depends on this function to determine if the user is an admin, it will break in Windows Seven Ultimate Edition and perhaps others too.

btw, I'm not convinced it is bad form to shell an elevated version of my app for admin purposes in a user session, do you have any references on that one, I would like to look into it further.

I have to agree with you regarding the potential essentiality of manifest files after trying windows styles.
Step 1: Add this to a text file

Code:

---

<?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"
  processorArchitecture="*"
  name="MicrosoftWindowStyles"
  type="win32"
/>
<description>Manifest for Window Styles</description>
<dependency>
  <dependentAssembly>
    <assemblyIdentity
      type="win32"
      name="Microsoft.Windows.Common-Controls"
      version="6.0.0.0"
      processorArchitecture="*"
      publicKeyToken="6595b64144ccf1df"
      language="*"
    />
  </dependentAssembly>
</dependency>
</assembly>

---

Step 2 Save the file as myapp.exe.manifest

Step 3 Add this code to your project's sub main if you don't have any user controls in your project (and change form1 to the name of the first form displayed in your project-highlighted in blue):

Code:

---

Option Explicit
Private Declare Sub InitCommonControls Lib "comctl32.dll" ()
Sub Main()
InitCommonControls
Form1.Show
End Sub

---

Or this code if your project contains user controls (and change form1 to the name of the first form displayed in your project-highlighted in blue):

Code:

---

Option Explicit
Private Declare Sub InitCommonControls Lib "comctl32.dll" ()
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
Private Declare Function FreeLibrary Lib "kernel32" (ByVal hLibModule As Long) As Long
Private m_hMod As Long

Sub Main()
m_hMod = LoadLibrary("shell32.dll")
If m_hMod Then
    InitCommonControls
    FreeLibrary m_hMod
End If
Form1.Show
End Sub

---

Step 4 Optional: add the manifest file into the exe via the resource editor as I previously described to internalise the manifest.

Sources: http://support.microsoft.com/kb/309366
http://www.vbaccelerator.com/home/vb...wn/article.asp

Note: Enabling a Theme or Visual Style in Visual Basic 6.0 Is Unsupported.
If you enable a Windows XP theme in Visual Basic 6.0, you may encounter unexpected behavior.
For example, if you place option buttons on top of a Frame control and then enable a Windows XP theme or visual style, the option buttons on the Frame control appear as black blocks when you run the executable file.

Although I only looked for a little time so I wouldn't be surprised it is also possible to do this without needing a manifest.

Witis,

Quote:

---

I am not so sure about the validity of the IsUserAdmin api function. In order to test it I created 3 accounts:
.....
.....

---

Sorry for getting back to you a bit late. I concur to what Diletantte has meanwhile explained; actually it was aiming at the "elevated privilege" that I made my earlier posting.

If the user is with Admin status, but has not "elevated" as Admin through "Run As Admin" or via an equiv setting elsewhere, IsUserAnAdmin would return False still.

Since IsUserAnAdmin is only a wrapper, some people directly use TokenMembership as an alternative.

I am far from being a fan of manifest (I do not program for a living and I don't intend to make my life that more complicated and difficult), hence cannot participate in the disussion on manifest deployment.

Quote:

---

Originally Posted by Witis

dilettante are you sure that IsUserAnAdmin reports the rights of the process, not the user, as according to the link you provided:
"IsUserAnAdmin Function Tests whether the current user is a member of the Administrator's group."
I feel I should reiterate my findings after checking again, in Windows Seven the IsUserAnAdmin returned false when I logged into the second network manager's account with administrator rights.

---

Yes, I am sure. It calls CheckTokenMembership based on the current process, nothing else. There is no way to "log on with administrator rights" so I'm assuming you failed to elevate the process.

Quote:

---

Originally Posted by Witis

If you have any code that depends on this function to determine if the user is an admin, it will break in Windows Seven Ultimate Edition and perhaps others too.

---

The only thing "ultimate" about this edition is the price. Could easily be called "I paid too much Edition." You get some extra stuff with it which may or may not be of value, but it is the same OS.

Quote:

---

Originally Posted by Witis

btw, I'm not convinced it is bad form to shell an elevated version of my app for admin purposes in a user session, do you have any references on that one, I would like to look into it further.

---

Go through the style guides and such. We're just laboriously reiterating what has already been published. The point is to avoid UAC prompts unless/until they're required. Feel free to do as you wish. Doing it correctly is called competitive advantage, plus it's also required for logo certification ("Designed for Windows Vista, Windows 7").

Quote:

---

Originally Posted by Witis

I have to agree with you regarding the potentially essentiality of manitfest files after trying windows styles.
Step 1: Add this to a text file

Code:

---

<?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"
  processorArchitecture="*"
  name="MicrosoftWindowStyles"
  type="win32"
/>
<description>Manifest for Window Styles</description>
<dependency>
  <dependentAssembly>
    <assemblyIdentity
      type="win32"
      name="Microsoft.Windows.Common-Controls"
      version="6.0.0.0"
      processorArchitecture="*"
      publicKeyToken="6595b64144ccf1df"
      language="*"
    />
  </dependentAssembly>
</dependency>
</assembly>

---

Step 2 Save the file as myapp.exe.manifest

Step 3 Add this code to each form in the project:

Code:

---

Private Declare Sub InitCommonControls Lib "comctl32.dll" ()
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
Private Declare Function FreeLibrary Lib "kernel32" (ByVal hLibModule As Long) As Long
Private m_hMod As Long
Private Sub Form_Initialize()
    m_hMod = LoadLibrary("shell32.dll")
    InitCommonControls
End Sub
Private Sub Form_Unload(Cancel As Integer)
    FreeLibrary m_hMod
End Sub

---

---

Explicitly calling LoadLibrary on shell32.dll is a worse hack in my opinion than calling a neutral entrypoint, for example IsUserAnAdmin which you probably want to check anyway. Then you don't need the FreeLibrary call. Both are hacks, take your pick. There isn't a better way to do it as far as I know though.

However you'll probably find that making these calls in Form_Initialize can be too late and your program will fail to even start on some machines (seems to vary by version and service pack level). All the user gets is a Windows sound and possibly an event logged. The program never raises any exception dialog.

So do this in Sub Main, prior to loading any Forms.

Quote:

---

Originally Posted by Witis

Step 4 Optional: add the manifest file into the exe via the resource editor as I previously described to internalise the manifest.

---

As I already suggested external manifests are frowned upon. Ok for some things but they're not desireable for production programs, and again disqualify your application for logo certification.. which just means Microsoft is saying "don't do this."

Quote:

---

Originally Posted by Witis

Although I only looked for a little time so I wouldn't be surprised it is also possible to do this without needing a manifest.

---

Good luck with that.

Clearly you don't understand what that manifest is doing. The alternative is to use the UxTheme library to set styles on all of your controls' various components (borders, etc.). The manifest selects ComCtl32.dll version 6 which already does all of that internally. This is what the SxS assembly selection is doing: requesting ComCtl32.dll version 6 instead of the default version.

This can be done by calling the Fusion APIs directly instad of using a manifest, but I'm not sure it can be done in a VB6 program and in any case Microsoft doesn't recommend it for normal applications.


Beyond this you're using a legacy installer technology and probably other things that will bite you sooner or later. You might save yourself a lot of time and frustration with my "opinions" by reading the docs yourself.

Start by going through all of the Windows Vista Developer Story. Then go through Vista Application Compatibility. Finally look at the (much, much smaller) addendum Windows 7 and Windows Server 2008 R2 Application Quality Cookbook. Finally you might find Windows 7 Developer Guide useful. Don't overlook Platform Update for Windows Vista which talks about some of the Win7 features optionally back-portable to Vista.

That might get you about 70&#37; of the information that was once available for developers back in 2006-2007, plus some of the newer stuff in Windows Vista R2 (a.k.a. Windows 7).

Dilettant,

Just curiosity. Would you please enlighten me on the following:

If we go back to the very beginning, this thread is initiated by Witis because, as he puts it in his posting #1, "Windows seven won't let me write text files to the program files directory (without virtualisation), so I need to find an alternative ......". Following our discussion on IsUserAnAdmin, would it be practical to say that, if merely for the purpose of arriving at what Witis wants, all he has to do is to "elevate" his privilege before attempting to write the text files?

Edited: I mean to "elevate" privilege simply through "Run As Admin" in a popup.

Quote:

---

Originally Posted by petersen

Dilettant,

Just curiosity. Would you please enlighten me on the following:

If we go back to the very beginning, this thread is initiated by Witis because, as he puts it in his posting #1, "Windows seven won't let me write text files to the program files directory (without virtualisation), so I need to find an alternative ......". Following our discussion on IsUserAnAdmin, would it be practical to say that, if merely for the purpose of arriving at what Witis wants, all he has to do is to "elevate" his privilege before attempting to write the text files?

Edited: I mean to "elevate" privilege simply through "Run As Admin" in a popup.

---

Sure, that works in many instances. There are some places where not even membership in the Administrators Group plus elevation gets your access rights though. Those are rare but they exist: folders owned by TrustedInstaller for example. But I'm wandering...

I believe what he needs though is for standard users to be able to run his application. That makes elevating every run impractical, because you'd need an admin standing over you every run (the UAC prompt seen by standard users is called an "over the shoulder elevation request"). Users are not supposed to be using an admin account, which is what "standard user" is all about. There are even application analysis tools related to this: Standard User Analyzer (SUA) Tool and Standard User Analyzer Wizard (SUA Wizard).


Even a hobby coder should know about these issues and try to follow them. This helps us shed the reputation that VB is just for kids.

I appreciate a lot of the information you've provided and which is very learned indeed. That has helped fitting various pieces right in place.

The trick is keeping up with the changes to Windows so we can keep VB6 programs viable. A lot of this is still required even in VB.Net. They just get easier tools to work with.

There is a ton of stuff to track down and read though, I agree.

Dilettante,

May I ask one more question? You seem to often advocate the use of Manifest, how do we go about it when the program may be used in Windows platforms ranging from WinME to Win7, e.g. in a shareware scenario? (Not to mention the diversity of users, a single sizable organization alone can have assorted Windows systems)

I'm not sure why you see this as me "advocating" manifests. That's the rule now, as defined by Windows. Anything without a manifest is seen by Windows as "legacy" software to be handled by applying application compatibility rules to try to make it keep limping along.


Versions of Windows before Windows XP ignore any application manifest. Nothing in a manifest has any impact on those downlevel (and now unsupported) versions of Windows.

Starting with Vista the manifest contains additional things that XP doesn't know about (remember XP is almost dead now too). If those things are in the manifest XP ignores them. Those won't matter though in XP, because XP doesn't have those features like the UAC split user token and application integrity levels.

Starting with Windows 7 there are just a few more things that can go in a manifest. These help Windows 7 know whether Vista rules or Windows 7 rules are followed by the program. Vista ignores those new things since they don't apply to it.


So you can always safely use a manifest, that's no problem. But if you want your program to run correctly on downlevel systems you may have to either have multiple versions of your program for different Windows versions (and a lot of Microsoft downloads install different code based on the OS version these days) or else do "version sensing" so your program can make different calls depending on what OS it is running on. For example XP has no way to define a program as "High-DPI Aware" in the manifest, so such a program must make extra API calls to run properly on Windows XP.


Ultimately you can't do everything on an unsupported OS that you can do on a current version of Windows.

For example starting in Windows XP and not entirely reliable until XP SP2 (August 2004) you can package a VB6 program with a manifest that lets it be a portable program. Such a program can run from a flash memory drive or CD without needing to register libraries on the host system at all. The COM registration info goes into the manifest, not the host system registry.

Such a program just won't work right before Windows XP. So you specify that as the minimum version required.


Most of the "new rules" like which folders to put files into have been around since the Windows 95 Desktop Shell Update of 1997 though.

Thank you.

Here I hold quite a different view on it. I am of course aware of the existence of the many differences between the Windows platforms, I also fully realize that there are many goodies in later Windows as well as the justifications behind the launching of them, e.g. Vista and Win 7, etc (at least so claimed by MS, whether users at large agree with MS is another matter, Vista is a good example of it). But all these are not the issue under discussion -- as long as MS is still in a monopolistic position in the marketplace, all these are beyond discussion -- we just have to accept whatever is given by MS (through our throats) and abide by the rules laid down by MS (and we are always at the mercy of MS, re posting #14).

The hard fact is, for whatever reasons there are still plenty of people with the older Windows. So, if I infer correctly from what you've said above, the answer is that: shareware developers must provide different versions of a program in order to use "manifests" effectively.

Edited: Practically, how many shareware dvelopers can afford the practice of the above-said, I wonder. This manifests yet another example of how MS can gulp down the small guys.

Well, this thread is about writing your programs correctly to run now that the 1997 rules are enforced by post-XP versions of Windows. In particular the issue of writing to Program Files.

If you want to discuss Microsoft making new versions of Windows maybe that should go into its own thread.

Please don't start putting words into my mouth. I've clearly said that we must accept whatever is given by MS.

I am still sticking to the discussion on "manifests". You have given your answer that everyone must use manifests. What I am saying is that circumstances show that for some users this is not possible, practically speaking.

As I said in post #26 you can always safely use a manifest. It just won't have any effect on downlevel versions of Windows.

If you need to do things are accomplished through a manifest in current Windows versions on a downlevel system you have to use some other means. Those are pretty limited to things like SxS assembly selection, reg-free COM, DLL redirection, and High DPI aware though.

My "answer" was that you need a manifest with a trustInfo node in it to be considered "Vista aware" by Windows, to avoid having virtualization appcompat shims applied. This started in 2006 when Vista came out. There is a new option "Windows 7 aware" that is ignored by everything before Windows 7.


How does this apply to shareware (or any-ware)? If you don't have such a manifest your program will see filesystem and registry virtualization when run in Vista, Server 2008, Server 2008 R2, Windows 7, or Server 2010. Win2K and Win9x will ignore the manifest and WinXP will ignore the new sections like trustInfo, dpiAware, and Compatibility.

So to make your shareware work correctly you need a manifest.

dilettante,

Regarding IsUserAnAdmin Function,
it seems to me that you are using this function to determine if a process is elevated rather than to determine if a user is an admin.
Instead of using this function I would recommend writing two custom functions, one to determine if a user is a member of the administrators group, perhaps by writing an IsAMemberOf function using GetTokenInformation API combined with TokenGroups and then adding an IsCurrUserAnAdmin function which uses the previous IsAMemberOf to check only for membership to the administrators group, and one to determine if the current process is elevated by using GetTokenInformation combined with token elevation(TOKEN_INFORMATION_CLASS.TokenElevationType).

Regarding windows styles,
first a warning, MS states:
"Do not link to UxTheme.lib."
http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx
(scroll down to the last few points)
I take it this would result in a grave error on many systems.

As all the manifest is doing is referencing the MS windows common controls version 6 (typically instead of version 5), I wouldn't be at all surprised if it was possible to reference this control from within VB6 instead of via a manifest, although it would have to allow for the situation where it is absent from a particular system.

After some more reading and testing it seems that the LoadLibrary call was unnecessary although unlikely to cause any problems. Of potentially more concern was that the InitCommonControls Function is marked obsolete, although strangely it works on windows seven which for an obsolete function is nothing less than amazing. http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
I found an example with the replacement function here which looks promising: http://vbnet.mvps.org/index.html?cod...nitcomctls.htm
Although it might need some alterations to make it load all of the classes not just the listview class, and to make it run from the sub main (it should not be run from the form_load event) which sounds like a good idea despite my tests which failed to confirm the problems relating to form_initialize event.

Regarding the other links eg Windows 7 Developer Guide,
I am working my way through them at the moment, thanks for the information.

Regarding Inno Setup,
at the moment I have no problems or complaints, and it has support for all versions of Windows in use today and thus I don't see fading in the near future, why do you consider it legacy installer technology?

petersen,
regarding free to try ware or shareware,
the largest market share is now accounted for by Windows XP onwards. Anything further back than this might only account for 1-5&#37; of all users. So far in my testing manifests files containing requestedExecutionLevel and windows styles (unsupported by MS for vb6) have not caused a problem on XP, and so I would not be overly concerned about using them in your applications.

Witis,

Thank you for your info. Actually I am not overly concerned about the shareware stuff (my profession belongs to another discipline, not programming, although I do serious programs selectively). I chimed in just for the sake of participating in the discussion on certain "hot" points. In the course I might pick up something and learn from others.

Quote:

---

Originally Posted by Witis

Regarding IsUserAnAdmin Function,
it seems to me that you are using this function to determine if a process is elevated rather than to determine if a user is an admin.

---

Yes, that's exactly it. Knowing the user is in the Administrators group is not useful for this purpose. You don't need to know anything except whether the process is elevated.

Quote:

---

Originally Posted by Witis

Regarding windows styles,
first a warning, MS states:
"Do not link to UxTheme.lib."
http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx
(scroll down to the last few points)
I take it this would result in a grave error on many systems.

---

Yes but VB6 programs can't normally be linked to .LIBs anyway. This isn't an issue for VB6, where normally you only use DLLs, not statically linked libraries.

Quote:

---

Originally Posted by Witis

As all the manifest is doing is referencing the MS windows common controls version 6 (typically instead of version 5)...

---

No, it is selecting the Version 6 library from the SxS assembly cache. From XP onward there are two of these libraries, but only one registration for them (identical typelibs). There is a way to set the activation context through API calls but it isn't worth the trouble.

Quote:

---

Originally Posted by Witis

After some more reading and testing it seems that the LoadLibrary call was unnecessary although unlikely to cause any problems.

---

Using LoadLibrary explicitly isn't required, but you do want shell32.dll loaded before comctl32.dll is loaded. We tested the heck out of this in an earlier thread. Just do it. I suggest a call to IsUserAnAdmin instead because it is a cheap call, gets the job done, and you often want the result anyway.

If you leave this out and your application breaks on some user's machine... oh well!

Quote:

---

Originally Posted by Witis

Of potentially more concern was that the InitCommonControls Function is marked obsolete, although strangely it works on windows seven which for an obsolete function is nothing less than amazing.

---

Nothing amazing at all really. The only reason we call the function is to control when comctl32.dll gets loaded. We don't care that it does nothing, much like calling IsUserAnAdmin and discarding the result.

Contrary to belief around here the VB controls (TextBox, Command, etc.) take care of initializing themselves. Othewise no VB6 program would work without making an elaborate call to InitCommonControlsEx. It's taken care of, don't sweat it.

You could cram another LoadLibrary/FreeLibrary in there for comctl32.dll and get the same result (with more work).

Quote:

---

Originally Posted by Witis

Regarding the other links eg Windows 7 Developer Guide,
I am working my way through them at the moment, thanks for the information.

---

You're welcome. Quite a pile of stuff hmm?

Quote:

---

Originally Posted by Witis

Regarding Inno Setup,
at the moment I have no problems or complaints, and it has support for all versions of Windows in use today and thus I don't see fading in the near future, why do you consider it legacy installer technology?

---

It isn't me, it's Windows.

Anything but Installer MSIs are considered "legacy." They get handled through Installer detection technology in newer versions of Windows, another kind of appcompat shim.

This doesn't always work because "Installer detection" can be disabled by policy settings.

petersen
Yep writing applications can be satisfying especially if they incorporate other professions eg medical tech, defense tech, etc. What area are you working in?

dilettante
When you said:
"Using LoadLibrary explicitly isn't required, but you do want shell32.dll loaded before comctl32.dll is loaded. We tested the heck out of this in an earlier thread."
I am interested in reading the thread to confirm these details do you have a link or a search key?

Also I didn't know that about inno setup, although I can confirm it:
"Will it support Windows Installer in the future?At the present time, I do not have plans for a Windows Installer edition of Inno Setup. "Supporting" Windows Installer would likely involve a near-complete rewrite of the program - something I don't have the time or interest to do." http://www.jrsoftware.org/isfaq.php
Are there any good alternative to check out?

Quote:

---

Originally Posted by Witis

When you said:
"Using LoadLibrary explicitly isn't required, but you do want shell32.dll loaded before comctl32.dll is loaded. We tested the heck out of this in an earlier thread."
I am interested in reading the thread to confirm these details do you have a link or a search key?

---

Take a look through http://www.vbforums.com/showthread.php?t=628956 where we kind of beat this to death.

Quote:

---

Originally Posted by Witis

Also I didn't know that about inno setup, although I can confirm it:
"Will it support Windows Installer in the future?At the present time, I do not have plans for a Windows Installer edition of Inno Setup. "Supporting" Windows Installer would likely involve a near-complete rewrite of the program - something I don't have the time or interest to do."

Are there any good alternative to check out?

---

He'd have to just about throw away all of it, it is sort of like a less-smart (which can be a useful thing) version of the PDW.

Either of these are fine within their limits. They just aren't first class solutions anymore (for about a decade).

Back around the turn of the century Microsoft provided Visual Studio 6.0 Installer 1.1 to free licensed VB6/VS6 users for doing this. The download links are gone now. You might scrape it up at some "archive of the Web" site if you're lucky.

There are alternatives but most cost money. Here is one list: http://www.installsite.org/pages/en/msi/authoring.htm

Witis,

My profession is in finance. Since "finance" is a bit vague, so I must also mention what statutorily recognized professional bodies I belong at the background. For the better part of my life I was a "Fellow" of a Chartered accountancy body of UK and a certified accountant in Canada, etc. Years ago I did some computer applications in the "Quantitative Technique" area (in North America, "Operational Research"). In recent years I am hooked in graphics programming using VB6, as my hobby. Stemming therefrom I completed a few sharewares (including a full-fledged Icon Editor and a full-featured Animated GIF Editor included in a Paint program). Although the humble income is just enough to cover my daily wine and cigarette consumption, the satisfaction derived in the course is not measurable in money terms. (To avoid advertising here, I will PM you, and Dilettante whose help is really great to me, to gauge how deep I have gone into it).

Just a chatty, since you asked. Cheers.

petersen, with finance, accounting, graphics and programming I am sure there are quite a number of options to create further apps if you enjoy the work, good luck with it. rgds

dilettante, thank you for discussing all of the issues that started from a seemingly innocuous question regarding folder permissions in %program files% on windows seven and lead to all of the vista UAC changes, manifests, windows styles, folder permissions, installers and more, which no doubt has caused so much pain for businesses wanting to move beyond XP. Not only does my current application write to %program files% correctly now, it also looks like it has had a renovation.:thumb:

I'm glad it was able to provide some assistance, if only to help point to some of Microsoft's information on how to keep programs working properly in this post-XP era.

Dilettante,

I still want to draw your expertise on this specific point: Just take Vista as an example, if I don't care whether my program would gain the nice Vista VISUAL effects or not, do I still need a manifest?

Edited: Remarks: Quite some people, comparatively senior in age perhaps, prefer Classic Theme for their machines.

Edited 2: I should have stated that only intrinsic VB controls are used (none of the boxes in Components ticked), though I don't know if this bears any relevance.

Manifests can specify many things. If all you want is for your program to be treated as Vista-aware then just use the trustInfo part of the manifest.

But as far as Common Controls version 6 goes it follows the theme set for the machine. If the user has Classic they'll still see Classic.

As in my case, I can confirm that currently my program (exe approx 8 mb) is being used on different Windows platforms, 32-bit or 64 bit, without any manifest, and without any problem.

So far, users on assorted Windows systems, e.g. XP/Vista/Win7 can install and run all functionalities of the program without a problem. Over the years, there had been exchanges of mail between some users and myself, that is why I can vouch the above-said (in the first place they wouldn't have paid if they could not install and run the program, secondly they would have written to me if they bumped into any problem).

Therefore, it appears to me that if one does not care about the cosmetics aspect (and not intending to intrude into a restricted system area), his/her programs would run as usual without a manifest.

Thank you again. Cheers.

Edited: As far as the installation is concerned, VB's P&D is used, but much modified (e.g. to avail desktop icon, to provide submenu items in Windows program menus).

Quote:

---

Originally Posted by petersen

Therefore, it appears to me that if one does not care about the cosmetics aspect (and not intending to intrude into a restricted system area), his/her programs would run as usual without a manifest.

---

Dilettante, Petersen, & Wilis: THANK YOU for the amazing insight into these subjects! Your work has really helped clarify some of the muddied water I've been wading through (I'm not as smart as you guys - hopefully my code will still be valid and I'll still be breathing by the time I get through half of the volumes of info you've provided).

petersen: Your statement seems to be backed up by Si the Geek's definition in his post Si the Geek's discussion of Virtualization:

Quote:

---

Originally Posted by Si the Geek

Virtualisation (Windows Vista [and possibly later versions too])
On Vista if a user does not have permission to work with a file, Virtualisation comes in to effect.

This is a process to deal with programs that seemed to work properly on Windows XP/2000, but only because they were not tested properly under limited user accounts - if they had been, the issues described in 'User Permissions' section above would have been noticed.

What Virtualisation does is let the program think that it has got permission to work with those files, by creating copies of the files in a special location, and automatically re-directing the programs requests for those files.

While this allows badly written programs to run on Vista, it is not a perfect solution - one example of this is that if one user runs the program and it makes changes to one of the files, it will not be seen by other users who run the program (because the virtualised files are per-user)."

---

Seems he says that as long as users have full rights to modify a writeable file, Vista and 7 will not virtualize them.

I'm not averse to including a manifest file eventually, but want to make sure it's really necessary before I climb that hill right now. I understand the ramifications you guys discussed herein.

I'm also using Inno Setup and it seems very straightforward to set the rights.

Quote:

---

Originally Posted by Set me As newtype

Seems he says that as long as users have full rights to modify a writeable file, Vista and 7 will not virtualize them.

---

That is the way I made it sound (the FAQ article isn't really about that, so I didn't work out+explain the full detail), but I'm fairly sure that it isn't as simple as that - I have a feeling that files in protected locations ("Program Files" etc) require a manifest to be writeable without virtualisation.

Please see, in dilettante's post #11: "With the proper rights (for example write rights if you want to write to a given file) no virtualization will take place with or without a manifest. In many cases you end up giving full access on the folder to the Everyone group, and any files created there after you do this will also have those rights. There are lots of different rights: read, write, update, excute, delete, etc. so "full access" is often simpler than struggling over fine granularity."

Let's say I have one database in ProgramData\My Name that I want users to read/write. In my Inno Setup script, I grant full permissions/rights to all users for the folder and file.

Straightforward (no shenanigans).

Is a manifest file needed to prevent virtualization?

I am trying to comply (still and always). There just seems no way to get help with writing a manifest file quickly enough.

I'm fairly sure that what you intend to do will be fine, as ProgramData is not a protected location (thus any extra details of virtualization shouldn't come into effect).