For example, my article on SoftRAM95 contains over 100 links to information on the Internet, and embeds a stock-quote application running on another machine. Thanks to DejaNews, I can list every newsgroup message posted by a particular person, and then -- and this is the clincher -- link to that listing (Click here for an example; on the other hand, this URL once changed out from under me, and that too is an important fact of web life). I got tired of telling people where to buy my book, so now I just have a link to an online order form at amazon.com, who cleverly have made their entire catalog directly linkable via the ISBN number, like this. (I'm in the process of building an online "bookstore" based on amazon.com's "associates program.") Readers can register with the URL-minder to receive email about updates to my web pages. A web counter -- running on another machine -- produces a GIF file that tells how many times one of my pages has been accessed.
A stock-quote server, a newsgroup search engine, and online book order forms, a reminder server, an access counter: these are all applications. PC developers are used to thinking of "killer apps" like Word and Excel as applications, but services like the URL-minder, Book Stacks, and DejaNews, are applications too: Common Gateway Interface (CGI) scripts, running on some other machine, which -- thanks to the ridiculously simple <FORM> statement in HTML -- you can link to and embed into your document. And if "link to and embed" sounds like OLE, but much simpler than OLE, that's good. Just as the network is the computer, the document is now a progam.
It's important to realize that this ability to combine multiple programs in a single document exists today; the web sites you access probably use it all the time. CGI and perl are the glue that hold this distributed computation together. While Java is important, and possibly crucial to the next phase of the web, it's important to remember that web in many ways today is already "active." Code runs on the web server, not the client, but in some ways this is a bandwidth issue.
At any rate, web applications are becoming increasingly important, while standalone monolithic apps like WinWord, Excel, and PowerPoint are becoming less interesting. HTML is the crucial document format now (even Microsoft recognizes this, with its plan to make HTML the basis for its "Nashville" integrated shell).
As another example of the new type of application, consider the NYNEX Yellow Pages, which are now online. It's easy to forsee the Yellow Pages becoming a new interface to the web, similar to Yahoo but much more extensive. This is not just some online database, but a major new application. This shift -- the merging of network and computer, of content and program, of software development and online publishing -- requires a major change of focus by developers.
But look again at that statement, "most important single development." Microsoft had almost nothing to do with this most important single development! It was largely surprised by it. Well okay, Microsoft and Intel are largely responsible for the huge number of cheap, powerful PCs that exist, and something like 75% of all Web access comes from these Wintel machines, and the Winsock API is used by all the major web browsers for Windows, and Win95 includes a bundled-in TCP/IP stack.
But this is all plumbing, and few would deny that Microsoft is pretty good at plumbing. As for the web itself, Microsoft until quite recently just wished it would go away; Microsoft was focusing on its proprietary Microsoft Network (MSN). Now Microsoft is trying to catch up, in an area that moves much faster than MS's typical two-year product cycles.
On the one hand, recall that this isn't the first time Microsoft has trailed behind the real world, trying to play catch up. Microsoft in fact is very good at catch up. There's an interesting business book by Steven P. Schnaars, Managing Imitation Strategies: How Later Entrants Seize Markets from Pioneers (Macmillan Free Press, 1994); you won't be surprised to hear that Microsoft figures prominently among the 28 case studies in this book.
So, even if Microsoft has failed in the leadership business (look at OS/2), it has succeeded brilliantly in overtaking leaders (look at how MS-DOS overtook CP/M, how Excel overtook Lotus 1-2-3, how Windows overtook the Mac). Meanwhile, it's not as if Netscape has been flawless (its implementation of JavaScript, to take one example, has serious problems).
And Microsoft has one key advantage: its ownership of Windows. While Netscape and Microsoft will compete head-to-head on web features -- and users and developers will benefit from this competition -- it will be difficult for Netscape to compete with Microsoft's planned integration of the web browser with the "Nashville" shell. Microsoft can leverage its control of the operating system to attempt to wrest control of the web.
In fact, the conventional wisdom is that "Microsoft will integrate its web browser into the operating system, and that will be that. When that happens, Netscape is toast."
But I'm not so sure. Microsoft will put its web browser into the next version of Windows, and then we'll wait for large numbers of users to upgrade, or for large numbers of machines preloaded with that version of Windows to be sold.
Remember, the Microsoft Internet Explorer (MSIE) today is free, yet MSIE has at best 10% market share. Netscape has actually been making money by selling web browsers. One reason, I think, is that Netscape is much more focused on Windows 3.1 -- where most customers still are -- than Microsoft is.
This is an important point. Often Unix advocates whine that Microsoft's solutions are "not portable." But with 80% or more market share, they don't need to be any more portable than they are. By relying on the Windows API, you have the vast majority of machines taken care of. Yet, Microsoft no longer has a Windows strategy; it has a Win32 strategy. It is pushing Win95 and WinNT; these still account for a small percentage of Windows PCs. This will change over time, obviously, but right now Netscape is better able to serve all those Windows 3.1 and 3.11 customers.
Another key advantage Microsoft has is money, a lot of money, to fund its attempt to catch up to the web. It can give MSIE away for free ("Why pay $50 for Netscape's browser when you can get a great browser that's free?" asks the MSIE home page). But while this raises some interesting antitrust issues, the fact is that IBM also had money to burn at one point. Money can't -- at least not by itself -- buy you love.
Now, a Microsoft document on Creating Platforms for Innovative Internet Software (March 1996) says that "Standards Are the Key to the Internet's Success. The force behind the success and power of the Internet is, quite simply, standards." Given Microsoft's reputation in the area of standards, it is not surprising that this overview devotes a section to "Microsoft's View of Standards": "So the natural question is: How is Microsoft going to participate in this world created and based on standards?"
Unfortunately, Microsoft gives only a very vague answer to this excellent question. But one clue is its reference to MSIE as "Microsoft's standards-based Internet browser application."
MSIE provides a useful clue to Microsoft's view of standards, because both MSIE versions 1 and 2 make heavy use of undocumented Win95 functions provided by SHELL32.DLL. So does MSN and the rest of the "Windows 95 Internet Jumpstart Kit." According to Netscape chairman Jim Clark, when Netscape asked Microsoft for information about undocumented Win95 APIs, Microsoft in return asked for a 20% stake in Netscape (Reuters, September 27, 1995)! Is this what Microsoft means by "standards-based"?
The best way to start answering this question is to quote from a new (1995) Microsoft Press book, Programming the Windows 95 User Interface by Nancy Winnick Cluts, a writer with the Microsoft Developer Network. This book is largely a description of the interfaces provided by SHELL32.DLL. According to the Introduction (p. xv):
"Microsoft Windows 95 sports an exciting new user interface, redesigned to make it easier and faster for both beginners and power users to get their work done. But there's even better news for developers: you can incorporate the new functionality that has been implemented for this interface in your own applications.
"No longer will a developer have to reverse-engineer a control used in the interface - the software development kit now contains the controls. No longer will a developer need to find a third party to add support for long filenames - the operating system itself now permits long filenames. No longer will a developer have to figure out some way to hack into the interface code - extensibility is now built in."
This promise that independent software vendors (ISVs) no longer need reverse-engineer or "hack into" the Windows user interface is significant on several counts. It is an acknowledgment, first off, that in the past ISVs have had to do this. Second, it would seem (if one's not reading too much into what may be casually-made statement) to condone the common practice of reverse-engineering Microsoft code in order to reveal undocumented APIs. But third, it appears to maintain that Microsoft now, in contrast to the past, provides everything ISVs need to write applications that integrate well with the Windows shell.
The Microsoft Press book for the most part documents various APIs
provided by SHELL32.DLL in Windows 95. As noted on p. 265, when using
SHELL32.DLL, developers must include the SHELLAPI.H header file. This
file documents a little over forty different shell APIs (find
"WINSHELLAPI" \msvc32\include\shellapi.h | wc).
But meanwhile, SHELL32.DLL exports many unnamed APIs. These are not included in SHELLAPI.H, nor are they discussed in the Microsoft Press book, nor do they seem to appear anywhere in the MSDN, despite extensive searching by many developers interested in the undocumented "Name Space" or "Virtual Folders" interface provided by SHELL32.DLL (see Mark Hughes's pages of information on extending the Windows 95 shell "name space").
So it is simply not true that ISVs no longer have to reverse engineer or "hack into" the Windows shell in order to figure out how to best integrate applications with the shell: see Mark Hughes' pages for messages from typical third-party developers trying to reverse-engineer this information.
At the same time, it is well known that Netscape too has undocumented interfaces. As one example, Microsoft has complained that Netscape won't document how to host Netscape plug-ins.
Apparently, some of the APIs requested by Netscape, such as the Phone Book API, have been subsequently documented -- after Microsoft had a nice head start. A Microsoft document on the previously-undocumented ("b-list" as Microsoft calls it) "Windows 95 Explorer Name Space Extension Mechanism" is planned to appear on the April 1996 MSDN. And in the MSIE 3.0 alpha, MSIE is just tiny shell around SHDOCVW.DLL, the "Shell extension DLL for DocView host," which in turn relies on undocumented SHELL32 APIs. We can assume SHDOCVW.DLL will be documented, but in the meantime Microsoft again has used undocumented interfaces to give itself a nice head start over ISVs.
When Microsoft says that it going to fully participate in the web standards process, it is also worth remembering that Microsoft has for years maintained that its Windows API is already an open standard. For example, here's Brad Silverberg again (formerly VP in charge of Windows and DOS, and now in charge of Microsoft's Internet strategy), quoted in the somewhat fawning book by Michael A. Cusumano and Richard W. Selby, Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People (Free Press, 1995, p. 168):
"But once you have those interfaces, you're pretty much locked. You can't just change them and break applications. A system like we have, we don't own it; the ISVs [independent software vendors] own it."Now, Brad's a nice guy and everything, but if he thinks that ISVs rather than Microsoft own the Windows API, you sort of have to wonder how he intends to adapt to the web "world created and based on standards."
(The Microsoft Secrets book, unfortunately, really isn't all that useful. See Ron Burk's review from Window's Developers Journal. As Burk points outs, the authors just accepted at face value what Microsoft officials such as Brad Silverberg told them. If you want a good book on Microsoft history and business practices, I suggest Gates by Stephen Manes and Paul Andrews.)
For developers, the real question is not whether Microsoft "wins," or "Netscape" wins, but what sort of applications you want to write, what sort of API you want to be using, and where you want to look for direction.
For years, the answer was simple: the Windows API, then Win32. There was little point to alternatives such as OS/2; even long-time Mac developers were writing to the Windows API. You went to a Microsoft developer's conference every year, subscribed to Microsoft Systems Journal, subscribed to the Microsoft Development Network (MSDN) CD-ROMs, got the latest Microsoft software development kits (SDKs), and you knew where you were headed for the next year or so.
Now, it's not so simple. If you had been looking to Microsoft for direction, the explosion of the web would have until just a few months ago have passed you by. While Microsoft was holding its conferences, putting out MSJ, issuing new SDKs, the real world had a different agenda. The web exploded, without any direction (and without much notice) from Microsoft. With this track record, do you really want to look to Microsoft for future directions?
The fact is that Microsoft no longer solely sets the agenda for the PC software industry. It once did. There is now, for the first time in about five years, genuine competition in the systems software business: which means genuine competition over APIs. And Netscape, while at least as annoying a company to deal with as Microsoft, has at least been in the forefront of the web explosion.
So sure, attend the Microsoft conferences, keep reading MSJ, keep getting the MSDN. But don't mistake Microsoft's "vision," or any single vendor's "vision," for reality.
In particular, it's worth remembering that the web exploded thanks to a few very simple standards. The ability of URLs such as http://xxx, ftp://xxx, gopher://xxx, telnet://xxx, and even file:///xxx to unify previously disparate services is one example. The ability to create worldwide hyperdocuments with a few simple HTML tags like <A HREF>, <IMG SRC>, and <FORM ACTION> is another. The standard was stretched, for sure (the <IMG> tag hack created by Netscape's Marc Andreesen is widely regarded as having fueled the explosion of the web), and one wishes HTML had been kept consistent with SGML, but definitely HTML, HTTP, MIME, CGI, and so on, are the right sort of solution, compared with the OLE beast.
Microsoft's latest solution to the web is "ActiveX." This, unfortunately, feels like another overly-complex solution like OLE. It's not clear how real ActiveX can be, without support for Windows 3.1, and without active support from Netscape (NCompass does have a Netscape plug-in that supports OLE: this plug-in seems to be the key to any hope ActiveX has of becoming important).
And even if ActiveX is the answer, it's not clear what the question is. What is the problem that ActiveX is a solution to? Telling developers to "activate the Internet" (Microsoft's latest slogan) sounds like encouragement to go off and do more superficially-exciting pages, with less emphasis on content. Yet what the web needs most is more and more content (major apps like the NYNEX Yellow Pages), and easier ways to find it. What most web users want is "information at your fingertips," not Microsoft's apparent vision for "scrolling marquees at your fingertips" (or even Sun's "tumbling dukes at your fingertips"). It's the content, stupid!
With compilers that today come on multiple CD-ROMs, whereas fairly nice compilers not so long ago fit on a single floppy, have we really made progress under Microsoft's reign? Many developers feel instinctively that we took a wrong turn about five years ago: we've made a lot of progress, but not entirely in the right direction. Software has become bigger, and more complex, and users ignore 95% of the new features we spend so much time on. It would be nice if one side-effect of the web were to get us back on track.