I use Microsoft Visual C++ 6 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 C++ Builder 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 Microsoft Visual C++ to build most of the Synchronet command-line utilities and all the DLLs, you may use Borland C++ or C++ Builder instead, if you prefer. But note: if you rebuild any of the DLLs, you must also re-link sbbsctrl.exe with the Borland import libraries for those DLLs (see src/sbbs3/ctrl/makelibs.bat for details).
Caveat: 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 50 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 Source\rtl directory):
As for the build files: the .dsp and .dsw files are used by Microsoft Visual C++, the Makefiles are used by Borland C++ 5.5 (or C++ Builder), and the .bpr files are used by C++ Builder.
Project | Build File | Compiler |
---|---|---|
sbbs.exe, ftpsrvr.dll, mailsrvr.dll, services.dll, and most utilities (e.g. addfiles.exe, baja.exe, etc.) | src/sbbs3/build.bat src/sbbs3/sbbs3.dsw src/sbbs3/*.dsp | msvc6 |
src/sbbs3/Makefile | bcc32 | |
scfg.exe | src/sbbs3/scfg/build.bat src/sbbs3/scfg/scfg.dsw src/sbbs3/scfg/scfg.dsp | msvc6 |
src/sbbs3/scfg/Makefile | bcc32 | |
echocfg.exe | src/sbbs3/Makefile | bcc32 |
sbbsctrl.exe | src/sbbs3/ctrl/build.bat src/sbbs3/ctrl/sbbsctrl.bpr | bcb6 |
chat.exe | src/sbbs3/chat/chat.bpr | bcb6 |
useredit.exe | src/sbbs3/useredit/useredit.dpr | delphi6 |
dosxtrn.exe | src/sbbs3/dosxtrn/make.bat | msvc15 |
sbbsexec.dll | src/sbbs3/sbbsexec.dsp | msvc6 |
sbbsexec.vxd | src/sbbs3/execvxd/makefile | msvc6 and VtoolsD |
Compiler legend:
Abbreviation | Full Product Name |
---|---|
bcb6 | Borland C++ Builder 6 |
bcc32 | Borland C++ Compiler 5.5 (Free!) or Borland C++ Builder |
delphi6 | Borland Delphi 6 |
msvc6 | Microsoft Visual C++ 6 or Visual C++ Express with the Platform SDK (Free!) |
msvc15 | Microsoft Visual C++ 1.5 (16-bit) |
If the DLLs you just built are from a more recent version of Synchronet than your Synchronet Control Panel executable (sbbsctrl.exe), you will need to use sbbs.exe or sbbsNTsvcs.exe instead of sbbsctrl.exe to run Synchronet.
See docs\sbbscon.txt for more details on using the console mode version of Synchronet.
See docs\sbbsNTsvcs.txt for more details on using the NT services version of Synchronet.
-Ic:\borland\bcc55\include -Lc:\borland\bcc55\lib
If you only have the free Borland command-line C++ compiler, all of the above steps still apply except for those referencing the src\sbbs3\ctrl directory. Also, if the DLLs you built are from a more recent version of Synchronet than your Synchronet Control Panel executable (sbbsctrl.exe), you will need to use sbbs.exe (or sbbsNTsvcs.exe) to run Synchronet.
See docs\sbbscon.txt for more details on using the console mode version of Synchronet.
See docs\sbbsNTsvcs.txt for more details on using the NT services version of Synchronet.
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.
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.
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 "back doors"). In any case, if and when you make useful modifications to the source code, you are encouraged to submit those changes to mods@synchro.net 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 me, the maintainer of the project.
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:
#ifdef MYMODS bprintf("You are experiencing my custom modification.\r\n"); #endif
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. Example:
#ifdef MYMODS i = j/100; #else /* Original code */ i = j/50; #endif
This allows you to easily "undo" 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.
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.
Prior to Synchronet v3, I used a form of "condensed" K&R style to get as much code in an 80x25 character display as possible while maintaining some degree of readability.
Example (K&R style): main() { char line[MAXLINE]; int found = 0; while (getline(line, MAXLINE) > 0) if (strindex(line, pattern) >= 0) { printf("%s", line); found++; } return found; } Example (Synchronet v2 style): main() { char line[MAXLINE]; int found=0; while(getline(line,MAXLINE)>0) if(strindex(line,pattern)>=0) { printf("%s",line); found++; } return(found); }
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.
In Synchronet v3, I've taken advantage of modern GUI text editors capable of displaying more than 80 characters on a line and have "uncompressed" the style to a degree:
Example (Synchronet v3 style): main() { char line[MAXLINE]; int found=0; while(getline(line,MAXLINE)>0) if(strindex(line,pattern)>=0) { printf("%s",line); found++; } return(found); }
Now the body of the function is indented and the closing curly brace has been placed on its own line (as in the K&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.
There are two very important areas of compatibility that must be maintained when modifying the code:
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.
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 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:
#if defined(__MSDOS__) mswait(1); #elif defined(__OS2__) DosSleep(1); #elif defined (_WIN32) Sleep(1); #else #error "No Sleep Function for target platform!" #endif
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:
#if defined(__unix__) this_code_for_any_unix_variant; #endif #if defined(__linux__) this_code_only_for_linux; #endif
Also, be sure to separate compiler dependancies from platform dependancies. For example:
#if defined(__GNUC__) this_code_only_for_gcc; #else this_code_for_all_others; #endif
Please use the following pre-processor symbols to determine the target platform:
Symbol | Target Platform |
---|---|
| Any Unix-like OS |
| GNU/Linux (use sparingly) |
| FreeBSD (use sparingly) |
| Any BSD-based Unix |
| Win32-based OS |
| OS/2 |
| MS-DOS |
| Rational 32-bit DOS extender |
| Other 32-bit DOS extender |
Please use the following pre-processor symbols to determine the compiler:
Symbol | Compiler |
---|---|
| GNU C/C++ Compiler |
| Borland C++ or C++ Builder Compiler |
| Watcom C++ |
| Microsoft Visual C++ |
Little-endian/80386-class target CPUs are assumed, so no testing for CPU-type is required at this time.
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 mods@synchro.net. Modifications should be submitted in the Unix diff 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.
Copyright © 2006 Rob Swindell
$Id: source.html,v 1.17 2006/05/31 03:36:12 rswindell Exp $