Linux build progress

[codefenix-dev]

I spent the last few days adding compiler directives to the source and header files, and managed to successfully compile working Linux versions of the setup, umrc-bridge, and umrc-client programs on Linux Mint.

Problem is, umrc-client only seems to work properly in local (-L) mode. For whatever reason, it isn't properly capturing input from the user when ran as a door. Looking into it further with my faithful testers. All other functionality works as expected, just like the current Windows build.

Ideally, I'd like to understand this more before I commit any code changes, but I may go ahead and commit what I have and simply hold off on an updated release. That way, at least people who understand Linux better than I do could try their hand at compiling it themselves.

I'll post again in another day or two.

[gab-dev-7]

Hey, keeping it simple—this sounds exactly like a Canonical Mode vs. Raw Mode issue with the Linux terminal (termios).

When you run locally (-L), your shell likely handles the raw input for you. But when running as a door, stdin often defaults to "Canonical" mode, which buffers everything until the user hits ENTER. If your client is waiting for single keystrokes (like od_get_key in OpenDoors), it will sit there forever ignoring input because it's waiting for a newline that never passes through the buffer.

You likely need to force the terminal into raw mode at startup when in door mode. In C on Linux, it usually looks something like this:

struct termios raw;
tcgetattr(STDIN_FILENO, &raw);
raw.c_lflag &= ~(ICANON | ECHO); // Disable buffering and echo
tcsetattr(STDIN_FILENO, TCSAFLUSH, &raw);

Also, double-check that stdin isn't fully buffered. Adding setbuf(stdin, NULL); at the start of your main function is a quick sanity check to rule that out.

Good luck with the port! Linux door logic can be a pain compared to Windows handles.

[codefenix-dev]

Hi gab-dev-7!

To elaborate slightly on the user input issue, the testing user who reported it described it as sometimes needing two key presses to get a single character typed into the door, and other times it just appeared to do whatever it wanted.

However, in the time since I posted the progress announcement, we made two discoveries:

• Mystic BBS is the only BBS software known so far that has this user input problem. I.E.: Synchronet works just fine.
• The door's user input works fine in Mystic when using the DOOR.SYS drop file type instead of DOOR32.SYS.

Upon realizing this, I did add a brief note to the README.md in a section labeled "NOTE to Linux Users":

It has been observed that using the DOOR32.SYS drop file type with this door
can lead to user-input issues on Mystic under Linux. If DOOR32.SYS does not
work properly with your BBS type, then use DOOR.SYS instead.

We do have a couple working Linux setups over at A-Net Online Mystic BBS (mystic-anet.online:23) and Unix-Bit (x-bit.org:1336). Anyone else who wants to try the Linux build and has the ability to build from source is invited to try it out as well (README.md outlines the steps involved).

I do appreciate you taking the time to explain in detail a possible cause. But seeing as how it can be made to work properly by simply changing the drop file, I'm inclined to think this is just a quirk with Mystic+Linux.

Still, I will try your suggestion and see how it goes! Thanks again!