message is shown as with str_cmds.bin

Currently, when using str_cmds.js the command ``;spy die'' crashes the BBS.

Deal with it by preventing wincrypt.h from being loaded with windows.h
by defining WIN32_LEAN_AND_MEAN and NOCRYPT

(Do we really NEED windows.h?  It is nastiness beyond compare!)

Note: Dunno what line 1983 is about... Borland warns that the value
is unused, but it looks like it was there for a reason... DM?

just plain silly.  Fairly large display speed up results.

Hooray!

term.c to keep all socket "stuff" together.
Detect remove SSH hangup by the return value of send/recieve, not checking
the socket directly.

Add Win32 support (untested)

of hardcoded ones.
Add support for ssh:// URLs
When the protocol is changed, change the port as well to help prevent
such mixups as using the telent protocol on port 513

Not enabled in default builds.  Still experimental.

the test for NPTL should be in there too and that every app which uses
threads, set*id(), and libsbbs.so should call it.

Does jsexec do this?

If not, should it?

Since the only way to correcty detect NPTL is at *runtime*, add that
detection in to main() and honour it throughout.  sbbscon.h makes the
thread_suid_broken variable/macro available to other files which need it.

prevent threads from exiting while ids are beign changed.

the SIG33.

So, looking into this issue has shown me a number of things...
1) THE CAUSE FOR SIGWAIT FAILURE!!!
   The new Linux pthread model sends a "real-time signal" SIG33 to every
   thread when the saved, real, or effective user or group ID changes which
   then allows every thread to synchronize their IDs.  You cannot prevent
   this signal, and it causes the current syscall to fail.
2) Synchronet calls do_seteuid() quite often during startup and, when thread
   setXid is broken, every time a thread starts up.  As a result, you can
   get a storm of SIG33s.  Further, calling setXid() when not all threads
   have processed their SIG33 results in a deadlock apparently.
3) There is no apparent way of telling if all other threads have processed
   their SIG33s yet.

As a result, I've added a 10ms pause after a setXid() call to give it time
to work.  Since this happens while the mutex is held, it should work, but
10ms may be too large or too small or not effective.

This will add 10ms to EVERY threads startup time which will negatively
effect just about everything.  I'll be looking into the possibility that
setXid() is no longer actually broken on Linux and so we can reduce this
issue to only happening while Synchronet is still starting up, rather than
ongoing for every thread.

Thanks to everyone for their patience on the sigwait() failure issue.
Hopefully we'll be able to actually resolve this relatively soon.

NOTE: There will still be the sigwait failures during startup... the hope
is that we can prevent them from being an ongoing issue.

was linked with ciolib.  This seems to work perfectly on *nix and is untested
on Win32.

This *should* fix all the SDL-related stupidities that were occuring
previously (second system() call killing the program, etc).

Testers welcome!

setre?id() since new systems apparently hang on that call when the IDs
are already what you want.  Further, use a single mutex to protect both
do_setuid() and do_seteuid().

The symptoms:
When you connect to the BBS, the user prompt would repeat quickly three
times then drop carrier on you.  Nothing you entered ever showed up.
--OR--
You seem to connect to the BBS, but you never see any output.

This was only easily reproduced when starting the system as a non-root
user.

This has been confirmed on FC3, FC4, and Debian etch.


The cause:
output_thread or input_thread called thread_up() which called do_seteuid()
which hung in setregid().  Since do_seteuid() is holding a mutex at this
point, when the other *put_thread calls thread_up(), it waits forever for
the mutex.  If output_thread starts first, this results in getchr()
returning ^C every time it's called since input_thread_running is false.


Question for DigitalMan:
Should output_thread/input_thread post a semaphore when they're up to prevent
SMP systems from getting far enough into answer() to call IO stuff before the
corresponding thread is running?  A timed semaphore wait in main.cpp then
could be used (you wouldn't want to block forever in case this happens again).