March 1996 How-To Columns

By Eric Carr

The computing development that will have the most significant effect on your life is the commercialization of the Internet. You can accomplish an Internet connection in many ways, but the best way for you may not be the best for someone else. I'll start with the simple methods and move to the more complex connection scenarios.

Next on the map is a look at the tools you can use to explore this vast resource. I've been Windows 95-centric in past months, but the Internet is a different kettle of fish. Vendors are conceiving new Internet applications on a daily basis, and no one vendor can possibly include all the necessary tools for your explorations. So, in future columns I'll branch out and look at tools from different parties, such as gopher, ftp, telnet, Web browsers, Java applications and Internet chat.

First, you must connect to the Internet. Think about how you plan to use it; the Internet-based functions you employ will dictate your bandwidth (or throughput) requirements. Do you need only occasional e-mail access? Do you want to use a Web browser? Maybe host a Web site? Download or upload files? Work on a remote computer? Post and receive messages to newsgroups or list servers? These are a few of the major uses of the Internet today. Tomorrow, who knows?

Character data throughput is normally measured in kilobits per second. You'll also see it measured as kilobaud, or Kbaud. That's 1024 bits (1s and 0s) every second.

Most data is represented by seven or eight bits, and there's some bit housekeeping as well, so you can roughly assume 1Kb per second is equal to 100 characters of data per second.

Base your connection decision on the transmission speed of your link to the Internet and the persistence of the connection. Obviously, if you have a Web server, you'll want to have an Internet presence 24 hours a day, and you might have several hundred people accessing your server at once. For this type of application, you'll need a fast, continuous link to the Internet -- essentially, putting your Web server on the Internet. Contrast this with the need to send/receive e-mail a few times a day.

The connection profile for these two applications is very different. To maintain the Web server, you must be able to transmit and receive hundreds of thousands of bytes every second. To send an occasional e-mail, on the other hand, a few thousand bytes a day will do. Here's a good rule of thumb: For a console session on a remote computer or for e-mail, you'll need a minimum of a 9.6Kbps to 28.8Kbps dial-up connection. For a slow Web server and file downloads, you should have a 56Kbps dedicated connection. A fast Web server will require a 1.544Mb-per-second dedicated connection. But beware: The faster you go, the more it will cost.

In the simplest of cases -- occasional e-mail use -- you don't have to connect to the Internet per se. You can send e-mail through an intermediary service, also known as an online service, that has a mail gateway to the Internet. CompuServe, America Online, Prodigy, the Microsoft Network, GEnie and Delphi are examples of these online services. Most of them offer a variety of transmission rates, up to 28.8 Kbaud. This is sufficient for occasional use (certainly e-mail) and yes, you can use a Web browser at this speed. But the graphical nature of the Web and the size of the graphics images contained therein will make your modem work overtime just trying to keep up. You'll waste plenty of time watching the pictures slowly come in over the wire, too. It's analogous to "Well, you can run Windows 95 in 4MB of memory, but you wouldn't like the results." To use the Web effectively, you need to go faster.

Before you scoff at the idea of using an online service as your gateway to the Internet, consider that online services are inexpensive, starting at $10 per month, and most offer a free trial subscription. They also offer many other features you may find useful, such as chat rooms, news feeds, financial and weather information, extensive file archives, vendor forums and so on.

The benefit of online services is that hardware setup consists solely of your machine, a modem and a phone line. You don't have to worry about assigning IP addresses or exotic hardware (routers, CSUs and DSUs used to maintain a dedicated/near-dedicated Internet connection) or some hacker breaking into your system. You also don't have to deal with any special configuration to Windows 95 for Internet access. And, unlike services that provide you with dial-up access to a UNIX box, the online services have interfaces that are much easier to learn than a slew of UNIX commands (many of which don't have vowels). UNIX is incredibly powerful, but it's not for everyone.

Although setups vary, most services include communication software. If they don't, you can use the Windows 95 Terminal applet and your modem to connect to the remote service. It's that simple. If these services meet your needs, they represent the best way for you to connect to the Internet.

By John D. Ruley

If you've surfed the World Wide Web, you've seen Perl. Almost anytime you hit a Web page that does something interesting -- such as providing a query interface -- there's a Perl script in the background doing most of the work. Perl is a sophisticated interpreted script language originally developed for UNIX systems. It's now available for NT, and it's included on the 3.51 Resource Kit CD (in the RESKIT\PERL directory).

A word of warning: Perl is a full-blown programming environment. Don't expect to sit down with the Resource Kit and start writing system scripts the same day. I've been programming in various languages for 18 years, yet I'm a novice at Perl. If you have Web access (forget Perl if you don't because the documentation is provided via Web pages), you'll find a wealth of information at www.metronet.com/perlinfo/, including a pretty good FAQ file. You'll also find a list of books and magazine articles, and a large archive of sample scripts.

Perl's not the only scripting language included with the new Resource Kit. One of IBM's main selling points with OS/2 is REXX, an advanced interpreted scripting language with many of the same capabilities as Perl. Microsoft wisely chose not to force Perl down everyone's throat, and instead included a REXX port (Ataman Software) along with Perl on the 3.51 Resource Kit.

The Resource Kit update also includes a slew of new utility software. (For a rundown, check out my NTQA02.ZIP file in WinMag's America Online, CompuServe or ftp software libraries.)

What really surprised me in the software grab bag was a comparatively trivial utility called INET.EXE. In my days as an OS/2 LAN Manager system administrator, all network functions were performed using the NET.EXE command-line interface. I still tend to use it, so when I discovered INET.EXE, I almost fell out of my chair: It's a variant of NET.EXE that works over the Internet. For example, inet use x: \\ftp.microsoft.com \data turns Microsoft's Internet ftp server into a network drive. If you have STP, it can be a folder on your desktop. This may not seem like much, but think of the implications. While you're at it, review the rest of this column, in which I mention one Internet-related utility after another. Get the feeling Microsoft may be up to something?

For months now, we've heard rumors about Microsoft taking a big position on the Internet. In December, the company made it official. Here's the news for NT users: Microsoft will provide a plug-in upgrade to both Win95 and NT next year that integrates Web browsing capabilities with the Explorer desktop. Internet sites become icons and folders -- essentially identical to local resources -- and you can browse local resources using a Web-page-style view. Microsoft has also promised equivalent capabilities for Windows 3.x and Macintosh client systems. All you need to do is download them. And Microsoft's new Internet Information Server (IIS), formerly known by the code name Gibraltar, will come bundled with the next version of NT Server. By the time you read this, a version of IIS for NT Server 3.51 should be downloadable from Microsoft's Internet site or available on CD for a nominal fee.

IIS is easy to set up. It took me less than 15 minutes, and I'd never run a Web server. It also comes with predefined sample pages, so there's no guesswork about whether you set it up properly. And it has nice, built-in database support (using 32-bit ODBC drivers). I got a set of demo queries working with Microsoft SQL Server in another 10 minutes. It includes sophisticated management tools for supporting anything from a completely secure in-house Web (using Secure Sockets Layer encryption) to anonymous-only Internet access. And it's all in a single box, nicely shrink-wrapped and well documented.

If you weren't planning to set up a Web site, this probably strikes you as not very important. Au contraire! Think through the combination: free Web browsing software included with Win95 and NT, or available for the price of one download for Windows 3.x and Macintosh, and free Web server software (with NT Server). This makes NT the first network operating system to offer built-in intranet (or private Web) support. You can make your in-house network as easy to browse as the Internet.

I have to give Microsoft the "brilliant" nod this month for integrating Web support into NT. That's nothing but good news for NT users.

In the bogus department, Adobe gets a Bronx cheer. A few weeks before I wrote this column, WINDOWS Magazine got a letter from a disgusted reader who'd bought PageMaker 6.0, which has the Windows 95 logo. The reader believed Microsoft's propaganda about Windows 95 logo-compliant applications supporting NT. When he tried it under NT, it worked but he had some printing problems. When he called Adobe for support, he was told, "We don't support Windows NT."

When I confronted Microsoft's NT Workstation group product manager Megan Bliss about this, she told me, "We obviously have some work to do with Adobe." That's an understatement! Bottom line: Do not buy a Win95-logoed application to use with NT unless you've checked with the vendor to be sure the app supports NT.

And now a few words for Adobe. It boggles my mind that the inventors of PostScript can't get their act together on NT. They announced an NT port of Adobe Type Manager in 1993. It has yet to ship. In a word: Pathetic.

Ever since NT came out, NetWare supervisors and other planners have scratched their heads trying to decide how much RAM and hard disk space they need for a given-size network. Well, scratch no more! Microsoft finally has a set of guidelines. Like so much else this month, they're on the Web. Check out http: //www.microsoft.com/NTServer/plandeploy.htm.

Don't have Web access? Get it!

By Martin Heller

IN 1797, THE U.S. government had a problem: War with France was looming, and the two national armories had produced only 1,000 muskets in three years. The government invited bids for 40,000 muskets, but received bids for only 30,000. Why so few? Because in 25 of the 26 bids submitted, each musket would be handmade by a skilled gunsmith. If such a musket broke, a replacement part would have to be cut to fit that specific musket.

The 26th bidder was Eli Whitney, whom you may remember as the inventor of the cotton gin. Whitney also invented machine tools, with which he proposed to have semiskilled machinists fabricate standardized, interchangeable parts for 10,000 muskets in two years. In reality it took him more than 10 years to deliver his 10,000 muskets, but his system worked. In 1801 in front of President-elect Thomas Jefferson, Whitney's people randomly picked parts from piles and assembled complete working muskets.

I'm not the first to liken today's software developers to early 19th-century gunsmiths. We laboriously write each function to fit the others in order to form a complete, working application. We sometimes work to specification, but we're notorious for doing things our way "because it's better." The only thing we mass-produce are finished application disks.

I'm in no hurry for the software equivalent of the industrial revolution. I find it very satisfying to design and build each part, as well as entire programs, by hand. But most software shops can't compete because they desperately need new tools and methodologies.

I've heard lots of promises, but so far I haven't seen any big payoffs. Remember structured programming? Proving programs correct? Remember how object-oriented programming was going to change our lives? Has any of it happened for you?

As a measure of where you are, consider how much internal code you reuse in your shop. Probably not a lot, because it isn't easy writing reusable code. On the other hand, you probably use some third-party libraries, custom controls and class libraries, because vendors sell lots of them. It's easier to buy reusable parts than to reorganize to make them yourself.

OLE and COM (Component Object Model) are two technologies that claim to enable interchangeable software parts. The COM layer provides communications for an interface; OLE builds on COM by adding a lot of other functionality. This month I'd like to discuss COM.

Microsoft has underscored the importance of COM by using it for the interface to the DirectX Game APIs. The company also plans to deliver a new COM implementation that works over a network, and will use COM as the underpinning of all its future information superhighway technology.

Does COM really give you interchangeable parts? It's a start, but COM (or anything else that serves the same function) is to software components what dimensions and tolerances are to interchangeable mechanical parts: necessary but not sufficient.

COM gives software components a way to identify themselves uniquely, present their capabilities and interfaces, and exchange information. It's an extension of the Open Software Foundation's Distributed Computing Environment/Remote Procedure Call (DCE/RPC) specification, and as such is system-independent.

COM defines a base class for all objects IUnknown, from which all COM-compatible classes, or "interfaces," are derived. IUnknown has three required methods: AddRef, Release and QueryInterface. AddRef and Release control memory management for a COM object and implement a reference counting scheme that allows the management of multiple references to a single object. Programs that want to use a COM object first call AddRef either explicitly or implicitly. When they're done, they call Release. When the object's reference count drops to zero, it deletes itself.

QueryInterface lets you get at a COM object's useful parts. As I mentioned earlier, COM gives software components a way to identify themselves uniquely. The IID is a 128-bit number that uniquely identifies each interface of a software component. Given an IID, QueryInterface returns a pointer to the interface object requested, through which the client application can then call the object's methods. QueryInterface also calls AddRef, so it's common to see QueryInterface and Release bracketing calls to COM object methods.

When you call QueryInterface, you do so through pUnknown, a pointer to an IUnknown object, also called

an unknown. How do you get one of those? Is this a chicken-and-egg problem?

Not really, although it does feel that way sometimes. For starters, you need to initialize the COM library with CoInitialize. Then you can create an object using CoCreateInstance. This takes five parameters: a reference to a CLSID, a pointer to the controlling unknown if the object will be part of an aggregate (I'll get to that in a minute), a set of flags that control the context in which the object will be allowed to run, a reference to an IID and a pointer to a location into which CoCreateInstance can return the interface pointer.

The CLSID is a globally unique 128-bit class identifier for the object you want to create. It's stored in the system Registry where OLE, the system and programs can look it up as needed. Registering the CLSID is part of the start-up overhead of all COM servers, and therefore all OLE servers.

Because IUnknown is standard, you'd expect it to be implemented somewhere in MFC (Microsoft Foundation Class), and you'd be right. It resides primarily in the CCmdTarget class, using a helper class CInnerUnknown derived from IUnknown. You'll find the relevant MFC source code in OLEUNK.CPP.

MFC's implementation of IUnknown has a couple of twists. One is the additional concept of interface maps, implemented along the lines of message maps. The other is aggregation support, which allows COM objects to rely on objects they contain to supply some of their interfaces. In other words, aggregation allows COM objects to reuse code by calling other COM objects to do some of their work.

Interface map support is built into CCmdTarget, so to make an MFC class that supports COM, you should derive from CCmdTarget or one of its descendants. Then you can use a number of macros to simplify your definition and implementation. Among other things, the macros automatically declare AddRef, Release and QueryInterface for each object. You do have to implement these functions, but the implementations can be two-liners that invoke the METHOD_PROLOGUE macro and then the CCmdTarget implementation ExternalAddRef, ExternalRelease or ExternalQueryInterface.

Interface maps give you a reasonable way to declare nested COM classes and inherit interfaces from other classes. They also enable you to support aggregation in your COM objects.

Aggregation is a complicated subject that I'll try to simplify. You'll recall that one of the parameters to CoCreateInstance (and to IClassFactory: : CreateInstance) is a pointer to the controlling unknown, if the object will be part of an aggregate. This concept of a controlling unknown is the key to aggregation.

Suppose you have an object that's a specialized version of another object. In other words, suppose you want to reuse another object's code. You would create the other object "inside" and tell it you're doing so by passing it your IUnknown pointer, which it then treats as its "outer unknown." Its own IUnknown pointer becomes its "inner unknown." Thereafter the outer object can return the inner object's interface pointers as though they were its own, and the inner object knows to use the outer object's QueryInterface, AddRef and Release functions rather than its own. So, the aggregate appears to the outside world as though it were a single object.

The INTERFACE_AGGREGATE macro simplifies the implementation of all this in an MFC class. It's used in the interface map after all the native INTERFACE_PART lines, and refers to a member variable that holds the inner unknown -- the pointer to the aggregate object. When you've used INTERFACE_AGGREGATE and the inner unknown pointer is non-null, the framework knows to do the right thing about calling the inner object's QueryInterface method whenever the outer object requests but doesn't recognize an IID. You'd make the inner unknown pointer non-null by calling CoCreateInstance with an IID of IID_IUnknown to create the aggregate object and store the pointer returned in the member variable. You'd usually do that in your class' override of CCmdTarget: : OnCreateAggregates.

It's not simple, but it is elegant. Just imagine the possibilities for code reuse at the compiled object level. Think about how this allows you to use parts interchangeably. Eli Whitney would be proud.