OS/2 Warp 4: Internet & intranet

By Sheila A. Harnett, Ph.D., Edwin J. Hilpert, Jr., Lanness Robinson & James Taylor

Internet-Enabled Desktop



OS/2 Warp 4 has an array of features that enable you to access information on the Internet, the World-Wide Web, and your own company's intranet easily and seamlessly. This article covers OS/2 Warp 4's new features for accessing URLs, interacting with Web browsers, running Java applets, accessing FTP servers, and more.

The Internet and the World-Wide Web have woven their way into our everyday lives. Computer users are constantly hopping onto the information highway to retrieve or share information. So, it is fitting that IBM has equipped the latest version of its award-winning desktop operating system, OS/2 Warp 4, with many new features for accessing information on the Internet and the Web.

OS/2's object-oriented desktop user interface, the Workplace Shell, is the point of integration for these new features. OS/2 Warp 4's Workplace Shell lets you work with information stored either locally or on the other side of the world, via the Internet, in the same manner--by pointing and clicking on folders to open them and run programs, and by dragging and dropping files between local and remote folders. You can configure these same features to best fit your company's unique desktop needs.

What Does "Internet-Enabled" Mean?
The term "Internet-enabled" may mean different things to different people. In this article, it refers to the cumulative result of enhancements and additions made to the already powerful OS/2 desktop that extend existing user-interface techniques and conventions for dealing with local data and applications to those that reside on the Internet.

In OS/2 Warp 4, you do not have to "drop down" to a lower level of tools to access resources on the Internet; those resources are brought to you through the Workplace Shell. In addition, you can use data files found on the Internet, such as images and sound files, to customize your desktop.

LANs, Intranets, and the Internet OS/2
Warp 4 gives you an incredible set of network computing (NC) tools to choose from: IBM File and Print Client and Peer Services, TCP/IP 4.0, NetWare Client, Remote Access Client, Systems Management Client, and Mobile Office Services.

The Workplace Shell is the unifying user interface for accessing files, programs, and directories that reside on servers reached by these NC-oriented tools. Whether your system is configured to access an intranet inside a firewall, uses a combination of LAN and Internet access, or reaches the Internet via a modem--wherever information resides--OS/2 Warp 4 can connect to it, and the Workplace Shell can access it.

The Workplace Shell Object Model
Some user-interface techniques and conventions within the Workplace Shell can be applied with consistent results to any object you see on the desktop. New objects can be manipulated with these same techniques, blending into the rest of the desktop and extending its power (with little or no learning curve for the user).

Objects on the desktop represent items such as applications, data files, and folders. Double-clicking on an object opens it (whether it is a data file, application, folder, etc.). Clicking mouse button 2 on an object brings up a popup menu showing which operations can be performed on that object. Dragging with mouse button 2 picks up the object and drops it where you release the mouse button (for example, over a printer, another folder, an application, etc.).

Every object has its own settings that you can view and customize via its own Properties notebook. The Internet-related features described below have been implemented as Workplace Shell objects that you can manipulate in the same consistent manner.

New Internet-Enabling Features
The Templates for Internet folder, resides within the Templates folder on the OS/2 Warp 4 desktop. Inside are templates for the new Internet-related objects. As with any other template, you can create a new object by using mouse button 2 to drag a new copy from the template onto the desktop or any other folder.

The Templates for Internet folder contains the following new objects:


 * URL--Represents a Universal Resource Locator (URL), e.g., http://www. software.ibm.com. Once you have pointed to a specific URL address, open the URL object to go to that address.
 * URL Folder--A folder that organizes and displays URL objects in a sorted, details view.
 * HTML File (HTML.HTM)--A type of data file to which HTML-aware editors and HTML viewers can associate, so that they are opened automatically when the HTML file is opened.
 * FTP Host--Represents a remote FTP host. Once the remote FTP host is configured with hostname, username, and password, click on its object to open it. The FTP host then displays the file system contents of the remote host in a Workplace Shell folder view.
 * Java Applet Reference--Represents a Java applet (whether that applet resides on the local machine or at a specific URL on the Web). Once a Java Applet Reference is configured, double-click on it to launch the applet.
 * URL Objects
 * URLs are the keys to the doors on the World-Wide Web. A new kind of object, a URL object, has been added to the Workplace Shell to represent a URL address.

You can create a URL object from its template, as previously described. You can also create one by selecting the "Create another" option from another URL object's popup menu. In each of these cases, the new URL object's Properties notebook opens to a page into which you can type its URL address and set any other specific information for viewing this URL.

Figures 2, 3, and 4 show three pages from the Properties notebook for a URL object -- the Web Page, Browser, and Server pages.

In the Web Page properties page, type the address of the desired URL into the URL entry field. Next, use the Configura-tion checkboxes to set specific browser parameters for viewing Web pages at this URL (e.g., "Palette aware," "Load graphics," etc.). Note that only an integrated browser, such as IBM WebExplorer v1.2, can understand these Configuration parameters; other browsers may not accept such parameters. Therefore, if you do not select the "Integrated browser" checkbox on the Browser page of the URL object's Properties notebook, then these Configuration checkboxes on the Web Page properties page will be disabled.



'''Figure 2. URL Object's Properties Notebook, Web Page Tab'''



'''Figure 3. URL Object's Properties Notebook, Browser Tab'''



'''Figure 4. URL Object's Properties Notebook, Server Tab'''

In any URL object's Browser properties page, you can either change the browser that will be used to view this URL only or change the default browser that will be used to view all URL objects. To change the browser for a single URL, change the value in the "Path and file name" field, then close the notebook. To change the default for all URL objects, change the value in the "Path and file name" field, press the Set Default button at the bottom of the Browser page, then close the notebook.

IBM WebExplorer v1.2 (EXPLORE.EXE) is set to be the default browser for URL objects in OS/2 Warp 4, although an OS/2 version of Netscape Navigator will be available.

The default OS/2 Warp 4 desktop has a preconfigured URL object, "Get Netscape Navigator," to help you download the most up-to-date version of Netscape Navigator for OS/2. Double-clicking on that URL object takes you to a Web page from which you can download Netscape Navigator for OS/2. The install program for Netscape Navigator for OS/2 will ask you if you want to change the default browser for all of your existing URL objects to NETSCAPE.EXE; if so, it makes that change.

The Internet-enabled features described in this article will work with the Netscape Navigator for OS/2 to complement and further enhance the browser's world-class functionality.

If you change the browser to something other than the default, and if your specified browser does not support command-line arguments for the settings on the Web Page properties page, then make sure you de-select the "Integrated browser" checkbox on the Browser properties page.

You can also specify in the Parameters field additional command-line arguments that will be passed to the specified browser's executable when the URL object is opened. If you want to set the information you enter on this page as the new default for all URL objects in your OS/2 Warp 4 system, then press the Set Default pushbutton at the bottom of this page.

Use the Server properties page to set the defaults for configuring the browser for e-mail and news and for getting past a firewall (if a proxy or socks server is available). After you enter the appropriate values in this page and press the Set Default pushbutton at the bottom of the page, all URL objects will pass this information to the specified browser when it is opened.

URL Objects Are Portable
Because URL objects are stored on your local system as data files, they are portable. You can copy an entire folder of URL objects onto a diskette to share with someone else. When that diskette is copied to another OS/2 Warp 4 system, its files show up as the identical URL objects.

Cut and Paste
Another nice feature in the OS/2 Warp 4 Workplace Shell is its ability to cut text from a document and paste it into a folder, thereby creating a datafile object containing the selected text. You can exploit this capability to create new URL objects on the fly. For instance, if you are reading mail or browsing a document and you want to create a URL object for a URL that appears in the text, you can:

1. Select the text specifying the URL. 2. Put it onto the clipboard. 3. Go to a folder's popup menu and select Paste.

This brings up a dialog box titled "Paste clipboard contents to folder." In that dialog box:

4. Type the title you want to give the new URL object. 5. Change the Object class to WPUrl. 6. Press the Paste pushbutton.

A new URL object now appears in the folder to which you pasted.

Other URL Address Prefixes
URL addresses have different prefixes for different protocols; http: is the most common. But several other forms of URLs can be specified, and some of those additional URL formats are very useful when combined with the built-in support provided in OS/2 Warp 4's URL objects.

A URL can also have a protocol prefix of mailto:. Using this protocol, you can create an object on your Workplace Shell desktop that allows you to send e-mail quickly to a designated person, using the mailto: support provided by your Web browser. For example, if Santa Claus were to accept online mail, you could create a URL object on your desktop and enter Santa's URL into the "Uniform Resource Locator (URL)" field on the Web Page page of your URL object's Properties notebook: mailto:santaclaus@northpole.com. At simply double-click on that URL object whenever you want to send more mail to that ID.

Another very useful protocol prefix for a URL is news:. Using this URL prefix, you can create a URL object and place it on your Workplace Shell desktop or into a folder for quick access to an Internet newsgroup. For example, if you create a URL object with the URL address news:comp.os.os2.advocacy#Current_Article and then open that URL object, the newsgroup comp.os.os2.advocacy is opened at the current article.

You can also use a URL object to access gopher sites by specifying the gopher: protocol. For example, to access the text of IBM Announcement Letters, create a URL object with this URL address: gopher://gopher.ibmlink.ibm.com.

Similarly, you can use a URL object to access an FTP site with your Web browser by specifying a URL with the ftp: protocol, e.g., ftp://hobbes.nmsu.edu. However, the new FTP Host Folder object (described later) provides an easier, more intuitive interface for accessing FTP servers.

Web Browser Integration
As mentioned previously, the WebExplorer v1.2 browser (EXPLORE.EXE) is an integrated browser. This means that when you start EXPLORE.EXE by opening a URL object, it accepts command-line arguments from the Workplace Shell.

WebExplorer v1.2 is integrated with the Workplace Shell in other ways as well. If you drop a URL object onto the WebExplorer program object in the WebExplorer folder or onto an open view of the WebExplorer, then WebExplorer loads that URL. In addition, if you use mouse button 2 to drag a Web page viewed in WebExplorer and drop it onto a Workplace Shell folder, you create a URL object pointing to that page.

If you drag an image on a Web page viewed in WebExplorer and drop it onto a Workplace Shell folder, you create an image file containing that image. You can then double-click on that image-file object on the desktop to launch the multimedia viewer associated with that type of image file. So, if you find a neat image on the Web that you want for your desktop's background image, you can drag it from the Web page onto the desktop; then, once the image file is created, you can drag it to the Background properties page of the desktop's Properties notebook. Voila! You have a new desktop background image.

The new Links menu item in the menu bar for WebExplorer v1.2 gives you the option to navigate a Web page by using the VoiceType speech and dictation features built into OS/2 Warp 4. The Links submenu displays the links that are present in the visible viewing area of Web-Explorer v1.2 and can therefore be navigated with spoken commands (as well as with the mouse or keyboard).

URL Folders


'''Figure 5. A URL Folder'''

URL objects can be placed on the desktop or in any folder; however, a special kind of folder, a URL folder, is preconfigured to display URLs in a sorted, details view. A URL folder affords a nice way to view your URL objects, because it shows both the title of a URL object and its address (URL) at the same time. You can find a template for a URL folder in the Templates for Internet folder. Figure 5 shows a URL folder containing several URL objects.

HTML Files
Any application that recognizes files with an .HTM or .HTML filename extension or the file type HTML will automatically associate with HTML file objects and appear in their "Open as" submenu.

The default association for HTML files is the OS/2 System Editor. Drag an HTML file from the HTML file template in the Templates for Internet folder, drop it onto the desktop or any other folder, and open it to start editing a new HTML document.

An organization can design its own HTML file template, which can be used to create Web pages with a similar appearance. Simply create an HTML file with the contents you desire, open its Properties notebook, go to its Icon page, and check the Template checkbox. Your users can then drag a new HTML file from this customized template, drop it on the desktop or any other folder, and edit it with their own information.

You can also use the "paste to folder" technique (described previously to create URL objects on the fly) to create a new HTML file object. Just select WPHtml as the Object Class in the "Paste clipboard contents to folder" dialog box.

FTP Host Folders
You can create an FTP Host folder and use it to access a remote FTP site, to view files at that FTP site, to navigate directories at that site, to transfer files between the local machine and the remote host, and to transfer files directly between two remote hosts. Operations such as login, cd, get, put, mget, mput, ASCII, binary, etc. are built into the predefined Workplace Shell folder behaviors.

An FTP Host folder's icon changes state when the folder is opened and closed. The title of the folder is initially set to its corresponding hostname and username but, once configured, can be renamed.

Open views of an FTP Host (or one of its subfolders) are presented as folder views, like any other Workplace Shell folder. To distinguish these views from those of folders that reside locally, a subtle background bitmap in the folder indicates that it is a view of an FTP Host directory.

Figure 6 shows an open FTP Host folder, with a view of one of the remote files opened in the local machine's OS/2 System Editor.



Figure 6. An FTP Host Folder

You can create an FTP Host folder by dragging an FTP Host Template object from the Templates for Internet folder and dropping it onto the desktop or any other folder. Or you can choose "Create another" from the context menu of another FTP Host folder. You can create a different FTP Host folder for each host to which you want to connect, or you can create a single FTP Host folder that you use to access different remote hosts each time. This flexibility is available in an FTP Host folder's Properties notebook. If any of these values are not specified when you open the FTP Host, you are prompted to enter the missing value(s), for example, hostname, username, password.

Other Settings in an FTP Host Folder
Other settings that can be configured in an FTP Host folder's Properties notebook are:
 * The initial remote directory to change to when the host is opened.
 * Default transfer type (binary or ASCII). This value can also be toggled from the FTP Host folder's popup menu.
 * The default local directory to which a remote file will be downloaded. This directory is used when no explicit target directory for a get operation is specified (e.g., when double-clicking on a remote file results in a get operation without an explicit target directory).
 * A file pattern filter that can be used to specify which files you want included in a remote directory view.

Figures 7 and 8 show two of the Properties notebook pages for an FTP Host folder.

Using an FTP Host Folder
Like any other folder on the desktop, you can open an FTP Host folder by double-clicking on it with the mouse or by selecting "Open as" (in a tree view, icon view, or details view) from the FTP Host's popup menu. When the FTP Host is opened, it displays its remote contents in a folder view; the files and directories it contains are displayed as file and folder objects with their own context menus and properties.



'''Figure 7. FTP Host Folder's Properties Notebook, page 1 of 2'''



'''Figure 8. FTP Host Folder's Properties Notebook, page 2 of 2'''

You can navigate a remote host's file system by opening subfolders to get to the desired remote directory, just as with any directory on the local machine. To view a remote file, double-click on it. In this case, the viewer in which the file is opened is the executable on the local machine that associates to the file's extension. For example, a remote .BMP file, when opened, is loaded into an image viewer on the local machine; a .TXT file is loaded into the default editor on the local machine; and a .WAV file is loaded into the audio player on the local machine. This functionality lets you quickly view and sample data files that exist on the remote host. You can also change the initial starting directory for the remote host, which is used as the starting point for navigating that host, by editing the "Initial remote directory" field in its Properties notebook.

Alternately, you can open a remote file by dragging it from an open view of a Host folder and dropping it onto a program object on your desktop that you want to use to view the file. In addition, you can print a remote file by dragging and dropping it onto a printer on your desktop.

In all these cases of viewing and printing a remote file, a get of the file is done transparently to you. When this happens, if you have not specified a default download directory in the FTP Host folder's Properties notebook, the directory specified by the TMP environment variable on your machine is used as the download directory for the transparent get operation.

Remote hosts may be running any operating system that supports an FTP server. For this reason, on the client, the FTP Host folder provides folder-based views of directories and files that exist on remote hosts running UNIX, VM, Windows NT, OS/2 Warp, or other operating systems -- right alongside folder-based views of directories and files that reside on your local machine!

Figure 9 shows four open FTP Host views -- a VM host, an OS/2 host, a Windows NT host, and a UNIX host.

Once you have opened a view of an FTP Host, you can transfer files. Select the files with your mouse, then either drag them to the desktop or other folder to perform a get operation from the host, or drag a file from the desktop or other folder to the host to perform a put operation.



'''Figure 9. Four Open FTP Hosts'''

If you perform the drag from the remote host directly (i.e., without using the remote file object's "Get. . ." popup menu items), you will see no prompts or progress indicators. If, however, you initiate the get operation from the remote file object's "Get. . ." popup menu item, you will see the standard Workplace Shell progress dialog. The "Get. . ." popup menu option also allows you to use the Work-place Shell's built-in target resolution dialog to pick the target folder for the get operation, just as with any other menu-initiated operation on an object. You can perform an mget or mput operation by selecting multiple files for the operation.

When you perform get and put operations, the default transfer mode (either binary or ASCII) that is currently specified for the host is used. This value can be toggled from the FTP Host folder's context menu or from its Properties notebook.

You can directly transfer files between two open FTP Host folders that reside either on the same host or different hosts. This "proxy put" uses an FTP service that transfers the files without involving the local client. When proxy puts are performed, the transfer mode used is that of the target host; however, if the two hosts involved in a proxy put specify different, incompatible, default transfer modes, you should perform the transfer in two steps, first by dragging the desired file from one host to your desktop, then dragging the resulting file to the second host.

In addition, if you are given the appropriate access, you can delete files on the remote host either by selecting the "Delete from host. . ." context menu option on the remote file object or by dragging and dropping the remote file object onto the Shredder.

Other operations allowed on an FTP Host folder are pinging, querying the host's operating system, and querying the host's present working directory. You can select these operations from the remote host folder's context menu. The output of the ping operation estimates the access time to the host in KBytes per second transferred; that number indicates how long it will take to transfer given files to and from the host.

Once the initial connection with the host has been established, use the second page of the FTP Host folder's Properties notebook to specify the directory to which you want to change and to specify any path name that is valid on the remote host. For example, for OS/2 Warp hosts, you can specify a path name with a different drive letter than that of the initial login directory (even a drive letter that specifies a virtual drive or a LAN drive on the remote host), or you can simply specify a path name for a directory farther down in the file system.

In the event that the remote file system's contents may have changed since the FTP Host view was opened, you can use the FTP Host folder's "Refresh" menu option to refresh the folder view.

You will find it useful to configure FTP Host folder objects for the sites you most frequently visit. (Viewing them is only a double-click away!) During OS/2 Warp 4's development, FTP Host folders were used to continually transfer new DLLs to a test machine as a part of the daily development cycle. The new DLLs were simply dropped onto the preconfigured FTP Host folder whose "initial remote directory" was set to be the test DLL directory on the remote machine.

If you are a "connected consumer" or, in other words, mobile, you will find it convenient to place an FTP Host folder on your laptop that points to your office computer's desktop directory. That way, when you finish writing a report off site, you can simply drop it onto the preconfigured FTP Host folder, and it will pop up on your office computer's desktop!

Other applications of these new features will make it easier to work with different sources of information, coordinate team projects, and telecommute.

Integrating Java Applets with the Workplace Shell
Java promises to break the barriers between disparate systems, so that developers can create software that everybody, everywhere can execute. Java is installed as part of OS/2 Warp 4, and the Work-place Shell can help you take advantage of it. One of the types of objects that has been added to the Workplace Shell is the Java Applet Reference.

WebExplorer v1.2, which comes with OS/2 Warp 4, is not a Java-enabled browser. When a Java-enabled browser becomes available, then running Java applets through that Java-enabled browser will be as simple as visiting another Web site. Until then, it's not automatic, but if you follow a few steps, you'll be downloading, viewing, and playing some nifty stuff in no time. Even with a Java-enabled browser, the Java objects that have been added to the Workplace Shell will be useful to you for keeping favorite applets just a double-click away.

Running Java Applets via Java Applet Reference Objects A Java Applet Reference object does what its name implies -- it points to Java applets that reside on your local computer or on the World-Wide Web.

To create a Java Applet Reference object, you can drag a new one off the template in the Templates for Internet folder and drop it onto the desktop or any other folder, or you can select "Create another" from an existing Java Applet Reference object. Once created, you must configure a Java Applet Reference object (within its Properties notebook) to point to a particular applet and to specify values for parameters expected by the applet.

As Figures 10 and 11 show, two properties pages -- the Applet page and the Reference page -- control access to the applet. The Applet page allows you to enter into the object everything that is in the HTML description for the applet. The Reference page identifies the URL specification of the directory containing the applet's .CLASS file, as well as settings for how to access the Web via a proxy, if required (e.g., if your desktop resides inside a firewall).



'''Figure 10. Java Applet Reference Object's Properties Notebook, Applets Tab'''



'''Figure 11. Java Applet Reference Object's Properties Notebook, Reference Tab'''

Figures 10 and 11 show the required entries for configuring a Java Applet Reference object's Properties notebook for the Blink demo applet that comes with the Java for OS/2 Development Kit (JDK). The Blink demo is an example of a Java applet whose class file resides locally on your computer. To access the many Java applets that reside on the Web, you can use a Java Applet Reference object to point to non-local applets as well as local applets.

The starting point for configuring a Java Applet Reference object is the HTML source for the applet. If the applet is local (e.g., one of the demos installed with the JDK), its .HTML file can be found in the directory with its .CLASS file. If the applet resides on the Web, its corresponding HTML file can be found in the HTML source for the Web page containing the applet. In the case of a non-local applet, you should load the page containing the applet into WebExplorer, view its HTML source, and look for the {applet} HTML tag. In either case, you must enter the information found in the applet tag into the Java Applet Reference object's Properties notebook.

Figure 12 gives an example of how to set up a Java Applet Reference object. It contains the HTML source for the Blink applet (which is located in the \javaos2\demo\blink directory, if you included the JDK as part of your OS/2 Warp 4 installation). The parts you need to enter into fields in the Java Applet Reference properties page are highlighted.

The tags labeled title, width, and height have direct counterparts in the Java Applet Reference object's Properties notebook. The Java class name is designated by the code= field of the {applet} tag; in this case, the class name is Blink. Specifying the .CLASS extension is optional.

For each param tag in the HTML source, create a line in the Parameters field on the Browser page of the Properties notebook. For example, if the HTML source includes the line {param name=X value=Y}, create a line in the Parameters field specifying X=Y. Enter applet parameters, one per line, into the notebook's entry field.

The Reference page of the Properties notebook is for the URL specification of the directory containing the .CLASS file for the applet. For local applets (those stored on your local computer), the URL has a prefix of file:///. (Note that the file: prefix requires three forward slashes.) For applets residing on the Web, the URL has a prefix of http://. For the Blink demo applet (a local applet), the URL is file:///c:\javaos2\demo\blink/. The slashes here are significant. The mixed slashes in the URL are part of the legacy of the UNIX origins of the Web and the Internet. UNIX path names have forward slashes to separate directory and file names, while OS/2 Warp path names have backward slash separators.

'''Figure 12. HTML Source Code for the Blink Java Applet'''

{title}BLINKING TEXT{/title} {hr} {applet code="Blink.class" width=300 height=100} {param name=lbl value="This is the next best thing to sliced bread!"} {param name=speed value="4"} {/applet} {hr} {a href="Blink.java"}The source.{/a}

If you are configuring a Java Applet Reference object for an applet that resides at a URL on the Web (say, http://www. foo.bar/html/applet.html), the URL field should be http://www.foo.bar/html/ (don't forget the trailing forward slash!).

If the applet resides on your local computer or inside a firewall, you don't have to enter anything in the other fields of the Reference page. If your desktop is located inside a firewall, but the applet resides outside the firewall, you will need to configure the "Proxy host" and "Proxy port" fields. In this case, set the "Proxy host" field to your network's proxy server, set the "Proxy port" field (e.g., 80), and check the "Enable proxy" checkbox.

Once you have configured your Java applet, you can easily change the parameters of the applet to tailor it to your particular tastes or to see how different parameter values affect the applet's execution.

Now to run the applet, just double-click on the Java Applet Reference object!

Running Java Applets via URL Objects An alternate mechanism for running a Java applet is to launch the Java applet from a URL object. The Java applet viewer (APPLET.EXE) is part of the Java for OS/2 runtime. The difference between this mechanism and the one described above is that Java Applet Reference objects enable you to vary the applet's parameters, whereas an ordinary URL object does not; however, using a URL object is simpler. So, if you do not need to vary an applet's parameters, you should use a URL object. This is the mechanism used to showcase the Java for OS/2 samples in the URLs for Samples folder (which resides in the Samples for Sun's Java Programming Environment folder).

Figure 13 shows the JDK samples folder with its URL objects configured to use the Java applet viewer.

If you are using WebExplorer v1.2 to browse a page containing a Java applet, you may not see an indication that there is a Java applet in the page (but if you had a Java-enabled browser, you would see it). In this case, you can scan the HTML by pulling down the File menu item and selecting "View file (HTML)." If the HTML source for the page you are viewing has {applet} in it, it contains a Java applet, and you can drag the page containing the applet from WebExplorer v1.2 to the desktop. A URL object will be created on the desktop.



'''Figure 13. URLs for Samples Folder'''

Once you have created a URL object pointing to the Web page containing a Java applet in this manner, you can run the applet using the Java applet viewer. To do this, click mouse button 2 on the URL object you just created to bring up its popup menu. Then select "Java applet viewer from URL" from the Open submenu of the URL object, which passes the URL on to the Java applet viewer and launches the applet.

A final note about the Java applet viewer: If your desktop resides inside a firewall, the viewer's own version of proxy/gateway information must be initialized once. To do this one-time configuration, go to an OS/2 command prompt and type:

cd ?:\javaos2\demo\tumblingduke applet example1.html

where ?: is the drive on which Java was installed.

Any JDK demo will do. Once the applet viewer is open, click on the Applet menu bar item and select "Properties." Fill in the fields with the values required for you to access URLs outside your company's firewall. Select the Apply button, and you are ready to use URL objects to execute Java applets across the Web.



'''Figure 14. Connections Folder'''

The Whole Network Computing Package in OS/2 Warp 4 The Connections folder on the desktop is a starting point for exploring many of OS/2 Warp 4's networking features. Figure 14 shows an open view of the Connections folder. Inside it, you will find the following folders:


 * Printers -- Contains local and network printers accessible from your desktop.
 * Drives -- Provides access to local, remote, and PCMCIA disk drives and directories. Any drive on your system that can be identified with a drive letter is found in the Drives folder and can be browsed with a Workplace Shell folder view.
 * Network -- Provides access to resources on the LAN to which your desktop is connected as a peer or client. LAN drives and directories are presented as regular Workplace Shell folders; you can open files and directories that reside on the LAN and drag and drop them to and from the desktop.
 * Web Sites -- Contains an assortment of more than 100 pre-configured URLs in the areas of Business & Shopping, Computing, Entertainment, Reference, Web Search Sites, IBM Web Pages, OS/2-Related Web Pages, Education, and News & Sports. Have fun surfing!

Enhancements
Installing the components for the Internet- and LAN-enabled Workplace Shell is simpler than ever. To use the FTP Host folders and URL objects, as well as to install WebExplorer v1.2, simply select TCP/IP as one of the components during installation, and be ready to enter your TCP/IP address, hostname, domain, router, and name server. Or accept the defaults, and enter your information later via the TCP/IP configuration object in the System Setup folder.

In another improvement over previous OS/2 Warp Connect packaging, the various pieces of the TCP/IP, File, and Print Client user interfaces have been integrated with the similar pieces from the base operating system. For example:


 * The desktop's Assistance folder contains the help and reference information for all of the installed pieces, rather than distributing them in different places on the desktop.
 * Configuration objects are centrally located in the System Setup folder, and a new Programs folder is the centralized location for selectively installed applications such as TCP/IP, multimedia, speech, Java Development Kit, etc.
 * Selective install and selective uninstall utilities for all pieces of OS/2 Warp 4 are located in the new Install/Remove folder, which is in the System Setup folder.

Something for Everyone
The Internet-related features of the OS/2 Warp 4 desktop will appeal to different audiences.


 * End users will immediately benefit from the built-in onramp to the Internet.
 * Connected consumers can use these features whether they are connected directly to their organization's LAN or intranet or are connected via a modem from home.
 * System managers responsible for setting up multiple OS/2 Warp clients and servers can programmatically create and configure instances of the new Internet-related Workplace Shell objects discussed above (via REXX or Win APIs).

Figure 15 shows a sample REXX script that creates a URL on the desktop pointing to a particular Web page. Note the ClassName variable, WPUrl.

To create an FTP Host folder, specify the ClassName WPHost and appropriate values (listed in Figure 16) for a WPHost setup string.

'''Figure 15. Sample REXX Program to Create URL Object'''  /* create a URL object via a REXX command file */ call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs' call SysLoadFuncs

ClassName='WPUrl' Title='OS/2 Warp Home Page' Destination='{WP_DESKTOP}' SetupString='LOCATOR=http://www.software.ibm.com/pspinfo/os2.html' SetupString=SetupString| | 'OBJECTID={NEW_URL}'

rc=SysCreateObject(ClassName, Title, Destination, SetupString) if rc then say 'URL object creation succeeded' else do	say 'URL object creation failed' end exit 

For more information about using REXX and Workplace Shell setup strings, consult the OS/2 Warp 4 Developer's Toolkit documentation.

New Setup Strings
Figures 16 and 17 list the new setup strings for the WPUrl and WPHost classes, respectively.

Application developers can programmatically create and configure URL and FTP Host folders using the Workplace Shell's object-oriented programming interface, also documented in the OS/2 Warp 4 Developer's Toolkit.

Merging the Desktop with the Internet
The features discussed in this article are a first step toward merging the desktop with the Internet and its resources. These Internet-related features, combined with the overall set of new features added to the Workplace Shell for OS/2 Warp 4, have created a desktop operating system that is more fun to use, while remaining as solid as ever. OS/2 Warp 4 with its Internet-enabled Workplace Shell is a powerful vehicle for bringing the world to your fingertips.

Figures 16 and 17
'''Figure 16. Setup Strings Understood by URL Objects (ClassName WPUrl)'''

END FIG. 16

'''Figure 17. Setup Strings Understood by FTP Host Folders (ClassName -- WPHost)'''

BEGIN FIG. 17 {|class="wikitable sortable" !Keyword||Value||Description
 * HOSTNAME=	||hostname	||Sets the hostname to access via this FTP Host folder, e.g., ftp.software.ibm.com.
 * USERNAME= 	||username	||Sets the username to supply when accessing a hostname via this FTP Host folder.
 * PASSWORD= 	||password	||Sets the password to use to access a particular host with a particular user-name. This value is not required when the object is created. If no password is specified, you are prompted to enter a password after the host is accessed. When they are furnished, passwords are stored in an encrypted form.
 * ACCOUNT= 	||account	||Sets the account value to be used when accessing a particular hostname and username via this FTP Host folder. This value is required only when the FTP server being accessed maintains account information for host accesses.
 * FILETRANSFERTYPE= 	||ASCII|BINARY	||Sets the default file transfer mode for an FTP Host folder. The default is BINARY.
 * REMOTEDIR= 	||pathname	||Used as the initial working directory when connecting to a host via the specified FTP Host folder (e.g., e:\public\bin or /usr/johndoe/work or pub). This path specification's format must be understood by the remote host's operating system, and the username and account must have permission to access this directory on the remote host.
 * LOCALDIR= 	||pathname	||Used as the default download directory for get operations via the FTP Host folder whenever a download directory is not explicitly indicated.
 * INCLUDE= 	||pattern	||Used to filter remote files and directories from the FTP Host folder's open views. The syntax of the pattern must be understood by the remote host's operating system, e.g., *.exe.
 * HOSTOSTYPE= 	||UNIX/OS2/WIN	||Specifies the type of operating system (OS) running on the remote host
 * ||.VM / OTHER	||When the host OS type is not explicitly specified, the FTP Host folder tries to determine it. This type is used for determining how to display the contents of the remote directory in a folder view. In general, setting an explicit value for HOSTOSTYPE is not required; however, it may be necessary to override the default detected type for some remote hosts (e.g., hosts that do not reply to OS type requests via their FTP servers). Note: the UNIX type is used to include OSs that use similar file specification syntax and directory formatting information. When OTHER is specified, or when a host OS type cannot be determined, only files will be displayed in the FTP Host folder view (i.e., the equivalent of an ls operation will be shown, as opposed to a dir operation).
 * REMOTEDIR= 	||pathname	||Used as the initial working directory when connecting to a host via the specified FTP Host folder (e.g., e:\public\bin or /usr/johndoe/work or pub). This path specification's format must be understood by the remote host's operating system, and the username and account must have permission to access this directory on the remote host.
 * LOCALDIR= 	||pathname	||Used as the default download directory for get operations via the FTP Host folder whenever a download directory is not explicitly indicated.
 * INCLUDE= 	||pattern	||Used to filter remote files and directories from the FTP Host folder's open views. The syntax of the pattern must be understood by the remote host's operating system, e.g., *.exe.
 * HOSTOSTYPE= 	||UNIX/OS2/WIN	||Specifies the type of operating system (OS) running on the remote host
 * ||.VM / OTHER	||When the host OS type is not explicitly specified, the FTP Host folder tries to determine it. This type is used for determining how to display the contents of the remote directory in a folder view. In general, setting an explicit value for HOSTOSTYPE is not required; however, it may be necessary to override the default detected type for some remote hosts (e.g., hosts that do not reply to OS type requests via their FTP servers). Note: the UNIX type is used to include OSs that use similar file specification syntax and directory formatting information. When OTHER is specified, or when a host OS type cannot be determined, only files will be displayed in the FTP Host folder view (i.e., the equivalent of an ls operation will be shown, as opposed to a dir operation).
 * INCLUDE= 	||pattern	||Used to filter remote files and directories from the FTP Host folder's open views. The syntax of the pattern must be understood by the remote host's operating system, e.g., *.exe.
 * HOSTOSTYPE= 	||UNIX/OS2/WIN	||Specifies the type of operating system (OS) running on the remote host
 * ||.VM / OTHER	||When the host OS type is not explicitly specified, the FTP Host folder tries to determine it. This type is used for determining how to display the contents of the remote directory in a folder view. In general, setting an explicit value for HOSTOSTYPE is not required; however, it may be necessary to override the default detected type for some remote hosts (e.g., hosts that do not reply to OS type requests via their FTP servers). Note: the UNIX type is used to include OSs that use similar file specification syntax and directory formatting information. When OTHER is specified, or when a host OS type cannot be determined, only files will be displayed in the FTP Host folder view (i.e., the equivalent of an ls operation will be shown, as opposed to a dir operation).
 * ||.VM / OTHER	||When the host OS type is not explicitly specified, the FTP Host folder tries to determine it. This type is used for determining how to display the contents of the remote directory in a folder view. In general, setting an explicit value for HOSTOSTYPE is not required; however, it may be necessary to override the default detected type for some remote hosts (e.g., hosts that do not reply to OS type requests via their FTP servers). Note: the UNIX type is used to include OSs that use similar file specification syntax and directory formatting information. When OTHER is specified, or when a host OS type cannot be determined, only files will be displayed in the FTP Host folder view (i.e., the equivalent of an ls operation will be shown, as opposed to a dir operation).
 * ||.VM / OTHER	||When the host OS type is not explicitly specified, the FTP Host folder tries to determine it. This type is used for determining how to display the contents of the remote directory in a folder view. In general, setting an explicit value for HOSTOSTYPE is not required; however, it may be necessary to override the default detected type for some remote hosts (e.g., hosts that do not reply to OS type requests via their FTP servers). Note: the UNIX type is used to include OSs that use similar file specification syntax and directory formatting information. When OTHER is specified, or when a host OS type cannot be determined, only files will be displayed in the FTP Host folder view (i.e., the equivalent of an ls operation will be shown, as opposed to a dir operation).

END FIG. 17