RE: folder virtualisation

Hi Ashnah,

Thank you for the feedback.

I suspect the not working of the link is caused by the long URL
line-breaking. You may sum up the all the URL parts and paste it in the IE
address bar. I can visit them through the links I provided in the first
reply:
http://groups.google.com/group/microsoft.public.dotnet.framework/msg/de13b42
b45702650?hl=en&
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/brow
se_thread/thread/40533315861bd2de

If you still failed to find my reply, I paste the main part below for your
information:
"In this scenario, below is the recommended solution:
1. Coding a separate Windows Service as a broker process which runs under a
high priviledge account, such as LocalSystem or Administrator.
2. When you need to update the plug-in dlls, your normal application can
use some type of inter-process communication technology to ask write
request to the Windows Service, and the Windows Service with high
priviledge work on behalf of your application to write "Program Files" for
replacing the old dlls with new ones.(which are read-only to your normal
user account)

This is a safe solution since we separate the high priviledge
operations/code from the normal operation code. Also, by defining a
well-defined interface between the normal game application and the Windows
Service, we expect it to be safe. In this mode, the Windows Service
application is called a permission broker application. Microsoft IE7
protected mode uses 2 broker applications for high priviledge write
operation which idea is the same here. Please refer to the "Understanding
Protected Mode" section in link below to see these 2 broker processes:
"Understanding and Working in Protected Mode Internet Explorer"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/d
nwebgen/ProtectedMode.asp

A variation of this solution is coding a separate high-priviledge updating
application. While asking for updating, your normal application can use
ShellExecute API with "runas" parameter to run the updating application
under the full administrator token, which has the permission of writting to
the "Program Files". This approach has the advantage of prompting the end
user with a consent dialog for updating, which aligns with Vista UAC
behavior. See the "Run as administrator" section in the link below for
details:
http://weblogs.asp.net/kennykerr/archive/2006/09/29/Windows-Vista-for-Develo
pers-_1320_-Part-4-_1320_-User-Account-Control.aspx "

To your questions:
1. Coding a separate Windows Service is ok.
2. If your Windows Service needs to access network, the Vista Service
Hardening may impact on it. This is because Vista willl restrict network
access of Windows Services. Please refer to the articles below for details:
"Services Hardening in Windows Vista"
http://www.microsoft.com/technet/technetmag/issues/2007/01/SecurityWatch/
http://www.microsoft.com/whdc/system/vista/Vista_Services.mspx
3. It should be ok to use named pipe to communicate between GUI normal
application and Windows Service
4. Can you tell me what "AppData" directory you are specifying? Based on my
experience, the Virtualized directories on Vista are hard coded in kernel.
They are:
%ProgramFiles% (\Program Files)
%AllUsersProfile% (\ProgramData - what was \Documents and Settings\All
Users)
%SystemRoot% (\Windows)
%SystemRoot%\System32 (\Windows\System32)

Do you mean %AllUsersProfile%\ProgramData directory?

Since your Windows Service has full right to any folders, it does not
matter where you store the application data.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

.

Relevant Pages