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.