Adding Win32 support to Digital's OS will allow developers to target OpenVMS and NT machines
Mark Feniello
Good things come to those who wait. Digital Equipment Corp. and Microsoft have had an agreement for several years to help each other develop, promote, and market products. Soon after this relationship was formed, Digital's Alpha AXP machines were among the first to support Windows NT. Since then, however, there have been few tangible results to support the flurry of marketing and PR announcements. But finally this alliance is starting to bear real fruit.
The two companies have agreed to exchange engineers, license some of each other's patented technology, and provide access to each other's source code. And Microsoft will fu
nd the training of at least 1500 Digital employees to support Microsoft products. But perhaps the biggest news is Digital's announcement that its OpenVMS operating system will soon support Microsoft's Win32 API.
Word for OpenVMS?
So does this mean Microsoft Word will run on OpenVMS? That's a question Wes Melling, Digital vice president of OpenVMS Systems Business, hears often. And his answer is "No." The long version of the answer is that when enough of the Win32 API is supported by OpenVMS, you could get Word to run under OpenVMS by recompiling and relinking the source code. That is not likely to be a high priority for either Microsoft or Digital, so Melling is probably right; the answer remains "No."
On the other hand, many OpenVMS developers want to know if they can now develop Windows applications and then run them on an OpenVMS system. This is the question Digital wants to hear, because the answer is a resounding "Yes." Digital wants developers to build applications f
or Windows and then keep OpenVMS in mind when deciding which platforms to support with these new applications. This is the message Digital must keep telling developers as desktop machines play an ever-increasing role in the day-to-day business operations of Digital's traditional user base -- medium to large scientific and commercial sites.
The announcement of OpenVMS support for the Win32 API is part of a much larger picture Digital is painting. OpenVMS is already widely accepted as a bulletproof operating system capable of providing 24-hour-a-day, 365-day-a-year reliability to business-critical, enterprise-wide applications. But Digital knows that business desktops are dominated by PCs, most of which are running Windows. Digital wants to make it easier for developers to create client/server applications for a single OS (i.e., Windows) and then deploy those applications on a combination of Windows, Windows NT, and OpenVMS systems.
The Three-Tier Approach
Digital and others
in the industry are now promoting a new model for client/server applications. They are warning that applications with a "fat client" or a "fat server" will not scale or perform well in the future.
An application with a fat client is one in which the client handles not only the user interface but most of the application's decision logic as well. This leaves only the data-retrieval and update functions to the back-end server. A fat server application results when the client is little more than a GUI that issues SQL requests to a database server. In this type of application, the server handles most of the decision logic and calculations. The server then sends packets of formatted information back to the client for display.
Some analysts and makers of development tools are now advocating a three-tier client/server model (
see the figure
). In this model, the decision logic and heavy calculations are separated from the rest of the application and put into a partition of their own. Th
is becomes the middle tier of the three-tier model. The first tier contains only the presentation services, the GUI. The third tier provides all the data management services.
With an application partitioned in this way, you have the flexibility to deploy each piece of the application on the system that gives it the best performance. Instead of running a CPU-hogging number cruncher on a 66-MHz 486, let it rip on a blazingly fast 275-MHz Alpha AXP system. If you have to work with huge amounts of data, why try to cram a small piece of it into the 8 MB on the desktop client when you could fit everything into memory at once by accessing 512 MB of shared memory on an application server?
Some development tools take this even further by allowing you to replicate the application logic across multiple servers. With this configuration, automatic load balancing can be performed, letting the application server with the most available resources handle the clients' requests for services. Having multiple applicat
ion servers also provides another benefit: Even if one or more servers goes down, requests can still be processed by the remaining servers. You can quickly envision a system that is as fast and as reliable as you want to make it. All you need to do is throw more hardware at the problems until there are no more problems left to solve.
Platform Oblivious
If you are a developer, you may wonder what hoops you have to jump through to get a program to work like this. That is one of the main reasons that Digital is building support for the Win32 API into OpenVMS. It is already possible for you to build and partition a client/server application using the three-tier model, and you have a number of development tools to choose from to help you. The problem comes when you need to choose the target platform.
With most of the existing tools, you need to be very aware of the target platform for which you are writing the application. If you don't continually take this into account, your be
autifully designed program will probably not run properly when it gets to the target system. According to Digital's Melling, it is Digital's goal to make things so transparent that the developer can be "platform oblivious."
By supporting the Win32 API on OpenVMS, Digital has brought developers one step closer to being "oblivious." You will be able to develop a client/server application on a Windows or Windows NT machine and then deploy it on any combination ofWindows, Windows NT, or OpenVMS systems.
Support for the entire Win32 API will not come all at once (
see the chart
). First, Digital will support what Microsoft used to call the Win32s subset of the API. This portion of the API provides everything needed by a typical Windows program, such as I/O functions, memory management, and object management, plus the common graphics- and window-management calls. By the time you read this, support for the Win32s portion of the API, along with support for OLE 2 and the Microsoft Found
ation Class, should be available. Within six to nine months, some of the Win32 server API calls will be supported.
Digital is now in the process of surveying customers as to which calls are most important and should be included in this second phase of support. Then, in the next 12 to 24 months, Digital intends to support the rest of the Win32 server API calls as well as the BackOffice API.
Presto Change-o
Bristol Technologies (Ridgefield, CT) is performing the magic that allows OpenVMS to understand and handle the Win32 API calls. Bristol is writing a library of callable routines that translate the Win32 API calls into the appropriate OpenVMS system services. The routines translate GUI-related API calls into their equivalent Motif calls. To enable an application designed for Windows to run under OpenVMS, you simply recompile your source program on an OpenVMS system and link it with this library. Except for minor differences between the Motif and Windows interfaces, you sho
uldn't know or care about the operating system on which your application is running.
It will take benchmark tests to determine comparative performance figures based on real applications. But Digital expects that performance will be almost identical between a Windows application running under Windows NT and the same application running under OpenVMS on the same hardware. Mike Cuccia, director of OpenVMS marketing at Digital, says that application performance on an OpenVMS platform is within 10 percent plus or minus of the performance on a comparable NT platform. Some calls are faster under OpenVMS and others are slower, so the performance of your specific application will vary depending on what it does.
Large applications that can be scaled over multiple processors can benefit from the better symmetric multiprocessing performance of OpenVMS. Windows NT tops out at three or four processors, while OpenVMS can go up to 10 or 12 processors. Another potential benefit of OpenVMS is that it will soon supp
ort 64-bit memory addressing. If your application manipulates massive amounts of data, you could see performance increases of up to 200 times by being able to get all the data into memory at once instead of having to bring it into memory in smaller pieces.
Digital expects that most client/server application development will continue to be done on Windows or Windows NT platforms. The company is therefore concentrating on making its OpenVMS development tools integrate with existing Windows development tools. Digital is making its compilers compatible with Microsoft compilers and is porting its development tool set to run under Windows NT.
Digital is working with other development-tool makers to ensure that these tools integrate well with Windows clients and OpenVMS servers. Some of these third-party environments help the developer with both the design process and the complex task of partitioning the final application. These environments insulate the developer from the underlying hardware and OS depe
ndencies. Their ultimate goal is allowing the developer to concentrate on the application. The details of splitting the source code into different parts for compiling and deploying on different OS platforms will all be handled automatically by the development environment.
For years, OpenVMS has proven to be a secure, highly reliable OS for mission-critical applications. If Digital can pull off the integration of OpenVMS with Win32, it will have a powerful argument to convince developers of future client/server applications that they should continue using Digital's operating system.
Expected Release Time: Features Supported:
====================== ===================
Now to 3 months Win32s API, OLE 2, Microsoft
Foundation Class
6 to 9 months Selected Win32 Server API calls
12 to 24 months
Remaining Win32 Server API,
BackOffice API
illustration_link (9 Kbytes)
OpenVMS with Win32 will enable developers to deploy three-tier client/server applications.
Mark Feniello has worked with various Digital systems, including OpenVMS, for 15 years. He is currently a systems analyst for Spokane Computer in Spokane, Washington. He can be reached c/o
editors@bix.com
.
Open(ing) VMS to Win32
