Be sure to rigorously test for compatibility conflicts, and then test some more
David S. Linthicum
For the existing mass of 60 million Windows users -- and the new users who join this club each day -- there seems to be little doubt that Windows 95 will be their next-generation OS. Windows 95 promises productivity gains and better performance. However, when adopting any new OS, users and their organizations need to create an upgrade plan to avoid any potential pitfalls.
Without a doubt, there will be new hurdles to overcome. Technical problems are inevitable when you move from one OS to another. First and foremost, Windows 95 users need to work out hardware- and software-compatibility issues. Your personal combination of applications, drivers, fonts, and hardware could be uniq
ue, and thus untested in the Windows 95 environment. Microsoft expects compatibility and porting problems to be a fact of life when Windows 95 ships, which is now scheduled for late August.
Microsoft says that most existing 16-bit device drivers will work with Windows 95. The key word here is
most
. A few drivers won't work, at least until all device vendors get around to fixing the inevitable Windows 95 compatibility problems. The same goes for applications. Most are fully compatible with Windows 95, but some, especially those that don't use the Windows API, won't work until the applications vendors either make all their applications Windows 95-ready or provide upgrades to the Win32 API.
Other things for you to consider include upgrading to the 32-bit world. For example, your existing 16-bit TCP/IP protocol stack may work with Windows 95. However, Windows 95 provides a 32-bit TCP/IP protocol "stack in the box" that will perform better and with less memory. But will it work with your Int
ernet applications? Moreover, you may have to port your current suite of 16-bit in-house applications to the new Windows 95/Windows NT Win32 API to take advantage of the new 32-bit features of the OS.
The Compatibility Shuffle
Microsoft's mixture of 16- and 32-bit architectures solves some compatibility problems but creates others. Microsoft provides
a mix of 16- and 32-bit
subsystems to ensure that Windows 95 can run existing 16-bit Windows software, as well as the new Win32-compatible applications. The use of 16-bit subsystems allows Windows 95 to run applications as fast as, or faster than, Windows 3.1 can--and, Microsoft claims, with minimum hardware requirements (a 386SX processor and 4 MB of RAM).
Within Windows 95, 16-bit subsystems are used where such code is needed to maintain compatibility or where 32-bit code would require additional memory without an equivalent increase in performance. The 32-bit code exists where Microsoft thought it would
enhance performance without sacrificing compatibility.
All the low-level services in the OS, for example, exist as 32-bit code. All I/O subsystems, including the file system, the network, and memory management, use 32-bit code. The remaining 16-bit code exists in Windows 95 as Intel-dependent assembly code that can provide the most performance per processor cycle. For instance, all Windows management code remains as 16-bit code for the sake of providing both compatibility and performance.
Windows 95 provides a much better device-driver architecture with 32-bit VxDs (virtual device drivers). These drivers work like conventional real-mode device drivers, but they use protected mode wherever possible. Thus, they use almost no conventional memory and should be more reliable. However, a better architecture does not mean compatibility. Beta testers have reported device-driver compatibility problems with the final beta version.
But Microsoft claims that most Windows 3.1 applications will work w
ith Windows 95. That is, applications will work if they adhere to the rules of the API in the previous release of Windows (Windows 3.1 and Windows for Workgroups 3.11) or make use of the Win32 API (i.e., they are Windows NT applications).
Unfortunately, some software vendors have made their applications Windows 3.1 dependent. For example, an application may go directly to the graphics subsystem and bypass the API altogether. This may provide better performance for games and other graphics-intensive software, but Windows 95 won't like it. Windows 95, unlike Windows NT, supports only portions of the Win32 API. Therefore, some NT applications that use Win32 API calls that are unsupported under Windows 95 won't work. Win32 applications developers are certainly aware of the upcoming Windows 95 release, and they have avoided using API calls that are not shared by both Windows 95 and Windows NT.
How, then, do you know if your software will be compatible with Windows 95? The only reliable way is to actu
ally run it on Windows 95. Even if your application works with the beta version, you could still run into compatibility problems with the shrink-wrap release. Microsoft will constantly change Windows 95 until the company freezes the code for production.
Performance: Myth and Reality
Users who migrate from Windows 3.1 to Windows 95 will notice better performance for most 16-bit Windows applications, according to Microsoft. Windows 95 can spend more time in protected mode, which provides a stable OS and enhanced performance. In addition, Windows 95 can avoid switching from real mode to protected mode, an operation that slows things down. Disk reads and writes don't require real mode in Windows 95. Also, applications that use a lot of disk I/O should run faster.
But if you want to take full advantage of Windows 95 performance, you'll have to upgrade to 32-bit applications. Most software vendors will create Win32 versions of their products shortly after Windows 95 hits the s
treets.
Windows 95 also supports multithreaded applications, which are applications that can split themselves into threads for parallel execution. Most multithreaded applications run faster than applications that don't take advantage of threading. In fact, Windows 95 tracks resources for each application by placing each one in a separate thread. Thus, Windows 95 protects applications from other ill-behaved applications, which stops an application crash from taking down the entire OS.
But there could be a downside to threading. During beta testing, some Windows 95 testers noticed that the use of multithreaded applications, such as Microsoft's own MSN (The Microsoft Network), cut the amount of available memory to such an extent that it caused an OS crash. Microsoft says it is fixing this problem for the final release.
Network Considerations
Windows 95 supports networks with its out-of-the-box client support for IPX/SPX, NetBEUI, and TCP/IP. Will it support your netw
orking applications? Windows 95 employs a MAC (media access control) device-driver model. The MAC layer is the lowest point in a networking subsystem and communicates directly with your network adapter of choice (e.g., Ethernet and Token Ring).
A MAC driver uses the NDIS (Network Driver Interface Specification) 3.0 standard. MAC clients (i.e., transport protocols) bind to the MAC driver functions using the NDIS interface. If that's confusing, just remember that NDIS allows multiple transport protocols to communicate with multiple network adapters, and most network adapters come with NDIS drivers.
But initially, network vendors won't provide protected-mode Windows 95-ready NDIS drivers for Windows 95, and that's where the trouble will start as network users begin the migration to Windows 95. In addition, different network vendors have different ways of doing things. Novell's ODI (Open Data-Link Interface), for example, looks a lot like NDIS in that it provides a protocol-independent device interf
ace, and there are a lot of ODI drivers available on the market. Therefore, Windows 95 supports ODI as well as NDIS, and if your application supports one of these standards, chances are that it will work with Windows 95.
To solve the problem of using non-NDIS protected-mode drivers (e.g., NDIS 2.0 and ODI), Windows 95 provides a series of low-level services known as
helper modules
. These modules bind the various interfaces to make them work together. For example, the Windows 95 protected-mode
TCP/IP protocol
for Internet access can run alongside a real-mode IPX/SPX driver for NetWare.
If you're running third-party network-protocol stacks and drivers, Windows 95 will probably work with them in 16-bit mode. For example, FTP's TCP/IP protocol stack and tools work with Windows 95 without any additional modification. Chances are that your current network configuration (i.e., the protocols and the drivers) will work with Windows 95.
However, only testing will prove f
or certain whether or not that's true. If possible, you should use protected-mode protocols and drivers. They perform much better than their real-mode counterparts, and they require almost no memory.
There is no law that states you must upgrade to Windows 95. If your current environment works, don't rush to change it. However, if your organization will upgrade to Windows 95 the moment it becomes available, now's the time to do your homework and testing.
PRODUCT INFORMATION
Windows 95..............$99
Microsoft Corp.
Redmond, WA
(800) 426-9400
(206) 882-8080
fax: (206) 936-7329
screen_link (26 Kbytes)
Windows 95 provides new 32-bit versions of accessory software, such as Microsoft's WinPad. However, you can still run existing 16-bit software.
screen_link (47 Kbytes)
You can use your existing TCP/IP transport protocol or the Windows 95 protected-mode version of TCP/IP for Internet access.
A GUI Cascade
screen_link (27 Kbytes)
The main change you'll see with Windows 95 is its interface. Note this cascading menu.
Let Windows 95 Be Your Guide
screen_link (38 Kbytes)
Windows 95 detects what hardware is already on your system and guides you through the installation of new components.
David S. Linthicum, a senior consultant with CSC Consulting in Falls Church, Virginia, is the author of several books on software development, a speaker, and an associate professor of computer science. You can reach him on the Internet at
70742.3165@compuserve.com
or on BIX c/o "editors."
How Best to Migrate to Windows 95
