Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Heidi Moeller: Hello and welcome to the Microsoft Support WebCast program. We'd like to thank all of you for joining us today. Our topic will be "How Does Internet Component Download Work?" Our presenter will be Joshua Lee. I'm Heidi Moeller and I'll be your host for today's session.

We'll start this session with Joshua's presentation, and follow that up with a question-and-answer period when the presentation is finished.

I'd like to take a moment to introduce Joshua. Joshua Lee is with the Developer Support Internet Client team. He is a Code Download Specialist and supports developers who are creating applications with Internet Explorer. Thank you for joining us today, Joshua.

Joshua Lee: Thank you, Heidi. Since Microsoft^® Internet Explorer 3.0, Internet Explorer has the capability to download and install components over the Internet. This is a very complicated process, involving many different DLLs. Quite often, components fail to download and Internet Explorer doesn't provide a direct, clear message explaining why this fails. To make the situation worse, a component could download successfully on some machines, but fail on others.

Internet Explorer is an end-user tool to browse the Web. Internet Explorer is made to avoid downloading components, to give users better surfing experiences. Internet Explorer is also made to fail silently on download, since users are not likely to be able to fix the download problem, and bec ause of security concerns, users have the final say on whether a download can be performed.

Combining all these factors, it's very hard to debug an Internet download problem without a good understanding of the process. This presentation will help you to understand just that, and it will provide some troubleshooting tips.

I'm going to first talk about the ways to download files over the Internet. Then I will step through the download process with some ActiveX^® control samples. Then we will look at what happens when things go wrong. And then we will look at ActiveX document download. Finally, I will go over some common issues and give you some references.

I'm going focus on the two most common methods of Internet download: direct navigation, and using INF and CAB files. And then I'll briefly talk about some other methods of Internet download.

The simplest way to deliver a single-file download package is to use an anchor tag on your HTML page, with an HREF pointing to a file on your HTTP server. You could point to different files like an HTML page, or a Microsoft Word document, etc. Based on the file extension or the content of the file, Internet Explorer will launch the proper ActiveX server to process the file, and either Mshtml.dll for the HTML page or Microsoft Word for Word document.

For some file types, like EXEs, Internet Explorer will display a File Download dialog box to users for instructions, due to security concerns. This dialog will come up whenever Internet Explorer doesn't know what to do with the file. You can find out what these extensions are from the Knowledge Base article Q232077: "Executing Files by Hyperlink and the File Download Dialog."

Direct navigation is very simple and easy. However, you cannot include dependencies. And it won't work with an ActiveX control. You have to use an OBJECT tag instead.

When you use an OBJECT tag, often you will use a cabinet or CAB file to download the control and its dependencies. I will talk about the syntax of the OBJECT tag later. But first, let's give you some background on the CAB files.

Cabinet technology was first introduced with Windows^® 95 for the Win32^® type of installation. Its main purpose was to create a smaller installation package by compressing multiple files into single or multiple CAB files. When Microsoft introduced Internet Explorer 3.0, some extensions were added to this technology to make it download Java applets and ActiveX controls over the Internet.

An information, or INF file, is often used with a CAB file. It provides processing instructions for the CAB file. With INF files, developers can specify very complex setup instructions, including adding, modifying, or even deleting registry entries, or specifying when, where, and how each file is installed. Like the CAB file, the INF file is an existing technology and has been incorporated in Internet download since Internet Explorer 3.0.

There are two formats for INF files: Win32 and Internet Download. Often, when we see an INF file for Internet Download, it will include some Win32-type instructions. They look very similar; however, they are processed by different components, and some of the syntaxes are unique in a particular format. You will have a problem if you mix up the syntax. So, it's very important to notice the differences. I will go into more detail about the INF file structure later in the presentation.

So, what other download options are there? Since Internet Explorer 4.0, developers can use OSD, or Open Software Description files, to specify processing instructions for a CAB file. Even though it can be used with ActiveX controls, most often you will see it used with Java applets.

Indeed, you can use both an OSD file and an INF file along with a CAB file in Internet download. I'm not going to talk in depth about this option. One thing I do want to mention is that, if both files exist inside a CAB file, Internet Explorer will always process the OSD file first, and then it will process the INF file.

You can also use the File Transfer Protocol API to download files over the Internet.

To learn more about what method you should use for Internet Download, read this MSDN article: http://msdn.microsoft.com/workshop/delivery/download/overview/method.asp.

To create a successful Internet download process, we start with preparing an ActiveX control for Internet download and usage. Then we will write a HTML page with an OBJECT tag. Then comes the actual download process. If everything goes smoothly, Internet Explorer will display the component.

In general, you will first create your ActiveX control. Then you will package the control to create a CAB file with a tool like the Package and Deployment Wizard, or PDW, for Visual Basic^® controls. Then you will sign the control with a valid certificate.

Since you should be very experienced with these steps, I will skip the details here. Instead, toward the end of the presentation, I will mention some common issues. Now, let's jump right into creating an OBJECT tag.

To put an ActiveX control on a HTML page, we use an OBJECT tag. The CLASSID attribute specifies the class identifier or the GUID for the object. This is the primary way for Internet Explorer to identify the control. The CODEBASE attribute specifies where the component can be downloaded.

Optionally, you can specify the version of the ActiveX control you require by attaching a number sign (#) and version number at the end of the CODEBASE path. If you don't specify a version, Internet Explorer will get any version of the control.

The TYPE attribute shows the MIME type of this object. If there is no CLASSID in the OBJECT tag, Internet Explorer will use the MIME type to look for the CLASSID from the registry. To us, these are the most important attributes. And there are many more attributes for an OBJECT tag. You can find more information on the syntax from the URL (http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/object.asp).

Let's use an example to continue our discussion. I created a simple ActiveX control in Visual Basic 6.0. This simple control will show the current date and time. Since this control is created by Visual Basic 6.0, it is dependent on the Visual Basic 6.0 run time. Also, the OLE files are dependent on the VB run time.

We will use this ActiveX control as an example throughout this presentation, and I will walk through the process of deploying it on a machine that doesn't have the control or the dependencies.

After I package and sign the CAB files for MyTime control, I created the MyPage.htm. I stated the CLASSID of the control in the OBJECT tag, starting with CLASSID=, and I'm asking for the 1,0,0,3 version of the control. And I tell Internet Explorer that the control can be found at MyTime.cab by providing a relative path to the CAB file.

There are three ways you can specify a URL for a CODEBASE. You can specify a full URL path, starting with HTTP, all the way to the CAB file name. Most commonly, like the previous slide, you would specify a relative URL for the CODEBASE. If you just enter the name of the CAB file here, Internet Explorer will look for it in the same folder as your HTML page, by default. In this example, we specified a subdirectory called Controls under that same folder as the HTML page.

If you specify a base tag in your Web page, your CODEBASE path will be relative to this HREF instead.

When you specify a BASE HREF, please be sure you end the HREF with a forward slash (/); otherwise, the parent directory will be used instead. And of course, your CAB file won't be there.

You can also specify just the version number, without a URL path. By doing so, you instruct Internet Explorer to discontinue the process if Internet Explorer cannot find the version of the control you specified.

Please make sure there are no leading or trailing spaces in the version number. Otherwise, Internet Explorer will parse the versioning incorrectly, and treat the version as 0,0,0,0. At that point, any version of the control will be accepted.

When you specify the version as -1,-1,-1,-1, Internet Explorer will always check if the CAB file has changed at the server. If the CAB file has not changed since the last download, Internet Explorer will not download or process the CAB file. If the CAB file has a creation date later than the installation date of the control, Internet Explorer will pull down the CAB file and process it again.

The actual download process consists of six different steps. First, Internet Explorer will process the OBJECT tag and get your requirements from it. Then Internet Explorer will determine if a download is needed by checking different things. It will perform a download if needed. Then it will process the CAB file and the INF file. Then the control and its dependencies will be installed. Finally, the control will show up on the screen.

Let's start with how Internet Explorer sees the OBJECT tag. When the HTML rendering engine of Internet Explorer, Mshtml.dll, sees an OBJECT tag, it first gets the CLASSID from the OBJECT tag, or resolves the CLASSID from the MIME type.

Once Internet Explorer identifies the control, Internet Explorer 4.0 or later will check the ActiveX compatibility flags under the HKEY_LOCAL_MACHINE registry key. If this flag is set to hex value 400 (we call it the kill bit), the control is disabled, preventing it from running inside Internet Explorer.

If the kill bit is set, Internet Explorer will just stop the entire process right there. If the kill bit is not set, Mshtml.dll will try to immediately invoke the control with the version specified in the OBJECT tag.

If the control fails to invoke, Mshtml.dll will ask the code download engine, Urlmon.dll, to initiate a download by calling CoGetClassObject from the URL functions.

Urlmon.dll will check to determine whether the users have right to modify HKEY_LOCAL_MACHINE in the registry. If not, it will abort the download.

If we are asking for an Office or Internet Explorer component, Urlmon.dll will go to a predefined location for download. Otherwise, it will create a list of URLs according to the order specified under CodeBaseSearchPath key in the registry. This list will be used to search for the component later on.

In this search path, a CODEBASE keyword is used to specify when the CODEBASE attribute of the OBJECT tag should be searched. If you remove the CODEBASE keyword from the CodeBaseSearchPath key, Internet Explorer will ignore the CODEBASE in the OBJECT tag.

Urlmon.dll will also collect machine information, like CPU type, operating system, and Internet security settings, and some other information, too.

You can easily check the zone of your page by looking at the lower right corner of your Internet Explorer browser window. See the circle on slide 18.

After it collects all the information needed, Urlmon.dll will go to the URL list created to look for your component. Internet Explorer will send a POST request to these URLs to ask for the component. If it matches, they will return the correct CAB file. Then Urlmon.dll will process the INF file.

Based on these instructions, Internet Explorer will install the components and register them.

Depending on your Internet security settings, a Security dialog may show up and prompt users for permission to download when the CAB file comes in. It will follow with a dialog to accept the certificate, if it's not already installed. These checking procedures are performed by Wintrust.dll.

When users agree on both dialogs, Urlmon.dll will save the CAB file to the Temporary Internet Files folder. Then a temporary folder will be created to extract the contents of the CAB file. It's usually under the C:\Temp directory, or whatever your temp variable is set to be.

After that, the INF file will be handled. An INF file is made up of different sections. Each section cannot exceed 1024 bytes. They are not handled according to the order shown in the INF file. A line with a square bracket ([ ]) signals the start of a new section. The word inside the square bracket is the section name. All the lines that follow are considered the same section, until the next section starts. Each line inside this INF file is one instruction, and cannot be longer than 256 bytes.

In the next few slides, I will discuss the [Setup Hooks] section and [Add.Code] section with you. They are the most important sections in an Internet download INF file. If both sections are missing, the INF file is treated as a standard Win32 format, without Internet download extensions.

The [Version] section is an optional section, and it is only needed if there are hooks or Win32 INF format sections.

So what are hooks? There are two types of hooks: conditional and unconditional hooks. A hook is a way to override or customize the installation process of one or more components. Unconditional hooks will apply for all sections, and will always be executed. Conditional hooks run only until a condition is satisfied. We will wait a few slides for conditional hooks, and first talk about unconditional hooks.

All hooks are executed by Advpack.dll, along with other Win32 type instructions.

Unconditional hooks are represented by the [Setup Hooks] section. We usually put registry changes in this section. If you use the VB Package and Deployment Wizard to create a CAB file, and you mark the control as safe, the PDW will create the appropriate commands to modify the registry and put them under this [Setup Hooks] section.

The entries in this section are executed based on the order listed here. Before the [Setup Hooks] section is evaluated, Urlmon.dll will first handle the [Add.Code] section. This section lists the components to be installed. On the left-hand side of the equal sign is the file name. On the right-hand side is the section name, which contains information on how to process this file. You can choose your own section name; however, the file name must match your components.

Urlmon.dll will read this section from the top down and create a list of components to be handled. Then, it will process the list in the same order. Urlmon.dll will collect all the necessary information, and download additional files, if needed, to create yet another list of instructions. This procedure is handled asynchronously, so Urlmon.dll will handle multiple sections at the same time. However, the actual installation will be performed after all the sections are processed.

Following our example, we can see here that it's dependent on the VB run time, some OLE files, and system files.

I'm not going to explain all the syntax in an INF file here. At the end of this presentation, you will find some more references to it. However, let's look at a couple of sections in our example to see what happens there.

I will start with the [myTime.ocx] section. The [myTime.ocx] section tells Urlmon.dll that the physical OCX file is located in the current CAB files, in the file-Win32-x86. It asks to register this OCX by stating RegisterServer=Yes.

It specifies the GUID for the OCX at the CLASSID line, and the file version we need is 1,0,0,4. So, Urlmon.dll will compare this CLASSID and version number to see if an installation is needed.

By leaving DestDir= blank, we point out that the control should be installed under the Downloaded Program Files directory. You can also use 10 for the Windows directory, or 11 for the System directory.

If an earlier version of the control is already installed on the machine, Urlmon.dll will ignore this DestDir instruction. Instead, any upgrade will be installed at the previous location.

Another section that we are going to look at is the [comcat.dll] section. This is an example of using a conditional hook.

A conditional hook is specified with the keyword hook. When using a conditional hook, we usually specify the file version and/or the CLASSID of the component. If the machine doesn't have the required version of the file, then the conditional hook will be processed. In this case, since we don't have the right version of the Comcat.dll, the [comcat.cab_Installer] section will be executed.

This [comcab.cab_Installer] section looks very similar to the previous two sections; however, it is very different in meaning for the download process. This section is in Win32 format. When using hooks, you have much more flexibility in where and how the component is installed. However, Win32 syntax is usually harder to understand. In fact, if you specify Internet download instructions, like hook or DestDir in Win32 sections, the instructions will be ignored or will return you an error.

In this [comcat.cab_Installer] section, we specify the file is located at http://activex.microsoft.com/controls/vb6/VBRun60.cab.

The run syntax, which is a Win32-specific syntax, indicates that after the VBRun60.cab file is downloaded, VBRun60.exe should be run under the extracting directory.

After Internet Explorer processes the entire INF file, it will call Occache.dll to install the components. After your control is installed, it will show up in the Downloaded Program Files folder. You can find out the status of your control in this folder. Also, you can update or remove it by right-clicking the entry for your control.

In some old documentation, this directory is referred as the Occache directory.

During the actual installation process, Internet Explorer will install each component needed in reverse order, as stated in the [Add.Code] section. So, you need to make sure that the main OCX file is listed first in this section, followed by dependent DLLs or OCXs. And put the least-dependent component at the bottom of the list. Then dependencies are guaranteed to be installed and available at registration time of the main OCX.

When Internet Explorer processes each component, it will once again check the version of the physical file with the file installed on the machine to avoid overwriting later versions of the file installed.

So, in our example, we will start with the [comcat.dll] section. As we saw earlier, VBRun60.exe will be executed. Since VBRun60.exe will replace some of the system DLLs while they are in use, Internet Explorer will ask for a reboot to replace these DLLs, and it will terminate the rest of the installation process until the reboot is performed.

After the reboot, users will go back to the same HTML page, and Internet Explorer will start the entire download process again, starting from reading the OBJECT tag. After the dependencies and the controls are installed, Urlmon.dll will be done with its job.

Mshtml.dll will come in again to initiate the control by calling CoCreateInstance, based on the CLASSID on the OBJECT tag.

But watch out: at this point, Internet Explorer will just invoke the version of the control installed. If Urlmon.dll is actually downloaded and installs version 1,0,0,2 of the control, this version of the control will be invoked, even though my OBJECT tag is still asking for version 1,0,0,3. And next time, when users come to this HTML page, a download process will be triggered, because the version of the OBJECT tag is still not satisfied.

Those are the six steps, starting with how Internet Explorer processes the OBJECT tag, to when the control is displayed on the screen.

When this process fails, often Urlmon.dll will create a file to log the cause of the problem. This log file is created in the Temporary Internet Files folder, and the name will be ?CodeDownloadErrorLog!.

If you open the Temporary Internet Files folder with Windows Explorer, you will probably find more than one file that starts with this name. Those files were probably created during previous installation failures of other components. So be sure to check the last modified date to get the correct log for your component.

To view this log, you can use the Code Download Error Log Viewer tool, or view it directly in Internet Explorer by performing some steps. The KB article Q252937, "How to Find Information About Why Code Download Failed," will give you step-by-step details on using this tool, or viewing it directly in Internet Explorer.

An in-progress KB article, Q254648, "How to Read the Code Download Error Log" is designed to help you understand the error log better. This article is not published yet, but it should be available soon.

At this point, you probably would ask, "Do we always see an error log?" Indeed, you don't always get a ?CodeDownloadErrorLog!. If everything goes fine, this log will not be generated.

This log is created by Urlmon.dll; if the process fails before Urlmon.dll gets involved, or after Urlmon.dll is done, then no log will be generated. For example, when the process fails when Mshtml.dll is gathering information, or the kill bit is set, the process is terminated before Urlmon.dll is called, and you will not get an error log.

Also, if the control is correctly downloaded and installed, but it fails, Mshtml.dll tries to display the control, or there is some error during your control initialization, there will be no error log then, either. Sometimes a run-time error will be generated instead.

Of course, when Internet Explorer has some unpredictable internal error like crashing, or the process terminating abnormally, then no error log will be generated here, either.

So, the ?CodeDownloadErrorLog! won't give you all the answers. What else can you check?

Depending on where the process fails, you can look for different information to help with debugging the problem. Again, the key here is to understand the process and realize at which stage the process fails.

In general, here are some other things that you need to check to gather information. You will check the Security tab of the Internet Options dialog to find out if the machine is set to allow downloading signed or unsigned ActiveX controls. Be sure you're checking the right security zone. Also, if you are signing with a certificate, you need to make sure the certificate is installed correctly.

You can search the CLASSID of your ActiveX control and its dependencies in the registry to see if they are installed correctly on the machine. You can look at the Temporary Internet Files folder to see if the main CAB or any secondary CAB files are downloaded. You can also look at the Downloaded Program Files folder to check the status of your control to see if it shows up correctly here.

Make sure you have the correct version of the DLLs installed and that they are registered correctly. You can verify that information with the Microsoft DLL Help database at http://support.microsoft.com/dllhelp.

Let's talk about ActiveX document or VBD download. In general, the download process is very similar to an ActiveX control.

Internet Explorer still determines if download is needed, then downloads the CAB file, installs the components, and finally displays the ActiveX document. When it fails in the download and installation stage, it will generate the ?CodeDownloadErrorLog!.

The differences are that you will not use an OBJECT tag. Instead, with Internet Explorer 4.01 SP1 and later, you can directly navigate to the VBD. If that's the case, Mshtml.dll will not be involved in the process. Instead, Urlmon.dll will start the process right at the beginning.

Urlmon.dll will check the header of the VBD file for the CLASSID, the version of the ActiveX server needed, and the CODEBASE path. That information is written inside the VBD at compile time, or when you package the VBD with the Package and Deployment Wizard. Or you can use the SetCodebase tool to write in the information.

Another difference is that you cannot sign the VBD files. You can only sign the CAB file that the CODEBASE is pointing to. And you cannot specify if the VBD is safe for scripting or initialization, because they are not considered scriptable, in general.

When a VBD fails in the download process, it almost always gives you the File Download dialog box and asks you whether you want to Run this program from its current location or Save this program to disk. Whenever this dialog comes up for a VBD, it means the process has failed; so choosing either Run this program from its current location or Save this program to disk will not resolve the problem. Just click Cancel to dismiss this dialog box. If you choose OK, in certain situations a .vbd extension entry will be made to the registry.

When that happens, Internet Explorer will fail on any subsequent download of VBDs, because Internet Explorer will think that there is a program already associated with .vbd extensions, and it will not try to download the CAB file in the CODEBASE path. And hence no ?CodeDownloadErrorLog! will be generated.

You can check for this .vbd extension entry under the HKEY_CLASSES_ROOT in the registry. Delete it whenever you see such an entry.

What are some other common issues? When you create your ActiveX controls or ActiveX documents, please do not use the Initialize and Terminated events. These events will not always fire, and using these events might cause a failure in displaying the control or VBD. Instead, use the Show or Hide events.

Also, Internet Explorer 4.0 and later are apartment-threaded. So, don't use any single-threaded controls, including some old Microsoft controls. Some controls that ship with Internet Explorer 3.0 are single-threaded, too. Be sure to check the threading model of the controls before you use it with Internet Explorer 4.0 and later.

The IObjectSafety interface always take precedence over the registry safety markings. The component implemented IObjectSafety to show it's unsafe; specifying the safety registry settings won't make your control safe. Because these safe registry settings are made during the installation of the control, they will not be made on your development machines, because no download is needed. When you have problems showing up on a development machine, check the security settings to make sure you allowed the control of VBDs.

When you package your components, please make sure you package only the necessary components. The fewer the components, the greater the chance the download process will be successful. And please include all the dependencies that you don't think the client machines already have; however, if you are using MDAC (Microsoft Data Access Components) to access the database, make sure your INF files do not reference MDAC, or any component that wants MDAC. Manually deploy the right version of MDAC on the client machine first. MDAC is a system component, and it was not tested with Internet Component Download. So it's likely going to fail in the process. Read this KB article, Q251325, for more information.

If you need to modify the INF file created by the PDW, you can run the batch file in the same support folder to regenerate your CAB files.

Also, if you are creating your control in Visual C++^®, or other languages, you can use the tools Cabarc.exe or Makecab.exe, which come with the Microsoft Cabinet SDK, to create a CAB file.

However, please do not use the tool Dubuild.exe, which comes with the SDK for Java, to package your ActiveX control or ActiveX document. That tool is for Java components only.

When you sign your CAB file, please make sure you sign it with a valid certificate. Authenticode^® tools can help you with the signing process. But make sure you match the version of the tool with the version of Internet Explorer on the signing machine. Otherwise, you'll get an error.

We have gone through a lot of material. However, if you still want more, here are some tools for you. The Internet Component Download Online Troubleshooter will be available soon to help you troubleshoot Internet Download problems. You can attend the WebCast next month to learn about Common Java Download problems [Editor's note: This WebCast is scheduled for May 25, 2000.]

Also, there is an archive WebCast that gives some tips on creating ActiveX controls using ATL and MFC (http://support.microsoft.com/servicedesks/Webcasts/wc010600/wcblurb010600.asp).

I pointed out a few very useful articles here for your reference (http://msdn.microsoft.com/workshop/components/activex/intro.asp; http://msdn.microsoft.com/workshop/delivery/download/overview/infarchitecture.asp; http://support.microsoft.com/support/kb/articles/Q181/3/74.asp.) And you can find many more articles on this topic by searching the MSDN site.

Let's answer some of the questions that you have sent in.

Heidi: It is time now to move on to the Q&A portion of this Support WebCast.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside of the scope of the Support WebCast.

If you have suggestions for topics for future Support WebCasts, you can send those to us using the feedback@microsoft.com alias, and include "Support WebCast" in the subject line.

We have had several questions submitted today, so let's go ahead and get started.

The first question is: I work on a firewall virus scanning product, and we frequently see time-out issues with Internet Explorer 4.0 and Internet Explorer 5 when virus scanning ActiveX components and other files downloaded via HTTP. What time-outs are in place between document request and document receipt? Can these be changed?

Joshua: Even though this question is not directly relevant to the download problems, I'm going to answer it, because it is very much related. Internet Explorer has a registry entry in the client machine, and it specifies five minutes, by default, for the time-out. If you like, you can change it in the registry settings. However, please make sure you change all machines for the download. Most likely, you will not be able to do so, or will not want to do so. So you have to find a better way to process your virus scanning.

Heidi: Okay, terrific. Moving right along to the next question. What does Internet Explorer use to determine how to display a file: DOC versus HTM versus CAB, etc.? Does it use a file extension at the end of the URL, which can vary greatly, or does it exclusively use the MIME-type indicator in the HTTP header?

Joshua: The way Internet Explorer determines what should be done with the component is very complicated. It uses the file extension, it uses the MIME type, and it also does something called data sniffing, as we discussed in the WebCast, where it opens up the file and looks at the beginning section of the file and sees what it is. And based on the combinations and the result of this process, Internet Explorer will process the file accordingly. However, there is not always a fixed or a set rule for Internet Explorer to follow. Here's an article related to the answer: "MIME Type Detection in Internet Explorer" (http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp).

Heidi: Okay. The next question is: I have a control on my page, Msinet.ocx, which I want to distribute. Can I do so just by specifying it as an OCX?

Joshua: Based on Q193366 "CAB Files Distributed with Visual Basic 6.0," Internet Transfer Control should be pointing to this CAB for distribution: http://activex.microsoft.com/controls/vb6/MSINET.CAB.

Heidi: Okay. Moving to the next question: Can you use ProgIDs versus CLASSID in OBJECT tags?

Joshua: No. You cannot use the ProgID; you have to use the classid in the CLASSID attribute. But if you do not need to download the components, you can use scripts, and you can call CreateObject with the ProgID within it. However, that does not give you a way to download it.

Heidi: Okay. Next question: What's the number one error most ActiveX developers make during control creation?

Joshua: I would say the number one error would be using the Initialize event. Quite often developers would like to initialize their controls, and this seems like the correct event to do so. As I mentioned in the WebCast, you should use the Show event instead.

Heidi: Okay. The next question: How is downloading a Win32 executable not in the CAB file different from downloading an ActiveX in a CAB file?

Joshua: If you just point to an EXE on the CODEBASE path, you will only download that EXE; and if you point to a CAB file, you can compress all of your files and put them inside this CAB file, and it can involve multiple DLLs and EXEs all together. I hope this is addressing your question, as I am not exactly sure what the question is.

Heidi: Okay. Well, if the individual who submitted that question can send us any clarification, if we haven't addressed that question appropriately for you, please do so and we will go ahead and try to clarify it a bit. The next question is: Could I point to an OCX directly, in the CODEBASE path, to download an ActiveX control?

Joshua: Yes. You could point to OCX directly, and download the OCX. As long as the controls do not have any dependencies, or those dependencies are already installed on your client machines, you will be all right.

Heidi: Okay. Excellent. The next question is: Can I download MDAC components along with my ActiveX control?

Joshua: As I mentioned in the WebCast, no. You cannot download MDAC components with your ActiveX control. And in fact, PDW will make a mistake and encode that for you. So be sure to take those references out, and read the KB article I referenced earlier to find out more information about it. The article number is Q251325.

Heidi: Okay. Excellent. If you need to get a copy of those slides for the Q numbers, they are downloadable. The next question is: What is the most important thing to remember when creating controls for extranet versus intranets? Is that something you can answer, Joshua?

Joshua: I think, given the creation times, there might not be much difference between using an Extranet and intranet; but usually, when you have an Extranet, you have a firewall, and some firewalls will prevent the downloading of ActiveX controls. So be sure you check with your system administrator and allow ActiveX controls through the firewall.

Heidi: Okay. Moving right along: I see a Conflict.1 directory under the Downloaded Program Files folder. What is that for?

Joshua: That Conflict directory is created on purpose when your controls do not have a CLASSID, or it is referenced by different CLASSIDs. There is a KB article on the Web site that will explain this conflict directory. I do not have the KB article number here, but you can search the keywords "conflict" and "directory," and it should give you the KB article. [Editor's Note: See Knowledge Base article Q196150.]

Heidi: Okay, excellent. The next question is: Are certificates necessary within an intranet environment?

Joshua: Certificates are not necessary. They are a way to tell the user to accept your controls. It is an indication of the author of the controls. If you are in an environment where everybody knows this control is safe, and they are likely to accept it, you can ask the user to adjust the settings in the Internet Options, on the Security tab, to accept and download signed ActiveX controls.

Heidi: Okay. And the last question that we have in the queue at the moment is: Why does Internet Explorer keep asking for reboot when it is trying to download my Visual Basic control?

Joshua: As I said earlier, when you are trying to download Comcat.dll, it will reference to VBRun60.exe. And this EXE is referenced by other OLE and Visual Basic run times. When this EXE is executed, it will need to replace some systems components. And since these component are in use, the only way Internet Explorer can replace these files is by doing a reboot. If you create your CAB file in a machine that has Windows^® 2000, or some later software with OLE components, and you try to deploy on a Windows NT^® machine or a machine that has earlier OLE version files, the Package and Deployment Wizard will get the wrong version number for those OLE files. So after the first reboot, Internet Explorer goes in and processes the CAB files, and sees the versioning is still not fulfilled, and it will try to install again. And so, a second reboot will be performed, and the same thing will happen again and again.

There is an upcoming KB article addressing this issue. But essentially, you can open the INF file and change the version number of those OLE and system files to make sure the version matches the CAB file that we pointed you to on the Microsoft site. Again, there will be a KB article addressing this issue soon.

Heidi: Okay. We did have one more question that someone submitted while that one was being answered. And it is: Does Internet Explorer page caching affect version checking?

Joshua: In general, I would say it does not.

Heidi: Okay, we will double check to confirm that, and we will make sure to send the individual who submitted the question an e-mail with the answer, if the answer is different from what Joshua said. We will post the answer in the transcript for anybody else who's interested in getting that additional information.

We just got some clarification to a question asked previously, and that is: Can I download and run a Win32 application setup without packaging it in a CAB file?

Joshua: Yes. You can use an OBJECT tag and point to an EXE file in the CODEBASE path. If you do so, Internet Explorer has given the permissions, if allowed under the Internet Explorer Internet Options settings. When Internet Explorer downloads the EXE, it will just run the EXE and let it go from there.

Heidi: Excellent. Next question: What is better for compiling ActiveX controls, pCode or native code?

Joshua: pCode will generate a smaller combination unit. Native code has faster execution. So if you consider the speed of the download, you will probably go with pCode. However, a lot of times the difference is not too great, and there are other concerns between compiling pCode and native code. You can find more documentation in this area under the Visual Basic documentation.

Heidi: Okay, excellent. And with that question answered, we have cleared the queue of all questions that were submitted during today's Support WebCast. I want to thank all of you for joining us today, and I want to thank Joshua for joining us. I do hope that this information was useful to you.

Once again, we are very interested in your feedback regarding the Support WebCast program. You can send us your feedback using the e-mail alias feedback@microsoft.com. Be sure to include the Support WebCast topic in the subject line.

Once again, thank you so much for joining us today. I hope you have a wonderful day and that you join us again in the near future. Thank you, and good-bye.