Fix age-old bug with Borland/C++Builder built executables (Windows):
to achieve compatibility with  the default __cdecl symbol naming rules of
Visual C++, we were using __stdcall convention for DLL functions when
building code with Borland/C++Builder tools and using the default (__cdecl)
convention when building with Microsoft (Visual C++) tools. Although this
allowed symbols to be located when linking, the calling convention mismatch
caused a stack cleanup issue that very rarely manifested itself in a bug
(e.g. exception of some kind in sbbsctrl.exe, usually). Mismatching
the calling conventions was unintentional (I thought the default for MSVC
DLL functions was __stdcall) - but since the calls to MSVC-Built DLL functions
worked 99% of the time, I didn't realize there was an underlying issue. So I
now work-around the DLL symbol naming mismatch using a command-line option (-a)
passed to implib in src/sbbs3/ctrl/makelibs.bat

I had previously worked-around exceptions when calling MSVC DLL functions in
sbbsctrl.exe by calling the problematic DLL functions from a timer tick handler
rather than a user control (e.g. button) event handler. Those work-arounds can
now be removed.

The erroneous "DLLCALL" definition design pattern was replicated (copy/pasted)
to many other projects' header files in cvs.synchro.net. In the future, we may
want to just remove all instances of *CALL since they now serve no purpose and
appear as useless "Kruft" (but do allow us to more-easily globally change DLL
function calling conventions if/when necessary in the future).

warning: ‘%s’ directive writing up to 4096 bytes into a region of size 3969

function of the same name. The dirwrap version (now) behaves identically
when passed a pathname ending in a directory name (ending in a '/') but
differs when passed a pathname ending in a file name (not ending in a '/').
That should be okay.

accommodate configurations of more than 10,000 things (e.g. sub-boards)
in a single menu (e.g. message group).
This brings this value over the 16-bit thresholds (0x7ffff and 0xffff)
where problems could happen if short's/int16's are used to capture the
return value of uifc.list(), but that's unlikely happening anywhere. Still
a good idea to make sure if you're using this library/headers.

Most of the copyright years in the source code were misleading (the date of
most recent publish was actually later) and all were unnecessary. I've been
removing copyright years piecemeal, for a long time, but I decided it was time
to just perform a bulk search and (mostly) replace. In some cases, I left
old copyright years on files that either are not used (and soon to be removed)
or obsolete and unlikely to ever be touched again (e.g. Win9x FOSSIL VXD). Some
of the runtime binaries still contain copyright years and those were updated to
2018.

--"coverity"

in the file though, or it will output garbage.

-- coverity

We're switching to TrueColor now, and maintaining a 65536 entry palette
for the various palettized bits.  This change hurts the overlay output most
since it currently means floating point calculations for every pixel.

The getfont() function now takes a fontnum argument so you can get all the
current fonts.

The vmem array now holds the font data, so once a glyph is written to the
screen, it can stay in that font "forever".  This still has some issues
with savescreen()/restorescreen() since there's no extension to grab the new
stuff... that'll be coming soon, likely replacing the pgettext() and
pputtext() functions.  For now, various popups will likely reset fonts to
the default font on the screen.

Now that we have all this, the status bar in SyncTERM can retain the default
font and colours at all times.  Further, menus can be displayed in the "right"
colours and fonts, and no more translation will be needed.  This is a work
in progress though, so there's likely to be glitches.  The scrollback doesn't
have the font data either (same issue as savescreen()/restorescreen()).

messages (frame), introduced in rev 1.231.

calls to uifc.input() - don't default to overwrite mode for every call.
This also allows external/app control of the insert/over-write mode via new
uifcapi_t element: insert_mode (default is FALSE).

- Update bottom-line/status bar with applicable control keys (Ctrl-C/X/V)
- Ctrl-X now cuts the text to the Clipboard, rather than just deletes
- Ctrl-C now copies the text to the Clipboard, rather than aborts
- Ctrl-V now pastes from the Clipboard into the text field, not toggles insert
The old CUA keyboard equivalents for Copy/Cut/Paste are supported too
(Ctrl-Ins, Shift-Del, Shift-Ins)
The system Clipboard is used, just like with the mouse methods of copy/paste.

ufic.showbuf() changes (used for displaying help text):
- Fixed the "End" key behavior (actually goes to the bottom of the text)
- Display up and down arrow glyphs in the lower-right corner/border to indicate
  if the text can be scrolled up or down (e.g. with the arrow keys/etc.).
  If the arrows are mouse-clicked, that simulates the arrow keys being hit.

the same as the Delete key. Apparently this change was introduced in the uifc.c
->uifcc.c/uifc32.c port and never noticed (by me). Pointed out by Nelgin.

before printing the message.

is always the same operation (e.g. Paste-Insert).
MSK_PASTE_OVER and MSK_PASTE_INSERT have been removed (now combined into
MSK_PASTE), so current SCFG code, for example, won't compile.
Introduced a separate WIN_CUT uifc.list mode flag to enable the Cut (e.g.
Ctrl-X) option on the status/help line.
Re-factored the bottomline() routine to re-use the WIN_* mode flags.

Added Cut and Paste-Insert support to stdio version of UIFC.

applicable.

i.e. for new scfg/echocfg -k (keyboard only) option.

different from Ctrl-V or F6 which is "Paste Over" (overwriting selected item)

- returns index with MSK_CUT in upper nibble
- Cut is initiated with Ctrl-X or Shif-Delete
- Same as Get/Copy (F6/Ctrl-V) except the source item is removed

* Ctrl-Insert is now supported for Copy (in addition to Ctrl-C and F5)
* Shift-Insert is now supported for Paste (in addition to Ctrl-V and F6)

* Fixed a couple of potential NULL savbuf dereferences (one sighted when using
mouse).

(blank) item. Replaces the previously unused WIN_EDITACT mode flag.

v3 to crash when used with the '-iD' option. Oops.

online help, set the current "window" to inactive colors and then restore to
original colors when online help is exited. For 80x25 consoles, the user
probably won't notice any change since the online help window fills the screen.

If DigitalMan uses the Edit and Continue feature, he can fix it.  :-)

WIN_EXTKEYS special.

the caller.

is the only defined flag.  Set when the UIFC function exits because a
CIO_KEY_QUIT was read.