Re: Manifests and requestedExecutionLevel
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:9oj993h418ra3r0mp6dq9ru4015nfer084@4ax.com...
That is what I've had to do, since 99% of the time the co-process will be
running as
Medium. It has been running for several days that way. But this violates
some issues
about simplicity of installation and use that the customer finds desirable
criteria.
Well then, what if you create a single .exe that is responsible for
launching a second .exe at Medium MIC. The trick is the second .exe is
stored in the resource, so at startup, it is extracted from the resource and
placed in either the same folder or a temporary one for which write access
is obtained. Then the second .exe is launched at Medium MIC. All of this
transparent to the user. It's what SysInternals does by self-extracting a
device driver at startup and dynamically installs it (I think it is either
for Process Explorer or Process Monitor).
I think you need to set your customer's expectation that a second .exe is
necessary to ensure Medium MIC. That is clearly established by now. They
can do whatever tricks like the above to make it more paletable, but they
need a second .exe.
There is even a suggestion
that talking to a High MIC process would simply be forbidden, so I was
tasked with
investigating ways to cause this launch to occur at the correct level in
the first place,
without using the current intermediate launch mechanism (which, as I said,
is a real pain
to debug with). And that's where the frustration has come in: there's
enough missing
information to make it difficult to determine if the lack of information
is due to lack of
functionality, inadequate documention, or whatver.
It's clearly a lack of functionality as the CodeProject UAC Elevator article
makes readily apparent.
For example, although I find that for
an actual 64-bit build the processorarchitecture="amd64", the
documentation CLEARLY states
the ONLY two allowable values are "x86" and "ia64". Given how long the
AMD64 has been out
and running Windows, do you think I give much credibility to documentation
that has
clearly not been updated in 3 or 4 years? Could I tell from reading the
documentation
that the statement "The only allowable value is win32" has any meaning in
a win64
environment? (It turns out that inspection of a win64 manifest shows that
it really does
say "win32", even though this makes no sense). So the documentation is
misleading,
confusing, and certainly out of touch with reality. For all I know there
have been
massive changes in what manifests do, and there is no real source of
authoritative
information.
Yeah, well undocumented Windows is a way of life. Windows still remains one
of the best documented API's of all time, in no small part to MSDN but also
due to 3rd parties feretting out the details and presenting them, as Kenny
Kerr did.
There is no documentation like the source code in terms of authority. Have
you considered using a Service Support Incident that comes with your MSDN
subscription to see what MS has to say about this?
-- David