Subj : WINE!

Subj : WINE!
To : Ralph Smole
From : Igor Savitskiy
Date : Sat Jun 28 2008 03:44 am

Hi, Ralph!

RS> Howdy,all!
RS> Just finished converting from Windows to Ubuntu Linux. I ran a BBS for
RS> years under DOS and Windows. Does anybody know if Synchronet BBS
RS> software can run using WINE? Thanks!
RS> --- SBBSecho 2.12-Win32
RS> * Origin: Vertrauen - vert.synchro.net (1:103/705)

More http://www.synchro.net/
There is a native version for Linux:

=========Beginning of the citation==============
Synchronet for Unix
-=-=-=-=-=-=-=-=-=-

By: Rob Swindell (digital man) and Stephen Hurd (deuce)
http://www.synchro.net

$Id: sbbsunix.txt,v 1.65 2007/10/15 07:49:39 deuce Exp $

The information in this file is current as of the date above. The answers
and
instructions in this file may change over time, so be sure to get the
current
version of this file at ftp://ftp.synchro.net/sbbsunix.txt
or ViewCVS at
http://cvs.synchro.net/cgi-bin/viewcvs.cgi/*checkout*/docs/sbbsunix.txt

Answers to Frequently Asked Questions
=====================================

Q. What flavors of Unix (and Unix-like operating systems) are supported?
A. Currently, Linux, FreeBSD, OpenBSD, and NetBSD are actively supported.
Additionally, QNX and Solaris-x86 have been known to work in the past,
but are not actively maintained.

Q. What distributions of Linux are supported?
A. Should work with any GNU/Linux-x86 distribution (e.g. RedHat, Mandrake,
Debian, Slackware, etc.).

Q. 64-bit?
A. Untested experimental support for 64-bit platforms is in CVS. Use the
directions available at
http://cvs.synchro.net/cgi-bin/viewcvs.cgi/*checkout*/docs/64bit.txt
in conjunction with this document for building and be prepared to deal
with
bugs.

Q. The installer (e.g. Linux-install from sbbsunix.tgz) segfaults, crashes,
or fails to get the file size of sbbs_src.tgz.
A. This installer has known issues and is currently *unsupported*. Do not
use
it. This installer (known to us as "sbbsinst") will be revamped and
re-released in the near future.

In the mean-time, follow the steps given in this document to download,
build, install, and run Synchronet for Unix.

Q. Linking error: undefined reference: '__ctype_b'
A: This is an issue linking the JavaScript library for Linux (libjs.a) on
RedHat Linux 9 and Mandrake Linux 9 using glibc v2.3.2-11+.

This issue has been resolved with the addition of libjs.so and
libnspr4.so
to the CVS repository (in the lib/mozilla directory). If you're having
this
problem, run "cvs update" in your lib and src/sbbs3 directories and
rebuild.

Another solution is to use the lib[moz]js.so file included with your
Linux
distribution (if it is). See installation steps 1.E and 1.F for more
details.

Q. Are non-x86 (Alpha, SPARC, 68k, PowerPC, etc) processors supported?
A. Not currently. Synchronet assumes a little-endian processor. It *may*
work
on other little-endian processors (e.g. Alpha), but hasn't been tested.
Big-endian support is currently being developed for the v3.20 time-frame.

Q. Will Synchronet ever support big-endian and/or 64-bit processors?
A. Yes, that is the plan.

Q. Will Synchronet be ported to Mac OS X?
A. Definitely. See the 2 questions above.

Q. Where do I get Synchronet for Unix?
A. There are no binary distributions at this time, so you must get the
source
code from the Synchronet CVS repository (see the step-by-step
instructions
below for details) or by downloading the latest verified buildable source
code tarball (tgz file) from ftp://vert.synchro.net/Synchronet.

Q. Will there be binary releases?
A. Maybe. Linux is a particularly difficult "platform" to deliver
consistently
compatible binaries for and unfortunately, it is the most popular
Unix-like
operating system we currently support.

Q. Can I mix Synchronet for Unix and Synchronet for Win32 or DOS or OS/2
nodes
on the same BBS?
A. Yes. As long as all the nodes can access the same live data files (via
LAN)
you can have as many instances of Synchronet on as many different
platforms
as you wish.

Q. Does Synchronet for Unix support external DOS programs/doors?
A. Currently, only the FreeBSD build has doscmd support "built-in" (and this
"support" requires emulators/doscmd to be installed):

For FreeBSD, the path that is entered in the Start-up Directory is mapped
as C:\ the current node directory is mapped as D:\ and the Synchronet
root directory is mapped as E:\. When a DOS door is executed, a
.doscmdrc
is created in the node directory. Copying this file and using it to run
doscmd in X11 mode while running the setup programs is the simplest way
to configure the doors.

Other platforms can use DOSEMU or whatever is available for running DOS
programs.

There's a patch for "building-in" DOSEMU support with Synchronet for
Linux:
http://www.icequake.net/bbs/syncmods/index.html and
(mirror) http://www.synchro.net/docs/linux-dosemu.html

and a FAQ for using DOSEMU with Synchronet for Linux (without a patch):
http://www.exeonline.com/bbs/howto-doors.txt

Q. What external programs/doors does Synchronet for Unix support?
A. External programs can either use standard I/O (e.g. bash, pico, Lord/X,
PimpWars) or socket I/O (e.g. Synchronet XSDK doors).

Q. Does Synchronet for Unix require X-Windows?
A. No, Synchronet for Unix is currently a console-based application.
However, it does have an X-based character mode console now. The X11
headers (Part of the X11-devel package or something similar) are required
for this to work.

Q. Are there any plans to make an X-Windows front-end for Synchronet?
A. Possibly, but it would be optional.

Q. What are the recent developments in Synchronet?
A. There are changes (fixes, improvements, etc.) being made all the time.
See http://cvs.synchro.net/commitlog.ssjs for a log of the most recently
committed changes to the Synchronet CVS repository.

New releases are always posted on the web-site (http://www.synchro.net),
as well as announced in the Synchronet discussion groups
(http://www.synchro.net/docs/support.html) and the Synchronet
Announcements
mailing list (subscribe at [email protected]).

Q. Can I use a different compiler to build Synchronet for *nix?
A. Yes, currently Synchronet has successfully been built with both GCC and
ICC
(The Intel C Compiler). To specify an alternate compiler, add
``DONT_CLOBBER_CC=1 CC=icc CXX=icpc'' to the gmake command lines where
icc is the C compiler name and icpc is the C++ compiler name. If you get
errors during the build (not warnings) please submit a bug report. If
you
are using a commercial compiler other than ICC, we will probobly be
unable
to help you without a copy of the compiler.

Q. I'm using SELinux and nothing works.
A. Yes, you'll need to use chcon on each of the shared objects (.so files)
chcon -t texrel_shlib_t /path/to/libwhatever.so
Do this for each .so file that Synchronet creates.

Step-by-step Instructions
=========================

Note: These instructions assume you are already logged in as 'root'.

Note: Example command-lines are pre-fixed with '#', symbolizing the Unix
shell
prompt. You do not actually type the '#' character.

Note: The "make" command may be used in place of "gmake" on systems where
the GNU Make utility is named "make" (e.g. Debian Linux).
Type "make -v" to verify that "make" is indeed GNU Make.

Note: Any references to cvs.synchro.net can be replaced with
cvs-mirror.synchro.net (the Synchronet CVS Mirror site run by Stephen
Hurd) if you're having any problems with cvs.synchro.net.

Note: Skip to step 8 if you are updating an existing Synchronet
installation.

1. Get the required installation and source code modules from CVS:

A. Create the Synchronet BBS directory on your file system:
# mkdir /sbbs

B. Change to the Synchronet BBS directory:
# cd /sbbs

*> Optional Shortcut:
*> At this point you can copy the file from this url:
*>
http://cvs.synchro.net/cgi-bin/viewcvs.cgi/*checkout*/install/GNUmakefile
*> into the Synchronet directory, run "gmake install SYMLINK=1"
*> and then skip ahead to step 5.

C. Get the required installation modules from the CVS repository:
# export CVSROOT=:pserver:[email protected]:/cvsroot/sbbs
# cvs co run-sbbs3

*> Recommended Shortcut for Linux systems:
*> Download the last verified buildable source archive (for Linux)
*> from ftp://vert.synchro.net/Synchronet/sbbs_src.tgz
*> extract (with "tar -xzvf <filename>") in the Synchronet BBS Directory,
*> and skip ahead to G.

D. Get the required source code modules from the CVS repository:
# cvs co src-sbbs3

*> Reccomended Shortcut (existing JavaScript library):
*> If your Unix distribution includes the file /usr/lib/libjs.so or
*> /usr/lib/libmozjs.so, you can save a lot of time by using this
*> library instead of the one supplied in the Synchronet CVS repository.
*> If you have /usr/lib/libmozjs.so (instead of libjs.so), you can
either:
*> Create a symlink or copy of this file with the name /usr/lib/libjs.so
*> or specify "JSLIB=mozjs" on the "gmake" command-line mentioned later.
*> If libmozjs.so is not located in a standard library path such as
*> /usr/lib or /usr/local/lib, you will also need to specify JSLIBDIR
*> also on the gmake command-line such as "JSLIBDIR=/usr/lib/mozilla".
*> If your system already has the JavaScript library, skip ahead to step
2.

E. Get the required JavaScript library for your platform and build type:
# cvs co lib/mozilla/js/linux.debug
or:
# cvs co lib/mozilla/js/linux.release
or:
# cvs co lib/mozilla/js/freebsd.debug
etc.
Note: If you want to get the full source code to the Mozilla
JavaScript
library to build it yourself, the cvs repository is:
:pserver:[email protected]:/cvsroot
the module name is mozilla/js/src.

F. Get the required NSPR library for your platform and build type:
# cvs co lib/mozilla/nspr/linux.debug
or:
# cvs co lib/mozilla/nspr/linux.release
or:
# cvs co lib/mozilla/nspr/freebsd.debug
etc.
Note: This step is not necessary if your system already has the file
/usr/lib/libnspr4.so

G. Create symbolic links to the Mozilla Libraries (JavaScript and NSPR)
in
your /usr/lib directory:
# ln -s /sbbs/lib/mozilla/*/linux.debug/*.so /usr/lib

or: Add these two directories to your LD_LIBRARY_PATH environment
variable.

H. Get the required Cryptlib library for your platform and build type:
# cvs co lib/cryptlib/linux.release
or:
# cvs co lib/cryptlib/freebsd.release
etc.
Note: This step is not necessary if your system already has the file
/usr/lib/libcl.so

I. Create symbolic links to the Cryptlib Library in your /usr/lib
directory:
# ln -s /sbbs/lib/cryptlib/linux.debug/*.so /usr/lib

or: Add these two directories to your LD_LIBRARY_PATH environment
variable.

2. Build Synchronet:

Prerequisite: curses
You must have either the curses or ncurses headers and library files
installed on your system, or you must remove the USE_CURSES definition
from the various GNUmakefiles in the src/sbbs3 tree. If you have the
files /usr/include/curses.h and /usr/lib/libcurses.a then you're ready
to continue.

A. Change to the Synchronet src/sbbs3 directory:
# cd /sbbs/src/sbbs3

B. Build the main executable (and utilities):
# gmake
NOTES:
1: If you're linking with /usr/lib/libmozjs.so, don't forget to add
"JSLIB=mozjs" to the gmake command-line
2: If X is not installed in /usr/X11R6,
use "gmake X_PATH=/path/to/X"
3: To debug compile/link command-line problems, adding "VERBOSE=1"
to the gmake command-line can be very helpful
4: Warnings (if any) can be safely ignored
5: The "current" code in the CVS repository is in a fairly constant
state of change. And often, one or more projects will not build
successfully on any given platform. This is a common occurance
and is expected in a fluid development project such as this one.
If you'd like a verifiably-buildable source code base, either
download one of the source code archives (e.g. sbbs_src.tgz) or
use a release label (tag) when checking out files from CVS.
6: By default, this will build DEBUG binaries which will be larger,
slower, and consume more resources than a RELEASE build. If you
wish a RELEASE build, add "RELEASE=1" to the gmake command-line.
This will make it more difficult to send us usefull error reports
though.

C. Change to the src/sbbs3/scfg directory:
# cd /sbbs/src/sbbs3/scfg

D. Build the Synchronet configuration utility (SCFG):
# gmake
Note: If X is not installed in /usr/X11R6,
use "gmake X_PATH=/path/to/X"
Note: Warnings (if any) can be safely ignored

E. Congratulate yourself on a job well-done.

3. Prepare the "exec" directory:

A. Change to the Synchronet exec directory:
# cd /sbbs/exec

B. Copy (or create symbolic links to) the following files:
../src/sbbs3/gcc.linux.exe.debug/*
../src/sbbs3/scfg/gcc.linux.exe.debug/scfg*
(the paths will be different for other platforms or release builds)

Example:
# ln -s ../src/sbbs3/gcc.linux.exe.debug/* /sbbs/exec
# ln -s ../src/sbbs3/scfg/gcc.linux.exe.debug/scfg* /sbbs/exec

C. Copy (or create symbolic links to) the following shared libraries:
../src/sbbs3/gcc.linux.lib.debug/*
(the path will be different for other platforms or release builds)

Example:
# ln -s ../src/sbbs3/gcc.linux.lib.debug/* /sbbs/exec

Note: Another option is to create the symbolic links in your /usr/lib
directory (note the trailing dot):
# ln -s /sbbs/src/sbbs3/gcc.linux.lib.debug/*.so /usr/lib

OR: set the LD_LIBRARY_PATH environment variable to point to your
gcc.<os>.lib.<build> directory:
# export LD_LIBRARY_PATH=/sbbs/src/sbbs3/gcc.linux.lib.debug

D. Build the required Baja {tm} modules (exec/*.bin):
# gmake

4. Prepare the "xtrn" directory:

A. Change to the xtrn/sbj directory:
# cd /sbbs/xtrn/sbj

B. Build Synchronet Blackjack:
# gmake

C. Change to the xtrn/sbl directory:
# cd /sbbs/xtrn/sbl

D. Build Synchronet BBS List:
# gmake

5. Configure the BBS:

A. Run the Synchronet Configuration Utility (SCFG)
# /sbbs/exec/scfg /sbbs/ctrl
(if you have problems with the curses interface, try running
"scfg -id" instead)
Tip: Set the SBBSCTRL environment variable and you won't have to
specify
the path to the "ctrl" directory on the command-line:
# export SBBSCTRL=/sbbs/ctrl

B. Change SCFG->Networks->QWK->Hubs->VERT:
Pack Command Line %@zip -jD %f %s
Unpack Command Line %@unzip -Coj %f %s -d %g
Call-out Command Line *qnet-ftp VERT dove.synchro.net
YOURPASS
(see docs/dove-net.txt for more details)

C. You should also consider configuring important details about your BBS
(like the name) in SCFG->System.

6. Running Synchronet:

A. Set the SBBSCTRL environment variable to point to your "ctrl"
directory:
# export SBBSCTRL=/sbbs/ctrl

B. Run the main executable (with default settings/options):
# /sbbs/exec/sbbs

C. To view available command-line options, run:
# /sbbs/exec/sbbs help | more

D. To view default settings (node and port numbers), run:
# /sbbs/exec/sbbs defaults

E. To change the default settings, edit the file /sbbs/ctrl/sbbs.ini

F. For more details, see /sbbs/docs/sbbscon.txt

7. Debugging:

You can either run Synchronet (sbbs) from the GNU debugger (gdb), or you
can debug an sbbs crash "post mortem" provided you have a
system-generated
core file as a result of a crash. Often times, a core file is the best
way
to find the root cause of a crash, so if you can configure your system to
create core files when sbbs crashes, that can be very helpful to the
developers in finding and fixing any bugs and ultimately, improving the
quality of the software.

You can run "ulimit -c" to check if core file generation is enabled for
the
current user profile (0 = disabled, non-zero or "unlimited" = enabled).
An
"unlimited" core file size is the preferred setting. If your system is
configured for no core file generation, check for a call to "ulimit -c 0"
in your /etc/profile (or similar startup file) and remove/edit the
command.

Linux Sysops: to help locate sbbs crash core files, the following
lines in your /etc/sysctl.conf file can be helpful:

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
kernel.core_pattern = /tmp/core.%e.%p

This will place core files with the name "core.sbbs.####" in the /tmp dir
instead of core.#### in the current directory (typically /sbbs/ctrl).

A. Run the GNU debugger:
# gdb /sbbs/exec/sbbs
or:
# gdb /sbbs/exec/sbbs /tmp/core.sbbs.####

B. Run Synchronet (if no core file used):
(gdb) run -nd

C. After segfault or other crash (or when using a core), display
back-trace:
(gdb) bt

D. If (and only if) the last line of the output looks like this:
'#2 0x00000000 in ?? ()' (The number at the start will vary)
display backtraces of all threads:
(gdb) thread apply all bt

E. Copy and paste in e-mail to rob[at]synchro[dot]net or post in one of
the
Synchronet discussion groups
(http://www.synchro.net/docs/support.html).

8. Updating/synchronizing the source code with the CVS repository:

A. Change to your Synchronet installation directory:
# cd /sbbs

B. Back-up your working exec directory:
# cp -a exec exec.bak

C. Get the latest changes from CVS:
# export CVSROOT=:pserver:[email protected]:/cvsroot/sbbs
# cvs update docs exec xtrn src lib include

D. Repeat steps 2, 3 and 4 (only).

E. Shutdown and re-run sbbs.

F. You're done. :-)

Default Configuration (SCFG) Screen-shots
=========================================

[Viewable File Type]
1: File Extension zip
2: Command Line %@unzip -vq %s
3: Access Requirements

[Viewable File Type]
1: File Extension tgz
2: Command Line tar -tzf %s
3: Access Requirements UNIX

[Viewable File Type]
1: File Extension tar
2: Command Line tar -tf %s
3: Access Requirements UNIX

[Testable File Type]
1: File Extension zip
2: Command Line %@unzip -tqq %f
3: Working String Testing ZIP Integrity...
4: Access Requirements

[Testable File Type]
1: File Extension zip
2: Command Line %@zip -z %f < %zzipmsg.txt
3: Working String Adding ZIP Comment...
4: Access Requirements

[Testable File Type]
1: File Extension tgz
2: Command Line tar -tzf %s
3: Working String Testing TGZ Integrity...
4: Access Requirements UNIX

[Testable File Type]
1: File Extension tar
2: Command Line tar -tf %s
3: Working String Testing TAR Integrity...
4: Access Requirements UNIX

[Extractable File Type]
1: File Extension zip
2: Command Line %@unzip -Cojqq %f %s -d %g
3: Access Requirements

[Extractable File Type]
1: File Extension tgz
2: Command Line tar -xzf %f %s -C %g
3: Access Requirements UNIX

[Extractable File Type]
1: File Extension tar
2: Command Line tar -xf %f %s -C %g
3: Access Requirements UNIX

[Compressable File Type]
1: File Extension zip
2: Command Line %@zip -jD %f %s
3: Access Requirements

[Compressable File Type]
1: File Extension tgz
2: Command Line tar -czf %f %s
3: Access Requirements UNIX

[Compressable File Type]
1: File Extension tar
2: Command Line tar -cf %f %s
3: Access Requirements UNIX

[File Transfer Protocol]
1: Mnemonic (Command Key) X
2: Protocol Name Xmodem (SZ)
3: Access Requirements UNIX
4: Upload Command Line rz --xmodem
5: Download Command Line sz --xmodem %f
6: Batch Upload Command Line
7: Batch Download Command Line
8: Bi-dir Command Line
9: Native (32-bit) Executable Yes
10: Supports DSZLOG No

[File Transfer Protocol]
1: Mnemonic (Command Key) Y
2: Protocol Name Ymodem (SZ)
3: Access Requirements UNIX
4: Upload Command Line rz --ymodem
5: Download Command Line sz --ymodem %f
6: Batch Upload Command Line rz --ymodem
7: Batch Download Command Line sz --ymodem %s
8: Bi-dir Command Line
9: Native (32-bit) Executable Yes
10: Supports DSZLOG No

[File Transfer Protocol]
1: Mnemonic (Command Key) Z
2: Protocol Name Zmodem (SZ)
3: Access Requirements UNIX
4: Upload Command Line rz -p -R
5: Download Command Line sz %f
6: Batch Upload Command Line rz -p -R
7: Batch Download Command Line sz %s
8: Bi-dir Command Line
9: Native (32-bit) Executable Yes
10: Supports DSZLOG No

[File Transfer Protocol]
1: Mnemonic (Command Key) K
2: Protocol Name Kermit (G-Kermit)
3: Access Requirements UNIX
4: Upload Command Line gkermit -q -P -r -a %f
5: Download Command Line gkermit -q -P -s %f
6: Batch Upload Command Line
7: Batch Download Command Line gkermit -q -P -s %s
8: Bi-dir Command Line
9: Native (32-bit) Executable Yes
10: Supports DSZLOG No

[Native (32-bit) Program List]
1: cmd.exe
2: sh
3: csh
4: bash
5: node
6: zip
7: unzip

[Pico (Pine Composer) Editor]
1: Name Pico (Pine Composer)
2: Internal Code PICO
3: Remote Command Line pico -t -o %g %f
4: Access Requirements UNIX
5: Intercept Standard I/O Yes
6: Native (32-bit) Executable Yes
7: Use Shell to Execute No
8: Quoted Text Prompt User
9: QuickBBS Style (MSGTMP) No
10: Expand Line Feeds to CRLF Yes
11: Strip FidoNet Kludge Lines No
12: BBS Drop File Type None

[Synchronet BBS List]
1: Name Synchronet BBS List
2: Internal Code SBL
3: Start-up Directory ../xtrn/sbl
4: Command Line sbl%.
5: Clean-up Command Line
6: Execution Cost None
7: Access Requirements
8: Execution Requirements
9: Multiple Concurrent Users Yes
10: Intercept Standard I/O No
11: Native (32-bit) Executable Yes
12: Use Shell to Execute No
13: Modify User Data No
14: Execute on Event No
15: BBS Drop File Type Synchronet XTRN.DAT
16: Place Drop File In Node Directory

[Synchronet Blackjack!]
1: Name Synchronet Blackjack!
2: Internal Code SBJ
3: Start-up Directory ../xtrn/sbj
4: Command Line sbj%. /l
5: Clean-up Command Line sbjclean%.
6: Execution Cost None
7: Access Requirements
8: Execution Requirements
9: Multiple Concurrent Users Yes
10: Intercept Standard I/O No
11: Native (32-bit) Executable Yes
12: Use Shell to Execute No
13: Modify User Data Yes
14: Execute on Event No
15: BBS Drop File Type Synchronet XTRN.DAT
16: Place Drop File In Node Directory

[Synchronet Configuration]
1: Name Synchronet Configuration
2: Internal Code SCFG
3: Start-up Directory
4: Command Line %!scfg -d -l%r
5: Clean-up Command Line
6: Execution Cost None
7: Access Requirements SYSOP
8: Execution Requirements
9: Multiple Concurrent Users No
10: Intercept Standard I/O Yes
11: Native (32-bit) Executable Yes
12: Use Shell to Execute No
13: Modify User Data No
14: Execute on Event No
15: BBS Drop File Type None
16: Place Drop File In Node Directory

SBBSecho zip/unzip configuration (ctrl/sbbsecho.cfg)
================================
PACKER ZIP 0 504B
PACK %@zip -jD %f %s
UNPACK %@unzip -ojC %f -d %s
END

Send comments/questions to rob[at]synchro[dot]net

/* End of sbbsunix.txt */
=========The end of the citation================

Best regards. Savitskiy Igor

--- Fidolook Lite FTN stub
* Origin: Ekibastuz, Kazakhstan (2:5004/75.168)