More than any other application, data acquisition puts your Operating System to the test. It's important to understand how Windows 95 will make your job easier or more miserable - before you're committed.
DON'T rush out and "see" what happens if you install Windows 95 on your DA station. Make sure that you install the new operating system on a test machine, or, at least, not in the middle of an active production cycle. This way, if you encounter glitches, you won't be devastated and stressed out. Before you install Windows 95, call your data acquisition hardware and software developers and ask them for compatibility information, patches (if any) and if they have any helpful information. Many vendors have updated their products to take advantage of Windows 95, so you'll be glad you found out about.
At this point, one of the most ballyhooed and probably least useful Windows 95 feature for all of us is Plug-and-Play. Plug-and-Play in Windows 95 enables Plug-and-Play systems (with Plug-and-Play compatible BIOSs) and Plug-and-Play adapters to automatically install and allocate systems resources. Since most of us already have systems or adapters, Plug-and-Play is useless and can even make board installation more confusing by introducing a new level of change into the process. So, unless everything you have is new and compatible with Plug-and-Play, you'll still have to configure interrupt levels and DMA channels.
Windows 95 promises to be a more robust and reliable operating system than Windows 3.1 on DOS. Its improved system resource allocation functions should enable you to run more applications at the same time without running out of resources.
In particular, GDI and Free Memory heaps are in 32-bit address space in Win 95 which provides more room for your applications to run in. Windows 95 does a far better job than Windows 3.1 at cleaning up and reallocating memory when a program ends. This helps stop your system from inexplicably hanging periodically, due to out-of-memory conditions.
Windows 95 runs each native application in a separate address space and each address space has its own message queue, which protects it from other applications. However all 16-bit Win 3.1 applications still run in a single shared address space and share a single message queue (unlike in Windows NT, by the way). If one of your applications stops responding to the system, it could still prevent all your other 16-bit applications from executing, just like in Windows 3.1.
Windows 95 applications can take advantage of the operating systems preemptive multitasking features, leaving multitasking in the control of the system. In Windows 3.1 applications must relinquish control to the operating system and "cooperate." Multi-tasking in Windows 95 provides smoother response times and minimizes data overflow errors that can occur with Windows 3.1.
Data Acquisition users are often concerned about timers. Happily, most data acquisition boards have built-in timers that control data acquisition so you don't rely on the system timers. The greater concern when doing real-time or high speed data acquisition ins interrupt latency....this is the time it takes the system to service an interrupt generated by your data acquisition hardware. Preliminary data indicates that most board vendors are finding that latency has been decreased with Windows 95 compared to Windows 3.1. This promises higher data transfer rates without overruns.
Finally, under Windows 3.1, data acquisition boards are operated by 16-bit DLLs that require special coding and care to operate. Under Windows 95's 32-bit flat addressing scheme, this is eliminated, making the 32-bit DLLs more reliable and less subject to addressing conflicts.
So, the good news is that if you can run a native Windows 95 data acquisition application, you will benefit from all of the new features of Windows 95 and be able to run a faster, more efficient and more reliable environment. The bad news is that if you run Windows 3.1 data acquisition applications under Windows 95, you may be better off or you could be worse off. The only way to find out is to try it yourself.
--This article was contributed by Stuart Ariewitz, Technical Director at SciTech International, Inc.
© 1996 Scitech International, Inc. All rights reserved
Back to articles menu
Go to next article