Technology Initiatives

Legacy devices, especially ISA-based devices, remain the most frequent cause of problems in PC system configuration. The most common cause of support calls continues to be resource conflicts or loss of functionality occurring when end users install ISA devices such as modems, audio, or multimedia devices. In addition, even with the performance capabilities of current processors and the multitasking capabilities of Microsoft« Windows« 95/98 and Windows NT«, there is a significant performance impact when a fast processor has to access a slow bus such as ISA.

Microsoft is working with the PC industry on the technology and market issues related to migrating from ISA to new buses. However, if you are designing with ISA or other legacy components, these resources provide some implementation guidelines.

ISA Migration

To improve system performance, reduce customer support costs, and ensure true ease of use in PC systems and peripherals, manufacturers must plan to migrate all components in their systems away from ISA and legacy devices.

With the addition of ACPI support and manageability features in Windows 98 and Windows 2000, the operating systems provide a strong foundation for configuration, power management, and central administration of systems and devices. Buses such as USB, IEEE 1394, and PCI offer much better throughput and greater ease-of-use for customers.

Migration from ISA is being undertaken on a step-by-step basis. The first step, as originally defined in PC 97 Hardware Design Guide, focused on efforts to eliminate non-Plug and Play devices from new systems. This was a key feature of the 1997-98 "Designed for Microsoft Windows" hardware logo program.

The second step, as originally defined in PC 98 System Design Guide and continued in the current PC 99 System Design Guide, is that new PCs do not include add-on devices that use legacy ports or the ISA bus. This is a key feature of the Microsoft Windows logo program, and includes audio, modems, and other devices that in the past have often used the ISA bus.

The ultimate goal, however, is the complete elimination of the ISA bus.

The following list summarizes the planned migration road map:

• PC systems planned for the year 2000 and later should not include ISA expansion slots.
• If system-board devices such as BIOS ROM, Super I/O, audio, and keyboard controller are included, then each device must meet Plug and Play design specifications either as an ACPI device object (the preferred implementation) or as an ISA Plug and Play device.
• Graphics adapters should not use ISA (a 1997-98 hardware logo requirement).
• AGP or PCI are the recommended connections.
• Modems, scanners, and other input and imaging devices must not use legacy buses.
• USB is recommended for modems, and SCSI or IEEE 1394 is recommended as the default I/O bus for scanners and other imaging devices.
• Multiple solutions are immediately available for audio, the most common being PCI and USB.
• ATAPI devices should comply with SFF 8070i.

OEMs will probably continue to provide legacy mouse devices and keyboards, but USB solutions are encouraged. Legacy and proprietary solutions for game devices should be avoided.

Legacy Designs
Although Microsoft urges all hardware designers to prepare product plans to move from ISA to other solutions, if you are implementing an ISA-based design, it is important that you adhere strictly to the Plug and Play guidelines. In addition, the white papers cited below and the current PC System Design Guide provide guidelines to ensure the best possible customer experience with your legacy design.

Digital Signatures and Supportability Initiatives 
To promote driver quality and support capabilities that ensure a better user experience, Microsoft is providing new technologies such as Windows Update Manager and new programs such as digital signatures for drivers.

"Supportability" refers to the ability to ensure customer satisfaction by reducing or eliminating the problems that result in support calls. Supportability also refers to tools and methods that enhance the ability to easily resolve customer support issues.

Microsoft currently has several initiatives related to supportability issues:

• Digital Signatures for drivers, to help reduce customer problems related to installation of out-of-date drivers.
• Windows Updates, to ensure that customers can use the Internet to easily access up-to-date drivers, service releases, and other components.
• WinRep and DOSRep supportability tools, provided as part of Microsoft« Windows« 98, to offer a way for OEMs to customize their customer support operations.

Digital Signatures

Driver Signing uses the existing Digital Signature cryptographic technology to store identifying information in a catalog (CAT) file. This information identifies the driver as having passed testing by WHQL. No change is made to the driver binary itself. Instead, a CAT file is created for each driver package and the CAT file is signed with a Microsoft digital signature. The relationship between the driver package and its CAT file is referenced in the driver's INF file and is maintained by the system after the driver is installed.

IHVs should submit their drivers to WHQL for testing to obtain a digital signature for their driver package.

Windows Update Overview

Windows Update for Windows 98 and Windows 2000 is invoked several ways:

• Through user installation of a new device on a PC
• From the Start button
• By clicking the Update Driver button in Device Manager
• By connecting directly to the Microsoft Windows Update web site

Microsoft maintains a server farm to host the updated drivers, files, and patches. Globalization of Windows Update also includes plans for international content sources in 33 languages.

WinRep and DOSRep

To take advantage of these tools, OEMs must customize WinRep to fit existing support processes or to implement new ones.

Supportability Features in Windows 98 and Windows NT 4.0

• MS-DOS Report Tool (DOSRep)
• Windows Report Tool (WinRep)
• Microsoft System Information
• Dr. Watson
• System Configuration Utility
• Troubleshooting Wizards
• Emergency Startup Disk
• System File Checker
• Windows Update
• Digital Signatures for Drivers
• Registry Editor

• Emergency Recovery Disk
• "Last Known Good" Registry
• Troubleshooters on the Web
• Hardware Profiles
• Administrative Wizards
• Event Viewer
• Task Manager
• Performance Monitor
• Network Monitor
• Registry Editor

• Local Troubleshooter
• Client/Server Troubleshooters for the Internet and Intranet
• Microsoft System Information
• Disk Management
• DLL Management
• Improved Error Messages
• Network Diagnostic and Safe Boot
• Improved Crash Dump Support
• Improved Stop Screen Interpretation
• Virus Scanner Software
• Improved Add/Remove Programs Tool
• Windows Report Tool
• Windows Update Manager
• Digital Signatures for Drivers

Targeting Windows CE

Develop Compact, High-Performance Embedded Applications with Microsoft Windows CE
Designers of embedded systems have long been faced with frustrating technical and functional barriers that have affected performance, compatibility, and development costs. Microsoft Windows CE, a 32-bit, Windows-compatible real-time operating system eliminates those barriers. Windows CE is designed to fill the need for small, scalable operating system that works for a broad range of products, including mobile computers, terminals, industrial controllers, and many others. And best of all, it lets developers take advantage of the Win32 API, the award winning Developer Studio Environment, and a variety of other resources. The modular design of Microsoft Windows CE allows it to be customized for a wide variety of platforms, from consumer electronic devices to specialized industrial controllers. Because Windows CE is componentized, you can design embedded system platforms using the minimum set of software modules and components needed to support the platform's system requirements, which minimizes the memory footprint and maximizes performance of the operating system.

Windows CE directly supports many kinds of hardware peripherals and devices, such as keyboards, mouse devices, touch panels, serial ports, Ethernet, modems, USB devices, audio devices, parallel ports, printer devices, and storage devices (ATA or flash media). At the same time, as Windows CE extends to new markets and device categories, there is tremendous potential for embedded developers to easily add new device types and peripherals. This is made possible through Windows CE's simple and well-defined Device Driver model, which provides a well-documented set of device driver interfaces (DDIs) and sample code that demonstrates implementation. This model enables embedded developers (both OEMs and IHVs) to easily implement their own driver software for a variety of devices that run on the Microsoft Windows CE platform.

Windows CE supports more than 1400 of the most-frequently-used Win32 APIs, enabling Windows CE developers to leverage vast amounts of third-party programming resources, tools, software examples, and documentation for their Windows CE development. With more than 5 million Win32 developers worldwide, there are many experienced programmers who already know how to develop for the Microsoft Windows CE platform, which lowers training costs and shortens your time to market.

You can evaluate the Windows CE operating system and develop your embedded applications using the Microsoft Windows CE Platform Builder, a toolkit that also includes the Microsoft Windows CE operating system, an optimized version of Microsoft Visual C++ 6.0 and a set of tools for embedded development. Platform Builder includes cross-compilers for all Windows CE-supported processors, applications and kernel mode debuggers, system adaptation tools, operating system components, samples, and documentation.

In addition to Platform Builder, the Microsoft Windows CE Toolkit for Visual Basic provides a set of robust tools and controls for Windows CE application development. This toolkit delivers the tools Visual Basic programmers need to easily build solutions for Handheld PCs powered by Windows CE. The toolkit leverages the Microsoft Visual Basic development environment, including many of the common Visual Basic controls, making it easy for developers to apply their knowledge of Visual Basic and begin developing applications for Windows CE based devices.

Please note: you must license Windows CE for use on mobile and embedded devices; please contact Microsoft at http://windowsce.microsoft.com/licensing.asp  for licensing information.

General Features

• Supported processor architectures include:
  • ARM, including StrongARM
  • MIPS
  • PowerPC
  • Super-H
  • x86
• For the complete list of supported processors, including specific model numbers, please visit our technology partner Web site at: http://www.microsoft.com/windowsce/embedded/programs/semi.asp 
• Modular operation system, allowing for componentization
• Built-in support for communications, Windows CE shell, and device drivers
• Subset of Win32 API set and familiar development model and tools for application developers

OEM Adaptation Layer (OAL)

• Allows OEMs to adapt Windows CE to their hardware
• Consists of a set of small driver for interrupt services, RTC, etc.
• All processor-specific porting done by Microsoft

The primary purpose of the OAL is to expose the target platform's hardware to the kernel. This includes managing the hardware's timers and device interrupts, and implementing power management across the device's peripherals. Windows CE handles interrupts by associating each hardware interrupt request line (IRQ) with one interrupt service routine (ISR). When interrupts are enabled and an interrupt occurs, the kernel calls the registered ISR for that interrupt. The ISR, the kernel-mode-portion of interrupt processing, is kept as short as possible. Its responsibility is primarily to direct the kernel to schedule and launch the appropriate interrupt service thread (IST). The IST, implemented in the device driver software module, gets or sends data and control codes from or to the hardware and acknowledges the device interrupt.

Device Drivers

• Built-in support for the keyboard, touch panel, notification LED, display, audio (Soundblaster compatible), battery drivers, and a rapid development model that allows these devices to be ported quickly to your platform.
• Support for wireless and wireline Ethernet LAN connectivity
• Statically replaceable keyboard layout
• Simplified interrupt processing of device drivers based on the Win32 event model
• Network printing
• Support for serial and parallel devices
• PCMCIA Card and Socket Services for removable or built-in storage cards
• Host USB services for supporting many USB devices

Kernel

• Multi-threaded; preemptive multitasking
• Preemptive priority-based thread scheduling based on the Win32 process and thread model; supports eight levels of thread priority
• Support for priority inheritance to correct priority inversion
• Demand paging supported by ROM, RAM, and FAT file systems
• Execute in place from ROM
• Support for synchronization objects (WaitForSingleObject, WaitForMultipleObjects)
• Low ISR and thread latency
• Portable across microprocessors
• Heap size that is limited only by available memory

Object Store

• Available object stores include file systems, registry, and database
• Database provides storage and retrieval of database records, with up to four sort keys and support for transaction logging and rollback
• File System
  • Access is through Win32 API
  • Supports FATFS, including multiple FAT volumes (up to 99 volumes)
  • Installable block Device Drivers (ATA Flash and SRAM drivers included)
  • True Flash File System support
  • Installable file systems
  • Databases on mounted file systems

Registry

• Win32-like registry
• Access is through Win32 Registry API

GDI and USER

• Configurable from nothing to full-blown GDI & User, with intermediate points:
  • display-less, message passing (mininput)
  • graphics but no windowing (mingdi)
  • minimalist window manager (minwmgr)
• GDI--resolution-independent graphics
  • Raster and TrueType Font support
  • 1 to 32 BPP Color Pixel depths w/ palettes
  • Printing (device-side rendering)
• User--windowing, dialogs, messaging
  • Additional: Controls, clipboard, cursors, caret, idle time out, hot keys, etc.
• GDI and user export a subset of the Win32 API

Communications Support Includes

• Windows Sockets APIs
• WinInet with FTP, HTTP and HTTPS support
• Secure Sockets (SSL) with Server Gated Cryptography support
• TCP/IP, PPP, SLIP, and IrDA, including Fast IR
• TAPI modem support
• Serial APIs
• Direct connection, dial-up and device-to-device connectivity
• LAN connectivity using NDIS and Microsoft Network client software (to access remote file and print servers)
• Remote access services (RAS) to support remote connectivity
• Remote debugging over LAN, serial or parallel connections
• Built-in support for communication hardware (built-in modems, Ethernet chips, etc.)
• Windows NT« LAN Manager-based authentication provided. Other security service providers possible using SSPI APIs.
• Cryptography 1.0 APIs including RSABASE CSP (containing popular algorithms to encrypt/decrypt data, key generation/management/exchange, hashing, digital signatures, and verification of signatures

Remote Connectivity

• Remote APIs allow Windows-based desktop systems access to Windows CE-based devices
  • Manipulate Object Store and device registry
  • Transfer files
  • CE Invoke for remote execution of procedures or devices
• Remote networking
  • Direction connection to PC
  • Dial-up access to Internet, PCs, and Servers

Shell

• Includes a minimum shell that supports application launching and switching
• Source code is included so that the shell can be adapted to serve as the bases of an embedded application
• Key UI components included to allow rapid development of custom embedded shells

Internationalization/Localization

• French, German, Italian, Portuguese (Brazilian), Spanish, Dutch, Swedish, Japanese and Chinese (Beta)
• Far East text support
• Input Method Manager, Input Method Editor, and Soft Input Panel
• UNICODE support
• Handwriting recognition for both Japanese and English
• Support for the national language support (NLS) API, which allows system and user locales

Additional Component Features Include

• ActiveX and COM/OLE
• Microsoft Foundation Classes for Windows CE

Windows CE-based Hardware Requirements

Windows CE is a small-footprint, flexible operating system. The memory needed by a Windows CE-based system is totally dependent on which components the designer of the system selects. For example, a low-end system with just the kernel, the communications stacks, and a single non-display application would require less than 500K of ROM and 350K or RAM, depending on the application's needs. The Windows CE components, the full-fledged windows CE-based device using all of the components of the architecture, take up about 2 MB of ROM. Such a device would likely start up with the shell running in less than 512K of RAM.

For More Information:

For additional information on Microsoft Windows CE, visit http://www.microsoft.com/windowsce/ 

Home Networks / UPnP 

Home Networking is the collection of technologies and services that make it possible to connect multiple computing and information devices.

Home networking ushers in a new era of entertainment and convenience for consumers.

The most successful and useful home networks will be simple, reliable, secure, and inexpensive.

This site presents information about the initiatives, technologies, and industry standards Microsoft is investing in and believes will achieve the most powerful home networks.

Television and Broadcast Initiatives 

Microsoft is working on enhancing the existing TV Broadcast Architecture for the Windows operating systems using industry standards that ensure high-quality playback of multiple video, audio, and data streams. The goal is to work with the industry to ensure that video quality on the PC is beyond that currently achieved on consumer electronics devices. To this end, Microsoft has implemented operating system support for Digital TV using Microsoft DirectShow. 

Fundamental to achieving this goal for video quality is the separation of "receiver" functions from "display/rendering" functions, with the various MPEG streams received, separated, and routed by host software. One recommended method of implementing TV received modules is Device Bay. 

New technologies are becoming available that integrate the PC with television, making the PC more compelling for new audiences and new uses. These new technologies, which are built into Microsoft« Windows« 98 and Windows 2000, consist of broadcast components that allow PCs to receive television programming, data services, and new forms of entertainment that blend the two. These technologies are enhanced in the operating system with new user-interface elements appropriate for use on large-screen display devices such as a progressively scanned display or a television monitor.

The broadcast and video technologies in Windows 98 and Windows 2000 are based on industry standards such as MPEG-2, Win32«, ActiveX«, and DirectX«, and they are also built on current and emerging standards for broadcast networks and Internet protocols, enabling IP Multicast as a point-to-many networking standard for network traffic.

Broadcast network capabilities provide a transmission infrastructure that can support services such as automatic software and file updates. Broadcast technologies enable new applications and business opportunities such as:

• New types of programming that combine the PC, the television, and the Internet.
• Multimedia Internet content that is delivered by broadcast networks and stored locally on the PC, reducing the Internet bandwidth bottleneck and improving the overall user experience.
• Secure, billable, and scalable data services such as subscription services for software, electronic news, and entertainment, encouraging creation of new business models.

Designers must ensure that PCs and related computer devices can do everything the TV, VCR, set-top box, and hi-fi system can do. This requires careful design decisions for adding new features to the PC that contain the attributes of the traditional TV and other devices. In particular, the assessment of picture quality includes image clarity, smooth resizing, and precision of frame delivery. The challenge for the designer is to ensure that the PC meets or exceeds the video and audio quality of traditional consumer appliances. Particular emphasis will be placed on checking that rendering is accurate for the highest motion content scenes.

Important design issues that relate to integrating video and broadcast TV capabilities with the PC include the following:

• Increased quality of video capture and playback, including an absence of banding related to poor scaling methods.
• Low-latency video delivery, displaying video from both internal and external video devices.
• Support for receiving digital TV broadcasts.
• Increased use of multiple screens and their associated display controllers. This allows a PC to run a word processing application in one room, while simultaneously supplying a TV, located in another room, with a DVD movie or TV content.
• Separation of "receiver" functions from "display" functions. The two will be linked by software running on the host processor. This allows different elementary streams such as MPEG video, audio, and data to be sent to the appropriate subsystems within the PC. It also prepares the way for the long range goal of a video home network.
• Use of Microsoft DirectShow for video playback.
• Device Bay is recommended as a way of implementing TV receiver modules. This is in addition to the use of PCI adapters and external receiver boxes, which are also acceptable implementations.

Because Microsoft« Windows« 2000 is expected to become the mainstream operating system, Microsoft is urging widespread development of drivers for Windows 2000 that support Plug and Play, ACPI, and hardware management capabilities. Microsoft is also encouraging implementation of drivers based on the Windows Driver Model for the related device and bus classes.

Key issues for driver development in Windows 2000 include support for power management and Plug and Play, as well as ensuring a seamless installation (or upgrade) experience across as many hardware devices as possible. The upgrade scenarios are no longer limited to the case of upgrade from previous versions of Windows NT, but now include upgrades from Windows 95 and Windows 98.

Hardware developers should also pay special attention to upgrade scenarios where they must update hardware-specific configuration utilities or applications, particularly where they are dependent upon components that either will not run with Windows 2000 (like VxDs) or are otherwise not supported in a Windows 2000 environment. No assumptions should be made, for example, about number of processors in a system--in other words, hardware developers should test their tools on multiprocessor systems as well as uniprocessor.

Microsoft Driver and Hardware Development web site is here to help you get ready for Windows 2000. Visit us today at http://www.microsoft.com/msdn/hwdev. 

Windows Imaging Initiative:

The WIA API is designed to allow applications to:

• Run in a robust and stable environment.
• Minimize interoperability problems.
• Enumerate available image acquisition devices, both local and remote.
• Create connections to multiple devices simultaneously.
• Query properties of devices in a standard and expandable manner.
• Acquire device data using standard and high-performance transfer mechanisms.
• Maintain image properties across data transfers.
• Be notified of a wide variety of device events.

• Providing a standard device services library that performs most driver operations.
• Promoting industry device communications standards so that one WIA driver will support most WIA devices. For example, ISO 15740 from PIMA/IT10.
• Not requiring that the device driver use the standard device services library, while allowing it to support custom interfaces, if needed. However, drivers will still need to implement the standard WIA interfaces.

Figure 1: Windows Imaging Architecture

WIA Components. WIA is implemented as a DCOM out-of-process server to ensure the robust operation of client applications. There is a performance penalty for running the WIA server out of process, but WIA has a data transfer mechanism, IBandedTransfer, which uses a shared memory window to transfer data to the client. This eliminates a data copy caused by COM marshalling.

WIA has three main components: a device manager, a device driver service library, and a device minidriver.

• The device manager enumerates imaging devices, retrieves device properties, sets up events for devices, and creates device objects.
• The device service library implements all services that are device independent.
• The device minidriver maps WIA properties and commands to the specific device.

WIA Logical Device Model. WIA represents all imaging devices as a hierarchical tree of CWiaItem objects. CWiaItem and its interface, IWiaItem. The application is given an interface pointer, IWiaItem, to the root of this tree when it first creates a device object. The IWiaItem interface provides methods for the application to:

• Read and write device and properties.
• Navigate the entire item tree.
• Transfer data to/from the item.

Digital Content Management

Finding a particular picture will be especially easy, as DCM allows search by keywords and using the Microsoft query-by-example technology. That is, the user can point to a picture and request an image that looks similar to it. DCM will search across multiple volumes and against off-line media.

Searchable metadata can be provided within the file itself, as an adjunct file, or as annotations created at the time of acquisition. In the latter case, DCM ties into the new WIA architecture to capture these annotations using the WIA Picture Acquisition Manager for Cameras or Scanners.

DCM is under development for future releases of Windows operating systems  

© 1999 Microsoft Corporation. All rights reserved. Terms of Use.