More precalculation in bitmap_draw_one_char()
Optimize loop-initialization of buffers

This is about as good as it can get without drastic data structure
overhaul.  Biggest win with overhaul would be with eliminating
memmove() for scrolling and copying into scrollback. memmove()
accounts for a high percentage of CPU utilization right now.

When fast scrolling, memmove() takes most of the CPU by far... it
is likely actually worth having each line be a buffer of its own
and just moving the pointers around.  To help with this optimization
in the future, move the screen memmove() bit into a separate function.

Based on qwk.ssjs

I tested this using:
wget --auth-no-challenge --post-file=file.ext --http-user=username --http-password=passwd vert.synchro.net/upload.ssjs?filename=file.ext\?desc=description-text

This currently requires an "uploads" directory to be configured by the sysop.

I'm not sure if there's a better/more-standard way for the posted filename or
content to be included in the request. This is just a sort of proof-of-concept
as a solution for issue #554. Perhaps an ecbwebv4 page displays a prompt to the
user for their filename and it redirects to this page. Not sure how that'll
work.

user_dir, sysop_dir, upload_dir, and offline_dir

These properties could magically appear later once
file_area.[lib|dir|lib_list] was enumerated for the first time.

Not sure who mispelled Synchronet in here. That's embarassing.

Fix a couple warnings while we're here.

This should almost completely remove vstatlock contention in SyncTERM,
which should bring SDL output performance close to X11 performance.

This makes cvstat work as intended, so we no longer need to lock
vstatlock when accessing it since it's only accessed from the
video event thread.

There's still an irritating dependency on vstat for ALT-Enter handling.

When originally created, it was intended to be accessed only by a
single thread, and therefore not need mutex protection, allowing
less code to run with vstatlock held.  Unfortunately, this is not
how it turned out, so cvstat should either be removed, or it should
actually be cleaned up to work as intended.

for an extended time.  Should fix SDL mode slowness.

Only call RenderPresent() if we called RenderCopy().  Should fix
SDL mode flickering.

DDMsgReader: Allow word-wrapping header lines of arbitrary length

See merge request !287

DDMsgReader bug fix: Ensure header lines are not too long for the user's terminal. Should fix issue #550

Closes #550

See merge request !286

Eric Oulashin authored 2 years ago and Rob Swindell committed 2 years ago

DDMsgReader bug fix: Ensure header lines are not too long for the user's terminal. Should fix issue #550

Fix issue #551

DDMsgReader: Quick-validation of local user (Ctrl-Q) - For issue #548

Closes #548

See merge request !285

When adding a BBS entry with a TCP connection, if a ":port" suffix is included
(e.g. "vert.synchro.net:23"), parse and use that port number for the new entry
automatically and remove the suffix from the adddress itself.
This is just a time saver when adding new BBS entries.

Care was taken to not treat the following addresses in this manner:
 ":<port>"   - would have resulted in a blank address
 "a::<port>" - possible IPv6 address
 "a:<port>b" - possible IPv6 address or ... ?
 "a:<invalid-port>"

DD area choosers: Bug fix for current selected sub-board/file directory when using collapsing. Color settings no longer need the control character.

See merge request !284

When Secure EchoMail is enabled and a Bad Echo Area (*) is defined in the
area file (areas.bbs), but the packet source address is *not* listed as a
link to the Bad Echo Area (tag: *) in areas.bbs, any messages for unknown
areas in such a packet would cause the pkt to be considered a bad packet
with a security violation. Instead, the message should just be skipped.

Set the CIOLIB window title (so it's not the default "SyncConsole")

DD area choosers: Bug fix for current selected sub-board/file directory when using collapsing. Color settings no longer need the control character.

So a sysop now has 3 choices for SBBSecho's handling of incoming bad packets:
 - delete them
 - rename them *.bad
 - rename them *.reason.bad (the default)

If SBBSecho is configured to rename bad packets, but the rename fails, the
error is logged (as before) but the packet is not deleted (this is a change
from previous behavior).

Always log the *reason* a pkt was determined bad in the "Bad packet detected"
log message.

When bad packets are detected and renamed to ".bad" files, include the reason
in the new filename (e.g. "ff69453a.src-addr.bad" or "ff69453a.pkt-passwd.bad"
instead of just "ff69453a.bad") to make it easier for a sysop to determine
what to do with the bad packets without having to search through log files
to discover the reason *why* SBBSecho considered the packet to be bad.
This behavior can be disabled if desired by setting EchoCfg->Global->Verbose
Bad Packet Names to "No". Note: the reason used is the *last* reason
detected/logged for a packet to be considered bad; it's possible that there
are multiple reasons that a packet may be considered bad. All reasons will be
logged, but only the last reason is used in the new bad packet filename.

Also added the missing "Delete Packets" option (to EchoCfg->Global). Though
this setting was added in sbbsecho v3.0 (and settable via sbbsecho.ini), it
was never exposed via EchoCfg; I don't think that was intentional. Normally,
you'd always want to leave this set to Yes (the default) to delete processed
packets, but when debugging, it may be desirable to leave the packet files
in place. This what the old sbbbsecho v2 '-x' command-line option used to be
used for (disable the deleting of processed packets).

Moved the Global Settings, EchoMail Settings, and File Paths config menus to
the upper left of the screen in EchoCfg. The placement seemed inconsistent
and erratic, so this is a bit of a cosmetic improvement.

Using the same logic that SBBSecho uses to decide if a packet header is in
fact 2+ (the auxNet field must be non-zero), otherwise, type reported is 2e.

CID 452331
CID 452330

The CP437 character characters used for the arrow indicators aren't always
mapped to the expected characters in all fonts (e.g. on Windows), so add an
option to use ASCII alternatives (<>^v) when that's a problem.

Command-line options must begin with '-' (not ye olde CPM/DOS '/option')
Command-line options are now all case sensitive (e.g. '-a' not '-A').

Remove '-d' (long deprecated for '-id')
Remove '-t' (long deprecated, do nothing)

I noticed when setting a security level's lines per message value > 32767
in SCFG->System->Security Level Values, the value would be read back as 1 or
or some other crazy value. That was because we were writing this value
(and all the security level 16-bit values) using iniSetShortInt(). These are
*unsigned* 16-bit values, so that we should have been using iniSetUShortInt().
We'll just use iniSetUInteger() instead to fix that/those issues.

And since promotion/conversion from uint16_t or uint32_t to uint has no impact
when creating a decimal representation of a number, just use iniSetUInteger()
everywhere we're setting unsigned integer settings in the main config .ini
files. If/when these fields are made larger in the future, this code will just
work.

When reading .ini integers, use the more appropriate iniGet[U]Int16 functions
instead of iniGet[U]Short and use iniGetUInteger for reading enums or any
values that are immediately typecast to a uchar/uint8_t.

Replaced some other use of [u]short that I found when searching with stdint.h
types.

Rather than recomputing (possibly differently) the max lines in multiple
places.

This also enables the possibility that editfile() could be used to edit files
of > 10K lines in the future. <shrug>

If a user's security level lines per message was set to '0', bad things would
happen to the heap if the user posted/sent a message. '1' is a reasonable
minimum value. If you don't want a user/group of users to send/post messages,
there are restrictions for achieving that. Also this setting is (currently,
at least) 16-bit, so clamp it there too on the high end.

Also clamp the expire-to security level setting between 0 and 99, while we're
here and noticed that this value wasn't being sanitized either.