Automatic software downloading from a computer network6347398Abstract A method and system to automatically locate, download, verify, install, register and display computer software components from a computer network like the Internet or an intranet. The method and system is used to provide dynamic or interactive multimedia components in HTML documents with HTML <OBJECT> tags. The HTML <OBJECT> tags contain parameters including uniform resource locators (URLs) which reference dynamic or interactive multimedia components on remote computers. Network browsers and other applications can obtain computer software components from a computer network like the Internet or an intranet in a uniform, portable, architecture-neutral, robust manner. The computer software components obtained can be used to provide a variety of new multimedia functionality to an application program which is stored on remote computers. Claims We claim: Description FIELD OF INVENTION
Argument Type Description
rclsid REFCLSID CLSID of the object that needs to
be installed. If value is
CLSID_NULL then szContentType is
used to determine
the CLSID.
szCodeURL LPCWSTR URL pointing to the code for the
object. This may point to an
executable, to an .INF file, or to
a .CAB file. If this value is NULL,
then Internet Component Download
will still attempt to download
the desired code from an object
store server on an Internet Search
Path
dwFileVersionMS DWORD Major version number for the
object that
needs to be installed. If this
value and the next are both
0xFFFFFFFF, then it is assumed
that the latest version of
the code is always desired, an
attempt to download new
code will be made.
dwFileVersionLS DWORD Minor version number for the
object that
needs to be installed. If this
value and the previous one are
both 0xFFFFFFFF, then it is
assumed that the latest
version of the code is always
desired, an attempt to
download new code will be made.
szContentType LPCWSTR MIME type that needs to be
understood
by the installed object. If rclsid
is CLSID_NULL, this
string is used to determine the
CLSID of the object that
must be installed. Note: this
parameter is only useful
when trying to download a viewer
for a particular media
type, if the MIME type of the
media is known but the
CLSID is not.
pBindCtx LPBINDCTX A bind context to use for
downloading/installing
component code. The client should
register its
IBindStatusCallback in this bind
context to receive
callbacks during the download and
installation process.
dwClsContext DWORD Values taken from the CLSCTX
enumeration specifying
the execution context for the
class object.
pvReserved LPVOID Reserved value, must be set to
NULL.
riid REFIID The interface to obtain on the
factory object (typically
IClassFactory).
ppv VOID** Pointer in which to store the
interface pointer upon return
if the call is synchronous.
Returns S_OK Success. ppv contains the
requested interface pointer.
MK_S_ASYNCHRONOUS Component code will be downloaded
and installed
asynchronously. The client will
receive notifications
through the IBIndStatusCallback
interface it has
registered on pBindCtx.
E_NOINTERFACE The desired interface pointer is
not available. Other
CoGetClassObject error return
values are also possible
here.
In an illustrative embodiment of the present invention, the values for parameters passed to the CoGetClassObjectFromURL interface are read directly from an HTML <OBJECT> tag. For example, the szCodeURL, dwFileVersionMS, and dwFileVersionLS are specified inside an <OBJECT> tag with "CODEBASE=http://www.foo.com/bar.ocx#Version=a,b,c,d" where szCodeURL is "http://www.foo.com/bar.ocx", dwFileVersionMS is "a,b", the major version of a file on remote server (e.g., a software provider such as Microsoft), and dwFileVersionLS is "c,d", the version of a file on the local computer. The CoGetClassObjectFromURL interface is responsible for managing method 66 and system 56. A software component requested with method 66 is typically a factory class object. A class factory generates actual object class instances of an object and is known to those skilled in the art. As is shown in FIG. 5, the CoGetClassObjectFromURL interface uses method 80 to locate a control file on a remote computer 44. If it specifies 82 a CLSID, CoGetClassObjectFromURL checks to see if the desired software component (i.e., the control file) is registered and installed 84 on the local computer 36 with the right version number 86. If it does not specify a CLSID (i.e., has a value of CLSID_NULL), CoGetClassObjectFromURL will choose the appropriate CLSID by interpreting the Multipurpose Internet Mail Extension (MIME) 88 type specified in the szContentType parameter. MIME provides a standard mechanism for messages to be exchanged over computers connected to the Internet. See Internet Standard Document: RFC 1521 for specific details on MIME. If the desired software component is registered and installed on the local computer, and if the version number is correct, then the desired software component is obtained from the local computer 36. If the desired software component is not registered and installed on the local computer, or if the version number is incorrect, then the desired software component is obtained from the remote computer 44. To obtain the desired software component from the remote computer 44, the szCodeURL parameter is checked 90. If the szCodeURL parameter is not NULL, then an attempt is made to locate the desired software component with the URL stored in szCodeURL. If the URL is valid 92, the desired software component will be downloaded 70 (FIG. 4) to the local computer 36. If the szCodeURL is NULL, or the specified URL is invalid, a then a network search path is used to locate the software component 94. The network search path is specified as shown below. CodeBaseSearchPath=<URL.sub.1 >; <URL.sub.2 >; . . . <URL.sub.m >; CODEBASE URL; <URL.sub.m+1 >; . . . <URL.sub.n-1 >; <URL.sub.n > This search path is made accessible to the CoGetClassObjectFromURL interface. For example, using Microsoft's Internet Explorer.RTM. 3.0 running on Windows.RTM. 95, the search path is stored in the system registry. On other operating systems or with other software applications, this search path may be stored elsewhere as long as it is accessible to the CoGetClassObjectFromURL interface. On Windows operating systems, the network search path is specified in a string in the registry database under the key: KEY LOCAL MACHINE.backslash.Software.backslash.Microsoft.backslash.Windows.backslash . CurrentVersion.backslash.Internet Settings.backslash.CodeBaseSearchPath However, other registry database keys could also be used. The value for this key is a string of szCodeURL parameters. Each of URLs URL.sub.1 through URL.sub.N in the network search path are absolute URLs pointing to HTTP servers acting as "Object Stores" 44. However, other formats could also be used for the network search string. As is shown in FIG. 6, the CoGetClassObjectFromURL interface using method 96 will first try locating 68 (FIG. 4) the desired control file using URL.sub.1 through URL.sub.m (98-102). If the desired control file cannot be located using URL.sub.1 through URL.sub.m, CoGetClassObjectFromURL will try the location specified in the szCodeURL parameter (e.g., corresponding to the CODEBASE attribute in the <OBJECT> tag) 104. If the desired control file cannot be located using the szCodeURL search path, CoGetClassObjectFromURL will try the locations specified in locations URL.sub.m+1 through URL.sub.N (106-110). If this search fails, then the desired control file cannot be located. The network search using a network search path will use the first successful response from a server and will not subsequently continue searching for newer versions of components. However, newer versions of software components can also be searched for. If the CODEBASE keyword is not included in the CodeBaseSearchPath key, then calls to CoGetClassObjectFromURL will not check the szCodeURL location for downloading code. By removing the CODEBASE keyword from the CodeBaseSearchPath, corporate intranet administrators can effectively disable corporate users from accessing any remote computer to obtain a computer software component specified by a HTML <OBJECT> tag. This also allows registration of default Object Store locations 44 on the World Wide Web, where browsers can find code when no CODEBASE location is explicitly specified. In addition, by removing the CODEBASE keyword from the CodeBaseSearchPath and pointing URL.sub.1 through URL.sub.N to intranet sites, corporate intranet administrators can effectively disable corporate users from accessing software components from any computers outside a local intranet. In an alternative embodiment of the present invention, the network search path can be used in an alternative way: the URLs in the network search path (98-102, 106-110) will be searched for a control file after trying the location specified in the szCodeURL parameter for CoGetClassObjectFromURL, (e.g., after trying the location specified in the CODEBASE attribute 104 from a HTML <OBJECT> TAG). In an illustrative embodiment of the present invention, an Object Store on the network search path is an HTTP server that services requests for a desired control file. CoGetClassObjectFromURL will try to locate the control file from the various Object Stores in the search path. Specifically, an Object Store will receive an HTTP POST request with data in the format below: CLSID={class id} Version=a,b,c,d MIMETYPE=mimetype All the values above are optional, although at least one of CLSID or MIMETYPE parameters must be present. The Object Store parses this information, checks an internal database, and either fails, or redirects the HTTP request to the control file on the next remote computer in the network search path. The HTTP POST parameters are processed by the Object Store as follows: If CLSID is provided with no version number, then the most recent object matching the CLSID will be returned. If the CLSID is provided with Version, then the object matching the CLSID and with the highest version number greater than or equal to Version will be provided. If no object is available that matches the CLSID with a large enough version number, then the HTTP error (e.g., the 404 error) will be returned. MIMETYPE will be ignored when CLSID is provided. If no CLSID is provided, but MIMETYPE is provided, then the first object found in the database that matches the MIMETYPE will be returned. Version, if provided, is treated as described above. If neither CLSID or MIMETYPE is provided then the HTTP error return code "400 Bad Request" will be returned. In addition to the HTTP POST data described above, queries to Object Stores may also include HTTP headers for ACCEPT (MIME type) and ACCEPT-LANGUAGE, thus specifying the desired platforms and language-localized implementation for a component. HTTP headers are typically added to all HTTP requests made by method 66 and system 56. This allows Object Stores to serve different code implementations for differing platforms or even different languages. The illustrated and alternative embodiments of the present invention described above assume that all computer software storage servers searched with the network search path are active HTTP servers capable of handling HTTP POST requests and querying an object database to find the desired software components. In another alternative embodiment of the present invention, non-HTTP servers can also be used in the network search path (e.g., FTP servers and standard file servers). The control file located 68 on a remote computer can be, for example, a portable executable file, a cabinet file, or an initialization file. A portable executable (PE) is a single executable file that is downloaded, verified, registered and installed on the user computer according to method 66. The portable executable is typically an OLE control or ActiveX.TM. (network activation) control file (e.g., .OCX), a Dynamic Link Library file (e.g., .DLL), or a executable file (.EXE). OLE control, ActiveX.TM., Dynamic Link Library, and executable files are known to those skilled in art. A single portable executable file is the simplest way to package a software component to provide dynamic or interactive multimedia. However, when a single portable executable is used, the file is typically not compressed, and the software component will not be platform independent unless a HTTP server negotiates a platform independent format. The HTTP server negotiation will be explained in detail below. A cabinet file (e.g., CAB) can be used for the control file. The cabinet file contains one or more files, all of which are downloaded together in a compressed "cabinet." One file in the cabinet is an initialization file (e.g., .INF) providing further installation information. This .INF file may refer to files in the cabinet as well as to files at other URLs. Using a cabinet file requires authoring of a .INF and packaging of a CAB file, but in return it provides file compression. File compression is completed with Lempel-Ziv compression, which is known in the art. However, other compression formats could also be used. Cabinet files can be created with the DIANTZ.EXE tool by Microsoft Corporation. However, other cabinet file creation tools can also be used. The DIANTZ.EXE tool takes a directive file (e.g., .DDF), which specifies how to create a cabinet file, and creates a cabinet file. The DIANTZ.EXE is used with the following command line: DIANTZ.EXE/f directive_file.ddf where the "If" attribute tells the DIANTZ.EXE tool to use the file "directive_file.ddf" to create the cabinet file. An example directive file, CIRC3.DDF is shown below.
; DIAMOND directive file for CIRC3.OCX+CIRC3.INF
.OPTION EXPLICIT ; Generate errors on variable typos
.Set CabinetNameTemplate=CIRC3Z.CAB
;** The files specified below are stored, compressed, in cabinet files
.Set Cabinet=on
.Set Compress=on
circ3.INF
circ3.OCX
The example directive file shown above would be used to create a cabinet file (e.g., ".Set Cabinet=on") containing two compressed (e.g., ".Set Compress=on") files: circ3.INF and circ3.OCX where "circ3.INF" is the single initialization file and "circ3.OCX" is the desired software component for dynamic or interactive multimedia. The .OCX file extension signifies an OLE control or ActiveX.TM. (network activation control) file. Comments are designated with a semi-colon ";". As was discussed above for the portable executable, the cabinet file will also not be platform independent, except with HTTP server negotiation which will be explained below. A stand-alone initialization file (.INF) can also be used for the control file. This file specifies various files that need to be downloaded and setup. The syntax of the .INF file allows URLs pointing to files to download, and provides platform independence by enumerating choices for various platforms. An example initialization file is shown below.
;Sample INF file for CIRC3.OCX
[Add.Code]
circ3.ocx=circ3.ocx
random.dll=random.dll
mfc40.d11=mfc40.dll
foo.ocx=foo.ocx
[circ3.ocx]
;lines below specify that the specified circ3.ocx (clsid, version) needs to
be
installed on
;the system. If doesn't exist already, can be downloaded from the given
location
(a .CAB)
;note: if "thiscab" is specifled instead of the file location, it is
assumed
that the
;desired file is present in the same .CAB cabinet that the INF originated
from
;otherwise, if the location pointed to is a different .CAB, the new cabinet
is also
downloaded and
;unpacked in order to extract the desired file
file=http://www.code.com/circ3/circ3.cab
clsid={9DBAFCCF-592F-101B-85CE-00608CEC297B}
FileVersion=0,0,1,2
[random.dll]
;lines below specify that the random.dll needs to be installed in the
system
;if this doesn't exist already, it can be downloaded from the given
location.
file=http://www.code.com/circ3/random.dll
;Note that the FileVersion is option, and it may also be left empty,
meaning that
any version is ok.
FileVersion=
DestDir=10
;DestDir can be set to 10 or 11 (LDID_WIN or LDID_SYS by INF
convention)
;this places files in .backslash.windows
or.backslash.windows.backslash.system, respectively
;if no dest dir specified (typical case), code is installed in the fixed
occache
directory.
[mfc40.dll]
;leaving the file location empty specifies that the installation
;needs mfc40 (version 4,0,0,5), but it should not be downloaded.
;if this file is not already present on the client machine, component
download
fails
file=
FileVersion=4,0,0,5
[foo.ocx]
;leaving the file location empty specifies that the installation
;needs the specified foo.ocx (clsid, version), but it should not be
downloaded.
;if this file is not already present on the client machine, component
download
fails
file=
clsid={DEADBEEF-592F-101B-85CE-00608CEC297B}
FileVersion=1,0,0,143
The sample .INF file shown above can be used to install the files "circ3.ocx, random.dll, mfc40.dll, and foo.ocx" where the .OCX file extension signifies an OLE control or ActiveX.TM. control (network activation) file and the .DLL file extension signifies a Dynamic Link Library file. OLE controls, ActiveXTm controls and Dynamic Link Library files are known to those skilled in the art. The .INF file has instructions to install each of the necessary files, and comments are again designated with a semi-colon ";". For example, the .INF file specifies that the "circ3.ocx" file needs to be installed on the local computer with a "clsid={9DBAFCCF-592F-101B-85CE-00608CEC297B}." "FileVersion=0,0,1,2" is used to check a local version of a file to see if it is earlier than Version 1.2. If it is, it will be downloaded to the local computer. The "circ3.ocx" can be downloaded from a remote computer in a cabinet file using the URL "file=http://www.code.com/circ3/circ3.cab." The "FileVersion=" attribute for the "random.dll" file is empty, so that any version of this file is ok. The "file=" attribute is empty for "mfc40.dll" and "foo.ocx" which signifies that these files should not be downloaded to the local computer. If these files don't exist on the local computer, then the downloading fails. The initialization file also provides platform independence for HTTP and non-HTTP servers which store the desired software components. It is possible to create platform-independent setup scripts that pull desired software components from different locations depending on the desired platform. A sample platform-independent .INF file would include a text such as the following:
[circ3.ocx]
; lines below specify that the specified circ3.ocx (clsid, version) needs
to
be installed
on
; the system. If doesn't exist already, can be downloaded from the given
location (a
.CAB)
file-win32-x86=file://products/release/circ3/x86/circ3.cab
file-win32-mips=file://products/release/circ3/mips/circ3.cab
file-mac-ppc=ignore
; the `ignore` keyword means that this file is not needed for this platform
clsid={9DBAFCCF-592F-101B-85CE-00608CEC297B}
FileVersion=1,2,0,0
The "file-x-y" syntax used in the .INF file is expanded to "file-%opersys%-%cpu%", (e.g., "file-win32-mips" where %opersys%="win32" and %cpu%="mips") allowing the .INF file to specify multiple locations where various platform-dependent modules can be found and downloaded. Valid values for %opersys% and %cpu% attributes are explained below. The following MIME types will be used to describe PEs (portable executables - .EXE, .DLL, .OCX), cabinet files (.CAB), and setup scripts (.INF):
File description MIME Type
PE (portable executable) - application/x-pe-%opersys%-%cpu%
.EXE, .DLL, .OCX
Cabinet files - .CAB application/x-cabinet-%opersys%-%cpu%
Setup scripts - .INF (platform application/x-setupscript
independent)
The %opersys% and %cpu% attribute values shown below will specify the operating system and CPU for the desired platform desired software components will be executed on. For example, the MIME type for a Win32 cabinet file running on an Intel.RTM. x86-architecture processor (whether manufactured by Intel Corporation or another company) would be application/x-cabinet-win32-x86. The following are valid values for %opersys% and %cpu%:
Valid values for %opersys% Meaning
win32 32-bit Windows .RTM. operating systems
(Windows95 or Windows NT)
mac Macintosh .RTM. operating system
<other> will be defined as necessary
Valid values for %cpu% Meaning
x86 Intel .RTM. x86 family of processors
ppc Motorola .RTM. PowerPC architecture
mips MIPS .RTM. architecture processors
alpha DEC .RTM. Alpha architecture
However, more or fewer values could also be used. When the desired software component is on a non-HTFP server (e.g., at an intranet or local LAN location), a .INF file can be used to achieve platform independence by specifing different URLs for files to be downloaded for different platforms. Platform independence for HTTP servers which store the desired software components is also provided without using an initialization file. An HTTP ACCEPT header MIME request type is used to provide platform independence. The MIME request type specifies which platform the code is to run on, thus allowing platform independence when the CODEBASE attribute or the network search path is used. After locating 68 (FIG. 4) a desired information file, the necessary software components are downloaded 70 (FIG. 4)with a data download module 60 (FIG. 3). The CoGetClassObjectFromURL interface uses the URL moniker interface to download 70 the necessary software components asynchronously from one or more remote computers 44. However, other interfaces could also be used to download the necessary software components. The URL moniker interface is described in greater detail in URLMON.DOC and ASYNCMON.DOC in the ActiveX.TM. Software Development Kit (SDK) by Microsoft. The URL moniker interface uses the IBindStatusCallback interface, which is implemented in an application program like the network browser, to pass status information back to the application program. The IBindStatusCallback interface enables the browser to tell the user when the download 70, verification 72, registration 74, and installation 76 steps are complete. The client of the CoGetClassObjectFromURL interface (e.g., the network browser) will receive notification about the download/install process via the provided IBindStatusCallback interface. During the download process , the following additional values (from the BINDSTATUS enumeration of Windows 95, for example) may be passed back as the ulStatusCode parameter for IBindStatusCallback::OnProgress.
Value Description
BINDSTATUS_BEGINDOWNLOADCOMPONENTS
The download operation has begun downloading code for
software
components that will be installed before the object may
be
instantiated. The szStatusText accompanying
IBindStatuscallback::OnProgress provides the display
name of the
component being downloaded.
BINDSTATUS_INSTALLINGCOMPONENTS
The download operation has downloaded code and is
installing it.
The szStatusText accompanying
IBindStatusCallback::OnProgress
provides the display name of the component being
installed.
BINDSTATUS_ENDDOWNLOADCOMPONENTS
The download operation has finished downloading and
installing all
necessary code. The szStatusText accompanying
IBindStatusCallbackOnProgress provides the display name
of the
newly installed component.
Since the downloading 70 of software components occurs asynchronously, the CoGetClassObjectFromURL interface will often return immediately with a return value of E_PENDING. At this point, the IBindStatusCallBack mechanism is used to communicate the status of the download operation to the client (e.g., the network browser). To participate in this communication, the client implements IBindStatusCallback and registers this interface in pBindCtx passed into CoGetClassObjectFromURL using RegisterBindStatusCallback. The client can expect to be called with callback notifications for OnStartBinding (providing an IBinding for controlling the download), OnProgress (reporting progress), OnObjectAvailable (which returns the desired object interface pointer), and OnStopBinding (which returns error codes in case of an error). For further negotiations, the client also implement ICodeInstall to install the desired software component as is described below. However, other downloading and callback processes can also be used. After downloading 70 the necessary software components to the local computer 36, the software components are verified 72 with a code verification module 62. CoGetClassObjectFromURL uses the WinVerifyTrust interface and the ICodeInstall interface to ensure the necessary software components are safe and trusted, and to ensure that the user wants to install the software components. However, other interfaces could also be used to verify and install the necessary software components. ICodelnstall is implemented by the downloading client (e.g., the network browser), and is used whenever installation of software components needs some service (e.g., verification) before the download can be negotiated correctly. A code install operation 74 requires additional services from the client in order to complete the negotiation necessary for a download operation 70. Such services are requested using IBindStatusCallback::QueryInterface. The specific interface requested in IBindStatusCallback:: QueryInterface is ICodeInstall. This interface is implemented by a client application (e.g., a network browser). The ICodeInstall interface has two member functions: NeedVerificationUI and OnCodeInstallProblem. The ICodeInstall interface and functions are shown below.
interface ICodeInstall : IUnknown {
HRESULT NeedVerificationUI(
[out] HWND* phwnd);
HRESULT OnCodeInstallProblem(
[in] ULONG ulStatusCode,
[in] LPCWSTR szDestination,
[in] LPCWSTR szSource,
[in] DWORD dwReserved);
};
ICodeInstall::NeedVerificationUI is called to display User Interface (UI)
for verification of downloaded code. When a client is called with this
function, it has the opportunity to clear a message queue of its parent
window before allowing UI to be displayed. If the client does not wish to
display UI, code verification may continue, but components may fail to be
installed. The parameters for ICodeInstall::NeedVerificationUI are
explained below.
HRESULT NeedVerificationUI([out] HWND* phwnd);
Argument Type Description
phwnd HWND* Client-provided HWND of the parent window for
displaying code verification UI. If this
parameter is
NULL, the desktop window is used. If the value
is
INVALID_HANDLE_VALUE, or if the return value is
S_FALSE, then no code verification UI will be
displayed,
and certain necessary components may not be
installed.
Returns S_OK Success.
S_FALSE No window is available.
E_INVALIDARG The argument is invalid.
ICodeInstall::OnCodeInstallProblem is called when there is a problem with
code installation. This notification gives the client a chance to resolve
the problem, often by displaying UI, or by aborting the code installation
process. The parameters for ICodeInstall::OnCodeInstallProblem are
explained below.
HRESULT OnCodeInstallProblem(
[in] ULONG ulStatusCode,
[in] LPCWSTR szDestination,
[in] LPCWSTR szSource,
[in] DWORD dwReserved);
Argument Type Description
ulStatusCode ULONG Status code describing what problem
occurred. A member
of CIP_STATUS.
szDestination LPCWSTR The name of the existing file that was
causing a problem.
This may be the name of an existing file
that needs to be
overwritten, the name of a directory
causing access
problems, or the name of a drive that is
full.
szSource LPCWSTR Name of the new file to replace the
existing file (if
applicable).
dwReserved DWORD Reserved for future use
Returns S_OK Continue the installation process. If there
was an "access
denied" or disk-full problem, retry the
installation. If there
was an existing file (newer or older
version), overwrite it.
S_FALSE Skip this particular file, but continue
with the rest of the
code installation process. Note: this is
the typical response
for the CIP_NEWER_VERSION_EXISTS case.
E_ABORT Abort the code installation process.
E_INVALIDARG The given arguments are invalid.
The ulStatusCode parameter above is one of the following values:
Value Description
CIP_DRIVE_FULL The drive specified in
szDestination is full.
CIP_ACCESS_DENIED Access to the file
specified in szDestination is denied. The
client is required to
take a sequence of steps to possibly
correct the situation.
The client could check its own state
to see if the file in
question or the component it belongs to
is in use by the client
and close the file or release the
component and call COM to
free unused libraries in the
process. If it cannot
locate the file or component, it should
display UI to the user
suggesting that they close other
applications in the
system to retry the operation. The
operation can be retried
by returning S_OK. Returning
S_FALSE will ignore this
file and proceed with the rest of
the installation. Any
error returns will cause the code
download to abort.
CIP_OLDER_VERSION_EXISTS An existing file (older
version) specified in
szDestination needs to be
overwritten by the file specified
in szSource.
CIP_NEWER_VERSION_EXISTS A file exists (specified
in szDestination) that is a
newer version of a file
to be installed (specified in
szSource)
CIP_NAME_CONFLICT A file exists (specified
in szDestination) that has a naming
conflict with a file to
be installed (specified in szSource).
The existing file is
neither a newer nor an older version of
the new file--they are
mismatched but have the same file
name.
CIP_TRUST_VERIFICATION_COMPONENT_MISSING The code installation
process cannot find the necessary
component (e.g.,
WinVerifyTrust) for verifying trust in
downloaded code. szSource
specifies the name of the file
that cannot be certified.
The client should display UI
asking the user whether
or not to install the untrusted
code, and should then
return E_ABORT to abort the
download, S_OK to
continue anyway, or S_FALSE to
skip this file but
continue (usually dangerous).
CIP_NEED_REBOOT The self-extracting EXE
or `hook` (either
Win32 INF section or a
custom setup program hook run
using the
run=<cmd-line>) in the hook section updated
components in use that
can only be used after a reboot.
The client should display
UI and Shutdown windows if
the user agrees to reboot
the machine for the changes to
take effect. The INF
filename or command line of the
EXE that caused the
reboot is in szDestination. Returning
E_ABORT will abort the
download.
CIP_EXE_SELF_REGISTRATION_TIMEOUT The EXE that was spawned
to self-register (may also be a
self-extracting EXE) is
still pending completion. This is
usually called out when
the client calls IBinding::Abort()
while waiting for the
self-extracting EXE to complete.
The command line of the
EXE is available in
szDestination. The client
should display UI to the user to
warn that installation on
the page is incomplete. The
return value of S_OK from
the callback will cause a
continued wait for the
EXE to complete. S_FALSE will
abandon the EXE and
proceed with the rest of the
installation. Any error
returns will cause abortion of the
code download.
CIP_UNSAFE_TO_ABORT Code download is in setup
phase and one or more
components may have
already been installed irreversibly
rendering unknown the
state of the setup of the
component in question.
This notification is issued when
the client calls
IBinding::Abort() while in setup phase.
The return value of S_OK
will cause Abort() to return
with S_FALSE and the code
download will continue. Any
other return will cause
the code download to abort and the
state of the component is
not guaranteed.
After the necessary software components are downloaded, the WinVerifyTrust interface checks to see if the downloaded components possess a digital signature. However, other verification interfaces could also be used. If the downloaded software components posses a digital signature, the WinVerifyTrust interface validates the digital signature and its corresponding digital certificate. The digital certificate describes who issued the software component and who created the digital signature. If the downloaded software components do not possess a digital signature, or if the corresponding signature was not issued by a trusted authority, WinVerifyTrust gives the client-side (e.g., network browser) user the option of whether or not to trust the code and install it on the local computer 36. Before asking for verification on its own, WinVerifyTrust uses ICodeInstall::NeedVerificationUI to confirm that it is appropriate to display the appropriate UI for the user of the local computer 34. After the code has been verified 72, the control file is installed 74 on the local computer 34 with a code installation module 64. As is shown in FIGS. 7A-7B, method 112 installs 74 and registers 76 the control file. If the control file is a single portable executable file (e.g., .EXE, .OCX, DLL) 114, the single portable executable file is installed 116 on the local computer 34 by CoGetClassObjectFromURL. If the control file is not a single portable executable 118 (i.e., the file is a .INF or a CAB file), then each of the files referenced in the initialization or cabinet file are installed 120-124 on the local computer 34. In an illustrative embodiment of the present invention, most of the downloaded software components are installed in a permanent cache store in an operating system directory called "windows.backslash.occache." However, other directories could also be used. Some components (e.g., helper DLLs that need to be on the system PATH but currently are not) will also be installed in the ".backslash.windows" and ".backslash.windows.backslash.system" directories. However, other directories could also be used. If there are any problems during installation (e.g., a full disk, access violations, existing older/newer version of a file, etc.), the code install interface function ICodeInstall:OnCodeInstallProblem is called to make the user aware of the problem. If the portable executable file is an .OCX or a .DLL file 126, it is registered by calling the DllRegisterServer interface 128. The DllRegisterServer interface is an interface which registers a software component in the registry database of the operating system. However, other registering interfaces could also be used. If the portable executable file is a .EXE file 130 (FIG. 7B), the .EXE is registered during execution with the run-time parameter of "/RegServer" 132. This run-time parameter registers the .EXE file in the registry database of the operating system. In an illustrative embodiment of the present invention, self-registering software components are used because the .INF format does not provide syntax for changing registry information (for security reasons). For .OCXs, .DLLs, and .EXEs marked as "OleSelfRegister" in the Version resource, self-registration will be attempted. For .DLLs and OCXs, this means loading the .DLL library and calling DllRegisterServer. For .EXEs, this means running the .EXE with the run-time parameter of "/RegServer". This ensures that software components implemented as local servers (e.g. winword.exe) are registered correctly. If an object is not marked as "OleSelfRegister" but registration is necessary, or if it is desired to over-ride the "OleSelfRegister" flag, the following lines can be added to an .INF file:
[foo.ocx]
RegisterServer=no ; don't register even if marked OleSelfRegister
or
RegisterServer=yes ; register this even if not marked OleSelfRegister. This
is the typical workaround for getting old
; controls to register
Software components that are a self-extracting .EXE may remain unregistered because the "OleSelfRegister" flag is ignored if the URL points directly at a .EXE file. In this case it is assumed that this is a self-registering .EXE, and this enables self-extracting .EXEs to work correctly as long as they ignore the "/RegServer" command-line parameter. Supporting self-extracting .EXEs enables very complex setup mechanisms to be launched automatically. However, if a self-extracting .EXE is called via this mechanism, then any components that it installs will not be automatically tracked. Such components are permanently installed and may not be available for future cleanup. Every client (e.g., the network browser) of a software module (e.g., .OCX, .DLL, .EXE) is expected to increment and decrement the existing SharedDLLs section in the registry database when the components are registered to allow the operating system to keep track of how many clients are sharing the software components. Returning to FIG. 7B, if the file is a .INF or .CAB file, all downloaded software components are registered using a new section in the registry database called Module Usage 136 that keeps track of such components. The Module Usage section in the registry holds a list of "owners" and "clients" for each software module. Thus, the registry can keep track of how many clients a module has (i.e., the SharedDLL count), as well as what software applications executing on the local computer are using the software module. The registry entries for ModuleUsage use the following syntax:
[ModuleUsage]
[<Fully Qualified Path&File Name>]
.FileVersion=a,b,c,d
.Owner = Friendly Name/ID of Owner
<Client ID > = <info peculiar to this client>
<Client ID > = <info peculiar to this client>
A ModuleUsage section in a sample registry might be:
Under My
Computer.backslash.HKEY_LOCAL_MACHINE.backslash.Software.backslash.Microso
ft.backslash.Windows
.backslash.CurrentVersion:
[ModuleUsage]
[c:.backslash.windows/system/mfc40.dll]
.FileVersion=1,4,0,0
.Owner={CLSID of main object rclsid passed to
CoGetClassObjectFromURL}
{CLSID of main object rclsid passed to CoGetClassObject
FromURL}=<any info, or default>
AnotherAppID=<any info, or default>
The parameters of ModuleUsage are as follows:
Key name Description
<Fully Qualified This is the full path of the shared module. This name
has to use "/"s
Path&File Name> instead of ".backslash."s because the ".backslash." is
an invalid char in a key name.
.Owner The application that installs the shared module and creates
the
original ModuleUsage section will put some identifier in
the Owner
key section. If the DLL already existed on the system then
and this
Module Usage key did not exist then the .Owner key should
be set
to "Unknown" and the DLL should not be removed on
uninstall.
The owner should always also enlist itself as a client.
.File Version The version number for the shared module.
<Client ID> ID of a client who is using the shared module. The value
corresponding to each client key contains client specific
information. When the client is Internet Component
Download, the
<Client ID> is {CLSID of main object rclsid passed to
CoGetClassObjectFromURL}, and the client-specific
information is
a number which serves as a reference count. For other
clients, the
client-specific information should be the full path of the
client, so
that if the client is accidentally deleted it is possible
to do garbage
collection.
To permit code caching, the "SharedDLLs" section in the registry database is not used exclusively since reference counts are often incorrectly inflated. For example, any application that is re-installed on the local computer increases the reference count in the SharedDLLs section of the registry database even though the software component already had been incremented previously. However, in an illustrative embodiment of the present invention, every client (e.g., network browser) of a software module is expected to increment and decrement the existing SharedDLLs section in the registry database as well (a client only increments this value once when it adds itself as a client under ModuleUsage). This is to allow a migration path for applications currently implementing only SharedDLLs scheme. The ModuleUsage registry information complements the reference counts in the SharedDLLs section by remembering which clients are actually using a shared module. The SharedDLLs counting scheme is correct when used with ModuleUsage registry information and allows caching of downloaded code in the permanent cache store. Furthermore, when downloading files, the ModuleUsage registry information is used as an efficient shortcut for verifying whether a file needs to be overwritten because it is an out-of-date version. In another embodiment of the present invention, the registering step 76 is optional. Downloaded code installed in the permanent cache store can be removed manually or automatically. In one embodiment of this invention, a user is allowed to clean up downloaded code, either through the UI of the application program (e.g., the network browser) or via UI exposed by the operating system itself (e.g. the Windows.RTM. 95 "shell." In another alternative embodiment of the present invention, ModuleUsage information is used by the CoGetClassObjectFromURL interface to automatically detect old or unused downloaded code, and automatically delete such code from the permanent cache store. In another embodiment of the present invention, software can be located 68, downloaded 70 and installed 74, with the verifying 72 and registering 76 steps optional. This allows a user to control more of the automatic code downloading method with other software applications chosen by the user. For example, a "hook" mechanism is provided to override or customize steps of method 66. In the illustrative embodiment of the present invention, there are two types of hooks: Unconditional (e.g., for a setup program) and Conditional (e.g., for a version of an existing software component) hooks. Unconditional hooks are hooks that are always executed. Conditional Hooks are executed only when a certain selected condition evaluates to TRUE. Hooks are added to the .INF file described above. Unconditional hooks are used in [Setup Hooks] section of the .INF file. For Unconditional Hooks, the "CODEBASE=" attribute points to a cabinet file "foo.cab" that contains a "foosetup.exe", "foo.ocx" and "foo.inf." file. The setup file "foosetup.exe" run with the "/q" parameter will install the "foo.ocx" file silently in the "windows.backslash.occache" directory described above. For Unconditional hooks, an example initialization file "foo.inf" includes the following: [Add.Code] [Setup Hooks] hook1=hook1 [hook1] run=%EXTRACT_DIR%.backslash.foosetup.exe/q When the cabinet file foo.cab is opened, it is verified and then the .INF file is processed. Since the [Add.Code] section is empty, the [Setup Hooks] section is processed. The files in the cabinet file "foo.cab" are installed in a unique temporary directory and the command line listed in the "run=" attribute is executed (i.e., run=%EXTRACT_DIR%.backslash.foosetup.exe/q"). All the files left in the temporary directory after the completion of "foosetup.exe" including "foosetup.exe" are discarded. However, other commands could also be used for the Unconditional Hooks. Conditional Hooks are run only when a certain condition is evaluated as TRUE. This is typically when the [Add.Code] section points at a certain software component and that software component is not available on the client computer. The above example for Unconditional Hooks could be rewritten using Conditional Hooks. For Conditional Hooks the "CODEBASE=" attribute also points to a cabinet file "foo.cab" that contains a "foosetup.exe", "foo.ocx" and "foo.inf" file. The file setup file "foosetup.exe" run with the "/q" parameter also installs the file "foo.ocx" silently in the "windows.backslash.occache" directory as was described above. For Conditional Hooks, an example initialization file "foo.inf" includes the following: [Add.Code] foo.ocx=foo.ocx [foo.ocx] Clsid={. . . } hook=hook1 [hook1] run=%EXTRACT_DIR%.backslash.foosetup.exe/q When the .INF is opened, it is processed using the [Add.Code] attribute. When the [foo.ocx] section is processed, the Clsid, (e.g. for "foo.ocx") is used to determine if it is registered or available on the client computer by checking the operating system registry. If "foo.ocx" is not registered on the client computer, the hook mentioned in the [hook1] parameter is executed. The execution of [hook1] section is identical to the description of the hook as an Unconditional Hook, but occurs only after checking the Cisid of "foo.ocx." However, other commands could also be used for the Conditional Hooks. Conditional Hooks can be used to make the verifying 72 and registering 76 steps of method 66 conditional (i.e., optional). This allows a user to use method 66 and system 56 to simply locate, download, and install a desired software component without verification or registration. The verification and/or registration steps could be accomplished by methods different than those described in connection with method 66 and system 56 giving the user greater flexibility over the use of the software components downloaded and installed on the local computer. In another embodiment of the present invention, the HTML tag <EMBED> is also used to add multi-media or interactive behavior to HTML documents with method 66 and system 56. The <EMBED> tag has three attributes, SRC, WIDTH, and HEIGHT, and may also contain optional parameters that can be sent to a software component (e.g., a Netscape ONE plug-in) handling the embedded data type. The SRC attribute specifies the URL of the source document. The WIDTH attribute specifies the width of the embedded document in pixels. The HEIGHT attribute specifies the height of the embedded document in pixels. There can also be a number of optional parameters passed to a plug-in component with the <EMBED> tag, with PARAMETER_NAME=<PARAMETER_VALUE> (e.g., the parameters described for the <OBJECT> tag above). For more information on the <EMBED> tag, see the HTML 3, Electronic Publishing on the World Wide Web book cited above. When the <EMBED> object tag is encountered in the document by the network browser, the <EMBED> tag is parsed to pull out the <EMBED> tag attributes, and the attributes are used with method 66 and system 56 in a manner similar to that described for the <OBJECT> tag above. The present invention is not limited to the HTML <OBJECT> and <EMBED> tags. Other HTML tags can also be used to provide method 66 and system 56. In addition, the present invention is not limited to computer system 10 or the browsing environment 34. The invention can also be used in a set-top box, such as those which provide interfaces to cable television and other television networks, in a satellite control box, such as those which provide interfaces to digital and other satellite transmission services. The present invention may also be used in pagers, cellular telephones, personal assistants and other wireless personal communications devices. When all of the desired computer software components have been located 68, downloaded 70, verified 72, installed 74, and registered 76, any appropriate software components are returned 78 to the client application (e.g., the network browser) which made the request for the computer software components. The software components returned to the client application are then displayed in the document display area 52 on the display device 20 of the local computer 36. In an illustrative embodiment of the present invention, the network browser Internet Explorer.RTM. 3.0 by Microsoft uses system 56 and method 66 (and methods 80, 96 and 112) to browse HTML documents 46 on the Internet 38. The software interfaces and corresponding software subroutines just described for methods 66 (and methods 80, 96 and 112), and system 56 are available in the Internet Component Download Application Program Interface (API) for the Windows.RTM. 95 Operation System by Microsoft Corporation. HTML documents typically contain one or more HTML <OBJECT> or <EMBED> tags. When an HTML <OBJECT> or <EMBED> tag is encountered during browsing, Internet Explorer.RTM. parses the appropriate parameters out of the <OBJECT> and <EMBED> tags and passes them to the CoGetClassObjectFromURL interface as was described above. The HTML <OBJECT> or <EMBED> tags typically point to object oriented applications which provide dynamic or interactive multimedia to a HTML document. However, other applications which are not network browsers, and do not parse HTML documents with <OBJECT> or <EMBED> tags can also use system 56 and methods 66 to download any type of computer software component from a local or remote computer by passing appropriate parameters to CoGetClassObjectFromURL interface. The computer software components need not provide dynamic or interactive multimedia to a client application. In addition interfaces other than CoGetClassObjectFromURL could also be used. It should be understood that the programs, processes, and methods described herein are not related or limited to any particular type of computer apparatus, unless indicated otherwise. Various types of general purpose or specialized computer apparatus may be used with or perform operations in accordance with the teachings described herein. In view of the wide variety of embodiments to which the principles of our invention can be applied, it should be understood that the illustrated embodiments are exemplary only, and should not be taken as limiting the scope of our invention. Rather, we claim as our invention all such embodiments as come within the scope and spirit of the following claims and equivalents thereto.
|
Same subclass | ||||||||||