PWAD size limit

There is a strict limit on PWAD directory size in Vanilla Doom. While the definite number has yet to be determined, the limit seems to be around 4046 lumps.

Symptoms
If the limit is reached, a lockup during W_Init occurs, with no error message displayed. The lack of an error is due to I_Init not being called yet. On a real DOS machine, Doom will show bizarre, unexplainable behaviors such as randomly changing colored text blocks. A reboot is then required.

Demonstration
The effect can be demonstrated by creating a PWAD that reaches said limit. It is recommended to do this in DosBox to avoid data loss.

Cause
The cause of the crash is due to Vanilla Doom's W_AddFile using Watcom's alloca macro. alloca is a non-standard but widely implemented C function which allocates memory from the "stack". The "a" in alloca means "automatic", because such allocations have the same lifetime as local variables in Watcom C.

However, alloca is limited in Watcom's implementation to the size of the stack segment. This is determined at compile time. In Vanilla Doom, this was a 64 KB 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/or a lockup, because the return value of alloca is not checked by the code, but instead is passed blindly to the read functions later.

Under such conditions, Vanilla Doom will read a file into lower DOS memory, starting at offset 0 and continuing for the size of the wad directory. In some cases, this would trash the entire machine's interrupt table, and a considerable portion of whatever follows during the file operation.

Workarounds
For DOS Doom players, this is extremely dangerous. Any mappers that fear reaching this limit should split their work into sections if possible, reducing the total amount of lump entries loaded. However, there are some workarounds available that require opening Vanilla Doom in a hex editor, and changing the stack pointer and data section size. Increasing the stack to 512 KB will allow a theoretical 32768+ size, at the consequence of higher system memory requirements.