Robust systems, like Operating Systems, contain a directory structure that is important to the organization and operation of the system. Legacy/X is not any different. Now, depending upon the operating system you are using the Legacy/X root folder is different.
The root folder for Legacy/X is C:\LEGACYX\
The root folder for Legacy/X is /var/LEGACYX/ or /private/var/LEGACYX/
The root folder for Legacy/X is /var/LEGACYX/
Following this standard will allow you to easily install third-part modifications and external door applications.
Everything related to the Legacy/X BBS product can be found across those different folders. Since there are multiple files for certain aspects of the BBS, it just made sense to organize them better for you.
Besides all of the subfolders, there should only be 1 file in this folder after a new install. It is called main.p, and contains the source for the whole project. Even though the file is over 100 lines line, it actually contains just a few lines of code.
It Starts off with a Program Name and Version:
Program LegacyX.v1191218; {this builds version}
In this example, you are looking at the current build as of these article. To understand our build number you simply that the first 3 numbers and add 1900 (119+1900=2019), followed by a 2 digit month (12=December), and 2 digit Day, the 18th.
Next, as you scroll threw the source, you will see the project comment ~ describing the Purpose, Copyright, Structures, Requirements, and major milestone dates. This is followed by a list of Internal Run-Time Libraries (RTL) which are required for the functionality of Legacy/X.
Now from Line 43 to Line 111, is a list of MODULES that are loaded by the compiler. For the most part, each module is a single (almost standalone) method that does one specific job during the functionality of the BBS itself. I list the method name in the comment to the right of each MODULE to help new developers know where to find different methods.
Lastly, from line 113 to 141, is the main startup and workflow of Legacy/X. As time permits, I will add a section to this wiki to actually document each MODULE.
The documentation folder contains a collection of PDF files which contain most if not all of the Wiki and a lot more. The goal is for someone designing their BBS to have all of the available resources in this one folder. You will find PDF documents that step you through screen by screen of the setup application. PDF documents that explain TCP/IP communications and how to leverage the TDXSock communications object.
DOORs were a very important asset when setting up a BBS in the 80's and 90's. Just like all of the games on your mobile device and on Facebook ~ people came to expect a BBS to have a unique theme and a handful of unique Door Games.
Legacy/X does everything possible to allow you to offer that same experience today to your users. Legacy/X supports a dropfile interface by create a file called DOOR32.SYS which contains all of the information most DOOR Applications required
Legacy/X also supports what I call plug-in doors, where Legacy/X simply passes the socket handle to the door ~ as the door has been built to leverage different modules of the BBS ~ allowing the door to work much more like a part of the BBS itself.
Lastly, Legacy/X supports a proxy mode to communicate to doors as if the BBS was you. This allows a sysop to run a Game Server for example, or have a different machine or VM (Virtual Machine) that is capable of running old DOS games.
GENERAL contains almost all of the external graphics files for the BBS. The defacto ones are:
Notice, none of those have file extensions. Mainly due to the fact there are so many possible standards available to a sysop. For example, if you wanted to, you can configure Legacy/X to use the Commodore ASCII character set called PETASCII and follow the Commodore colors. Since Legacy/X operates as an Operating System service, it does not do any local rendering ~ allowing for almost endless end-user graphics.
Another Graphics Note: If you use PCBoard @X color codes, or our matching | (pipe) color codes ~ Legacy/X will auto-translate the graphics and colors to support systems that are Black and White, Use CodePage 437 (IBM Character Set) or today's Unicode UTF8 format, along with the standard 16 color Foreground and Background sequences ~ all from a single file ~ if it is encoded correctly.
While the name implies this is where everything would reside, it is actually the RULES and FILTERS folder.
This is a very important folder, it contains a collection of ASCII test files with the extension .MNU (for MENU). While some systems allow you to define the choices available at a MENU through their .MNU file. Legacy/X uses the .MNU file to literally specify the overall software workflow.
As mentioned earlier, the main block of code for Legacy/X is very small. As it loads up the system configuration/settings, and initiates the ANSI Detect/Splash Screen and then loads and executes the login.mnu file. Which decides to show you the WELCOME screen, the INTRO screen, the LOGIN screen and asks for your language ~ then hands the process over to the next menu file calls graphics.mnu.
By implementing this strategy, every Legacy/X BBS can look like any system the sysop wants to mimic. We even did a simple test site that appeared like PCBoard, then with a redesign and graphic file changes, it appeared like CompuServer from the 90's.
The Messages folder contains one or more JAM Message Areas. JAM being the initials of the authors who designed the structure (Joaquim-Andrew-Mats) (Joaquim Homrighausen, Andrew Milner, Mats Birch, and Mats Wallin). Prior to JAM, most message formats had design flaws (limitations). One could only handle 32,000 messages total, another could only have 9 replies in the reply chain. And most were/are limited in the poster and recipient name fields (like 25 character, 36 character and even 45 character). JAM was designed with forward thinking of features that were not even in use in BBSing nor ARPANET (now known as the Internet).
Note, Message Networks are expected to use a different folder, usually outside of the BBS hierarchy. This way, the sysop can do a nightly backup of the whole BBS (source and system related files) and not worry about the Message Network files, which in most cases can be %RESCAN(ed) if a system goes down.
This is the folder that contains all (80 files) of the methods that are Legacy/X BBS. Since we live in the era of MODs (Modifications), I tried to make it very straight and simple for third-party developers to publish their modified versions of the Legacy/X methods. Even giving select authors the ability to extend the MENU COMMANDS list. One of the few files that I ask people to refrain from making modifications without my approval. This avoids chaos down the road if we rollout a mandatory patch.
I ask people to think of methods.inc like Linux KERNEL SysCalls list ~ it is the roadmap used internally to hook everything together.