[Ascii2]

Microsoft documents that wildcards can be used with Feature Controls, but does not document how to use wildcards.

There are three public webpages documenting the existance of wildcards at the Microsoft website. They are:

http://technet.micro...y/bb457150.aspx
http://technet.micro...y/dd361873.aspx
http://www.microsoft.com/technet/prodtechn...x.mspx?mfr=true


How can wildcards be used with Feature Controls.

This post has been edited by Ascii2: 13 November 2009 - 07:59 PM

[Ascii2]

I figured out the wildcard.

It is a DWORD value named "*".

[GrofLuigi]

From empirical experience (read: fiddling with ProcMon):

YourApp.Exe tries to access Internet. (I'm not sure what is the exact trigger - winsock, winhttp or something else... I think it's urlmon.dll; some apps use Internet without triggering FeatureControl).

The Authoritae (I'm not sure who it is, in my case it isn't Group Policy since gp*.dll have been thoroughly nLited + manually eradicated; again I think it's urlmon since it's the last thing queried before the calls to Feature*) decides to give subset of controls to YourApp.Exe (I've seen different Feature_* queried for different apps; might be only my imagination) based on what operations YourApp.exe requested? (wild guess again).

Then YourApp.exe queries the subset of FeatureControl\Feature_* it received and if there is a YourApp.exe dword in there, it uses that; if not, it uses the * dword (if present).

I pray this post of mine makes sense. But Microsoft's documentation isn't too much more understandable (to me)...

GL

This post has been edited by GrofLuigi: 13 November 2009 - 08:55 PM

[Ascii2]

GrofLuigi, on Nov 13 2009, 08:52 PM, said:

From empirical experience (read: fiddling with ProcMon):

YourApp.Exe tries to access Internet. (I'm not sure what is the exact trigger - winsock, winhttp or something else... I think it's urlmon.dll; some apps use Internet without triggering FeatureControl).

The Authoritae (I'm not sure who it is, in my case it isn't Group Policy since gp*.dll have been thoroughly nLited + manually eradicated; again I think it's urlmon since it's the last thing queried before the calls to Feature*) decides to give subset of controls to YourApp.Exe (I've seen different Feature_* queried for different apps; might be only my imagination) based on what operations YourApp.exe requested? (wild guess again).

Then YourApp.exe queries the subset of FeatureControl\Feature_* it received and if there is a YourApp.exe dword in there, it uses that; if not, it uses the * dword (if present).

I pray this post of mine makes sense. But Microsoft's documentation isn't too much more understandable (to me)...

GL

I can understand MIcrosoft documentation. Unfortunately though, the newer documentations are in many places lacking an incorrect.

Not all feature controls begin "FEATURE_", but many of them do.

[cluberti]

Note FCKs are read via wininet, not urlmon. Actually, they can also be read by browseui.dll, if you go into the tools > Internet Options, browseui.dll re-reads all the FCKs (it reads ALL reg entries that IE can have to make sure the UI is properly populated).

Note that Feature Control Keys are created to "turn on" hotfixes that originate in the QFE or LDR branch of IE, hence why they're only documented originally for the person or company that the hotfix is written for - the ones that work in the GDR branch and/or are actually publicly documented on the microsoft.com site are for fixes that either migrated into the general public releases of IE either via service pack, or if the fix was considered valuable enough for everyone to have documented but one that Microsoft doesn't want "turned on" by default for whatever reason.