Currently, this has RIP.supported which returns true if RIP is
supported by the client, and rip.loadicons(archive) which sends
all the icons (and .RIP files) in the specified archive (either
an Arcive object or a filename) to the remote if they don't
already have them.

If you have a RIP enabled door, a small JS script as a pre-run
command like this:

require("rip.js", "RIP");
rip.loadicons('/sbbs/xtrl/lord/lordicns.zip');

Will automatically send all the icon files in the arcive to the
user if the user doesn't already have them.  For SyncTERM as of
this commit, they will be placed in the cache directory for that
BBS (and only be available for that BBS).

On *nix, the cache dir is ~/.syncterm/cache/<bbsname>
On Win32 it's something like:
C:\Users\User\AppData\Local\Microsoft\Windows\INetCache\SyncTERM\cache\<bbsname>

No ideal what it is on macOS.

I was going to start keeping the old rect around again, but that
idea didn't pan out.  This massive memory leak is what I get for
not doing more commits while tuning.

Reported by Booch (Thanks!)

This has the effect of the file being listed as absent/deleted in the listing that's in memory. As requested by Phil, plt via irc.

Moving a file after this change did result in a crash once, but I couldn't reproduce it with a debugger attached.

Pixes set via setpixels() were only set in the "blink off" screen
and not in the "blink on" screen... so they all reverse blinked.

1) Keep a rectangle updated per-screen rather than regenerate each time
2) Strip palette info when putting pixels into rectangles rather than
   during scaling
3) Tighten up the screen locks a bit
4) Don't require a full resend of both screens on an update request
5) Only force a redraw for cursor movement when the cursor is visible
   (And force it whenever the cursor changes)
6) Avoid doubles in interpolation
7) Heavily optimize interpolate_height()
   interpolate_width() likely doesn't need it because it's generally not
   used and also it reads from the next pixel in memory making the
   prefetchers job easier.
8) Fix some memory-leak-on-error issues
9) For ARGB8 XImages, manipulate the data directly rather than through
   XPutPixel()

At this point, the scaling and X11 output time is heavily dominated by
cache misses.  The only really effective way to reduce this hit is to
spread the work across all the L3 caches in the system or move it into
the GPU.

With the latest updates, at the SyncTERM menu, over 90% of the time is
spent in the rendering pipeline, and over 90% of that time is spent
thrashing the caches... the only real easy win left is vectorizing, but
that's highly compiler specific.

To that end, I've switched to -O3 for release builds.  There was a comment
that -finline-functions broke Baja "badly", but that's clearly false since
-f-inline-functions has been part of -O2 for quite a while now, and Baja
doesn't seem any more broken that it ever was.

SBBSecho uses mkstemp() now (instead of tempnam()) - so we need this POSIX function wrapper for Windows builds to succeed.

Since we're cleaning up warnings... this will break the Windows build for now.

It will be used in the future, so the code shouldn't be deleted,
but not using it causes a warning.

reply on.  Make it harder to merge this code from upstream in the
future instead.

At least the warnings are gone.

Deuce doesn't want to add "useless parenthesis" to xbr.c.
Hopefully Clang will just ignore this -Wno-* option?
warning: suggest parentheses around ‘&&’ within ‘||’

warning: always_inline function might not be inlinable [-Wattributes]

While we're doing that, actually use it in SyncTERM so the offline
scrollback retains fonts.

Also, fix an issue where the current mode would be updated with
the custom parameters when you changed them.

Finally, remove some unused variables.

It seems that at least LORD has upper-case in the ZIPs and lower-case
in the queries.

The biggest issue with SkyPix is the fact that it's *not* a character
cell mode.  The cursor is pretty much impossible to position correctly,
and all the text "stuff" basically needs to be bypassed.

WIN_INACT was not getting a border because it changes the value
of bclr which is explicitly compared with BLUE to detect if a
shadow should be drawn.

Instead, draw a shadow any time it would normally be drawn.

Fixes X11 window dragging blinkiness.

If do_scale ever failed, it would result in graphics buffers not
returning to the pool, resulting in them never being reused.

Now that ALT-Up/Down no longer have an effect on window size, they
can go back to their previous bindings of changing the emulated
output speed.

At the same time, remove AltGr support from keysym parsing since it
should be properly handled by the text input stuff now.

Caused the initial window to be the wrong size.

See https://www.pepto.de/projects/colorvic/ for details.

People are used to thinking about the aspect ratio of displays and
used to not thinking at all about that of pixels.  Most of the modes
are simplt 4:3 modes and the text area is the entire window.  The
only oddball here is the Commodore 64 and 128 40-column modes.
Because they have a border around them that's wider on the sides than
the top/bottom, the display aspect ratio is actually narrower than
a normal NTSC screen (6:5).  It seems the PAL version actually has
square pixels, but nobody has asked for a PAL Commodore mode, and I
think that has a different colour palette too so I'm not doing it.

Just to frustrate DigitalMan a bit, the default custom aspect ratio
is now 4:3 (but can be configured).  At present, modifying the custom
mode while *in* the custom modes "works", which no sane person would
want when adjusting the aspect ratio.

Use remaining bytes divided by CPS rather than total estimated time
minus elapsed time.

We squirrley on resumed ZModem downloads.

Fixes issue 56

This is fine.

Was using the 14 row font with 350 screen rows and expecting 43 lines.

We're leaving the "Awesome Modes" as 1:1, but the rest all assume
a 4:3 display that is filled by the described text.