Re: Manifests and requestedExecutionLevel

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:lf879399hnga0ujpqkvjt4n7ts357n2q9q@xxxxxxxxxx
Yes, the problem is that it takes a while to get to the state where the
level is
determined, and it involves a fair amount of work to launch a new process
with the correct
level and get it back to the right state.


Perhaps this check of state should be moved to the InitInstance() since it's
fairly critical functionality that can be determined if it's supported
without much fuss. Use IsUserAdmin().


Seems like manifests aren't really well-thought-out in terms of what they
can specify, and
certainly aren't documented.

I keep hoping that someone from Microsoft is reading these posts and takes
back to the
appropriate groups that we are complaining about poor documentation.


I agree MSDN is getting pretty sucky, and as MVP's it is our duty to tell
them so. I've done so on http://forums.microsoft.com where the important
people hang out. To be blunt, all your complaining on this newsgroup is
preaching to the choir and does no good because no one who can affect change
at Microsoft will read it here. On http://forums.microsoft.com, I've had
dialog with a MS Product Manager in charge of Windows Error Reporting and
complained that the Vista MSDN doc is totally inadequate, and MS seems to be
relying more and more on blogs and forum participation of key MS folks to
"document" the really important stuff. He agrees this is the case, and says
he will get published more info on the topic we were discussing.


See below...
No, I'm asking specifically for the list of tags that are used in
manifests. That is a
finite and documentable set!

Yes, perhaps, but since the info going into a manifest comes from diverse
groups within MS, they are probably not set up to organize the doc that way.


*****
Instead, each section (tag) of the
manifest is separately documented. For example, to specify elevation:

<v3:trustInfo xmlns:v3="urn:schemas-microsoft-com:asm.v3">
<v3:security>
<v3:requestedPrivileges>
<!-- level can be "asInvoker", "highestAvailable", or
"requireAdministrator" -->
<v3:requestedExecutionLevel level="requireAdministrator" />
</v3:requestedPrivileges>
</v3:security>
</v3:trustInfo>
*****
Hmm. So we have designations of integrity level such as "High", "Medium",
"Low" and even
"System", but the keywords are "asInvoker", "higestAvailable" and
"requireAdministrator",
and the correlation is obvious...


The keywords unfortunately don't associate with MIC levels. That's the
issue. The keywords are mainly concerned about getting to an elevated state
and don't allow specifying a non-elevated state which is what you need.
It's unfortunate, but scarcely a documentation issue as the keywords are
very well documented.


So where is the complete documentation of the manifest? I cannot find it
in the MSDN. In
fact, a search in MSDN for "requestedExecutionLevel" reveals absolutely
nothing usable,
such as a reference manual entry for this keyword. I did *that* search
two days ago.
Neither the installed MSDN nor the online search reveal anything useful.
The best
reference was to the beta 1 Longhorn distribution, although the details of
the relevance
of a beta1 document to a final product is problematic.

Google sites were not that much more informative, giving at best snippets
of manifests.

Joe, you're a smart guy, but now you're whining. In 5 minutes, I found:
http://msdn2.microsoft.com/en-us/library/aa905330.aspx which references a
Windows Help file that in the "Step 6: Create and Embed an Application
Manifest (UAC)" gives you all the gory details. Also, a good overview of
UAC is at http://msdn2.microsoft.com/en-us/library/bb206295.aspx which has
links to other things.

You don't much like it when people ignore your MVP essays, and yet you do
the same thing with these other well written articles, calling them
"irrelevant" and other such falsehoods. The Kenny Kerr article discusses
all these things in great detail and you seem to be the only one having
trouble understanding the definitions of the keywords. And I also cited the
CodeProject "UAC Elevator" article which is also great. You should have no
issue getting your problem solved with this info!

Like it or not, MSDN is being supplemented by other sources of info (very
accessible with google), and reading this material is required to stay
abreast of curent Windows development.

-- David


.

Relevant Pages

  • Re: if !defined and #pragma once
    ... gaps like these with the 'community content' features of the new MSDN. ... discussion of _MSC_VER, is merely incompetent documentation. ... Blogs are not documentation. ... VS5 was such crap that not only didn't it work very well, ...
    (microsoft.public.vc.mfc)
  • Re: Lisp Garbage Collection
    ... find my way through the MSDN? ... codes with no explanations of what they mean. ... In "Linux" system the GNU Info pages, and their HTML mirrors, are the ... best documentation of the Gnu parts of the system, ...
    (comp.lang.lisp)
  • Re: hInstance field in PROPSHEETPAGE structure: MSDN doc not corre
    ... That is unfortunate (the MSDN feedback link being broken). ... I've usually just gone the route of finding the companion doc page in my local SDK documentation and using that for bug submissions instead of trying to go through the MSDN online documentation. ... Windows SDK MVP ...
    (microsoft.public.development.device.drivers)
  • Re: How to get the documents in detail?
    ... Not MSDN Library. ... anyone trying to learn how/when to use a particular interface (I guess ... A halfway decent documentation on this interface would have put the ... blah blah blah is an example of a possible site and a yeah yeah yeah ...
    (microsoft.public.vc.atl)
  • Unsupported Features (was: Can forked/spawned address spaces ...)
    ... Even when something is a programming interface, ... detail would be provided (and added to the documentation). ... IBM wishes to reserve the right to change the behavior. ... Relational-Expression Keywords ...
    (bit.listserv.ibm-main)