No system seems to actually install en_??.IBM437, but that's what it should
be called, and it falls back to C so good enough I guess.

*may* break all sorts of other things.

a major regression for key input. :(

Hopefully this fixes the issue Ragnorok was reporting with a Spanish
keyboard.

Have the scrollback set the palette as well.

To be fair, this is all weird.

Requested by Jeffrey S. Worley.

Note: There's still no way to send ◢, ▗, ◣, and 🮂 as these are mapped
to Backspace, Tab, Line Feed, and Carriage Return respectively.

(successive beeps currently still will)

Make xptone_open()/close() reference count in threaded mode.
Use pthread_once() for init.
Use a semaphore to ensure the sample play thread is only started once.
Expose makewave()

programs: PCBDRIVE (the drive letter of the current node directory) and PCBDIR
(the path to the current node directory, without the drive letter).

These emulate the same variables crated by PCBoard.

The reason these are being added is that Sunrise Door Software's 16-bit doors
contain special support for these environment vars when used in their .CFG files
(e.g. %PCBDIR%DOOR.SYS) and this allows easy multi-node configuration with a
single .CFG file. The SBBSNODE environment varialbe would have worked perfectly
fine for this purpose, but apparently Sunrise Doors (or the DoorFrame
development kit they utilized) has hard-coded these PCBoard (and Wildcat!)
environment variable names, so SBBSNODE wont' work for this purpose.

For Synchronet-Win32, you will need the DOSXTRN.EXE revision 25 or later
or you may experience NTVDM crashes when running external DOS programs.

have more than 10 environment variables defined in it. I added no bounds
checking or dynamic allocation, so if the file contained more than 10
environment variables (and it has since 2002), other stack memory in DOSXTRN
would get over-written (classic buffer overflow).

When I recently experimented with adding another environment variable (PCBDIR),
all dosxtrn NTVDM instances would crash with a familiar but mysterious error
dialog. This bug may have been causing other dosxtrn instances to crash for a
long tmie.
I also had an arbitrary limit on the number of command-line arguments, 16, with
no bounds-checking, so passing a long list of space-separated arguments could
also crash DOSXTRN.

So I've increased both limits to 32 and added bounds checking. I had to break
out the old 16-bit MSVC (v1.52) and an NT2K DDK (and remove the 64-bit int
stuff from gen_defs.h) to get this thing to build. But here it is. Updated
again after all these years. Who'd a thunk.

to resolve the infinite loop when emulvt.pas received terminal sequences it
doesn't like (e.g. SyncTERM font-transfers).

in v3.4.5.

So Deuce spent a lot of effort creating patches to the original Cryptlib v3.4.5
source files to tune cipher-suite selections/priorities to make modern SSH
clients (e.g. OpenSSH v7.6) and HTTPS/TLS browsers or security-checking
software happy. See the current list of 3rdp/build/cl-*.patch files for details.

of the Cryptlib private key (cryptlib.key) and TLS certificate (ssl.cert) files.
When the system password is changed, prompt to delete the cryptlib.key and
ssl.cert files for the sysop.

This is sort of hacky-yucky but better than answering this FAQ all the time.

better traceability.

(e.g. because the console/terminal server was terminated locally), this routine
would attempt to handle any remaining (unhandled) vote mesages and throw-up
checking "conference number" access=0 invalid=invalid errors
because it was trying to process all the (unhandled) sections in the VOTING.DAT
file rather than just the sections beginning with the applicable section
prefixes ("poll:", "vote:" or "close:"). Every other section is actually just a
hex offset into the MESSAGES.DAT file and does not contain the "Conference"
key that qwk_vote() was expecting to find.

I noticed that more than one caller of smb_open_sub() would not call
smb_create() if the sub had not been previously "created" and in some of the
instances where they did call smb_create(), if create failed, the message base
was errorneously left open. So just do the create here to elmiinate the chance
of error (forgetting) and redundancy of logic.

builds.

center the xim in the resulting window and fill the rest with black.

Resize the xim if the window isn't scaled.

The xim wasn't scaled to the new size (ever)

be expanded if people like it... this can be used to store and replay data,
making sprites a lot easier to implement client-side.

Because the test to continue is *after* the loop, we can't continue
when c is the last index into lzh->son, or the code will make use of
lzh->son[sizeof(lzh->son)/sizeof(lzh->son[0])] which is outside the bounds
of the array.

32-bit Linux systems.

Found by Coverity.

Fixes coverity warning in SyncTERM... matches the size all callers currently
use.

easily result in a message body being added to a message base with no
accompanying message header: if the header data was 0-length, the hfield_dat
was not actually allocated and the applicable smbmsg_t convenience pointer was
not set accordingly. This had the side effect that if a message were to be
imported with a blank recipient ("To" field), the header was not created at
all (to support mutliple header, single body msgs, i.e. bulkmail).
The other functions that set the convenience pointers do not treat 0-length
header field data special, so this was inconsistent behavior.
Most message types (e.g. networks) don't want 0-length "to" fields, but that
shoudl be enforced somewhere else, not here.

So on Windows, calling unlock() on a file region that you don't have locked,
incurs a delay. Likewise, calling lock() on a file region that already have
locked incurs a delay. These delays were seriously throttling message imports
on Windows (e.g. importing echomail or QWK packets). What should take a few
seconds, was taking minutes with noticeable delays. This code has been
performing redundant locks/unlocks for over 15 years, so I can only conclude
that the performance penalty is a new behavior introduced in recent version(s)
of Windows.