"Activate the Internet?" What's that mean?
Since the Internet uses quite a collection of technologies, there are lots of ways to make use of the Internet from your applications.
First, some considerations. Always remember that, unless you're writing apps that will only be used on internal "intranets," most users connect at 28.8 Kbps or less. You'll want to take pains to make sure that the data and code you send to your users is as small as possible. Doing so will greatly reduce the pain for your users.)
Dr. GUI recommends making your app an ActiveX document, ActiveX control, or both. If it's an ActiveX document, users will be able to browse in-place and edit your documents using Web browsers, the Nashville Explorer shell, and any other ActiveX document container, such as the Microsoft Binder. When people start using Nashville later this year, apps that aren't ActiveX documents will look old—rather like Win 3.1 apps look today.
If your app is an ActiveX control, users will be able to embed it in Web pages or in any ActiveX control container, such as Visual Basic, Visual C++, Visual FoxPro, or Microsoft Access. This will make your app very usable.
There are other ways to take advantage of the Internet. It's possible to integrate Web browsing capabilities into your app—as TurboTax does—but even tighter integration is possible with ActiveX. Available technologies (and more are coming) allow client/server apps to communicate over the Internet.
There are four basic technologies for providing active components for the Internet: Netscape Plug-ins, Java applets, ActiveX controls, and ActiveX documents.
Netscape claims that you can convert your application to a plug-in in as little as thirty minutes. All you have to do is remove menus and so forth and change all the memory allocation calls to call Navigator's allocator rather than malloc, new, LocalAlloc, or GlobalAlloc. (To be fair, they don't require that you use their memory allocator, but they do recommend it.) Dr. GUI is skeptical about converting an application that quickly. Oh, and plug-ins aren't cross-platform, since they're compiled to native code.
But the real problem arises when you consider the result of that conversion: An app that won't run anywhere except when hosted in a Web browser. That means that the primary user interface and branding your user sees is the Web browser—not your application. In other words, you've converted your branded application into a generic component for another company's Web browser.
Dr. GUI is less than excited about this.