Geoff Chappell - Software Analyst
This function tests the value of an Internet Explorer restriction and displays a message box if the restriction applies.
BOOL
SHIsRestricted2W (
HWND hwnd,
RESTRICTIONS2 rest,
LPCWSTR url,
DWORD reserved);
The hWnd argument provides a handle to the window that should own the message box, or is NULL.
The rest argument selects the restriction whose value is wanted. The supported values in the RESTRICTIONS2 enumeration are listed separately.
The url argument, if not NULL, supplies a URL to evaluate the restriction for, most notably with respect to the URL’s security zone.
The reserved argument must be zero.
The function returns TRUE if the selected restriction evaluates to anything other than zero. Otherwise, the function returns FALSE.
This function exists as a convenience for the case where a restriction is a boolean indicator of whether some Internet Explorer feature is restricted from use, typically as an administrative policy. The restriction is evaluated by calling SHDOCVW’s own function SHRestricted2 (passing the arguments as given, except for the window handle). If the feature turns out to be restricted, then the SHLWAPI function SHRestrictedMessageBox is called to alert the user.
In version 6.0 and higher, SHDOCVW may have an activation context. If so, this is activated for the call to SHRestrictedMessageBox.
For the version 6.0 from Windows Vista, and higher, the preceding explanation of behaviour remains true of the implementation in SHDOCVW, but this is not the implementation that is accessed by importing SHIsRestricted2W from SHDOCVW. The function is duplicated in a new DLL, named IEFRAME, and is exported from there. SHDOCVW forwards all import requests to the copy that is exported from IEFRAME. The implementation in SHDOCVW still seems to have one way of getting used, but only internally (and even this may be due to oversight or to some difficulty in shedding it completely). In version 6.1, the implementation in SHDOCVW is eliminated entirely.
For the IEFRAME implementation, the two called functions are not called from SHDOCVW and SHLWAPI. First, although SHDOCVW retains an implementation of SHRestricted2 (in version 6.0), it is inaccessible. The exported implementation is in IEFRAME and that is what IEFRAME calls. Second, though SHRestrictedMessageBox continues to be exported from SHLWAPI, IEFRAME has its own copy and that is what IEFRAME calls.
This “separation” of Internet Explorer functionality from Windows seems to have been prepared some years in advance of Windows Vista. Starting with the version 6.0 from Windows XP SP2 and from Windows Server 2003 SP1, including builds from the Internet Explorer 7 and 8 packages for Windows XP and Windows Server 2003, the SHDOCVW implementation of SHIsRestricted2W is aware that an IEFRAME implementation may be present from installation of Internet Explorer 7 or 8. The exported function is not actually SHIsRestricted2W itself but SHIsRestricted2W_IeframeProxy. The proxy may have been intended to redirect the function to the IEFRAME implementation when IEFRAME is indeed present. As actually coded however, all the proxy does is save the address of the IEFRAME implementation before proceeding anyway to execute the rest of the SHDOCVW implementation.
The SHIsRestricted2W function is exported from
In version 6.0 from Windows Vista, and higher, SHDOCVW continues to export the function but only by forwarding it to IEFRAME.
Though this function dates from as long ago as 1999, it was still not documented by Microsoft as late as the January 2007 edition of the Windows Vista Software Development Kit (SDK).