I, Rob Swindell, started writing Synchronet BBS Software from scratch in 1990 (at the age of 20). At that time, I had been programming in C for about a year and a half. Needless to say, some of the early design decisions, I would've made differently today (hindsight is always 20/20). When browsing the code, keep in mind there are still portions of the source that have remained unchanged for the past ten years (a virtual eternity in modern software). This should also explain any perceived inconsistencies in programming style or design approach.
Synchronet v1 was written almost entirely in C with a couple of small portions written in x86 assembler. Synchronet was an entirely “hard-coded” BBS, that is, the user menu structure and command key sequences were hard-coded into the source code (the ASCII/ANSI/RIP menu files themselves were sysop replaceable/customizable). Synchronet v1 was a copyrighted commercial software package, and as such, was not distributed with source code. Synchronet v1 utilized an inefficient message storage method, using a separate file for each message (for both private e-mail and public message forums). Synchronet v1 was available as a 16-bit console-mode DOS program only.
Multi-node features (chat, multi-user games, etc) were abundant from the very first release, but each node required a separate instance of the program. Because of this requirement, local area networks (LANs) were often utilized for connecting multiple PCs as part of a single BBS as well as DESQview, Windows, and OS/2 for their DOS multi-tasking abilities.
Synchronet v2 incorporated a programmable command and menu structure (PCMS), mostly doing away with hard-coded user commands. This allowed emulation of competing BBS packages (from the user's perspective) as well as sysop-customizable menus and dynamically loaded modules. A module/script compiler called Baja was included that utilized a high-level BASIC-like programming language.
Synchronet v2 also incorporated a new database-style message base format called SMB (Synchronet Message Base). The specifications and C library were released free to the public in hopes of encouraging competing BBS packages and utility authors to adopt SMB as a favorable alternative to the prolific Hudson, JAM, and Squish message base formats.
A binary configuration file format (.cnf) was introduced in v2 to speed up the loading of configuration files and improve extensibility.
Although a 32-bit console-mode OS/2 version of Synchronet v2 was released in 1995, it retained the same multi-node design as its DOS counterpart and required a separate instance of the program for each node. It was also during the active development life of Synchronet v2 that I began to release 32-bit extended DOS (DPMI), OS/2, and Win32 flavors of many of the utilities included with Synchronet.
Synchronet v2 remained commercial software until it was released as Freeware in early 1997 and the source code was documented, packaged, and released to the Public Domain later that same year (the Digital Dynamics' copyright was officially relinquished at this time). In December of 1999, I released a public beta of v2.30c for DOS and OS/2 (in binary form) that fixed a few millennium bugs and introduced some of the minor features I had incorporated thus far in my development of Synchronet v3.
Synchronet was significantly redesigned in the fall of 1999 as a multi-threaded/multi-user telnet server for Win32 platforms. To aid the transition from the single-node-per-process model to a single-node-per-thread model, most of the source modules were converted from C to C++ so they could automatically inherit the current node's properties (previously implemented as global variables). Serial/modem/dial-up user support was not migrated from v2 to v3, so only telnet logins were supported. Configuration and database file compatibility with v2 was consciously maintained to allow mixing v2 and v3 nodes on the same live BBS. The main BBS module and telnet server was implemented as a single Win32 dynamic link library (DLL) built with Microsoft Visual C++.
Integrated FTP and Mail (SMTP/POP3) servers were also created for v3. The FTP and Mail servers were implemented as individual Win32 DLLs built with Microsoft Visual C++.
A GUI front-end called the Synchronet Control Panel was created using Borland C++ Builder and the VCL visual framework. The Synchronet Control Panel (SBBSCTRL.EXE) married the separate server DLLs and provided a uniform place for the sysop to view the various log files, real-time status and statistics, and perform system configuration and maintenance functions. It provided the functional equivalent of the “Wait for call screen” in v2.
A GUI user editor was also created using Borland Delphi and the VCL. Delphi was chosen for this project in anticipation of the Borland Kylix release and it represents my very first Pascal programming effort.
Synchronet v3 still has some reliance on some of the v2 utilities (most notably, SCFG.EXE), but moving as much code as possible to 32-bit (GUI where appropriate) is an increasing priority. Additionally, keeping as much of the code base as modular and portable as possible is a high priority. Reliance on the 16-bit assembler modules used in v2 has been eliminated.
The first official release of Synchronet v3 was v3.00b for Win32 (Windows 95-OSR2, 98, 98-SE, NT4, 2000, and Millennium Edition), released on June 25th, 2000. This release was simply Freeware, was not copyrighted, and did not include source code or any implied licensing (GNU GPL or otherwise). At this point, no proper revision control system had ever been utilized for Synchronet development.
Synchronet for Unix is considered by myself and many others to be a potentially highly-desirable “product”. From the onset of v3 design and development I have kept an eye towards GNU/Linux (and other free Unix-like OSes). The Unix/Linux community is increasingly biased towards free/open-source software, so I've been planning for some time to make Synchronet an open-source project, but was leaning towards waiting until after the Unix/Linux port was complete. In the mean-time, I've been getting increasingly frequent offers from Linux developers to assist in the porting effort. Since I had no proper revision control system in place, it would've been a logistical nightmare to co-develop Synchronet with anyone in a geographically undesirable location. Additionally, I had no copyright or licensing in place to protect the Synchronet source code from proprietary software developers.
This is not to suggest that only Unix/Linux sysops would potentially benefit from Synchronet becoming an open-source project. It's just that Unix users are traditionally more likely to be willing (and able) to mess with the source code, and hence, more likely to submit useful modifications to the project. In addition, development tools (i.e. C/C++ compiler, Make utility, CVS, etc) are usually included free with Unix-like operating systems, while they are not typically as readily available to Windows users.
So I created a revision control database (repository) using CVS and checked-in the v2.3 and v3 source code trees along with all the various menus, text files, and documents included in Synchronet distributions. I chose CVS as the revision control system because it is free software and is the tool of choice among most free/open-source software developers. I would've preferred to use one of the commercial revision control systems I've become accustomed to using in my professional development career, but their price and status as proprietary software would have potentially deterred valued open-source developers from contributing to the project.
I also copyrighted all of the source code (as Rob Swindell) and put the majority of the v3 source code files under the GNU General Public License to protect them from inclusion in proprietary projects. I put the XSDK and SMBLIB modules under the GNU Lesser General Public License, which allows them to be linked with proprietary projects.