Architecture of the Web Update Wizard

Web Server

The Web Update Wizard works with any web server.  It simply launches http: requests against the server.  All processing is done at the client end.  Therefore, the server does not need cgi, asp, php or any other type of server side processing.

(However, it is possible to dynamically generate the update scripts on the server using PHP / ASP etc..)

Client PC

There are 2 alternative options for delivering updates on the client PC:

1. Installing and using the Web Update Wizard 'server' application, WebUpdateSvc4.exe, as a Windows Service.
2. Using the Web Update Wizard component, WebUpdateSvc4.exe, as a simple Windows application.

More

More..

Service implementation of the Web Update Wizard (recommended)

1. Your application calls one of the exported functions from wuw4.dll, passing the url of the update script as an argument - for example
   
   WebUpdate("http://www.mycompany.com/updates/updatescript.txt"
   
2. WuW4.dll then launches WuWUI.exe, the user interface component.  WuWUI.exe therefore runs in the same security context as your application.  The wuw4.dll WebUpdate() function also sends the URL of the update script to the Web Update Wizard Service component (WebUpdateSvc4.exe) through a named pipe.
   
3.  WebUpdateSvc4.exe, the service component running in the SYSTEM security context, takes over control of the update process and WuW4.dll returns control to your application.
   
4. A Windows service should not interact directly with the user (and in Windows Vista it cannot without UAC intervention).  Therefore the service component communicates with WuWUI.exe, the user interface component, through a named pipe. WuWUI.exe performs the following tasks in response to the dialog it engages in with WebUpdateSvc4.exe:
   
   
   • Displays all user interaction from the Web Update Wizard to the user.
   • Downloads all files referenced in your update script (because SYSTEM typically does not have rights to proxy servers etc. whilst the logged in user does have these rights)
   • Launches processes in the logged on user's security context, for example, when the updated application needs to be restarted after a successful update. 
5. If the Web Update Service (WebUpdateSvc4.exe) determines that an update is required then it works cooperatively with the user interface component (WuWUI.exe) to process it.  WuWUI.exe interacts with the user and downloads the files required.  WebUpdateSvc4.exe installs the updated files into the required locations.  WuWUI.exe restarts the application in the logged on user's security context once the update has been installed.  WebUpdateSvc4.exe or WuWUI.exe can launch additional processes either before or after the update.  Which component launches the process is determined by the ExecBefore/ExecAfter optional parameters - there will be valid instances where you need to launch a process with SYSTEM (=Administrator) rights, and also when you want to launch in the logged on user's security context.  Both options are possible!
   
6. Once the update has been processed, WebUpdateSvc4.exe tells WuWUI.exe to exit, so that only WebUpdateSvc4.exe is left running on the user's computer.
   
7. If no update is required then the WebUpdateSvc4.exe component tells WuWUI.exe to exit and no user interaction occurs, (unless you specify a block [99999] message section in your update script).

If you find it easier to launch a process from your application than using an exported function in wuw4.dll you can, instead, launch our wuwstub.exe utility, passing it the url of your update script as a command line argument.  Using the Windows ShellExecute() API from your application, you would launch wuwstub.exe like this:

    ShellExecute(NULL, "open", "wuwstub.exe", "http://www.mycompany.com/updates/updatescript.txt", NULL, SW_HIDE);

Wuwstub.exe is dynamically linked to wuw4.dll.  Therefore when you call wuwstub.exe using ShellExecute() from your application, wuwstub.exe effectively becomes 'YourApp.exe" in the diagram above.

Using the Web Update Wizard in Application mode (i.e. not as a Windows Service)

Here is how the Web Update Wizard operates when it is running in application mode - i.e. within the logged in user's security context.  Click here to jump back up the page to a description of running WebUpdateSvc4.exe as a Windows service application.

Application mode means that WebUpdateSvc4.exe is launched as a normal Windows application by the wuw4.dll and therefore operates in the security context of the logged on user.

Therefore,

1. As with the service implementation, your application calls one of the exported functions from wuw4.dll.  However, this time you append the text "[AsApp]" to the URL argument - for example
   
   WebUpdate("http://www.mycompany.com/updates/updatescript.txt[AsApp]"
   
   
2. Wuw4.dll then launches WuWUI.exe, the user interface component.  It also launches WebUpdateSvc4.exe, passing it the URL of the update script as a command line argument.  Because WebUpdateSvc4.exe is launched as an application it is limited to operating within the security context of the logged on user.
   
3.  WebUpdateSvc4.exe starts up and takes over control of the update process.  Wuw4.dll returns control to your application.
   
4. If WebUpdateSvc4.exe determines that an update is required it works cooperatively with the user interface component (WuWUI.exe) to process it.
   
5. Once the update has been processed, WebUpdateSvc4.exe tells WuWUI.exe to exit and then exits itself.
   
6. If no update is required then the WebUpdateSvc4.exe component tells WuWUI.exe to exit, no user interaction occurs, (unless you specify a block [99999] message section in your update script) and WebUpdateSvc4.exe itself then executes.

If you find it easier to launch a process from your application than using an exported function in wuw4.dll you can, instead, launch our wuwstub.exe utility, passing it the url of your update script as a command line argument.  Using the Windows ShellExecute() API from your application, you would launch wuwstub.exe like this:

    ShellExecute(NULL, "open", "wuwstub.exe", "http://www.mycompany.com/updates/updatescript.txt[AsApp]", NULL, SW_HIDE);

Wuwstub.exe is dynamically linked to wuw4.dll.  Therefore when you call wuwstub.exe using ShellExecute() from your application, wuwstub.exe effectively becomes 'YourApp.exe" in the diagram above.

Summary

This topic has explained the architecture differences between running the Web Update Wizard as a service application and running it as a Windows application in application mode.

The advantage of running in application mode is that the Web Update Wizard imposes no memory overhead, except when it is processing an update.

The advantage of running as a service is that updates take place in the SYSTEM security context - i.e. as if an Administrator was driving the machine.  The disadvantage is that the service application imposes a permanent memory overhead of 2.5Mb to 5Mb.

In the past application mode was preferred by many for the memory saving.  However, although you are still free to use this mode, the restrictions and additional security settings implemented in Windows Vista and in corporate XP deployments makes application mode very much a thing of the past.