|
Device-Class Tips and News
Windows Support for Logical Units Larger than 2 TB
For Windows Server(TM) 2003 Service Pack 1 (SP1) and Windows XP 64-bit Edition (x64), Microsoft has added support for 64-bit block numbers in the disk/class layer, using the new SCSI commands included in the new SCSI-3 Block Commands-2 command set. GPT support has also been enabled for all Windows Server 2003 SP1 platforms. The new limits are as follows:
If you design and manufacture storage subsystems or PCI RAID devices, you can enable support for this capability by implementing the SCSI Block Commands-2 16-byte Command Descriptor Blocks (CDBs) for the following commands: READ CAPACITY (16), READ (16), WRITE (16), and VERIFY (16), and by implementing support for the long LBA version of the REASSIGN BLOCKS (07h) command.
The Windows disk class driver exposes new IOCTLs to support this capability:
IOCTL_DISK_REASSIGN_BLOCKS_EX
This IOCTL is similar to the IOCTL_DISK_REASSIGN_BLOCKS interface documented in the DDK. This IOCTL uses the REASSIGN_BLOCKS_EX structure, which has 8 bytes defined for the LBA.
IOCTL_STORAGE_READ_CAPACITY
This IOCTL can be used to query the disk capacity as returned by the READ CAPACITY command. This also provides the total disk length in bytes. This IOCTL returns the STORAGE_READ_CAPACITY structure.
For information about these interfaces, plus additional details about this change in Windows, see:
Large Logical Unit Support and Windows Server 2003 SP1
More Device Fundamentals - Overview...
Kits, Tools, Services, and Programs
Windows Logo Program Requirements Versions 2.2.1 Now Available
Microsoft is introducing updated "Designed for Windows" Logo Program system and device requirements in version 2.2.1. This revision, which supersedes version 2.2, provides new requirements for HD Audio and incorporates previous FAQ updates with the original version 2.2 requirements.
Download Version 2.2.1 of Microsoft Windows Logo Program System and Device Requirements
FAQ for Windows Logo Program (including an overview of changes in version 2.2.1)
Debugging Tools for Windows: New Beta Release
Beta versions of the 32-bit and 64-bit debugging tools are available for download.
Install 32-bit Beta Version 6.4.4.4
Install Native Itanium Beta and Native x64 Beta Version 6.4.4.4
Tips and Directions for Testing
Windows Driver Testing Best Practices
Thorough testing is essential to development of robust and reliable Windows drivers. A new paper on the WHDC Web site describes testing processes that driver developers can apply to achieve better test coverage for their drivers using available tools from Microsoft, including:
Configuring hardware for testing, including recommendations for debugger systems Installing software on test systems, including enabling the debugger and Driver Verifier during Setup Testing after installation, including tips for testing behind bridges and a sample test matrix Tips for lab automation
Download Windows Driver Testing Best Practices
Tips and Directions for Platforms
Live Meeting: Windows XP Embedded with Service Pack 2
Tune in to this Live Meeting and learn how to take advantage of everything that's new in Windows XP Embedded with Service Pack 2 that enables you to accelerate time-to-market as well as create more secure, manageable, and innovative experiences in and on your embedded devices. These Live Meeting events take place the first week in December.
Sign up now for Windows XP Embedded with SP2 Live Meeting
More PC Fundamentals...
News for Kernel-Mode Developers
Windows Driver Foundation Beta Program Invitation
The Microsoft Windows Device Experience Group invites you to participate in the beta program for the Windows Driver Foundation.
Invitation and Introduction to WDF
|
|
WinHEC and Driver DevCon News
In order to provide you the most cutting-edge technical and strategic Windows information, WinHEC and Driver DevCon will be held simultaneously in late April 2005. WinHEC will focus on engineering and design innovations for hardware and devices. Driver DevCon will focus on driver design and development issues for current and future versions of Windows.
Which conference should you attend?
WinHEC 2005
This annual industry conference focuses on future engineering and business directions for PC and device hardware, and Microsoft Windows operating systems.
WinHEC provides the year's best opportunity for engineers, designers, and business decision makers to:
Hear Bill Gates address vision and opportunities for a new industry wave of innovation. Network with Microsoft and other industry experts. Focus on technical issues for new hardware products. Explore new scenarios and strategies for client and server hardware platforms.
WinHEC 2005 will provide the information necessary for the hardware industry to build great Microsoft Windows PCs, servers, and devices for the platforms of today, tomorrow, and beyond.
Get Involved with WinHEC!
Industry participation is a key component of success for WinHEC. Your involvement in WinHEC 2005 will give your company, products, and services broad visibility and will demonstrate the essential role that your company plays as a key Microsoft partner and leader in the hardware industry.
Technical Presentation Opportunities
Join industry leaders in sharing information about engineering and design innovations that will define the future of the PC and server platforms.
Sponsor and Exhibitor Opportunities
Demonstrate your industry leadership by becoming a sponsor and exhibitor at the premier event for hardware engineers and developers.
Plan to attend this popular and industry-leading event for engineers, developers, and product planners.
Registration begins in early January 2005.
Learn more about WinHEC.
Windows Driver Development Conference (Driver DevCon)
This event allows experienced driver developers and testers to work closely with the Microsoft development teams creating new driver models and tools supporting advances in the Windows platform. Driver DevCon offers the chance to learn more about driver design issues for current and future versions of Windows.
If you develop or test Windows-based drivers, then this conference is designed for you. It offers:
In-depth knowledge transfer, education, and how-to sessions on the latest Windows development kits, tools, and resources Best practices for developing and testing your Windows driver Four days of deep technical content, hands-on labs, and previews of unreleased tools and kits in all areas of Windows driver development and testing, brought to you by your Microsoft peers: developers and testers
Driver DevCon is based on feedback from Windows driver developers and testers - everything from the conference format to the agenda content is defined by audience request.
Registration begins in early January 2005.
Visit the Driver DevCon site for additional details.
Tell us what you want!
What do you need from WinHEC and/or Driver DevCon to help you succeed in building products for new versions of Windows and in driver development?
Year to year, our conference attendees provide us with valuable feedback about our content and conference components. In the post-event reviews, attendees have said we continue to deliver! We plan the technical content, conference components, and interaction with Microsoft experts for each conference based on your requests.
What do you need from WinHEC and/or Driver DevCon to help you succeed in building products for new versions of Windows and in driver development? Please give us your requests and feedback - take the pre-conference survey now!
Security and Reliability
Best Practices for Security APIs
A buffer overrun is one of the most common sources of security risk. A buffer overrun is essentially caused by treating unchecked, external input as trustworthy data. The act of copying this data, using operations such as CopyMemory, Strcat, Strcpy, or Wcscpy can create unanticipated results, which allows for system corruption. In the best of cases, your application will abort with a core dump, segmentation fault, or access violation.
In the worst of cases, an attacker can exploit the buffer overrun by introducing and executing other malicious code in your process. Copying unchecked, input data into a stack-based buffer is the most common cause of exploitable faults. Preventing buffer overruns is primarily about writing good code. Always validate all your inputs and fail gracefully when necessary.
Security Best Practices in the Online SDK
More Driver Security and Reliability...
|
