open https://gitlab.synchro.net/main/sbbs/-/issues/1217

The 31-line DOOR.SYS drop file (SCFG drop file type "GAP (original)", see #399) is written as 31 real lines followed by 21 blank lines. The padding was added in ba8fdb5a7f (cups-37-soap, 2024-10-16) so that doors requiring all 52 lines would still find 52 lines, on the assumption that no program would object to extra lines.

OpenDoors objects. It decides which DOOR.SYS variant it is reading by testing whether a 36th line can be read at all (`src/odoors/ODInEx1.c`). A blank line reads fine, so the padding makes it classify the file as `DOORSYS_WILDCAT` (the 52-line variant) and then consume lines 32-52 as real data.

Reproduced with the bundled `ex_diag` example against hand-built drop files:

```
31 real lines + 21 blank -> Drop File Type : WildCat! DOOR.SYS
52 real lines -> Drop File Type : WildCat! DOOR.SYS
```

Consequences for a door built with OpenDoors:

* `od_control.sysop_name` is empty (line 35)
* `od_control.user_handle` is empty (line 36)
* `od_control.user_comment` is empty; `user_messages`, `user_upk`, `user_downk` are 0
* `user_error_free` is false (line 38)
* `user_birthday` and `event_starttime` pick up a stray CR

Confirmed against the drop file OpenDoors rewrites on exit: lines 35 and 36 come back blank.

Without the padding, OpenDoors hits EOF at line 32, stays in `DOORSYS_GAP` mode, and leaves those fields at their configured defaults. For OpenDoors doors, the padding therefore does the opposite of what it was added for.

The door kits that require all 52 lines are not named in the commit, so this is a trade-off rather than a clear revert. Possible directions:

1. Drop the padding and write a true 31-line file.
2. Keep the 52-line count but populate the identity fields the padding currently blanks (32, 35, 36), leaving the rest empty. That satisfies both the count requirement and OpenDoors.
3. Make the padding its own SCFG option, separate from the 31-vs-52 choice.

Found while comparing our DOOR.SYS generation against the OpenDoors and xpdoor parsers.

— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1217#note_10106

Heh, OpenDoors doesn't care if there's more lines than it expects, it just expects 31 or 52 lines. ;)
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1217#note_10107

The padding was not speculative -- it was tested. The history is in `syncprog`, 15-16 Oct 2024, replying to the commit announcement for b2601ca82c (stack-3-build, 2024-10-15):

* **#50075, Nightfox:** Thunder Cat v3.30 runs fine with the 52-line DOOR.SYS, but after switching to the new 31-line option "Thunder Cat didn't run." (dosemu2 on Linux.)
* **#50076, Digital Man:** "The problem that Rixter reported was with line 42 (Time credit, in minutes)." and "I wonder if adding 21 blank lines would resolve that problem."
* **#50083, Nightfox:** "the door was giving an error value of 62 with the 31-line door.sys. I tried adding 21 blank lines to that door.sys and manually running the door, and it didn't report that error anymore."

ba8fdb5a7f (cups-37-soap, 2024-10-16) landed the same day.

So Thunder Cat v3.30 genuinely requires 52 lines to be present, and the padding is confirmed to fix it. Error 62 is the QuickBASIC "Input past end of file" code, which fits a door that reads a fixed 52 lines regardless of the format it was told to expect, though I have not confirmed what Thunder Cat is written in.

That rules out option 1 in the description above. Dropping the padding would restore the OpenDoors behavior at the cost of re-breaking the door the 31-line option was added for.

Option 2 is the one the evidence actually supports, and can be narrowed further. Rixter's complaint was specifically **line 42** (time credits). Blanking all of lines 32-52 was broader than that report required, and lines 32-36 -- birthday, main and gen directory, sysop name, alias -- are precisely the ones OpenDoors reads once it has decided the file is the extended variant.

So: keep writing 52 lines, populate lines 32-36 as we do for the 52-line type, and leave line 42 (plus whatever else has no known-good value) blank. Thunder Cat still finds its 52 lines, OpenDoors gets a sysop name and a handle instead of empty strings, and the field that caused the original report stays empty.

Worth confirming with a Thunder Cat v3.30 run before committing to it, since the only thing we know for certain is that the door counts lines and that line 42 upset it.

I could not find the original Rixter report in the local message bases or in this tracker; the summary in #50076 appears to be the only record of it.

— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/1217#note_10110

Agreed -- and that is the whole of it. It picks between the two by whether line 36 exists, so the padded file *is* the 52-line format as far as it is concerned:

`DOORSYS_WILDCAT` is set inside `if(fgets(<line 36>, 80, pfDropFile) != NULL)` in `ODInEx1.c`, and a blank line reads fine. `ex_diag` prints `WildCat! DOOR.SYS` for the padded 31-line file and for a real 52-line one alike.

So our "GAP (original) / 31 line" setting never reaches OpenDoors as 31 lines. It arrives as the extended format with 32-52 empty, and `sysop_name` and `user_handle` come out as empty strings rather than keeping their configured defaults.

— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)