MSDN Interview
July 15, 1998
With Visual J++™ 6.0, Microsoft will try to bridge the gap between Web development and the classic programming framework most developers are used to having in their tools. To learn how Visual J++ 6.0 and the new Windows® Foundation Classes (WFC) in Visual J++ 6.0 will bring these two models together and make developers more productive, MSDN went straight to source: one of the key developers who helped create Visual J++ 6.0.
As Microsoft Visual Tools development manager Victor Stone explains in this interview with MSDN Online's John Swenson, Visual J++ 6.0 and WFC will make it easier to build n-tier, Internet-standard applications able to run on the Web or within Windows.
Victor Stone is a development manager in the Microsoft® Visual Studio® tools group, where he's currently focused on Visual J++ and the Windows Foundation Classes. Since joining Microsoft four years ago, he has worked as a developer and "technical catalyst" on a wide variety of Microsoft products and technologies, including interactive TV, Internet Explorer, Java Virtual Machine, and scripting languages. Before joining Microsoft, Stone was an architect and developer at Borland International and Peter Norton Computing.
MSDN: Can you briefly define this new framework that Microsoft created—the Windows Foundation Classes in Visual J++ 6.0?
Stone: WFC is a set of Java packages for dealing with different parts of the operating system. At the lower level, for example, there's data access through ADO wrappers, file I/O, utility classes that provide clipboard support, and other application type objects.
There are two user interface packages. One encapsulates the traditional Win32 GDI parts of the operating system. The other encapsulates HTML on the client and the server. With Visual J++ 6.0, developers only have to think about what it's like to program against WFC. They can take that very strong component architecture and apply it to any of the subsystems in Windows.
MSDN: Why did Microsoft decide to create the Windows Foundation Classes in the first place?
Stone: We looked at the Web and saw that something is missing. What's missing is what most developers understand today, a classic kind of programmer's framework. We asked ourselves, "Why don't we take the application model that's the Web, with it's great new features, specifically HTML for content and HTTP for delivery, and apply what's missing?"
If you look at Visual Basic, Delphi, and MFC [Microsoft Foundation Classes], you see that the most popular coding tools today are these frameworks. But the Web really doesn't have a framework for developers. There's DHTML, but that's really geared at scripters, typographers, artists, and layout people.
There really isn't a sort of classic programming framework to go up against the Web and HTML. There's no reason why there isn't. There are some technical issues with today's frameworks, such as MFC, that make their use on the Web somewhat prohibited. But the idea of a programming model like a framework for the Web—there was no technical reason why we couldn't create one. So we did.
MSDN: You obviously are targeting developers with this technology.
Stone: Yes. Developers, coders.
MSDN: Not HTML experts, UI experts, or Web designers?
Stone: No. The Web shops we talked with have cordoned off their artists and developers into somewhat separate camps. It was very important to us that we accommodate this type of shop, where a section of artists do the HTML layout and GUI design, and a section of developers attach code to the user interface. We spent a fair amount of time thinking and implementing this scenario.
With Visual J++ 6.0, an artist can create a page with their favorite GUI HTML tool—FrontPage, NotePad, or whatever. Then a developer can load that page directly into Visual J++ and start coding against it with minimal setup or importing. We're very non-obtrusive to the original artist's work. All we do is we add IDs into the page. We really leave the original art alone.
We wanted to keep a distance between people who code for a living and people who actually have an eye for typography and design. Developers are not very good at UI design, and we just keep proving it time and time again [grins].
MSDN: It's interesting to hear you use the term artists for the people who create the GUI for Web pages and Web applications.
Stone: You bet. Typographers, artists, and designers. Go look at the Web. Look at the pages being designed today. They aren't being done by propeller-head geeks.
Some of our most recent hires into Tools [the Microsoft Developer Tools Group] are artists. We actually have teams of artists that we never had before, working on our developer products.
MSDN: The Visual J++ team talks a lot about unifying the Win32 and Dynamic HTML programming models. Can you describe the vision behind this?
Stone: By unifying these models, we reduce the number of disciplines you need to understand in order to create the kind of Windows DNA [Distributed interNet Applications] applications we're advising developers to build. In other words, rather than require one discipline for building Win 32 applications and another for building Web applications, we see Visual J++ 6.0 and WFC as the first step toward merging them together, so developers don't have to split their energies and time between the two disciplines.
We've been talking for a long time about melding Web technologies directly into Windows. This is really the first indication of how we plan to do that with our tools.
MSDN: Can you talk about today's Web application model, and how it really doesn't synchronize with the traditional developer programming model?
Stone: The Web sprung up with a bunch of paradigms that the Windows API didn't really address. MFC, Delphi, and Visual Basic didn't address them very well either.
A lot of the application model of the Web came from layout artists and typesetting people creating very thin, tiny client/server applications. Scripting and HTML were a natural evolution of that.
Many core assets used by Win32 developers were not initially applied to the Web. Core assets like frameworks with derivation and extensibility, also properties, methods, events, and all those early-bound compiler technologies. These were not applied to the Web programming model.
It didn't take us long to look at the situation of Web client/server applications and ask "Why can't we just program like we've been programming for the last five or ten years, using the same frameworks?"
When we set out to build Visual J++ 6.0, we started with a component architecture that we called the WFC component architecture. When we began creating this, we thought first and foremost about programmer productivity. There really was no other attribute in our priorities that superseded programmer productivity.
We took all the different subsystems we could think of that would be useful for developing enterprise applications and put them against that component model. That included both the Win 32 and the Web stuff. By thinking of the component model first and the technology second, this gave us a strong foundation for unifying everything.
MSDN: What are the benefits of developers using the new Web application model that comes with Visual J++ 6.0?
Stone: Java grew up on the Internet, but it's still not perfect for the Internet. Having grown up around HTML and HTPP technologies, Java has inherited some of their qualities. Java developers expect a certain amount of "Webness" in their applications. I think we hit a sweet spot with Visual J++ 6.0 by targeting the mix of Win32 and the Web.
MSDN: If I'm a developer using Visual J++ 6.0 and WFC, do I have to learn HTML tags and other Web-centric UI design elements?
Stone: No. Until now there's been a strong corollary between a developers' HTML knowledge and how good their Web site looked and worked. We didn't totally eliminate the corollary, but we've reduced it dramatically. We don't think developers who are basically coders should have to learn typography to continue being professional developers. They shouldn't have to become grandiose UI artists with great UI layout abilities.
Developers still should know some HTML, depending on the complexity of their Web sites and pages. But they don't have to be an HTML expert to use WFC on their Web sites.
MSDN: So are Visual J++ 6.0 and WFC tools for building Web sites or applications?
Stone: We see them as tools for building enterprise applications. That's why we don't have classes for drop caps and kerning and typography elements like that. I used to work at a typesetting software company, so I have a pretty good understanding of what it takes to do that. We actually ignored all that stuff. We don't even have a paragraph object.
We really don't do any HTML stuff. We are not a replacement for GUI editors. I can't stress this enough in my talks. I didn't stress this in the earlier talks and that was a mistake, because people who heard me thought "Why would I create all my HTML by writing Java code?"
That seemed convoluted to them, and it is convoluted. We don't want you to do that. We want you to create HTML the same way you've always done it, but write your code and logic using a familiar developer paradigm, our component frameworks.
MSDN: Can developers use Visual J++ 6.0 and Visual Basic 6.0 together? Does that make sense?
Stone: For building a classic Windows DNA app, I think they're a pretty good pair. We spent a fair amount of time thinking about how Visual J++ 6.0 and Visual Basic 6.0 would work together, and in fact how all of Visual Studio 6.0 would work together, including Visual InterDev 6.0 and Visual C++ 6.0.
The new Web features of Visual Basic 6.0 are a particularly good match with Visual J++ 6.0 because they cover parts of the Web server programming model that Visual J++ doesn't, while Visual J++ covers areas that Visual Basic doesn't.
If you think about WebClasses, at their core they put code behind a URL. That doesn't happen in the WFC framework. On the other hand, Visual J++ objectifies HTML. That's something that doesn't happen in WebClasses and Visual Basic.
(Editor's Note: WebClasses are a new feature of Visual Basic 6.0. For information about them, see the MSDN interview with Visual Basic architect David Stutz, "David Stutz on WebClasses and Other New Features in Visual Basic 6.0.")
Because all the Visual Studio tools are based on COM, any of these components can interoperate. So the tools are a natural fit, depending on your scenario and what kind of app you're trying to target.
MSDN: What are WFC HTML classes?
Stone: It's a set of classes in the WFC.HTML package that ships as part of the core runtime with WFC. These classes encapsulate HTML usage on the client and the server. The way Java works is you have package names that developers use to identify what sort of libraries they're going to use. So WFC.HTML is the name of the library.
MSDN: Does WFC HTML support HTTP post and get?
Stone: One important thing to understand about WFC packages is that they don't enhance the current architecture of the platform when it comes to the Web. For example, you still use session and page and the typical ASP [Active Server Pages] objects on the server. You still use frame sets and Internet Explorer on the client for your Web architecture.
We just expose the HTTP functionality of those environments. What we've really done is simplify access to the existing HTTP architecture that's already in the platform. We don't enhance that in any other way, like we do the unification of client and server programming models.
MSDN: You've mentioned Internet Explorer several times. How well do applications developed with WFC run in Netscape and other non-Microsoft browsers?
Stone: With WFC, your Web site looks the same to the browser as it would without WFC. We add Java to the back end of the site, but the front end looks the same. You still have HTML on the client. You still have HTTP communication. There's nothing different about your site. Users of any browser don't know that you have WFC on the back end.
The important difference is that, with WFC, ASP now becomes two pieces. We want to separate completely the logic that programmers deal with from the GUI pages, which is very hard to do today using script.
Using WFC on Microsoft Internet Information Server (IIS) or offline with some other server, you can target what we call the "reach scenario." This lets you reach older Netscape browsers, older IE browsers, WebTV, and Windows CE browsers. It also works with the Opera browser, a popular lightweight browser that runs great on Windows. We actually tested the Opera browser in some of our server scenarios.
MSDN: What platform does WFC require for the server?
Stone: When you're running our Java code we require Windows NT on the server.
But we try to be very "host independent" with WFC. In other words, we let you host these classes in Internet Explorer on the client, in IIS on the server, or in basically any COM environment. These classes allow developers to continue using the paradigms they're used to—the coding paradigms of classic framework development. They can derive from classes and override constructors and virtual methods. WFC keeps developers in that classic programming world while also targeting a "pure Web scenario," or if they prefer, a richer DHTML experience.
MSDN: Where does Dynamic HTML fit in with WFC?
Stone: DHTML is the first step to making HTML look like what developers want it to look like, which is a set of functions to call. At the end of the day, what developers really want is an API. The number one question they ask as they're learning a new library is "What's the name of the function I call?"
DHTML is the first step toward that. We leapfrog it all with WFC by telling developers, "Just write some code in this framework. Oh, and by the way, we generate HTML." We let developers look at combo boxes, list boxes, edit boxes, and all the other things that are familiar to them, like properties, methods, and events. It's a really familiar paradigm for developers.
MSDN: What are the benefits of using WFC on the server as opposed to simply scripting ASP pages?
Stone: There are different usage scenarios for WFC. We think script will continue to be super important on the Web. It may remain the most important use of programming on the Web for a long, long time.
However, there's a community of developers who don't feel comfortable in script. They want early binding. Their projects are huge. The have tens of thousands or even hundreds of thousands of lines of code that they don't feel comfortable using script for. They want components—real, hard-boiled, reusable, packageable components they can use in traditional DLL binaries, class files, CAB files, or whatever packaging mechanism allows them to create slick applications. These people consider themselves professional developers. They write code that other coders use.
If you're going to reuse a lot of code in these libraries and other deliverables, you really want a "professional, traditional, development environment" that can target that scenario. We think WFC is a great first step in that direction. WFC and WebClasses are the first two steps along that way.
MSDN: Does that mean Visual J++ is moving upscale to higher-end developers in version 6.0?
Stone: Well, Java is a relatively sophisticated language. Especially compared to the warmth and fuzziness of VBScript, which is what most ASP pages use today. Compare script to the idea of inheritance, threads, exceptions, strict type safety, early bound linkage, and all of those other things developers need. Not that script writers don't need them too, per se, but they're not quite at the level of, say, a C++ ATL developer.
MSDN: Do you envision WFC as a replacement for CGI?
Stone: I don't have a crystal ball. It's hard for me to sit here and predict numbers. Again, I think it depends on what environments people are used to. If you come at the Web from a scripting environment or a batch kind of environment, then you'll probably stick with CGI. But a huge number of Visual Studio developers are not used to coding that way.
We're trying to help them target Windows DNA applications. We think it's natural for them to use WFC. We think it's natural for Visual Basic developers to go with WebClasses.
MSDN: What types of applications does WFC enable that were hard to build until now?
Stone: Hard is a subjective term, but I think WFC hits the sweet spot for developers who have struggled with the differences between HTML, script, compiled code, server, client, Win32, and so forth. These are all fundamentally disparate ways of creating pieces of a larger Windows DNA application.
WFC simplifies this by giving developers one centralized way of thinking about their entire application. It even lets them reuse pieces of their code, depending on whether they're using Win32 on the client or a "reach scenario" client/server. We've unified the programming model across all those disparate paradigms.
MSDN: There's been a lot of talk recently about XML [Extensible Markup Language]. How does WFC work with XML?
Stone: XML has a big future within Microsoft technologies. It hasn't woven itself into the operating system like HTML has in the last couple of years, but that could be just a matter of time. XML is still an emerging technology, and we're still looking for the right places to use it across all of Microsoft.
We're looking at XML very closely to figure out the best application. We know it's hot. We know it's good. We know it's important. But we want to make sure we understand the exact scenarios for XML, so users can benefit from it.
We've taken a couple of stabs at integrating XML into our tools environment, into our framework. For example, we have a lot of samples that allow developers to turn their HTML into XML using our library. We have other samples that turn XML into HTML using XSL. XML is something we're finding our way with right now.
MSDN: Can you predict the impact of WFC?
Stone: WFC and WFC.HTML, the piece closest to my heart, will allow MIS and IT managers to deploy their applications in a somewhat new way. WFC will lower the barrier for organizations to create Windows DNA applications. It will allow developers to be much more productive when creating this Windows DNA environment.
WFC.HTML is the first step toward putting the power back into the hands of MIS and IT managers. It lets them decide what's more important—reach or server load. WFC HTML lets them move the code to the client or control the architecture by keeping it on the server.
Rather than having the software force a configuration on them, we're allowing the configuration to control how they deploy the software.
MSDN: Can you explain what you mean by "creating this Windows DNA environment"?
Stone: I mean building n-tier, Internet-standard applications that use individual server or client components to reach out to disparate technologies via XML, HTTP, URLs. These can run on the Web, or they can run on Windows and take full advantage of the platform.
WFC takes developers a nice step toward that environment. I think we'll see more Windows DNA–type apps because of WFC. That's what we're targeting.