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!

This is pretty bad, someone who has a SELinux clue should give a better
question/answer.

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!