No, what you see here isn't the source code to Windows XP Beta 2,
nor do I even have access to source code. This is the source tree layout
of the Windows XP Beta 2 sources, complete with file names.
The source tree layout above probably represents about 90% of the
tree for the NTOSKRNL.EXE (multiprocessor version) image file, the NTFS
file system driver (NTFS.SYS), the TCP/IP driver (TCPIP.SYS) and the multiprocessor
HAL (HALMPS.DLL).
NTOSKRNL.EXE contains all of Windows XP's executive subsystems,
including the Cache Manager, Memory Manager, Process Manager, Object Manager,
and I/O Manager. It also contains the Kernel, which implements NTs synchronization
mechanisms. I threw in the other drivers so that the relationship of the
HAL tree and key drivers with respect to the main NTOSKRNL source would
be apparent.
So how did I get the information used to build the tree? I extracted
file names from the checked (debug) build images of various operating
system image files. The checked build version of the Windows XP (and Windows
NT and Windows 2000, for that matter) operating system includes many "assert"
statements. An assert statement is simply a run-time expression that should
be true. If it isn't, then some program variable has attained a value
considered impossible by the program and the assert statement flags the
condition in some way visible to a programmer. Developers sprinkle code
with assertions to catch faulty assumptions and programming errors.
In Windows XP, device drivers and kernel-mode subsystems include
assertions by using the ASSERT macro. This is an example ASSERT from the
keyboard class driver, the source of which comes with the Windows 2000
Device Driver Kit (DDK):
ASSERT(0 < deviceExtension->TrustedSubsystemCount);
The ASSERT macro is defined in the NTDDK.H DDK header file as:
#if DBG
#define ASSERT( exp ) \
if (!(exp)) \
RtlAssert( #exp, __FILE__, __LINE__, NULL )
#else
#define ASSERT( exp )
#endif
This means that the ASSERT is a no-op in release builds, but if
the assertion test fails in a debug build the function RtlAssert is invoked.
RtlAssert prints the expression, file, and line number information as a
debug output, and causes a debug break so that a developer can examine the
conditions that lead to the assertion failure from inside a kernel debugger.
The file name parameter causes the source file's file name to be embedded
in its image file, and it can be extracted with a string-search utility
like my own Strings.
Back to Top