MSDN Interview
September 1998
At this year's Professional Developers Conference in Denver, Microsoft pulled out all the stops to teach developers how Windows® 2000 can help them build better applications. Session after session at the conference focused on how Windows 2000 will make it easier to build multitier, distributed, Windows DNA-style applications.
One of the prime movers behind this push—and a key member of the Windows NT team since Windows NT 3.51—is Frank Artale. As general manager of the enterprise portions of Windows 2000, he's helping drive the use of the new operating system as a platform for building distributed applications. As Artale explains in this interview with MSDN, Microsoft designed Windows 2000 from the ground up for enterprise developers, yet the new product also contains important new features for third-party ISVs and small- and medium-sized businesses.
MSDN: Why did Microsoft decide to make Windows 2000 the focus of this year's PDC? Specifically, why focus the entire conference around using Windows 2000 to build multitier applications?
ARTALE: The reason I wanted to make this the focus of this year's conference is because the application development platform coming in Windows 2000 is really ready for prime time now, thanks to the release of the Windows 2000 beta 2 and the upcoming release of Windows 2000 beta 3.
We have a chance now to show application developers in a very concise way the kinds of tasks they can do with Windows 2000, without making them go through the whole product and all its documentation. Windows 2000 is a big product. If you look at the size of its SDK, it's really hard to make heads or tails of the product.
With Windows 2000 approaching feature completeness in beta 3, we can now give developers the road map they need in order to get their jobs done, without making them wade through tons and tons of documentation. The PDC was meant to be the starting point in their development process for Windows 2000. Developers should look at what we're doing with Windows 2000, take our samples distributed at the PDC, and use them as a starting point.
MSDN: Developers often tell MSDN they feel overwhelmed with all they have to keep up with, and that it's hard when Microsoft keeps creating so many new products and technologies for them to learn. What would you tell these developers to convince them it's worth their time to learn Windows 2000?
ARTALE: The key point developers need to realize about Windows 2000 is that it is a new Microsoft platform release. That means Windows 2000 will contain intrinsic support for all the new hardware being released over the next year. People buying new machines will need Windows 2000 in order to get the most out of them.
By making that hardware support available in our device driver layer, developers won't need to make specific decisions about hardware when building their applications. We just abstract that away from them like we always have, so they don't have to worry about it.
Windows 2000 also collects a lot of the run times Microsoft has been talking about for the last two years and shipping independently. Windows 2000 collects all of them in one place and tests all of them as a whole.
For example, if you're using different run times you've collected from various groups at Microsoft, all of them are in one place now, and we've tested them all with Windows 2000. You won't need to go grab different service packs and run times and install them all yourself. When you run your application in Windows 2000, you can just assume that the latest and greatest run times are all there. It's a lot less work for developers from a deployment perspective.
Deployment is a key part of Windows 2000. It's part of an operating system for the first time.
We've taken a hard look at what developers have to go through to actually deploy applications to end users' desktops. The best examples of this are in corporate scenarios, where application deployment is now part of the operating system.
When you look at the IntelliMirror™ features in Windows 2000, you'll see that we take into account the notion of application setup. In the past, we really didn't do that—we left it up to the applications. From a developer's perspective, the ability to deploy applications across an enterprise is of very high value. We've made tremendous progress there.
MSDN: Is Windows 2000 primarily for enterprise developers, or is it also targeted at ISVs and developers who build traditional desktop applications?
ARTALE: Windows 2000 is really for all developers. Every developer should look at the product in two ways, as a desktop operating system and as a server operating system.
From a desktop perspective, Windows 2000 is focused on the end user in a stand-alone or corporate environment. All end users can benefit from new features in Windows 2000, such as Plug and Play, power management, and the latest DirectX® support.
In a corporate environment, IT managers will benefit from new application deployment technology and the ability to remotely install the operating system from a server. So Windows 2000 really should appeal to both the stand-alone user and corporate IT manager.
The same thing goes for the server version of Windows 2000. New features in the server version apply mainly to large-scale enterprises, but there's also a lot there to offer small- and medium-size businesses.
If a company wants to have the greatest Windows 2000 Web server, that comes in Windows 2000. If you're looking to build a distributed application and use a directory service to support your configuration management, the infrastructure in Windows 2000 Server is a great way to do that. If you're a corporate IT manager who just wants the latest and greatest file and print serving technology, Windows 2000 Server can certainly supply that as well. So depending upon your deployment scenario and the type of user you are, Windows 2000 has a lot of great features targeted at you.
MSDN: You discussed some of the ways Windows 2000 can help developers build better applications. How will Windows 2000 make it easier for developers to build multi-tier Windows DNA applications—the kind of applications Microsoft is trying to convince them to build?
ARTALE: The newest wave of applications is definitely multi-tier. With Windows 2000, we've included right in the operating system all the runtimes necessary to build these three-tier applications, without requiring any add-on technologies.
Multitier applications typically include a user interface. These can be built from a new technology such as Dynamic HTML, or with tools such as Visual Basic® (VB) or C++. That's the front end of the application.
Multitier applications also usually have a data source the app wants to talk to on the back end. In the old days, we called client-server applications two-tier because their front end talked directly to that data source.
Today, you also want to have a tier in between, in order to improve scaling and distribution. This middle tier acts as a front end for the back-end data source. This middle tier is what people call, in traditional terms, a message queuing system and transaction processing (TP) monitor.
The technology necessary to build the UI or presentation layer is in Windows 2000. Transaction processing and message queuing features are also in Windows 2000. The ability to serve up your presentation via Internet Information Server is in Windows 2000. Tying it all together is the COM programming model, which lets you build these three-tier applications in a seamless manner.
This is the application development platform we call Windows DNA. All the runtimes for this platform are in Windows 2000, along with all you need to deploy your applications. There's nothing for you to add.
MSDN: Are you suggesting that developers think of Windows 2000 as more of a platform for application development than as an operating system?
ARTALE: Yes, a good way to describe Windows 2000, from a developer's perspective, is to call it a development platform and an execution environment. You can do all of your development and testing on this new platform. The execution environment is there when you deploy your applications.
MSDN: What is the single most important benefit Windows 2000 brings developers, in your opinion?
ARTALE: I always like to think about it in terms of the end-user focus. At the end of the day, what users really care about most is getting their jobs done. To get their jobs done, they need an operating system that is reliable and works as advertised.
From a developer perspective, the best thing about Windows 2000 is you can be sure it was tested to the highest degree possible for every API. When you call those APIs, you know they'll work. The system underneath is going to be reliable—seven days a week, 24 hours a day. You have the commitment of Microsoft's Windows 2000 team standing behind the product to fix any problems that might arise over its lifetime.
People like to talk about features and how cool products are, but the primary focus of the Windows 2000 team always has been on reliability and creating a product that works as advertised. If there's any one thing a developer should remember about Windows 2000, it's that.
MSDN: Should developers write migration DLLs to make sure their current Windows apps will run properly on Windows 2000 and take full advantage of the new operating system?
ARTALE: Developers should test their applications under a migration scenario from Windows® 98/95 to Windows 2000. If they discover that a Windows 98 or 95 application doesn't work properly under Windows 2000, they should let us know and then write a migration DLL for the application.
MSDN: What type of applications are likely to need a migration DLL to ensure they run properly on Windows 2000?
ARTALE: Any applications that detect Windows 98/95 or Windows NT 4.0/3.51 during their setup phase and install specific DLLs for that operating system. For example, if an application detects Windows 95 and then installs a version of a DLL specific to Windows 95, then it probably will need a migration DLL for Windows 2000.
If an application detects Windows NT 4.0 or 3.51 and installs a DLL specific to that operating system, then it's another likely candidate for a migration DLL.
If an application creates different registry settings depending on whether it detects Windows 98/95 or Windows NT, that's something developers can work through without the need for a migration DLL. But in summary, if your application installs different code depending on what operating system it detects, then a migration DLL may be necessary.
MSDN: How difficult is it to write a migration DLL?
ARTALE: Writing a migration DLL is no harder than writing any standard Win32® DLL in C. We have samples that actually do it for you. We've found that most migration DLLs usually end up just patching some existing files or copying some additional files. So they're typically not a complex piece of code. We've seen people write them in less than a day.
MSDN: How much do developers need to learn about Windows 2000 in order to build applications that take full advantage of its new capabilities? Do they have to fully understand all the major pieces of the new operating system such as the Active Directory, Windows Installer, and Microsoft Management Console?
ARTALE: No, developers don't need to understand all that to get started. A key point for developers to remember is that all the APIs in Windows 2000 are implemented in such a way that developers can use whatever pieces they need for their application—when they are ready to use them. Developers don't need to understand everything about Windows 2000 and implement all its APIs at once.
This is because, from a Win32 perspective, Windows 2000 is fully compatible with everything that came before it. The operating system and its APIs are laid out in such a way that developers can take advantage of them gradually.
For example, if you want your application to be smart about power management and detect when a machine is entering a power-managed state, you can add that feature when you learn how. If you want your application to detect when it is running on new hardware that supports wakeup from a sleeping state, you can add that capability when you learn how. You don't have to understand all the other new features in Windows 2000 to add those.
The same is true with the new directory service in Windows 2000. You don't have to understand all the other new features in the operating system to take advantage of the Active Directory. A lot of application developers will begin storing their configuration information in this directory service so that whenever their application is running on a network, it can just contact the Active Directory for its configuration data. This information is very easy to store in the Active Directory. It takes a lot of the work out of building this type of configuration information into an application. The Active Directory is good at replicating this information around a network.
MSDN: When Microsoft releases Windows 2000 next year, do you think we'll see a lot of new applications released that take full advantage of its new features and capabilities?
ARTALE: Yes, we already have a large body of developers building applications that take advantage of Windows 2000's capabilities. These range from personal productivity applications to disk utilities to large-scale ERP applications that can run an entire business.
This is a major operating system release. We're seeing specific versions of every type of application targeted at Windows 2000 right now, even while the operating system is still in beta.
MSDN: Any final advice for developers interested in Windows 2000?
ARTALE: Yes. The time to do this development work is now, and not wait for Windows 2000 to release to manufacturing.
Frank Artale is general manager of Windows 2000 enterprise, helping to manage the overall development of the operating system. He recently added responsibility for the engineering, testing, and development of systems management features in Windows 2000. He also oversees Microsoft's Systems Management Server product.
Artale has been a member of the Windows NT team for the past four years. He began as a program manager for Windows NT 3.51 and later was program manager for Windows NT Workstation 4.0 and Windows NT Server 4.0. He prefers to measure his time in terms of daily builds, however. When he began working on Windows NT team, the operating system was at build 862. It recently reached build 1877, and is still climbing.