PWAD size limit
There is a strict limit on PWAD directory size in the vanilla Doom engine. Based on the size of the executable's stack segment and the amount of space already in use when the offending routine is executed, the limit on lumps in a single WAD file's directory is approximately 4046.
If the limit is reached, a lockup during W_Init occurs, with no error message displayed. The lack of an error is due to the I_Init routine not having been called yet, which causes the DMX routine DMX_DeInit to malfunction. On a real DOS machine, the program may then display bizarre behaviors such as filling the screen with randomly changing colored text. A reboot is required to escape from this situation.
The cause of the crash is due to the Doom engine's W_AddFile routine using Watcom's alloca macro. alloca is a non-standard but widely implemented C function which allocates memory from the process call stack.
However, alloca is, as in most implementations, limited to the size of the stack segment. This is determined at compile time. In vanilla Doom, this was a 64 kilobyte segment. This means that, subtracting off the stack space already used when calling W_AddFile, there is only room left for approximately 4046 lumps. Any PWAD larger than this will cause memory corruption and possibly lock up the system because the return value of alloca is not checked by the code, but instead is passed blindly to the read function later.
Under such conditions, the Doom engine will read the file into low DOS memory, starting at offset 0 and continuing for the size of the wad directory. This may corrupt portions of the operating system which are not virtualized by the program's DPMI provider, leading to unpredictable and potentially dangerous behavior.
- It is possible to split large PWADs into multiple files, each with less than 4000 lumps, and avoid the problem altogether, as it applies on a per-file basis only.
- The executable can be modified with a hex editor or patching utility to change the stack pointer and data segment size. Increasing the stack to 512 KB will allow up to around 32768 lumps, at the price of increasing the system memory requirements of the program.
- discussing this bug