INFO: FAQ on Developing with the ActiveX SDK

• Microsoft ActiveX SDK, version 1.0

SUMMARY

This article covers some of the most Frequently Asked Questions (FAQ) about developing with the Microsoft ActiveX SDK. You can find this and other FAQ articles by querying on the keyword "FAQ."

MORE INFORMATION

This FAQ is also available on the Microsoft Web site at http://www.microsoft.com/support/products/developer/activexsdk/content/faq.

Due to the increasing number of FAQ's on the ActiveX SDK, the FAQ's are categorized in the following manner:

• ActiveX Controls: Common questions associated with developing ActiveX controls for the Internet using the ActiveX SDK.
• ActiveX Documents: Issues relating to DocObject servers that can be hosted from various containers such as Internet Explorer
• WebBrowser Control: Top issues that focus on the WebBrowser control, including printing, redistribution, and hosting issues.
• Code Download: Closely tied with ActiveX Controls, these issues focus mainly on downloading components over the Internet.
• Internet Explorer Object Model: Issues related to the Object Model exposed by Internet Explorer are addressed here.
• WinInet: A wide range of issues relating to the WinInet APIs.
• Related FAQ's: "Where can I learn more about . . .?" type of questions are addressed here.

Frequently Asked Questions on ActiveX Controls

1. Q. What really is the difference between an OLE Control and an ActiveX
   control?

   A. ActiveX controls are a superset of OLE Controls. Originally, OLE
   Controls were required to support a number of interfaces that are
   optional for ActiveX controls. For ActiveX controls, the only
   requirements are that the control supports IUnknown and is self-
   registering (that is, exports DllRegisterServer and
   DllUnregisterServer).

   Mike McKeown addresses this very confused issue of OLE Controls versus
   ActiveX controls in the October 1996 issue of the MIND (Microsoft
   Interactive Developer) magazine.

   More information on enabling controls for the Internet, as well as
   various documentation on interfaces and functions an ActiveX control
   should support, can be found on the "ActiveX Controls" section of the
   ActiveX SDK online documentation.

   Q. So, are out of the box OCXs, such as the one shipped with Visual
   Basic 4.0, also ActiveX controls?

   A. Yes. All OCXs are ActiveX controls.

   Q. How about MFC controls, are they also ActiveX controls?

   A. Yes, all MFC controls are ActiveX controls. An old Visual C++ 4.0
   control is an ActiveX control, as is one created with Visual Basic 4.0
   or the ActiveX controls BaseCtl Framework that comes as part of the
   ActiveX SDK samples. Look at the term ActiveX control as a renaming and
   restructuring of the OLE Control technology--an evolution.

   A control can be designed to work efficiently on the Internet, or to
   be hosted in desktop container applications, or to do both. Sure, some
   controls are not as well suited to be used on the Internet due to their
   large size and synchronously loading of properties, but they are still
   ActiveX controls. This is what causes most of the confusion.

   Q. Are there different types of ActiveX controls?

   A. Yes. The OLE Control and Control Container Guidelines version 2.0
   describe a number of optional features that may be implemented. Some
   controls implement features that require corresponding features in the
   container in order to work properly. Conversely, some containers
   recognize only controls that implement some optional features.

   Older containers typically recognize only controls that are marked in
   the registry with the "Control" key and that implement the older OLE
   Control specification, although they may be able to use newer controls
   as Automation objects. Newer controls and containers can use something
   called "Component Categories" to describe their abilities and
   requirements. Component Categories are defined in the OLE Programmer's
   Guide, which is part of the ActiveX SDK and Win32 SDK.

   The OLE Control and Control Container Guidelines version 2.0 and other
   related specifications can be found under the InetSDK\Specs folder of
   the ActiveX SDK installation.

   Q. So, do all ActiveX controls work with Visual Basic 4.0?

   Most ActiveX controls should work with Visual Basic 4.0. It is possible
   that a control requires container support that Visual Basic 4.0 does not
   provide. This is true for any control and container combination.

   Q. Do all ActiveX controls work with Internet Explorer 3.0?

   A. Again, it is possible that controls require container support that
   Internet Explorer 3.0 does not provide.

   Internet Explorer 3.0 also includes security features, which may
   prevent some ActiveX controls from working with all Internet Explorer
   3.0 configurations. This is most likely for older controls. In order for
   controls to work smoothly with Internet Explorer when it's active-
   content security is configured for the high safety level (which is the
   default), the controls must be marked as "safe for initialization" or
   "safe for scripting." If a control is used on an HTML page in a way that
   conflicts with its safety identification and the user's safety level,
   Internet Explorer does not create the control. See the "Safety API
   Reference" in the ActiveX SDK documentation for more information.

   Q. How do "lightweight OLE Controls" come into play?

   A. Typically, when someone uses this term, they are referring to
   controls that are written to be as small as possible, so they can be
   downloaded quickly. Lightweight controls are ActiveX controls, but may
   not implement all the required features of the older OLE Control
   specification.

   The ActiveX controls BaseCtl Framework (mentioned above) that ships with
   the ActiveX SDK samples provides small self-sufficient "lightweight"
   controls that are not dependent on associated DLLs (such as the MFC or
   Visual Basic runtimes). It should be noted that the BaseCtl Framework
   requires a solid understanding of OLE and COM technologies.

   The Active Template Library (ATL) was created to provide developers
   with a convenient mechanism for building lightweight and fast controls.

   If you want to know more about ActiveX controls, particularly on
   developing Web pages, check out another FAQ available on the "ActiveX
   controls" section of the ActiveX SDK page on
   http://www.microsoft.com/intdev/sdk/.

2. Q. Why does Internet Explorer bring up a "Potential Safety Violation"
   warning when I try to display a page that contains a control I've
   written?

   A. Depending on how Internet Explorer's Safety Level is set, Internet
   Explorer brings up a "Potential Safety Violation" message box indicating
   that "the page contains active content that is not verifiably safe to
   display." Then, it either refuses to display the control, or it gives
   the user an option to allow it to be used.

   Internet Explorer is trying to protect the client workstation by
   refusing to execute content that may be unsafe. There are three ways to
   resolve this issue:

   - The first option: The end-user reduces the security settings of their
     browser via Internet Explorer's View\Options\Security\Safety Level
     option. This is the least appealing option because it reduces or
     disables security on all content displayed in the browser.

   - The second option: Control developers register their controls as
     implementing the "safe for scripting" component category. When
     Internet Explorer encounters an <OBJECT> tag, it uses the Component
     Categories Manager to determine whether or not the specified CLASSID
     is safe for scripting.

   - The third option: Control developers implement the IObjectSafety
     interface.

3. Q. How do you register a control as a player for a particular
   file/MIME type?

   A. This information is available in the SDK documentation under
   \inetsdk\specs\register.htm. It is essential that you register an
   ActiveX object. Internet Explorer needs the registration to launch the
   correct player when it interprets the standard HTML <A HREF> tag, or
   Netscape's <EMBED> tag. Without the registration described in this
   document, it is impossible for ActiveX containers to guess what
   application to use to display or play an unknown media file.

   The document outlines the four steps necessary for registering your
   ActiveX control, including the special registry settings that allow
   ActiveX controls to do the following:

   - Launch with the <EMBED> tag (that is, without <OBJECT> and without
     CLSID specified)

   - Work full-frame (that is, for <A HREF> tags). Even ActiveX controls
     work full-frame, so you no longer need to have a DocObject to work
     full-frame (although controls won't get the full menu-negotiation, and
     so forth.)

   1. Register the CLSID for the ActiveX object.
   2. Associate the object's CLSID with a ProgId.
   3. Associate the object with a MIME type.
   4. Associate the file extension with a ProgId and optionally with a MIME
   type.

   However, information on how to get the file name from within your
   control is missing from the document. This is passed to
   IPersistPropertyBag as a parameter called SRC.

4. Q. I'm trying to license my control. Is there a tool available for
   generating .lpk (license package) files?

   A. Use the LPK_TOOL that is part of the ActiveX SDK on inetsdk\bin
   folder. In the HTML page, be sure to insert an <OBJECT> tag, specifying
   the ClassID of the Internet Explorer license manager object, in addition
   to the <OBJECT> tag for the control you're licensing.

   For example, if you run the LPK_TOOL, add the Masked Edit Control, and
   save it out to Maskedit.lpk, your HTML code should look like the
   following:

      <OBJECT CLASSID="clsid:5220cb21-c88d-11cf-b347-00aa00a28331">
      <PARAM NAME="LPKPath" VALUE="maskedit.lpk">
      </OBJECT>

      <OBJECT CLASSID="clsid:C932BA85-4374-101B-A56C-00AA003668DC"
       WIDTH=200 HEIGHT=200>
      </OBJECT>

   More information on this can be found on the "Licensing ActiveX
   controls" section of the ActiveX SDK documentation and from article
   Q159923 in the Microsoft Knowledge Base.

5. Q. Does Internet Explorer 3.0 support windowless controls? If not, when
   will support for this be available?

   A. No. Internet Explorer 3.0 does not currently support windowless
   controls, as it does not implement the IOleInPlaceSiteWindowless
   interface. Watch for this feature in future versions of Internet
   Explorer.

   Currently, you can work around this by embedding the HTML Layout Control
   in an HTML page. The HTML Layout Control is a container that supports
   windowless controls. It allows contained windowless controls to be
   transparent relative its background.

6. Q. Is there an API to render JPEG/GIFs from an ActiveX control?

   A. Not currently, but as a workaround you could host the WebBrowser
   control and point it to the file in question.

7. Q. I'm trying to build the WebImage sample, and I keep getting the
   error: "Cannot open include file: WImgInterfaces.H: No such file or
   directory". I searched my hard disk everywhere and this file is nowhere
   to be found. What did I do wrong?

   A. You'll run into this problem if you try to build the WebImage control
   sample within the Developer Studio environment (as opposed to running
   NMAKE /A from the command line, where it builds fine). The file
   WImgInterfaces.h is generated by the mktyplib call in the makefile.

   Make sure your Build.Settings are correctly set:

   - Go into Build.Settings, pick the ODL file and set the output header
   file to WImgInterfaces.h.

   - Make sure the Build.Settings match the MAKEFILE.

   More information on this can be found in article Q159967 in the
   Microsoft Knowledge Base.

8. Q. Where do I get support for the controls in the Internet Control Pack?

   A. Other than the information provided in the Internet Control Pack Web
   site on http://www.microsoft.com/icp, Microsoft does not support any of
   the controls that are part of the Internet Control Pack (ICP). The
   controls included in the ICP are the FTP, HTML, HTTP, NNTP, POP, SMTP,
   WinSock TCP, and WinSock UDP controls.

   Questions on these controls, including information on subsequent
   releases, as well as customized versions should be directed to the
   following:

   NetManage
   http://www.netmanage.com
   10725 North De Anza Blvd.
   Cupertino, CA 95014
   (408) 973-7171 sales phone
   (408) 257-6405 fax
   (408) 973-8181 support phone

   More information on this can be found in article Q156692 in the
   Microsoft Knowledge Base.

Frequently Asked Questions on ActiveX Documents

1. Q: I'm trying to access a .vbd file from Internet Explorer and I keep getting the error: "Internet Explorer is opening file of unknown type: xxx.vbd." What is wrong?

   A: A number of things can cause this error to occur:

   - You are using the wrong .vbd file - You are using an outdated .vbd file - The Actxprxy.dll is missing or is not registered

        properly.
   

   - The ActiveX EXE/DLL is not registered properly. - VB Runtime is not installed or on the path. - The ActiveX Document may not be signed or safe for

        scripting.
   

   More information on this can be found from article Q167380 in the Microsoft Knowledge Base.

Frequently Asked Questions on the WebBrowser Control

1. Q. I'm using the WebBrowser control in my application. How do I
   redistribute it?

   A. You must obtain a redistribution license for Internet Explorer 3.0
   and use the Internet Explorer 3.0 self-extracting executable
   (Msie30.exe) to install the necessary files and registry entries. You
   can license Microsoft Internet Explorer for Windows 95, Windows 3.1,
   Windows NT Workstation, and Macintosh royalty-free to redistribute
   within your organization or to your customers. Refer to article Q155969
   in the Microsoft Knowledge Base for more information.

   Microsoft provides an online form to register your organization to
   redistribute Internet Explorer. This sign-up form is available on the
   IEAK page.

2. Q. How do I print from the WebBrowser control?

   Although the WebBrowser control does not support a print method, you can
   print its contents using one of two ways:

   - Set focus to the Web Browser Control and send a key combination of
   Ctrl-P.

   -or-

   - Call the GetDocument() method, which returns an *IDispatch. Using this
   IDispatch pointer, call QueryInterface() on IID_IOleCommandTarget. With
   the object pointer returned, call Exec (NULL, OLECMDID_PRINT, 0, NULL,
   NULL):


      LPDISPATCH lpDispatch = NULL;
      LPOLECOMMANDTARGET lpOleCommandTarget = NULL;

      lpDispatch = m_ctlWebBrowser.GetDocument();
      ASSERT(lpDispatch);

      lpDispatch->QueryInterface(IID_IOleCommandTarget,
      (void**)&lpOleCommandTarget);
      ASSERT(lpOleCommandTarget);

      lpDispatch->Release();

      // Print contents of web browser control.
      lpOleCommandTarget->Exec(NULL, OLECMDID_PRINT, 0, NULL,NULL);
      lpOleCommandTarget->Release();

   More information on this can be found in article Q156732 in the
   Microsoft Knowledge Base.

3. Q. How do I change the font from a WebBrowser control?

   A. The WebBrowser automation model does not support a method that allows
   you to change the font of the text of the currently displayed page.

   The WebBrowser control, however, exposes this functionality through the
   IOleCommandTarget interface. Call the GetDocument() method, which
   returns an *IDispatch. Using this IDispatch pointer, call
   QueryInterface() on IID_IOleCommandTarget. With this IOleCommandTarget
   pointer, call Exec() with OLECMDID_ZOOM and use the pvaIn input argument
   to pass a value in the range of 0 to 5 (where 0 is smallest) indicating
   the desired scale of the font. In effect, this mimics the
   functionality available through Internet Explorer's View\Fonts menu:


      LPDISPATCH pDisp = NULL;
      LPOLECOMMANDTARGET pCmdTarg = NULL;

      pDisp = m_ctlWebBrowser.GetDocument();
      ASSERT(pDisp);

      pDisp->QueryInterface(IID_IOleCommandTarget, (LPVOID*)&pCmdTarg);
      ASSERT(pCmdTarg);

      VARIANT vaZoomFactor;   // Input arguments

      VariantInit(&vaZoomFactor);
      V_VT(&vaZoomFactor) = VT_I4;
      V_I4(&vaZoomFactor) = fontSize;
      pCmdTarg->Exec(NULL, OLECMDID_ZOOM, OLECMDEXECOPT_DONTPROMPTUSER,
      &vaZoomFactor, NULL);
      VariantClear(&vaZoomFactor);

      if (pCmdTarg) pCmdTarg->Release(); // Release document's command
                                         // target.
      if (pDisp) pDisp->Release();       // Release document's dispatch
                                         // interface.

   More information on this can be found in the IEZOOM sample described in
   article Q156693 in the Microsoft Knowledge Base.

4. Q. I'm trying to host the WebBrowser control from a non-MFC application
   using CoCreateInstance(). How do I do this correctly?

   A. Many controls, including the WebBrowser control, require that the
   container support certain OLE document/Control Site interfaces in order
   for the OLE Automation calls to work. These interfaces provide the
   visual containment for the control. An application that does not care
   about the visual containment of the control can create an instance of
   Internet Explorer, instead of the control, with code similar to the
   following:

      hr = CoCreateInstance(CLSID_InternetExplorer, NULL, CLSCTX_SERVER,
           IID_IUnknown, (void **)&g_pUnk);
      hr = g_pUnk->QueryInterface(IID_IWebBrowserApp, (void
           **)&g_pIWebBrowserApp);
      g_pUnk->Release();
      g_pIWebBrowserApp->GoHome();

   An application that needs visual containment of the control has to
   support the OLE Documents/Control Site interfaces described in
   \InetSdk\Specs\OCGUIDE.DOC. The WebBrowser control is a control written
   according to the OLE Control 94 specification, and therefore the
   containing application should implement the corresponding interfaces
   described in the document.

Frequently Asked Questions on Code Download

1. Q. I need to package the MFC 4.2b dependent DLLs with my ActiveX
   control. What's the best way to do this?

   A. The MFC 4.2b dependent DLLs are available as a signed .cab file at
   the MFC 4.2b CAB Download page.

   The URL for this CAB file is
   http://activex.microsoft.com/controls/vc/mfc42.cab. By clicking on this
   link, you'll install the files on your machine. You can include this
   link on your Web sites that require MFC 4.2b so your users can install
   the DLLs at their convenience.

   This .cab file installs the following files:

      Name           Version
      ----------------------
      Mfc42.dll     4.2.6256
      Olepro32.dll  4.2.6068
      Msvcrt.dll    4.20.6164

 2. Q. What version do I specify in the CODEBASE attribute of my <OBJECT>
   tag, especially when pointing to a .cab file?

   A. The #Version information applies to the control specified by the
   CLASSID parameter of the  <OBJECT> tag.

3. Q. How do I version stamp a CAB?

   A. Instead of putting a version on the .cab file, the .inf file inside
   the .cab should specify the version. The .inf file should have a file
   section that specifies a version and the same classid specified in the
   <OBJECT> tag. As illustrated in the example below, this file version
   specifies the version of the ActiveX control to be downloaded.

   Example .inf file section:

      [circ3.ocx]
      ; The lines below specify that the specified Circ3.ocx (clsid,
      ; version) needs to be installed on the system. If it doesn't exist
      ; already, can be downloaded from the given location (a .cab). NOTE:
      ; if "thiscab" is specified instead of the file location, it is
      ; assumed that the desired file is present in the same .cab cabinet
      ; that the .inf originated fromotherwise, 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}


      ; Note that the {}s are required when entering the CLSID in the .inf
      ; file. This is slightly different from the HTML syntax for inserting
      ; CLSIDs in an <OBJECT> tag.
      FileVersion=1,0,0,143

4. Q. Is there a way to see a debug trace of code download activity? This
   will really help me with debugging.

   A. Yes, there is a way to do this with the help of the DEBUG versions of
   Urlmon.dll and Wininet.dll:

   1. Make sure you have the DEBUG version of these DLLs installed in your
   system. They should be located in the \INetSDK\DEBUG folder. Although
   these DLLs are part of the core SDK available for download on the Web,
   they are not installed as part of the regular SDK setup.

   If you do not have the \INetSDK\DEBUG folder in your ActiveX SDK
   installation, use the following steps:

   - Go to the ActiveX SDK download page.
   - Select the "ActiveX SDK Core Components" from the drop-down list.
   - Follow the instructions to download and extract the SDK files.
   - Verify that the \Inetsdk\Debug subdirectory contains the debug
     versions of Urlmon.dll and Wininet.dll.
   - Back up your system Urlmon.dll before replacing it with the debug
     version; otherwise you may render Internet Explorer unusable or your
     system unbootable.
   - When you no longer need the DEBUG version of Urlmon.dll, restore the
     non-debug version of Urlmon.dll back to your system.

   2. Add the following entry to your Win.ini file:

        [urlmon]
        urlmk=0xFF200000

   3. Replace the retail version of Wininet.dll and Urlmon.dll with the
   debug version. Be sure to back up these system DLLs before replacing
   them with the debug version. Otherwise you may render Internet Explorer
   unusable or your system unbootable.

   4. Open an MS-DOS prompt.

   5. At the prompt SET WININETLOG=1.

   6. At the prompt start Iexplore.exe.

   7. Navigate to your desired URL, such as http://www.microsoft.com/.

   8. Shutdown Internet Explorer.

   9. Examine the file Wininet.log, which should have been created on your
   desktop.

5. Q. I notice that some controls and dependent files are not updated even
   when a newer version is specified in the CODEBASE. The first download
   seems to succeed fine, but subsequent downloads with newer versions fail
   to update the affected files. What is wrong?

   A. Among the files we've seen that have this problem are: Vbajet32.dll
   and the HTML Layout Control files P2d.dll, Fm20.dll, and Isctrls.ocx.

   These files fail to indicate their target operating system in the
   dwFileOS field of the VS_FIXEDFILEINFO structure defined in the version
   stamp resource. Since this field is set to VOS_UNKNOWN, the download
   fails.

Frequently Asked Questions on Internet Explorer's Object Model

1. Q. How do I access Internet Explorer's object model from a contained
   control?

   A. Internet Explorer supports an Automation interface called
   IWebBrowserApp. It also supports an object model for scripting through a
   hierarchy of interfaces. The root dispinterface of this model has one
   property, Script, which returns the dispinterface for the window
   scripting object described in the ActiveX documentation. From a
   contained control or doc object, you can get the dispinterface for
   IWebBrowserApp with the following code:

      IOleClientSite* pClientSite; // Already points to the control's
                                   // client site.
      IServiceProvider* pISP;
      IDispatch* pIEIDisp;

      pClientSite->QueryInterface(IID_IServiceProvider, (void **)&pISP);
      pISP->QueryService(IID_IWebBrowserApp, IID_IDispatch, (void
      **)&pIEIDisp);

   To get the root scripting model dispinterface, given that you already
   have the ISP pointer as above, you can use this code:

      IDispatch* pScriptIEDisp;
      pISP->QueryService(SID_SContainerDispatch, IID_IDispatch,
      (void**)&pScriptIEDisp);

   Please note that the actual interface names of the scripting interfaces,
   such as the interface for the window object, are subject to change and
   should be used only via late binding.

2. Q. Is there a way to launch Internet Explorer and have it open a URL?

   A. Yes, this is done through the magic of OLE Automation and the
   InternetExplorer object.

   The InternetExplorer object allows an application to create and
   manipulate an instance of Internet Explorer through OLE Automation.
   Here's how you can launch Internet Explorer 3.0 in Visual Basic, for
   instance, and have it open the Microsoft Web page at
   http://www.microsoft.com/. Note, however, that this method launches a
   new instance of Internet Explorer every time.

   Dim Explorer As Object

      Explorer = CreateObject ("InternetExplorer.Application")
      Explorer.Navigate "http://www.microsoft.com/"
      Explorer.Visible = True

   More information on the InternetExplorer object can be found on the
   ActiveX SDK page under the "IE Object Model" section.

   Another way an application can launch Internet Explorer, and have it
   navigate to a specified URL, is through Dynamic Data Exchange (DDE).
   Internet Explorer provides support for DDE so that applications can talk
   to a currently running instance of Internet Explorer, or even open a new
   Internet Explorer window.

   Applications can communicate to Internet Explorer in this manner by
   establishing a DDE connection with Internet Explorer, specifying
   iexplore as the appName, the verb WWW_OpenURL as the topicName, and the
   desired URL, say http://www.microsoft.com/, for its XTYP_EXECUTE string.

   More information on the extent of DDE support Internet Explorer provides
   can be found on articles Q160976 and Q160957 in the Microsoft
   Knowledge Base.

3. Q. When I build the ObjVw sample for the Alpha platform, I get an error
   M0003 from MKTYPLIB. What's wrong?

   In Objvw.odl, the line that reads the following:

      importlib("stdole32.tlb");

   should be changed to the following:

      importlib("stdole2.tlb");

Frequently Asked Questions on WinInet

1. Q. How do I get WinInet to work correctly in Windows NT 3.51?

   A. WinInet requires enhancements for asynchronous operations, which are
   only available with Windows NT 3.51 Service Pack 4 (SP4). Be sure to
   install SP4 when you are running WinNT 3.51.

   Also, verify that you're using Wint351.exe, which installs Wininet.dll
   and dependencies on WinNT 3.51. Refer to the ActiveX SDK's Readme.txt
   file for more information.

2. Q. Why do I get such strange behavior when calling my WinInet functions?

   A. When you are writing your application using the ActiveX SDK, verify
   that you are using the Wininet.dll that matches the version of your
   Wininet.lib and Wininet.h. You will need to install Wininet.dll using
   Wintdist.exe or Wint351.exe, the self-extracting utilities provided for
   redistributing Wininet.dll with your application.

   Note that these self-extracting redistributables are available as a
   separate download from the ActiveX SDK Download page. To install the
   redistributables, select the "ActiveX SDK Redistributables for Windows
   95/NT 4.0" from the drop-down combo box.

   A version mismatch between the Wininet.dll and the .lib/.h can obviously
   produce some very strange results.

3. Q. Why do I keep getting the message: "Error initializing the cache ..."
   when I try to use the WinInet APIs from my service?

   A. The complete error message comes up as follows:

      Error initializing the cache. Shut down all programs and run ScanDisk
      or ChkDsk.
      Delete the cache, cookies, and history directories in your WINDOWS
      directory and then restart IE. If the problem persists, reinstall IE.

   Microsoft has confirmed this to be a problem with the WinInet cache that
   occurs whenever WinInet is first loaded in the context of a service,
   such as an ISAPI filter, and then by a user process, such as a browser
   like Internet Explorer 3.0.

   As a workaround, either try not to use any IIS filter DLLs that use
   WinInet, or make sure a user-mode WinInet application is running before
   you start the IIS service--that is, you can manually start the IIS
   service after running Internet Explorer 3.0. This causes the WinInet
   cache to initialize in the user-mode context of Internet Explorer 3.0,
   thus preventing any filter DLL using WinInet from locking out other
   user-mode programs from the cache.

   Refer to article Q160060 in the Microsoft Knowledge Base for more
   details.

4. Q. I notice that Wintdist.exe does not run unless I'm logged on as an
   ADMINISTRATOR in Windows NT 4.0. Is this expected behavior?

   A. This is a limitation imposed by Windows NT security, particularly as
   a result of the registry being secure under Windows NT.

   Wintdist.exe is a self-extracting executable that not only installs the
   Wininet.dll into the system, but also writes information into the
   registry. Because not all users have access to all keys in the registry,
   the executable fails unless it is run with ADMINISTRATOR privileges.

5. Q. What's the difference between PragmA.No-Cache and the Expires:0
   header?

   A. Although an HTTP 1.0 client, such as Internet Explorer 3.0, is not
   required to do anything with "PragmA. no-cache", Internet Explorer 3.0
   honors this header for SSL by not creating a download file.

   "Expires: 0" is set if you want the browser to verify with the server
   and if the URL needs to be refreshed.

6. Q. Why don't WinInet FTP APIs work over my proxy?

   A. WinInet understands two proxy types: the TIS (Trusted Information
   Systems) FTP gateway (FTP) and the CERN (HTTP).

   WinInet FTP APIs (such as FtpPutFile, FtpGetFile, and so forth) cannot
   be used with CERN-type proxy. CERN proxy presents data as HTML, which
   does not work with the FTP APIs.

   It is still possible to get a file from the FTP or GOPHER server through
   a CERN proxy either by making HTTP requests, or by using
   InternetOpenUrl() as follows:

      InternetOpenUrl (hInternet, "ftp://MyFtpServer/MyFtpFile.txt", ...)
      InternetReadFile ();

Frequently Asked Questions on Other Related FAQ's

1. Q. Where can I find JScript documentation? I can't seem to find it in
   the SDK.

   A. There is no JScript specific document. JScript is exactly like
   JavaScript syntactically. The Scripting Object Model document applies to
   both VBScript and JScript because both are language engines calling a
   common model. Almost all questions are answered in this document.

   Refer to JScript Web Page (http://www.microsoft.com/jscript/) for more
   information, as well as to the FAQ
   (http://www.microsoft.com/JScript/us/techinfo/jsfaq.htm) available off