by Ross Mack - GUI Computing
Silent they came, under cover of darkness and with purpose in their eyes and their hearts. Under the stillness of the clouded night they slipped almost imperceptibly past the defences. They left little trace of their passing, yet moved with speed. Once they had arrived in the predetermined place they set to work. With their alien ways they constructed that which they had come to create. It would be the only sign of their passing. Working feverishly, putting each piece in place it took shape quickly. Once satisfied that the whole was finished they slipped away again, as quietly as they had come.
These days a lot of development is done in the form of Intranet or Internet sites where previously a traditional desktop application would have been produced. This is pretty cool in most cases and is often a good way to do things. One of the great things about this sort of development is that if you are working on the target server to start off with there is nothing to distribute. You just set the site up and away it goes. Changes can be made quickly and are immediate.
However, what happens when you need to create a web site and then send it to a client for them to install. Perhaps it has to be installed on a number of PCs. Or perhaps it will be installed as a local web site on laptops for people who travel. In these cases it becomes impractical to be on hand for every install and you need to be able to distribute a web site in some useful form. The user really needs to be able to install it just like a normal application.
Well, a web site will never be quite like a normal application, but you can come close. We've had to distribute a few web sites in this fashion and have had to figure out how to do each of the numerous things required. Here I will go through a few tips and tricks and ways of doing things that might just help out the first time you have to do this.
Let me point out right now that we use WISE from Great Lakes Business Solutions (www.glbs.com) to build installs like this. WISE makes many of the following tasks quite easy. If you are unfortunate enough to use something else there is most likely a way to achieve the same thing, but you may have to hunt a little further or go a different way around it.
Checking what's Installed.
First of all you need to make sure that everything your web site needs is installed. This will normally take the form of a web server and, in many cases, Active Server Pages. The easiest way to check that these two things are installed is to check for their associated settings in the registry.
To find out if either Internet Information Server or Microsoft Personal Web Server are installed you can check under HKEY_LOCAL_MACHINE in the following subkey:
I always check for the setting "/" The result will actually be the directory which is the root of the local server. If you find an entry here that tells you that wither IIS or PWS is installed. They cannot run without a root, so it must exist for them to be working.
Different web servers will use different registry keys to store their information. O'Reilly's WebSite, for example stores it's information under two different subkeys. Fortunately this is well documented and should be simple fto find for most web servers.
Checking for the existence of Active Server Pages is just as simple. I simply look for the default Script Language setting. The registry key is:
Again, if this registry setting exists ASP has been installed. If it does not exist you can assume that it's either not installed or probably missing most of it's registry settings and therefore not working anyway. <g>
If all the required system software is in place you can proceed with installing your web site with some hope that it will work. Reading these settings will not tell you whether or not everything is configured perfectly and working correctly, but they will at least tell you that they have been installed.
Determining the Web Root.
You need to know the web root of the currently installed web server for two potential reasons. Firstly, you should really install your web site beneath that root under most circumstances. This is one of those time where you do not want to just blindly install to a directory under "C:\Program Files\". Also, you may want to have your web site be the only site on the server, in which case you need to install it directly into that directory.
As it turns out we actually read the location of the web root from the registry in the last section. To reiterate, it's available in:
Another useful thing to check is what the default file name used by the web server is. This is usually index.html or default.htm. Something like that. Basically it's the file where if you navigate to a directory on the server without specifying a particular page the server will check for a page of this name and display it. Once you know what this default name is you can make sure that your default pages have that name or you can change the web server's default page name to what you want it to be.
In general it's good practice to have all the links in your site point to either specific pages or to directories only when they need to load the default page in that directory. Let's say that you build your web site on a server that uses "index.htm" as the default document name. You will probably end up having the main page in each directory called "index.htm". If you then deploy your site on a server that uses "default.htm" as the default page name you need to change either a few of your page names or the default page name on the server. If you can't change what the default on the server is, then you must change your page names. Now, consider the links within your pages. If they are in the following form you are fine:
<a href="/mydir/myotherdir/">Go over there</a>
If they are in the following form you will need to go through all your pages and replace the references to "index.htm" with "default htm" to make them work:
<a href="/mydir/myotherdir/index.htm">Go over there</a>
Anyway, the name of the default page can be found in the following registry setting:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3Svc\Parameters\Default Load File
Be careful about changing this setting. For example if you change it on an IIS 3.0 server or a PWS 1.0 server you will most likely stop the remote administration tools from working. I did this once and was less than happy as I had to then scrounge a monitor to administer the web server directly so that I could change it back and get everything working again.
I advise not doing that.
IIS 4.0 allows several default files, so that becomes somewhat easier to cope with.
Creating Virtual Roots.
Creating a virtual root is essential if you need to modify the details of any directory in your web, this may be required to allow the server to execute scripts (ASPs for example) in that directory or to simply place it in a different logical location to it's physical location.
Let's say for example that you have a directory called 'private script stuff' but you want this to appear to a web browser as if it is the 'scripts' or 'cgi' directory or something like that you would create a virtual root to make the translation.
Virtual Roots are quite easy to create under Personal Web Server or under Internet Information Server. They are simply registry entries under the key:
Each Entry is named for the virtual root it will be, then the value of the entry is the directory followed by two commas and a bitmask that specifies the permissions for that virtual root. Presumably there is another setting that goes between the two commas, but despite upwards of ten minutes research I still have no idea what it might be.
All web services have at leats one setting on install, which specifies the root. This is of course called '/' and the value would be typically something like "C:\Webshare\wwwroot,,1" or "C:\INETSRV\wwwroot,,1". The 1 (one) at the end indicates that read permission is granted. If the digit at the end is 4 then execute permission is also granted. If the figure at the end is 5 then both read and execute permission is granted.
So, all you need to do to create a Virtual Root is to write the appropriate setting into the registry. For example if you want to expose the directory "C:\Important" as a web root on your server called "guff" (http://myserver/guff) with read permission but not execute permission, then you need to write the following entry to the registry:
Or if you want to allow ASPs in the directory "c:\inetsrv\wwwroot\asps" to execute and to appear to be in the 'scripts' directory you would write the following Registry entry:
Note that the '5' on the end gives this virtual root BOTH read and execute permission.
When you create new Virtual Roots most Web Servers will need to be restarted before the new Virtual Root will be active. This is certainly the case for IIS and PWS, but you may want to check your web server documentation. You can actuall;y do this quite easily under NT using a simple command line. The following command line, launched from your setup program will stop PWS or IIS running under NT:
net stop w3svc
and to restart the service simply execute the following:
net start w3svc
Again, you should check your web server documentation as to the correct way to start and stop the service.
Configuring ODBC Datasources.
This is sort of beyond the scope of this article. However, it can be an essential part of configuring a data driven web site. For that reason it bears mentioning here. WISE includes excellent tools for configuring ODBC data sources. You can also manually add the required registry entries to create a datasource, but that is comparatively complicated and what entries are required will vary with the ODBC driver used.
When you do create a datasource for use by ASP or some other server side script tool make sure that it is a System DSN, not a User DSN or the web service may not be able to actually use it. If it is a System DSN all users and services will be able to use it.
Another option for creating a DSN on a PC is to create a new type of DSN, supported by ODBC 3.0 and above, called a File DSN. A File DSN is basically an INI file with a particular format that specifies all the information needed by a DSN and which resides in a specific directory on the hard disk of the PC using it. The location in which File DSNs are kept is specified in the ODBC Driver Manager but can also be read from the registry. The Registry setting is:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\odbc.ini\ODBC File DSN\DefaultDSNDir
And a typical value might be:
"c:\win\odbc\data sources"You can create a File DSN on one machine and simply copy it to the correct place on a target machine. WISE can easily handle this by reading this Registry setting and writing the .DSN file into the correct location. You can also create the file on the fly by writing to it as if it were a normal INI file. The name of the file specifies the name of the DSN. So, "MyDatabaseServer.DSN" represents a DSN called MyDatabaseServer.
A sample of the contents of a file DSN is as follows:
[ODBC] DRIVER=SQL Server UID=elvis DATABASE=dbMyDatabase WSID=MYPC SERVER=MyServer
Creating URL Shortcuts.
If you are installing a web site on a server it is often a good idea to provide a shortcut to the home page and/or other important pages on the desktop or on the start menu somewhere. Fortunately, creating a URL shortcut under Win95 or NT is also quite easy. Firstly the file must have a .URL extension, for example "My Web Page.URL". The contents of the file are then quite straightforward. Again, these files are basically in INI file format. They have one Section and one setting. A sample of the contents of a shortcut that goes to the AVDF would look like this:
If you are creating a shortcut for use on a machine on which you are installing a web it is often easiest to use 'localhost' as the hostname, otherwise you can get the current computer name from the registry at the following location:
Another alternative if you can call APIs directly is to simple call the GetComputerName API. This essentially returns the value in this registry setting. See you API documentation for more details.
You can then use either the retrieved computer name or localhost as the host name as in the following example:
[InternetShortcut] URL=http://localhost/myweb/ Or [InternetShortcut] URL=http://mycomputer/myweb/
So, you have the option of creating these files and distributing them with your installation or you can create them on the fly in your install.
Forcing a Reboot.
Sometimes you may find that during the install of a web site you have changed so many settinsg and things that the easiest thing to do is force a reboot. Obviously, you should avoid doing this if ti is not necessary. But, if you do need to do it there are a number of ways to achieve this.
If you are using WISE this is simple. WISE will often detect that a reboot is required due to having replaced system files. Otherwise you can force a restart in WISE simply by setting a variable. If you set the variable RESTART to 'W' Windows will be restarted at the end of the installation. If you set it to 'S' the whole system will be restarted (warm boot). This is documented in the WISE online help so you can check up the details there.
For those of you forced to use APIs to force a restart the appropriate API is ExitWindows in Win16 and ExitWindowsEx in Win32. Both APIs are quite simple, but how they are called will depend on the tool you are using. I recommend checking your API documentation and your installation tool documentation for further details on exactly how to use these calls.
The End Bit.
So, that's it. An overview of what you need to do, in practical terms, to install a web site on an NT or Win95 server. Each site will have individual issues to deal with, but this look at the general process should at least get you well on the way to installing your site.