Commits (1)
<title>Synchronet Source Code</title>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="Microsoft FrontPage 5.0" name=GENERATOR><meta name="Microsoft Border" content="tb, default">
<BODY><!--msnavigation--><table border="0" cellpadding="0" cellspacing="0" width="100%"><tr><td>
<p><a href="../overview.html" target="Body">
<img border="0" src="../images/synchronet2.png" align="middle" width="676" height="210"></a></p>
</td></tr><!--msnavigation--></table><!--msnavigation--><table dir="ltr" border="0" cellpadding="0" cellspacing="0" width="100%"><tr><!--msnavigation--><td valign="top">
<p align="left"><font face="Arial Black" color="#808080"><i>Synchronet - Source
<font face="Arial", "Helvetica">
<H2>Availability</H2>The <A href="">Synchronet</A> source code is
<A href="">freely</A> available:
<LI>Anonymous FTP (for official source code releases):
<LI><A href="">v2.30b for DOS and OS/2</A> (1997)
<LI><A href="">v3.00c for Win32</A> (2001)
<LI><A href="">v3.12a for Win32</A> (2004)
<LI><a href="">v3.14a for
Win32</a> (2006)<LI><A href="">Nightly-archive for Win32</A> (Current)
<LI><A href="">Nightly-archive for Linux-x86</A> (Current)
<LI>Anonymous <A href="">CVS</A>
(for <i>current</i> source code or previous releases by label):
<li>Repository: <tt></tt>
<li>Mirror: <tt></tt>
<li>Required modules for <i>building</i> Synchronet:
<li><tt>src-sbbs3</tt> (alias for several modules)
<li><tt>lib/mozilla/js/<i><b>os</b></i>.release (or .debug)
<br>example: lib/mozilla/js/linux.release</tt>
<li><tt>lib/mozilla/nspr/<i><b>os</b></i>.release (or .debug)
<br>example: lib/mozilla/nspr/win32.release</tt>
<li>Or you may use one of the following module aliases<br>
(for all required libraries for the specified OS and build type):
<li>Required modules for <i>running</i> Synchronet (if you don't already have Synchronet installed):
<li><tt>run-sbbs3</tt> (alias for several modules)
<li>Example labels (for checking-out a specific release):
<li>CVS command-line example:
<LI><tt>cvs -d co
<li>Win32 batch file to get/update required modules using the
<a href="">
Win32 command-line CVS client</a>:<ul>
<a href="*checkout*/install/checkout.bat">
<LI>Web-based CVS access, particularly useful for browsing the repository and visually comparing revisions of files ("diff'ing")<br>
<a href=""></a>
<LI>Log of recent commits (changes/additions) to the CVS repository<br>
<a href=""></a>
<LI>Rob's to-do list<br>
<a href=""></a>
<li>Step-by-step instructions on how to download, build, and run the current
source code on Unix (Linux, FreeBSD, and OpenBSD),
see<br><a href=""></a></li><br>
<H2>Building on Windows</H2>
Unlike on Unix, a combination of compilers may be utilized to build <i>Synchronet for Win32</i>.
If you have Borland's <a href=""> free command-line C++ compiler</a>
(v5.5) installed,
you can build almost everything except the GUI portions (e.g. <i>Synchronet Control Panel</i>),
which require <i>Borland C++ Builder</i>, and the FOSSIL drivers, which require <i>Microsoft Visual C++</i>.
I use <i>Microsoft Visual C++ 6</i> for most of the non-GUI portions of Synchronet
because it has a better debugger and more solid IDE (in my opinion).
However, Borland provides a much better GUI framework (VCL) with <i>C++ Builder</i> and
a handy console I/O library (conio) not present in Microsoft's C run-time library
(Note: Stephen Hurd has created a portable conio-compatible library for Win32, so this Microsoft omission
is no longer a factor).
Even though I use <i>Microsoft Visual C++</i> to build most of the Synchronet command-line utilities
and all the DLLs, you may use <i>Borland C++</i> or <i>C++ Builder</i> instead, if you prefer.
But note: if you rebuild any of the DLLs, you must also re-link <tt>sbbsctrl.exe</tt> with the
Borland import libraries for those DLLs (see <tt>src/sbbs3/ctrl/makelibs.bat</tt>
for details).
<b>Caveat:</b> There is a known limitation with the Borland C run-time library (RTL) which may effect any Synchronet
system built soley with Borland C++: The Borland C RTL is limited to <i>50</i> open files.
Microsoft's C RTL does not have this limitation. The solution requires you have the
source code to the Borland C RTL (normally in the <tt>Source\rtl</tt> directory):
<li>Increase the value for the <tt>_NFILE</tt> definition in <tt>include/_nfile.h</tt>
<li>Compile <tt>rtl\Source\io\files.c</tt> and <tt>files2.c</tt>
<li>Link <tt>files.obj</tt> and <tt>files2.obj</tt> with your Synchronet executable
(i.e. <tt>sbbs.exe</tt> or <tt>sbbsmono.exe</tt>)
As for the build files: the <tt>.dsp</tt> and <tt>.dsw</tt> files are used by <i> Microsoft Visual
the <tt>Makefiles</tt> are used by <i>Borland C++ 5.5</i> (or <i>C++ Builder</i>),
and the <tt>.bpr</tt> files are used by <i> C++ Builder</i>.
<table border="1">
<tr><th>Project<th>Build File<th>Compiler
<tr valign=top><td rowspan=2>sbbs.exe, ftpsrvr.dll, mailsrvr.dll, services.dll,
and most utilities (e.g. addfiles.exe, baja.exe, etc.)
<tr valign=top><td>src/sbbs3/Makefile<td>bcc32
<tr valign=top><td rowspan=2>scfg.exe<td>src/sbbs3/scfg/build.bat<br>src/sbbs3/scfg/scfg.dsw<br>src/sbbs3/scfg/scfg.dsp<br>
<tr valign=top><td>src/sbbs3/scfg/Makefile<td>bcc32
<tr valign=top><td>echocfg.exe<td>src/sbbs3/Makefile<td>bcc32
<tr valign=top><td>sbbsctrl.exe<td>src/sbbs3/ctrl/build.bat<br>src/sbbs3/ctrl/sbbsctrl.bpr<td>bcb6
<tr valign=top><td>chat.exe<td>src/sbbs3/chat/chat.bpr<td>bcb6
<tr valign=top><td>useredit.exe<td>src/sbbs3/useredit/useredit.dpr<td>delphi6
<tr valign=top><td>dosxtrn.exe<td>src/sbbs3/dosxtrn/make.bat<td>msvc15
<tr valign=top><td>sbbsexec.dll<td>src/sbbs3/sbbsexec.dsp<td>msvc6
<tr valign=top><td>sbbsexec.vxd<td>src/sbbs3/execvxd/makefile<td>msvc6 and VtoolsD
Compiler legend:<br>
<table border=1>
<tr><th>Abbreviation<th>Full Product Name
<tr><td>bcb6<td><a href="">Borland C++ Builder 6</a>
<tr><td>bcc32<td><a href="">
Borland C++ Compiler 5.5</a> (<b>Free!</b>) or Borland C++ Builder
<tr><td>delphi6<td><a href="">Borland Delphi 6</a>
<tr><td>msvc6<td><a href="">Microsoft Visual C++ 6</a>
or <a href="">Visual C++ Express</a>
with the <a href="">Platform SDK</a>
<tr><td>msvc15<td>Microsoft Visual C++ 1.5 (16-bit)
<h3>Step-by-step Instructions (using Microsoft Visual C++ 6.0)</h3>
<li>Install Visual C++ (if you haven't already)
<li>Get the Synchronet source and library files (if you haven't already)
<li>Edit <tt>src\sbbs3\build.bat</tt> (if necessary) to point to your MSVC installation directory
<li>At a command prompt, go to the Synchronet <tt>src\sbbs3</tt> directory and run <tt>build.bat</tt>
<li>At a command prompt, go to the Synchronet <tt>src\sbbs3\scfg</tt> directory and run <tt>build.bat</tt>
You can now copy the DLL and executables from the following directories into your Synchronet <tt>EXEC</tt> directory:
If the DLLs you just built are from a more recent version of Synchronet than your Synchronet Control Panel executable (<tt>sbbsctrl.exe</tt>),
you will need to use <tt>sbbs.exe</tt> or <tt>sbbsNTsvcs.exe</tt> instead of <tt>sbbsctrl.exe</tt> to run Synchronet.
See <tt>docs\sbbscon.txt</tt> for more details on using the console mode version of Synchronet.
See <tt>docs\sbbsNTsvcs.txt</tt> for more details on using the NT services version of Synchronet.
<h3>Step-by-step Instructions (using Borland C++ Builder)</h3>
<li>Install C++ Builder (if you haven't already)
<li>Make sure your C++ Builder <tt>bin\bcc32.cfg</tt> file (create the file if necessary) contains the correct <i>include</i> and <i>lib</i> paths.
<li>Get the Synchronet source and library files (if you haven't already)
<li>At a command prompt, go to the Synchronet <tt>src\sbbs3</tt> directory and run <tt>make</tt>
<li>At a command prompt, go to the Synchronet <tt>src\sbbs3\scfg</tt> directory and run <tt>make</tt>
<li>At a command prompt, go to the Synchronet <tt>src\sbbs3\ctrl</tt> directory and run <tt>build.bat</tt>
You can now copy the DLL and executables from the following directories into your Synchronet <tt>EXEC</tt> directory:
If you wish to build binaries with debugging information, add <tt>DEBUG=1</tt> to your <tt>make</tt> command-lines and
copy the binaries from the <tt>.debug</tt> instead of <tt>.release</tt> directories.
If you only have the free Borland command-line C++ compiler, all of the above steps still apply except for those
referencing the <tt>src\sbbs3\ctrl</tt> directory. Also, if the DLLs you built are from a more recent version of
Synchronet than your Synchronet Control Panel executable (<tt>sbbsctrl.exe</tt>), you will need to use <tt>sbbs.exe</tt> (or <tt>sbbsNTsvcs.exe</tt>)
to run Synchronet.
See <tt>docs\sbbscon.txt</tt> for more details on using the console mode version of Synchronet.
See <tt>docs\sbbsNTsvcs.txt</tt> for more details on using the NT services version of Synchronet.
<H2>History (as of October 2000)</H2>
<H3>The Beginning</H3>I, <a href="">Rob
Swindell</a>, 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.
<H3>Version 1</H3>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
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.<BR><BR>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.
<H3>Version 2</H3>Synchronet v2 incorporated a programmable command and menu
structure (<i>PCMS</i>), 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 <I>Baja</I> was included that utilized a high-level BASIC-like
programming language.<BR><BR>Synchronet v2 also incorporated a new
database-style message base format called <I>SMB</I> (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
<p>A binary configuration file format (.cnf) was introduced in v2 to speed up
the loading of configuration files and improve extensibility.<BR><BR>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.<BR><BR>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 <a href="">Public
Domain</a> 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.</p>
<H3>Version 3</H3>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 <a href=""> Microsoft Visual
C++</a>.<BR><BR>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++.<BR><BR>A GUI front-end called the
<I>Synchronet Control Panel</I> was created using <a href=""> Borland C++ Builder</a> 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 &quot;Wait for call screen&quot; in v2.<BR><BR>A GUI user editor was also created using
<a href=""> Borland
Delphi</a> and the VCL. Delphi was chosen for this project in anticipation of the
Borland <A href="">Kylix</A> release and it
represents my very first Pascal programming effort.<BR><BR>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.<BR><BR>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.
<H3>Today (October 2000)</H3>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 <a href="">GNU</a>/<a href="">Linux</a> (and other free Unix-like OSes). The
Unix/Linux community is increasingly biased towards <a href="">free</a>/<a href="">open-source</a> 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 <a href=""> proprietary
software</a> developers.
<p>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.<BR><BR>So I created a revision control database (repository) using
<A href="">CVS</A> 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.<BR><BR>I also <a href="copyright.html"> copyrighted</a> all of the source code (as Rob Swindell) and put the majority of the v3 source code files under the
<A href="">GNU General Public License</A> to
protect them from inclusion in proprietary projects. I put the XSDK and SMBLIB
modules under the <A href="">GNU Lesser
General Public License</A>, which allows them to be linked with proprietary
<p>Presumably, you are reading this file because you want access to the source
code. And you want access to the source code because you plan on making
modifications (or maybe you just want to verify there aren't any &quot;back
doors&quot;). In any case, if and when you make useful modifications to the
source code, you are encouraged to submit those changes to <a href="mailto:mods&">mods&</a>
for possible inclusion in a future Synchronet release. Frequent contributors may
become official co-developers and be given direct read/write access to the CVS
repository by <a href="">me</a>, the maintainer of the project.</p>
<h3>Custom Modifications</h3>
<p>If you are modifying the code for use on a single BBS and do not wish to give
those modifications to anyone else, you have that right. To make synchronization
of your version with the official Synchronet releases easier, it is highly
recommended that you predefine a preprocessor symbol (e.g. MYMODS) and then wrap
your modifications in a conditional compilation statement. Example:</p>
<pre>#ifdef MYMODS
bprintf(&quot;You are experiencing my custom modification.\r\n&quot;);
<p>If you are changing existing lines of code, it is recommended that you
include both the original and modified versions in your source and use
conditional compilation statements to determine which version will be used.
<pre>#ifdef MYMODS
i = j/100;
#else /* Original code */
i = j/50;
#endif </pre>
<p>This allows you to easily <i>&quot;</i>undo<i>&quot;</i> your modifications
for testing purposes (by simply undefining MYMODS) as well as clearly marking,
for future reference, which parts of the code were modified by you.</p>
<h3>Coding Style</h3>
<p>If you'd like to submit your modifications for possible inclusion in a future
Synchronet release, it would be beneficial if the programming style was
consistent with the style of the existing code base. Consistency of style helps
improve readability and maintainability of the source code.</p>
<p>Prior to Synchronet v3, I used a form of &quot;condensed&quot; <a href="">K&amp;R</a>
style to get as much code in an 80x25 character display as possible while
maintaining some degree of readability.&nbsp;</p>
<pre><b>Example (K&amp;R style):</b>
char line[MAXLINE];
int found = 0;
while (getline(line, MAXLINE) &gt; 0)
if (strindex(line, pattern) &gt;= 0) {
printf(&quot;%s&quot;, line);
return found;
<b>Example (Synchronet v2 style):</b>
char line[MAXLINE];
int found=0;
if(strindex(line,pattern)&gt;=0) {
found++; }
<p>As you've probably noticed, in the Synchronet v2 style, the body of the
function is not indented and the closing curly brace is not on its own line.
Additionally, unnecessary white-space characters have been removed from within
the body of the expressions. While the above examples do not demonstrate the
potential advantages of compressing white-space in a C coding style, you can
imagine how the limitations of an 80 column display could make heavily nested
expressions difficult without resulting to such measures.</p>
<p>In Synchronet v3, I've taken advantage of modern GUI text editors capable of
displaying more than 80 characters on a line and have&nbsp;
&quot;uncompressed&quot; the style to a degree:</p>
<pre><b>Example (Synchronet v3 style):</b>
char line[MAXLINE];
int found=0;
if(strindex(line,pattern)&gt;=0) {
<p>Now the body of the function is indented and the closing curly brace has been
placed on its own line (as in the K&amp;R style), but the unnecessary
white-space characters remain compressed (eliminated from the body of the
expressions). You may still find v2 style closing braces in some of the v3
source files, but indentation and all other style elements should be consistent
with the v3 style shown above.</p>
<h4>Style Guidelines</h4>
<li>Use the Synchronet v3 indentation, white-space, and brace style (as
described above).</li>
<li>Configure your text editor for 4 space tab stops and keep the physical
tabs in the files (do not replace them with spaces).</li>
<li>Use the Synchronet copyright comment block (including the
<a href="">PT/SC
headers</a>) when creating new source files.</li>
<li>Do not extend lines beyond column 100.</li>
<li>Add comments around or near any code you add or modify explaining the
rationale behind the modification.</li>
<li>Use descriptive symbol (function and variable) and pre-processor macro names.</li>
<li>Use symbol and macro naming styles consistent with those already used in
the project/source file you are modifying.</li>
<li>Do not use unnecessary global variables (use class members or function
parameters to pass values).</li>
<li>Use return types and variable types consistent with the data to be stored
or returned (e.g. use bool/BOOL for true/false type values).</li>
<li>Do not embed important numeric constants in your code; use macros (e.g.
#define SPECIAL_VALUE 128) or configurable variables instead.</li>
<h3>Backwards Compatibility</h3>
<p>There are two very important areas of compatibility that must be maintained
when modifying the code:</p>
<li>Data and configuration file compatibility with older Synchronet versions
<li>Builds for other compilers and platforms</li>
<p>On the first point, you must take care not to alter structure definitions or
file formats that will cause the resulting file not to operate in a compatible
way with Synchronet v2. If you need additional data storage, try to use unused
or reserved elements, bit-fields, or data fields in existing structure or file
definitions (without changing the overall size of the structure or data record)
or create auxiliary data files that contain the additional required data. All
binary words and double-words are to be stored in little endian (Intel)
byte-order and there are currently no provisions in the source code to account
for byte-order translations on big endian systems.</p>
<p>On the second point, it is critical that you do not add system calls or
system-dependant functionality in a non-portable fashion. If you are adding code
that is only supported on a specific platform and when built with a specific
compiler or run-time library, be sure to wrap that code in&nbsp; conditional
compilation statements that test for the appropriate pre-processor definitions.
In addition, take care to add error conditions, warnings, or alternate behavior
when the code is built on an unsupported platform or with an unsupported tool.
For example:</p>
<pre>#if defined(__MSDOS__)
#elif defined(__OS2__)
#elif defined (_WIN32)
#error &quot;No Sleep Function for target platform!&quot;
<p>To maintain as much compiler and platform compatibility as possible, do not
unnecessarily restrict code portions to a specific Unix-like operating system (Linux for example)
when the code will (or should) compile with most Unix-like operating systems. For example:</p>
<pre>#if defined(__unix__)
#if defined(__linux__)
<p>Also, be sure to separate <b>compiler</b> dependancies from <b>platform</b> dependancies. For example:</P>
<pre>#if defined(__GNUC__)
<p><b>Please use the following pre-processor symbols to determine the target platform:</b></p>
<COLGROUP align=center>
<COLGROUP align=left>
<th width="150">Symbol<th>Target Platform
<p align="center"><b><code>__unix__</code></b><td>Any Unix-like OS
<p align="center"><b><code>__linux__</code></b><td>GNU/Linux (use sparingly)
<p align="center"><b><code>__FreeBSD__</code></b><td>FreeBSD (use sparingly)
<p align="center"><b><code>BSD</code></b><td>Any BSD-based Unix
<p align="center"><b><code>_WIN32</code></b><td>Win32-based OS
<p align="center"><b><code>__OS2__</code></b><td>OS/2
<p align="center"><b><code>__MSDOS__</code></b><td>MS-DOS
<p align="center"><b><code>__DOS4G__</code></b><td>Rational 32-bit DOS extender
<p align="center"><b><code>__FLAT__</code></b><td>Other 32-bit DOS extender
<p><b>Please use the following pre-processor symbols to determine the compiler:</b></p>
<COLGROUP align=center>
<COLGROUP align=left>
<th width="150">Symbol<th>Compiler
<p align="center"><b><code>__GNUC__</code></b><td>GNU C/C++ Compiler
<p align="center"><b><code>__BORLANDC__</code></b><td>Borland C++ or C++ Builder Compiler
<p align="center"><b><code>__WATCOM__</code></b><td>Watcom C++
<p align="center"><b><code>_MSC_VER</code></b><td>Microsoft Visual C++
<p>Little-endian/80386-class target CPUs are assumed, so no testing for CPU-type is required at this time.</p>
<p>When you've created a modification that you think other Synchronet sysops or
users may find useful, you are encouraged to submit this modification to <a href="mailto:mods&">mods&</a>.
Modifications should be submitted in the Unix <a href="">diff</a>
format. Currently, I am the sole judge of which submissions will be merged into
the code base and which ones will not. If I determine that a submission should
not be merged into the code base for any reason, I will make my best effort to
explain to the submitting developer the reasons why and offer advice on how to
remedy the situation, if at all possible. </p>
<p align="right"><font face="Arial" size="1">Copyright 2009 Rob Swindell
<br>$Id: source.html,v 1.18 2009/01/31 21:27:29 rswindell Exp $</font></p>
\ No newline at end of file
<meta http-equiv="refresh" content="0; url=" />
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Sysop Commands</title>
<!--webbot bot="Include" U-Include="_borders/top.htm" TAG="BODY" startspan -->
<a href=""><img border="0" src="images/synclogo_fancyred.png" alt="Synchronet BBS - Multinode Bulletin Board Software" width="626" height="86"></a>
<!--webbot bot="Include" endspan i-checksum="23126" -->
<p><a name="top"></a><a href="sysop.html#TOC">Back to Table of Contents</a></p>
<h2><a name="SysopDefinition">[5.1] - Sysop Definition</a></h2>
<pre>There is usually one sysop (System Operator) per BBS - the owner and operator
of the hardware which Synchronet is running on and accepting remote users.
Quite often systems require more than one sysop and Synchronet is flexible in
this respect. Within Synchronet, a sysop is defined as any user with a main
level of 90 or above. Any user that qualifies as a sysop, is prompted with an
&quot;<b>SY:</b>&quot; to enter the system password at logon. Any time a sysop attempts to
perform a sysop function that may breach the system security, he is prompted
with an &quot;<b>SY:</b>&quot; to enter the system password before he can proceed. Users with
sysop access can cause serious damage to the system. Give out this ability with
<h2><a name="MultipleSysops">[5.2] - Multiple Sysops</a></h2>
<pre>As stated above, any user with a security level of 90 or greater can perform
sysop functions, &quot;So why have levels 91-99?&quot; you might ask yourself. Well, you
can still restrict a user with sysop access from accessing Message Groups or
Sub-boards or File Libraries or Directories by setting the minimum required
level above that user's level. For example: If you have a remote sysop with a
security level of 90, you can still have a Message Group or Sub-board with a
minimum required level of 91. Now this remote sysop will not be able to access
that Group or Sub-board. While it is true that sysops can edit their own
and subordinate user's accounts, they can not edit a sysop of higher level's
account (when calling remotely). A remote sysop can't raise any user's level
above his own, or add flags or exemptions that he himself doesn't have.</pre>
<h2><a name="LocalSysopCommands">[5.3] - Local Sysop Commands </a><i><font color="#CC0000"><b>(v2
<pre>Most sysop functions will be performed locally, while some sysop functions can
<u>only</u> be performed locally. The following special key combination are only
available while online locally (not from the Waiting for Call screen).
</u> All the function keys (F1-F12) and combinations with Shift, Ctrl, and
Alt (48 macros total) are available for the sysop. A macro is a short
way to enter many keystrokes. Each macro is stored in a separate file
in the TEXT directory with a MAC extension. The name reflects which
key combination will initiate the macro. For regular F1 through F12,
the name is F1.MAC through F12.MAC respectively. For Alt-F1 through
Alt-F12 the name is ALT-F1.MAC through ALT-F12, Ctrl-F1 through
Ctrl-F12 are named CTRL-F1.MAC through CTRL-F12, and Shift-F1 through
Shift-F12 are named SHFT-F1.MAC through SHFT-F12. Each file is a basic
ASCII text file with one exception; an extended key combination (such
as Alt-D) can be entered by placing a Ctrl-@ (ASCII 0, NULL) in the
file followed by the scan code of the key you wish to use.
<b><u>Alt-key combinations:
<b> Alt-U (User Edit)
</b> At any place within Synchronet, pressing Alt-U at the local keyboard
will pop the local console into User Edit while the remote side (if
there is a remote user) will see [WAIT]. Alt-U is available while using
the terminal mode as well. See User Edit for more information.
See UEDIT command below.
<b> Alt-# (Quick Validation)
</b> Pressing Alt and then any of the numbers 0-9 will change the current
users level/flags/exemptions/restrictions/credits and extend their
expiration date to the settings for that quick-validation slot set in
the system configuration. SCFG-&gt;System-&gt;Toggle Options-&gt;Quick
Validation Hot Keys must be set to 'Yes' for this feature to work.
<b> Alt-S (Crazy Cursor Toggle)
</b> Pressing Alt-S will toggle the state of the crazy (spinning) cursor,
but doesn't change the current user's default settings regarding it.
<b> Alt-E (Local I/O Only)
</b> If a user is on remotely, this allows the local console to use the BBS
while the remote user just sees [WAIT]. Pressing Alt-E again re-enables
the remote console.
<b> Alt-L (Capture)
</b> This starts and stops the local capture of text to a file. If capture
is active the status line will reflect this state with a blinking 'C'
as the far left character. The file the BBS opens to capture to will be
appended if the file already exists. The filename to capture to is
prompted for when capture is started. The filename defaults to
CAPTURE.TXT in the current node's directory. To direct output to the
printer, change the filename to PRN.
See ANSCAP command below.
<b> Alt-Q (Quiet Remote User)
</b> If a user is connected remotely, hitting this key will disable him from
being able to enter any keystrokes into the BBS . The user will see all
the BBSs output, but any characters sent from his side will not be
accepted as input. Hitting Alt-Q again enables remote input again.
<b> Alt-P (Sysop Page Off)
</b> If someone is currently paging the local sysop (annoying sounds at the
local console), hitting Alt-P will turn them off. Scroll-lock toggles
local sysop availability.
<b> Alt-H (Disconnect)
</b> Hangs up on the current user immediately.
<b> Alt-I (Interrupt)
</b> Hangs up on the current user after displaying a message the node has
been closed for maintenance.
See INTR command below.
<b> Alt-A (Sysop Alert)
</b> When the current user logs off the BBS, the local sysop will be alerted
by a message and a continuous alarm.
<b> Alt-R (Rerun Node)
</b> When the current user logs off the BBS, this node will automatically
rerun itself.
See RERUN command below.
<b> Alt-X (Down Node After User Logs Off)
</b> Hitting this key combination while the user is in the BBS will toggle
the down status of this node. When a node is to be downed, it will
be automatically shutdown when the current user logs off.
See DOWN command below.
<b> Alt-- (Subtracts 5 Minutes)
</b> Subtracts 5 minutes from the users time allowed online this logon.
<b> Alt-+ (Add 5 Minutes)
</b> Add 5 minutes to the user's time allowed online this logon.
<b> Alt-N (Lock Node)
</b> Pressing this key will disallow any non-sysops or users without the
'N' exemption from logging on after the current user logs off.
See LOCK command below.
<b> Alt-T (Temp Sysop)
</b> Gives the current user sysop status temporarily for this logon. Hitting
Alt-T again removes the temp sysop status. This doesn't actually raise
the security level of the user to 90, but gives him access to all sysop
functions. The status line reflects Temp Sysop state with a blinking
asterisk to the far left of the status line.
<b> Alt-G (Guru Chat)
</b> Pops the user in and out of apparent local chat with the system's guru.
<b> Alt-C (Local Chat)
</b> Pops the user into chat with the local console.
<b> Alt-D (DOS Shell)
</b> Pops the local console into DOS. If a user is on remotely, he sees
[WAIT] till the local console exits the shell. The sysop can use the
'D' command to shell to DOS from the wait for call screen.
See DOS command below.
<b> Alt-Z (Local Key Menu)
</b> Displays the local key menu.
<b>Status Line:<u>
The status line displays one line of user information at any given
time. To change the current line, use CTRL and the UP and DOWN arrow
keys to scroll through different information lines, or CTRL-HOME to go
to the default (1st) or CTRL-END to go to the last.
The available status lines are:
0: UserName SecLevel Password ModemType Birthday Age Sex Phone
1: UserName SecLevel RealName/CompanyName &quot;Alt-Z for help&quot;
2: UserName SecLevel RealName/CompanyName Age Sex Phone
3: UserName SecLevel Location Phone
4: UserName SecLevel Note/Caller-ID Phone
5: UserName SecLevel Flags1 Age Sex Phone
6: UserName SecLevel Flags1 Expiration
7: UserName SecLevel DateFirstOn DateLastOn Expiration
8: UserName SecLevel Credits Minutes Expiration
9: SecLevel Flags1 Flags2
10: Exemptions Restrictions
11: ComputerType ModemType ChatHandle
12: Address Location ZipCode
13: UploadBytes UploadFiles DownloadBytes DownloadFiles LeechCount
14: Posts EmailSent FeedbackSent EmailWaiting TotalLogons TotalTimeOn
15: NetMailForwardingAddress
16: SysopComment
You can set the default status line number in SCFG-&gt;System-&gt;Advanced
options. This will be the default status line that appears until
manually scrolled.
There are status flags on the status line that indicate specific status
items. They appear blinking on the left or right edges of the status
line. They are defined as:
C Local text/ANSI capture is on
* Temporary sysop status
A Alert sysop when user logs off
R Rerun this node when user logs off
D Down this node when user logs off
E Run node daily event when user logs off
L This node is locked for sysop logons only</pre>
<h2><a name="OnlineSysopCommands">[5.4] - Extra Online Sysop Commands</a></h2>
<pre>Most of the additional commands available to sysops online (local or remote)
are initiated from the main or transfer sections. A menu of the available
commands can be viewed with the '!' command from the main or transfer sections
with the Synchronet Classic command shell. Additional sysop commands are
available in many other sections of the BBS and are displayed after the normal
menu with the '?' command. All sysop commands from the main or transfer
sections of the Synchronet Classic command shell begin with a semicolon (';')
character, end with CR (ENTER), and some have optional parameters (shown in
square brackets). Users with certain exemptions can use some of these commands
and have access to the menus via the '!' command using the Synchronet Classic
command shell.
<b> UEDIT [x] (User Edit)
</b> This command initiates the User Edit function. If 'x' is specified
and is a valid user number, that user will be the current user when
User Edit starts, otherwise the user online will be the current user.
This command is also available from the transfer menu. Locally, Alt-U
is the preferred method of initiating User Edit.
See the chapter on User Edit for more information.</pre>
<pre><b> SPY [n] (Spy on Another User) <font color="#CC0000"><i>(v3.00c+ Only)</i></font>
</b> This command allows the sysop to remotely monitor or control another node
running in the same instance as the node the sysop is logged into.</pre>
<pre><b> CHUSER (Change into Another User)
</b> This command allows the sysop to temporarily change to another user
account. If changing to an account with a higher level, the password
of that user must be given. Changing to an account of non-sysop status
automatically enables Temp Sysop mode so that the sysop can change back
to his/her own account before logging off (a suggested action).
<b> ANSCAP (Toggle ANSI Capture Mode) <font color="#CC0000"><i>(v2 Only)</i></font>
</b> Normal ANSI escape sequences are not written to the capture file. The
sysop can use this command to enable all characters (including ANSI
escape sequences) to be written.
<b> LOCK [x] (Lock Node)
</b> The sysop can use this command to prevent users logging onto a node
until the lock is removed. If 'x' is specified, that node's lock
status will be toggled, otherwise a list of all nodes is given and
the sysop is prompted for the node to lock or unlock. Sysops and
users with the 'L' exemption can use this command and log onto locked
nodes. A locked node will have an 'L' in parenthesis after the node
information in the node listings.
<b> INTR [x] (Interrupt Node)
</b> This command allows a sysop (or user with the 'I' exemption) to hang up
on a user on another node. If the user is currently executing an
external program (editors and transfer protocols included), he will
not be disconnected until control returns to Synchronet. A message will
be displayed telling the user that the node has been temporarily closed
for maintenance before carrier is dropped. If 'x' is specified that
node's interrupt status will be toggled, otherwise a list of all nodes
is displayed and the sysop is prompted for the node who's interrupt
state he wishes to toggle. The current interrupt status of a node is
reflected by an 'I' in square brackets following the node information
line in the node listings.
<b> DOWN [x] (Down Node)
</b> A sysop can toggle the down status of a node with this command. When
a node has the down status (noted by the [D] flag on the node status
line) it will be shutdown immediately after the user logs off. If a
user is not online, it will shutdown immediately.
<b> ANON (Anonymous)
</b> This command makes the current node anonymous. Sysops and users with
the 'Q' exemption have access to this command. To a sysop, an anonymous
node appears normal with the addition of an 'A' in square brackets
following the node information line.
<b> QUIET (Quiet Mode)
</b> Using this command, a sysop (or user with the 'Q' exemption) can make
his node appear to be &quot;Waiting for call&quot; to other users of the system.
Users with this ability can also make this state their default state
upon logon in the user defaults section. Local users can logon in
this state with the WFC command SPACE, then 'Z' or user number 1 can
logon fast and quiet with the WFC command SPACE, then 'Q'.
To a sysop, a node in this state appears normal with the addition of
a 'Q' in square brackets following the node information line.
<b> RERUN [x] (Rerun Node)
</b> This command allows a sysop to rerun any node on the system by
specifying the node number on the command line. If there is a user
on the node that is to be rerun, the node will not rerun until that
user logs off. A node that is going to be rerun is noted with an
'R' in square brackets following the node information in node listings.
<b> DOS (Shell to DOS)
</b> Using this command, a sysop can go straight to the DOS command line
locally or remotely. If the sysop is on locally, ALT-D is the
preferred method of shelling to DOS. If a local sysop wishes to shell
to DOS from the wait for call screen, he can use the 'D' command.
<b> EDIT [s] (Edit Text/MSG File)
</b> A sysop can edit any ASCII text (and MSG format) files on the system
with this command. If 's' is given, it will be used as the filename to
be opened or created if it doesn't exist. If 's' is not specified, the
filename will be prompted for.
<b> LOG (Today's Detail Log)
</b> A sysop can view today's detailed log file with this command. This
command views the same file as the 'L' wait for call screen command.
<b> YLOG (Yesterday's Detail Log)
</b> A sysop can view yesterday's detailed log file with this command. This
command views the same file as the 'Y' wait for call screen command.
<b> NS [x] (Node Statistics)
</b> This command will give today's statistics for node 'x' if specified,
or the current node.
<b> SS (System Statistics)
</b> This command will give today's statistics for all nodes combined.
<b> NLOG [x] (Node Statistics Log)
</b> A sysop can view the history of statistics information for any node on
the system. If 'x' is specified, that will be the node who's statistics
are viewed, otherwise the current node. Same as 'N' from the wait for
call screen.
<b> SLOG (System Statistics Log)
</b> Using this command, a sysop can view the history of statistics
information for the system. Same as 'S' from the wait for call screen.
<b> MEM (Available Memory) <font color="#CC0000"><i>(v2 for DOS Only)</i></font>
</b> This command displays the amount of memory available to Synchronet and
any external programs it executes (without swapping).
<b> LIST [s] (View Text/MSG File)
</b> A sysop can use this command to view any ASCII text (or MSG format)
file on the system. If the filename 's' is not specified, it is
prompted for.
<b> GURU (View Guru Log)
</b> A sysop can use this command to view the GURU.LOG file which contains
discussions that users have had with the system guru (GURU.DAT).
See GURU.DAT for more information.
<b> MAIL (Read All Mail)
</b> Using this command (or 'M' from the WFC screen) a sysop can read all
the e-mail on the system.
<b> BULKMAIL (Send Mass Mailing)
</b> Use this command to send a single e-mail message to multiple users.
<b> CALL [Hub-ID] (Force QWKnet Call-out)
</b> Forces a QWKnet call-out to the hub &quot;Hub-ID&quot; the next time the call-out
node is at the WFC screen. Example: CALL VERT
<b> EXEC [Command] (Execute a DOS program or Baja module)
</b> Execute internal DOS commands (DIR, TYPE, etc.) by prepending
&quot;command /c&quot; to your command line. Execute Baja modules by prepending
&quot;*&quot; to the command line. Baja modules must be located in your EXEC
directory. Command line specifiers (see appendix A) may be used.
<b> CHAT
</b> Users with the 'C' exemption can use this command to page the sysop.
<b> OLD (Search for Files not Downloaded Since New-Scan Date)
</b> A sysop can use this command to remove, edit, or move files that were
uploaded before the new-scan date (set with the '&amp;P' transfer section
command) and have not been downloaded since.
<b> OLDUL (Search for Files Uploaded Before New-Scan Date)
</b> A sysop can use this command to remove, edit, or move files that were
uploaded before the new-scan date (set with the '&amp;P' transfer section
<b> CLOSE (Search for Files Currently Open)
</b> If there are no users online and all nodes are running, there should
be no file records open. A sysop can check for open file records with
this command. Any file records that are left open erroneously, can be
closed with this command. This circumstance should not happen.
<b> ALTUL [x] (Alternate File Path Uploads)
</b> If there are alternate file paths configured, a sysop can use this
command to set the current upload path to one of the alternate file
paths. All subsequent upload commands will use the alternate upload
path as the storage directory regardless of the storage path specified
for the directory being uploaded to. This is a useful command for
those who wish to have one directory with files listed from multiple
See CD-ROM for more information on creating alternate file paths.
<b> UPLOAD (Bulk Local Upload)
</b> This command searches for files that are on disk, but not in the
database of the directory. If any are found, a description is prompted
for and the file is then added to the database.
<b> RESORT (Re-Sort and/or Compress)
</b> A sysop can use this command to re-sort a directory if he has changed
the sort order in the directory configuration or can use this command
to remove deleted file records from the database to conserve memory and
disk space. If there are many deleted files in the database of a
directory, performance will also be affected. Deleted file records
are used by new uploaded files, but if a substantial amount of files
have been removed from a directory, a sysop may wish to use this
<b> OFFLINE (Search for Offline Files)
</b> This command will search the disk for files that are in the database
of a directory but not actually on the disk. The sysop can then remove,
edit, or move these files to another directory. Offline directories
are ignored in this search.
<b> DIR [s] (Directory of Files)
</b> This command displays a DOS directory of the path specified. If no
path is specified, a directory of the current file transfer directory
is displayed.
<b> GET [s] (Download File From Anywhere)
</b> A sysop can download a file from any drive or directory on the system
by using this command. The file does not have to be in the file
<b> PUT [s] (Upload File to Anywhere)
</b> A sysop can use this command to upload a file to a local disk without
having to add it to the file database.</pre>
<pre>Note: The Baja source code file for these commands is: <b>exec/str_cmds.src</b></pre>
<p><a href="#top"><b>Back to Top</b></a></p>
<!--webbot bot="Include" U-Include="_borders/bottom.htm" TAG="BODY" startspan -->
<p><b><a href="">Copyright</a> © 2000 by </b> <a href=""><b>Rob Swindell</b><br>
<a href=""><font size="2"><br>
Synchronet BBS Software</font></a> <font size="2"> (Synchronet)
Version 3 is comprised of several documentation,<br>
library, executable, and <a href="">source code</a>
files, all of which are covered by the<a href="">
GNU General Public License</a> with the exception of the following portions
covered by<br>
the <a href="">GNU Lesser General Public License</a>:
SMBLIB and XSDK.<br>
Synchronet Version 2 (for DOS and OS/2) and its source code was released to the<a href="">
Public Domain</a> by <a href="">Digital Dynamics</a>
in 1997 and remains Public Domain software today.<br>
Synchronet Version 3 is not Public Domain software.</font></p>
<p align="left"><font size="2"><a href="">Rob Swindell<br>
</a>PO Box 501<br>Yorba Linda, CA 92885<a href=""><br></a>
<p align="left"><font size="2">For the complete Copyright Information please
read the <a href="">Copyright Documentation</a>
<!--webbot bot="Include" endspan i-checksum="55766" -->
<meta http-equiv="refresh" content="0; url=" />
\ No newline at end of file