This reverts commit 564b0aea.

The previous method (patching Makefile.in) didn't disable warnings when
building 'jsshell' (e.g. js.cpp).

If debugging build issues, build with VERBOSE=1 to get the very verbose
SpiderMonkey build output again.

Finally, a thread-safe version of mosquitto.dll <sigh>

Currently, sbbs.exe only
Includes non-Unix build fix in sbbscon.c for issue introduced in previous commit

Accomplished by manually removing #define HAVE_BCRYPT_H 1 from config.h and rebuilding using MSVC/Visual Studio IDE. Try as I might I couldn't get the CMakeLists.txt changes (e.g. setting ENABLE_CNG to OFF) to take effect, but this seems to have worked.

Why? Because Windows XP didn't include bcrypt.dll (a Microsoft DLL) and we don't really need it as we don't support password-protected ZIP files anyway. <shrug>

SpiderMokey is now built with ctypes, but the object is only
being created in jsdoor for now.

Remove cryptlib's -march=native to avoid SIGILL on x86_64 systems, where SBBS is compiled on a differnt host to where it is run.

This should fix issue #324

- Update SpiderMonkey config.guess
- Include patch for SpiderMonkey Mozilla bug 638056

This may fix various out of resources issues.  Here's what the source
has to say about this number:

/* The maximum number of objects.  By default we use a fixed limit set to an
   appropriate large-enough value because the only time anyone that would
   really be creating thousands of objects is if they're leaking them and
   setting a fixed limit means this is detected without the code having to
   run for days or weeks leaking handles, however we allow a dynamically-
   configurable limit set via CONFIG_NUM_OBJECTS if someone really needs to
   use vast numbers of objects */

This was preventing cryptlib from working with socket descriptors
over FD_SETSIZE despite being patched to use poll() to avoid the
issue it's protecting against.

May fix the various SSH/SSL internal error issues.

Per https://man7.org/linux/man-pages/man3/pthread_yield.3.html
	This call is nonstandard, but present on several other systems.
        Use the standardized sched_yield(2) instead.

Should fix #299.

We don't support platforms where '/' doesn't work as a path element separator.

Just don't check the python version at all.  If your python is older
than 2.5, you're already having other issues.

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

Just some more macOS silliness.

MinGW32 is getting long in the tooth and is missing a lot of modern
Windows features as well as having broken headers.  Most people will
be using MinGW-w64 at this point, so add support for it.  Once I
ensure SyncTERM works properly with it, MinGW32 support will be
discontinued.

I suspect this will impact exactly zero people since the reason this
exists is to build the Win32 versions of SyncTERM on FreeBSD.

Changes:
- Explicitly request 32-bit Windows output
- Detect the string "mingw32" anywhere in the hardware description
- Explicitly link with libuuid
- Add a terrible hack to syncterm.c to block wincrypt.h

This is used by some BBSs to enable encryption without needing to
integrate the BBS user base into their SSH server (and presumably
so they don't need to run multiple SSH servers).  All users log in
with the same username (ie: "bbs") and no password is requested or
required.

Once the BBS starts, it prompts for the BBS user name and password
as normal.

In SyncTERM, the user/password/syspass fields are redefined as
SSHuser/BBSuser/BBSpassword and they are moved around when you
change the connection type.  This means that if you change a listing
that has a syspass to SSH (no auth) and back, the syspass is lost.

I'm not sure if I plan to fix this or not.

It would be fine if this only warned while building JS, we're used
to ignoring that, but this bugger warns while building Synchronet
stuff.

Only supported on FreeBSD, Linux, Solaris, OS/2, GNU, Cygwin, and Darwin
Should allow OpenBSD to build JS engine.

Not yet tested, so more patches may be incoming.

Clang 11 throws an error if you do.

While PKCS#12 export likely works "fine", PKCS#12 import almost
certainly doesn't.  Cryptlib supports a basic strict PKCS#12 read,
while OpenSSL used wild and crazy extensions.

have contributed *something*." -- Cyan

backup the original.  Specify -b to make that happen.