As electronic commerce-mania grips a frenzied nation of Webheads, many sites have turned to Microsoft Commerce Server as an easy-to-implement solution for their storefront woes.

It's no wonder that so many companies these days consider electronic commerce (EC) their future. What's surprising is how few online stores go beyond the basics. Many vendors consider a bunch of semifunctional Perl scripts an online store—definitely a stretch considering the complexity of the Internet. EC applications based on custom engines like these are usually built as solutions to specific problems and lack the flexibility and robustness to accommodate a dynamic marketplace.       As a result, a good percentage of the commerce sites out there are like the Mona Lisa without her famous smile: plain and incomplete. Add the general public's notion that online shopping is not secure—despite the fact that it's as safe as any form of commerce—and you'll see why EC hasn't taken off so rapidly.       Earlier this year, Microsoft® released Commerce Server 2.0 (MSCS) as a component of the Site Server Enterprise Edition suite. MSCS is a significant improvement over Microsoft Merchant Server 1.0, Microsoft's previous EC software and many companies already support MSCS as their primary EC solution. The screenshots presented here are taken from the online software store Softmania (http://www.softmania.com), which I helped develop.       EC comes in two flavors: business-to-consumer and business-to-business. The consumer who is shopping online wants the experience to be easy, convenient, and secure. Online store operators, on the other hand, see the Internet not only as a channel for reaching their customers, but also as an inexpensive medium for communicating with their suppliers. For them, a commerce solution must be flexible, easy to maintain, and ready to be integrated with existing business-to-business standards such as Electronic Data Interchange.       MSCS provides excellent support for all the aspects of business-to-consumer commerce, and although the system doesn't directly handle business-to-business transactions, it provides enough customizability to let the developer take care of the problem. Microsoft is currently working on the Commerce Interchange platform, which will integrate business-to-business transactions in future versions of MSCS. Architectural Overview       For an EC engine to function properly, it must be modular enough to have a Web site front end while allowing its internal components to change depending on the needs of a specific implementation.       At its core, MSCS is a collection of Active Server™ components. Active Server Pages (ASP) provides all the functionality required to access the database used to store product, customer, and order information. A Web site built with ASP can be expanded easily through the addition of new Active Server components, and it makes the perfect choice for successfully integrating MSCS with the BackOffice® product family. MSCS requires Windows NT® Server 4.0 with Internet Information Server (IIS) 3.0, and supports either Microsoft or Oracle SQL servers.       ASP is not customizable enough for the engine to be truly flexible, however. ASP components are, after all, objects embedded in DLLs, and their code cannot be modified directly. To overcome this limitation, Microsoft introduced the Order Processing Pipeline (OPP). The OPP is a component-based process that handles the operations required to complete a purchase, from database information retrieval to the collection of payments. The OPP is divided into stages, and components for each stage can be chosen from a variety of built-in, third party, or custom objects. Figure 1 shows an overview of MSCS. Notice the distinction between the store, a single implementation of the EC engine, and the server, which contains the core components and utilities required to run and administer all the stores installed on a computer.

Figure 1: Overview of MSCS

      In MSCS, while each store has its own database, ASP-powered Web site, and OPP, it shares the functionality of the server with all the other stores. Store sites are divided into two main sections: shops and managers. A shop contains the interface that is usually accessed by customers through the net; this includes catalog browsing, order collecting, and so on. A manager usually cannot be accessed by users. It handles the store's maintenance issues, such as catalog editing, order viewing, and customer statistics. A store is, therefore, a fully integrated and self-contained ASP application whose parts can be accessed from anywhere through the Internet. No need to worry, though; MSCS managers can be protected using standard Windows NT security, and are therefore as safe as your passwords.

Managing Stores
      General maintenance of all the stores installed on a computer is done through an ASP-based application called Server Manager. This utility is useful for controlling all the sites through a single command center. It can be used to open or close a store (when a store is closed, it normally does not accept orders), to access its manager or shop section, to create new stores, and to copy or delete existing ones. Figure 2 shows the Server Manager's main page.

Figure 2: Server Manager’s Main Page

      Whenever you want to create a new store, the Store Foundation Wizard (shown in Figure 3) guides you through the necessary steps. You are asked the name of the store you want to create, your choice of database and datasource, and the login ID that will function as administrator for the Store Manager. The wizard creates all the structures required by the store to work properly, including a standard OPP. However, no actual HTML code is generated so that, in theory, developers can write their own site interfaces from scratch.

Figure 3: Store Foundation Wizard

Most programmers will use the StoreBuilder Wizard instead (see Figure 4). It's accessible through the Store Manager of a newly created store. After just a handful of clicks, you'll end up with a fully functional MSCS store that even includes its own graphics and support for the desired locale (taxes included).

Figure 4: StoreBuilder Wizard

Although stores created with Store Foundation Wizard and StoreBuilder Wizard need significant customization, particularly in terms of display, their structure is surprisingly complex. They are complete in many ways, and for a fairly simple EC site they can be used right as they come out of the wizard processes. Figures 5, 6, and 7 are taken from the Marco Tabini Store (OK, so it's not the most exciting name on earth). As you will notice, they are significantly simpler than a commercial site like Softmania (shown in Figures 8, 9, and 10). Yet it is possible to buy Marco Tabini-related products with the click of a mouse. The store will take care of computing taxes, shipping and handling fees, and ensuring that the customer provides a valid credit card during payment.

Figure 5: Marco Tabini Store

Figure 6: Selecting a Product

Figure 7: Buying a Product

Thus, in five minutes (even less once you know your way through the wizards) it is possible to create a site that would have taken much longer to develop from scratch and that would have left the client with a very basic store and a lot less money in their pocket. Instead, you can use it as a starting point, leaving an incredible amount of time for customization and improvement—not to mention higher margins!

Figure 8: Softmania's Online Store

Figure 9: Games/Entertainment Page

Figure 10: Buying on Action Game

You may have been wondering what buying something from your site looks like from your customers' point of view. Chances are your store will look a lot like a department store, even though you may sell only one type of product.       During their visit, customers will click around the various sections of the store, and hopefully will add some of the products you offer to their Virtual Shopping Basket (VSB). The VSB can be reviewed at any time and the items that it contains can be removed or their quantity can be changed. Figure 11 shows Softmania's VSB. Softmania calls it a shopping cart, but the functionality is exactly the same.

Figure1: Softmania's Shopping Cart

Once customers make up their minds, they might decide to place an order. They will be asked for personal information such as shipping and billing addresses and payment information. MSCS will process this data according to the parameters specified by the developer to either accept or refuse the order. Server Integration       MSCS introduces 11 new ASP components as the core engine of the system. Their uses vary widely, from enhanced database access to data collection for statistical analysis to session-wide storage. Figure 12 lists the new ASP components.       MSCS provides two general-purpose storage components, called Dictionary and SimpleList, that can be used to store lists and sets of variables in memory. SimpleList is a set of variant type variables. Objects of this class behave like linked lists and support enumeration.       Dictionary objects are dynamic arrays of variant type variables. Each variable is composed of a name element and a value element. (Dictionary variables are also called name/value pairs.) A variable can be added to a Dictionary object simply by assigning a value to it:

Set Dict = Server.CreateObject ("MSCS.Dictionary") Dict.Test = "Testing"

Afterward, the command

Response.Write (Dict.Test)

will print "Testing" on the page. Accessing the Database       Understandably, an EC application makes heavy use of databases. Just think of all the tables that you need to process an order: shopper, product, and order information are the bare minimum. The number of tables grows rapidly as you make your store more complex. Although handling database data using ASP and ADO is not difficult, it can be messy and resource-consuming to open too many recordset objects at the same time. Furthermore, it is often necessary to repeat the same operation in scripts that belong to different pages, and query text for those scripts takes up hard drive space, as does the scripting code to access ADO functions. The Content component, outlined in Figure 13, provides a convenient one-stop interface for storing queries and sharing them among various data sources.       While Content provides an application-wide storage space for queries, it also provides direct database access through the DataSource component (see Figure 14). ASP objects of this class are bound to an ODBC system or file datasource and are the real key to accessing databases.       Datasource objects are not created using the standard Server.CreateObject method, but through the AddDatasource method of the Content component, which opens an ADO connection and assigns it to a new Datasource object. The alias parameter will be used as a nickname to extract the DataSource object from the Content object using the DataSource method.       To successfully complete the connection process, the AddDatasource method requires a connection string in the standard ODBC format. If you have worked with ODBC before in Visual C++® or another language, you will have no problem writing connection strings. Otherwise, you can take a look at Figure 15, which describes the ODBC connection string format.       Since the storewide Content object and any related DataSource objects are usually created in the Application_ OnStart method of the Global.asa file, only one ADO connection is opened, and it lasts as long as the session does. This approach to data access improves the performance of MSCS-based applications and significantly simplifies the developer's life. Figure7: Product Listing       Once a DataSource object is created, it can be used to access data in one of two ways. The Execute method runs a query and returns its result (if any) in a SimpleList object composed of Dictionary objects. The only parameter needed to run DataSource.Execute is the alias of a SQL query stored in its parent Content component together with any parameter that the query might require. While it is possible to specify the text of a query directly, this method is not recommended by the MSCS documentation, as it excludes all the optimization procedures that the DataSource component provides. Furthermore, directly specified queries are forced to use a specific set of options, such as query timeout, cursor type, and maximum number of rows fetched. These can be customized when a query is stored in a Context object.        Figure 16 contains a simple script that creates a Content object, then adds a DataSource object and two queries to it. One of the queries is then executed and the resulting records written to the browser. Figure 17 shows the output of the script. Handling Shoppers       Identifying the people who shop at your site is crucial. It is also important that the system be able to distinguish a returning shopper with absolute certainty. MSCS implements this functionality by assigning a unique shopper ID to each visiting browser. The ID can be stored in a cookie on the client computer. Returning customers are identified by retrieving the shopper_id cookie installed on their machines. At the same time, being able to recognize a specific visitor significantly reduces the need to exchange sensitive information and consequently the possibility of someone stealing the data over the Internet.       Shopper IDs are handled through the StandardSManager component, outlined in Figure 18, which creates and deletes shopper IDs. It also stores them on the client machine and retrieves stored IDs.       While it is obvious that an EC store has to handle orders, it is not clear how the orders should be organized. The OrderForm component provides a well-structured collection of SimpleList and Dictionary objects to solve the problem. This component is completely flexible: it can be customized by simply adding new items to it. In fact, an OrderForm object is widely modified by MSCS in various places during a site visit. It collects information about all the items that the order contains, shipping and billing information, and any other data that can be of use to the system.       MSCS automatically sets a certain number of SimpleList objects inside an OrderForm object. They serve two purposes: to provide ordered storage for the order items, and to hold error messages that are generated during OPP processes.       Although you can find an outline of the OrderForm component's functionality in Figure 19, I will explore it in a bit more depth in the paragraphs dedicated to the OPP. Sprechen Sie Englisch?       Obviously, or at least hopefully, not all the people visiting your MSCS-powered site will be coming from your country. It is therefore likely that you will want to localize your site in different languages, resulting in a very annoying problem: most of the dynamic content, such as database results, will be generated according to the Windows NT locale specifications of the machine where your software resides. Many developers consider this a minor inconvenience and often ignore it. The truth is that your visitors do notice and really appreciate a site that correctly displays currencies and values in their locale.       In the MSCS environment, this problem is partly solved by the DataFunctions component. As you can see in Figure 20, it allows the conversion of dates, currency values, and other data types to a string according to the locale settings specified in the Locale property.       DataFunctions components also provide four functions for validating user input. Among these, the CleanString function is handy as it can be used to strip all spaces and carriage returns from a string. This can be useful when handling credit card numbers considering that many people like to input them separated by blank spaces. CleanString will not help the users who use dashes, but it is definitely a good start. HTML Made Easy (Almost)       Writing HTML can be a hassle sometimes. Using ASP helps make the task a little easier, but it also leaves many blanks that you'll want to fill.       The Page component, outlined in Figure 21, certainly doesn't solve it all, but at least introduces some features that I have been waiting for a long time. For example, the RequestXxx methods expand the original ASP Request function by introducing type and range checking, while the URL and SURL methods make the creation of HTML links a lot easier. There is even a setting that prevents SURL from generating secure links, a feature you will want to use during testing sessions. As you'll see later on, this component also provides support for executing purchases through the OPP. The Microsoft Wallet       One of the things I hate when shopping online is that each time I want to buy something I have to input all my personal data. Somebody at Microsoft must have realized the same thing and, tired of input boxes and dropdown lists, designed the Microsoft Wallet.       The Wallet is really a collection of two ActiveX® browser components: the Address Selector, used to collect and store addresses (as the name suggests), and the Payment Selector, which holds payment information. Both are designed to store their information on the computer where they are installed. They make this information available, with the user's consent, to any application that supports them.

Figure 22: Using the Wallet

As you can see in Figure 22, using the Wallet is simple. The user will typically specify an address in the Address Selector and a payment method in the Payment Selector. All the information is stored locally and, in the case of payment data, encrypted against a password specified by the user. By default, the Wallet will pop up a notification window whenever an address is about to be released and will ask for a password before transmitting any payment data. Several sets of information can be stored in a single Wallet and retrieved or edited individually (see Figure 23).

Figure 23: Payment Methods

Many of the Wallet's interface elements can be customized, including the font face used to display text information and the color of several interface items. The code in Figure 24 will produce an HTML page that contains both selectors and three buttons that will alter their appearance dynamically through scripting. Since it uses VBScript, it will work only on Internet Explorer, and I am sure that you will be able to produce some rather, um, unusual results with it.       Although the Wallet supports all major credit cards by default (VISA, MasterCard, American Express, and Discover), you might want to implement other payment methods to satisfy special needs: bank accounts, debit cards, or private label credit cards, and so on. This can be done by writing Wallet plug-ins using Visual C++ and the Commerce SDK, a rich collection of tools and samples that can also be used to write OPP components.       The downside of the Wallet is obviously that, unless you have Internet Explorer 4.0, it definitely doesn't come with your browser and has to be downloaded off the Microsoft Web site.

Figure 25: Page without Wallet Link

For those users who have trouble with the Wallet, or simply do not want to install it, MSCS provides support for what I call the Poor Man's Wallet—the dreaded HTML forms. Figure 25 shows the same page displayed in Figure 23 when the user selects the "Click here if you have problems with the Wallet" link. It is—at least to me—a very depressing view after seeing the beauty of the Wallet, but when you have a 28.8Kbps connection it is certainly less depressing (and expensive) than going out for a coffee while the browser downloads components.       Those of you attentive to details will have already noticed that by mentioning how the Wallet is an ActiveX control, I have suddenly reduced the potential Wallet audience to a mere 40 percent (but rising) of all the Web browsers. Well, do not despair—Microsoft provides a version of the Wallet intended for Netscape software.       The tricky part comes when you want to install a different version of each plug-in according to which browser the user has. You will need to implement some kind of browser recognition to give your store a certain solidity. If the visiting browser does not support either ActiveX or Netscape plug-ins (or if you have doubts whether it does), you will have to use forms.       Browser recognition is done through the MSWC.BrowserType standard ASP component, which simply compares server variables against a table contained in the Browscap.ini file usually located in the C:\Winnt\System32\Inetsrv\Asp\ Cmpnts directory on the server's hard drive. The problem with this technique is that the Browscap.ini file that comes with the ASP installation pack is not exactly up to date, resulting in obvious mistakes (see Figure 26 for an example).

Figure 26: Shipping Information

Microsoft used to provide regular updates to the Browscap.ini file that could be downloaded from their Web site, but the most up-to-date version is distributed by CyScape, Inc. (http://www.cyscape.com). CyScape is also working on a new component that will simplify the process of browser recognition. While I am writing this article, the component is in the first stages of its beta testing, and should be available soon. Order Processing       Hopefully, sooner or later some of your visitors will buy one or more products from your store. Order processing is usually a procedure that, for obvious reasons, you will want to keep as simple as possible for your potential buyer. However, the very nature of the Internet usually makes it complex unless you want to restrict your target audience significantly. To clarify this concept a bit more, here are a few situations where handling a purchase can get really hairy. Shipping You probably will not want people from your country to pay as much as somebody from the other side of the planet for the shipment of their orders—you'll either lose a lot of money or a lot of customers. Furthermore, people don't trust postal services everywhere in the world and some customers will want their products to be delivered by courier. Finally, several shipment methods (like second-day air or ground) might apply to the same geographical zone.       Do the math and you'll find that to provide the flexibility you need to be competitive, you will have to handle as many as 20 different combinations. For example, Softmania offers two shipping methods for each shipment with rates that are specific to almost every possible nation. The result is a cost-effective solution and less headaches for the production team. Promotions Where can I start? Catching up with the twisted minds that populate the marketing department has always been one of the developer's worst nightmares. Beyond the usual time-limited sales, there is a multitude of offers that you will have to cope with: buy X and get Y for free, buy n copies of X and get a Y for free, and so on. Taxes In some cases, it's really easy to handle sales taxes. For example, in the U.S. the taxes are under an individual state's jurisdiction, and do not apply to customers from elsewhere. But generally speaking, taxes represent the offspring of political minds and therefore usually belong to another plane of existence. Furthermore, many big retailers face the problem of doing business in several states, which means that they have to apply taxes to customers that come from those regions. Payments There are an almost infinite number of payment methods that your clients will want to implement: credit cards, electronic accounts, debit cards, private labels, and so on. Naturally, each and every one of them uses different protocols, making your life really easy.       Although none of these problems prevents you from creating a functional store that simply does not implement a solution for ordering, you can't really ignore them when you are trying to build a competitive store. Customers want choices, yet they get easily confused if they have too many. Thus, your site must be smart enough to obtain all the data that it needs by presenting only a few clear choices to the user. All the extraction and induction must be done inside your application without any external intervention. Using the OPP        Figure 27 shows the internal structure of the OPP. As you can see, it's fundamentally a sequence of 14 stages. Each one addresses an aspect of order processing and provides a container for one or more OPP components. Figure 27:       OPP Structure       While the components do the real work by reading, interpreting, and saving parameters to the OrderForm, the stage-based structure provides a well-defined framework to execute them in. While some stages are optional and can be left empty, many others require the components inside them to set several parameters before proceeding to the next stage. When the requirements needed to leave a specific stage are not met, an error is raised.       An MSCS store invokes the OPP several times during the purchase process, although sometimes it doesn't require all of its steps to be executed. Figure 27 also illustrates how stages have been grouped according to three execution modes, which correspond to specific actions on behalf of the customer. Product Mode is used when the user alters the content of the VSB (that is, by adding or removing an item). Plan Mode is used to verify that all the information contained in the OrderForm is correct and to compute all the costs related to the order (shipping, taxes, and so on). Purchase Mode is used whenever a purchase has to be completed. It executes all the stages of the OPP and attempts to commit the order to the database. The components that run inside the OPP are COM objects that implement several interfaces and support freethreaded execution.       Since it is not possible to control the execution flow inside the OPP (all the components belonging to the same execution mode are always executed), MSCS uses a collaborative model to determine how each component affects the OrderForm parameters.       Whenever the OPP is invoked, it automatically resets all the OrderForm parameters that are to be modified inside the pipeline by setting them to null. Subsequently, a component should only change a parameter if its value is still null. Thus, the order in which components are executed within the same stage is very important. Although this model has its disadvantages, it helps keep the OPP simple and does not cause any trouble as long as you use compliant components. Writing Your Own OPP Components       The OPP is configured by fundamentally altering the number of components inside it and their order. The simplest utility that MSCS provides to edit the contents of a pipeline is a Win32®-based tool called Pipeline Editor, shown in Figure 28. Being a MDI application, it allows for the editing of several pipelines at the same time. It also produces a visual representation of the pipeline which lets the user move through it quite quickly.

Figure 28: Pipeline Editor

There would be no justice, however, if Microsoft didn't provide the truly Web-based Pipeline Editor that you can see in Figure 29. This ASP-based application has almost the same functionality as the Win32-based version, although the interface is slightly more cumbersome. It comes in handy when you have to configure your OPP remotely, as often happens for security reasons.

Figure 29: Web-based Pipeline Editor

MSCS comes with 33 built-in OPP components whose use varies from tax calculation to the implementation of complex promotions. Although they are more than enough for the creation of a relatively complex store, sooner or later you will find yourself in need of something that is more specific than what MSCS covers.       The obvious solution is to write your own components from scratch, using a compiler that supports both the creation of COM objects and the Windows freethreaded execution model. Unfortunately, this rules out using Visual Basic®, which only allows for the creation of apartment-threaded COM objects. The next choice would probably be Visual C++ and the Active Template Library (ATL), a more powerful but also more complicated combination.

Figure 30: Scriptor Component

The easiest way to write your own components is by using the Scriptor component shown in Figure 30, which provides a programming environment that runs Microsoft Scripting Engine (MSE) compatible code. MSE is the same engine that ASP uses, which means that you can write your components in your favorite scripting language, such as VBScript or JScript™. The script to be executed can be specified as a parameter, in which case its length is limited to 2,048 characters, or it can be included in an external text file. Writing a Sample Component       OrderMagnitude is a very simple OPP component written using Scriptor that categorizes an order according to the number of items it contains. As you can see from Figure 31, six categories correspond to six item quantity ranges. An order belongs to a category if it contains a number of items that is greater than or equal to the lower boundaries and less than the upper boundaries set for that category. Category specifications are stored in the store database's OrderCategories table created by the SQL statement shown in Figure 32.       The entry point of a Scriptor component is a function called MSCSExecute, defined as follows:

MSCSExecute(config, orderform, context, flags)

Config contains information about the script (see Figure 33), as well as any parameter that has been specified in the Parameters section of the component configuration. Flags is a debug mode flag and should be equal to 1.       Context is a reference to a Context object—basically a set of ASP components. For example, any ASP page receives by default a Context object that contains several components, such as the Server, the Request, the Application, and so on. The objects included in an OPP component's Context object (see Figure 34) are fairly different from the ones available in an ASP page, but they contain everything that the component needs to manipulate the database and the OrderForm.       MSCSOpen and MSCSClose are optional functions that can be run before the execution of MSCSExecution and right before the destruction of the object.        Figure 35 shows the code for the OrderMagnitude component. The component executes a database query to find out what categories are defined in the OrderCategories table, then calculates the number of items in the order by simply adding the quantity for each product. Finally, the resulting number is checked again. Each category and the OrderCategory name/value pair in the OrderForm is set to the name of the correct category. If all the checks fail, the OrderCategory parameter is set to "Unknown Category."       The MSCSExecute function must return a value to indicate whether its execution was successful (see Figure 36). Returning a serious error level can result in interrupting the execution of the OPP, while some execution modes tolerate warnings.       A component can also return error messages to the user by storing them in the OrderForm.ShippingErrors and OrderForm.PurchaseErrors collections. Their contents will usually be dumped by the ASP pages of the store when the customer tries to proceed with the purchase. Running and Debugging the OPP       The OrderCategory component is designed to be inserted in the Order Check stage of the OPP. To test the component, I inserted some dummy entries in the products database of the Marco Tabini Store and tried various purchases. As you can see in Figure 37, OrderMagnitude seems to work perfectly.

Figure 37: Checking an Order

As often happens, this wasn't true at the very beginning. No matter how many items were ordered, I always got the same result: the component thought that my orders always had zero items in them and assigned them to the first category.       To solve the problem, I simply had to open up my store's Global.asa file and uncomment the following line that MSCS created for me as a standard part of the store:

REM Call MSCSOrderPipeline.SetLogFile("c:\temp\pipeline.log")

This way, the OPP will log the actions performed by all the components on the OrderForm. A quick look at Figure 38 shows that I had mistyped the word quantity as quntity and I was trying to access a parameter of the OrderForm that obviously didn't exist. Fixing the bug was a breeze, and afterward the component ran just fine.

Figure 38: Logging the Actions

Always remember to turn off the OPP logging by commenting the line in Global.asa again, or you will soon find yourself with a logfile of several megabytes that can easily make your store unusable. Conclusion       MSCS is by all means a very good product. I used it to complete several projects and it rarely let me down. If your company is interested in developing serious EC applications, either as a service provider or for itself, I strongly recommend that you consider adopting MSCS as your frontline solution.       There are still some issues that I would like to see resolved. ASP is still a relatively unstable system, and MSCS seems to be very delicate when it comes to Windows NT security. Although I have not been able to make MSCS run under IIS 4.0 beta 3 yet, I hope that the new version of ASP will significantly increase both the performance and the stability of the platform.       Business-to-business functionality is another important area in which MSCS is deficient. As I mentioned in the introduction, the next version of MSCS will include Commerce Interchange, hopefully providing a uniform interface to the various business standards that are now in use.       Finally, I feel that the model behind the OPP should be modified for more flexible programmability. Execution flow control should be added at a stage and component level, thus letting the developer choose what components are run.       If you are interested, I suggest that you consult the Microsoft white paper on electronic commerce, which can be found at http://www.microsoft.com/commerce. Screenshots taken from Softmania (http://www.softmania.com) are published with the permission of Internet Frontier, Inc.

From the March 1998 issue of Microsoft Interactive Developer.