This was ending up using an uninitialized value

No need to build twice just to create the bundle.

In theory, a crazy person could grab it every day and upgrade it.

You still need to specify it, but you can create a /usr/local dpkg
now if you don't.

It's pretty important to specift PREFIX here right now since it's
not actually used in the paths, which means there would be a mismatch
between where the files are installed and where the data lives.

This is fairly easy to fix, but I likely never will.

It appears its matching based on the class, not the application.
Since this was hard-coded to CIOLIB based on the idea of using
resources to customize all CIOLIB windows, this didn't match the
SyncTERM .desktop file, so ChromeOS assumed it was "something else"

Add yet another ciolib_initial_* variable to set this, and she's
finally good!

Part of my apparently never-ending quest to get the icon to show up
for the SyncTERM window on ChromeOS.

Cyan may have a better fix. <shrug>

Implied by _NET_WM_PID being set, so may as well do it.

Seems like a good idea, should allow WMs to kill hung processes and
stuff like that.

It was redudnant having "External Editors" under "External Programs" (they're
all external, yeah?) and of course, "Editors of what?"

So yeah, existing docs are now all wrong. :-)

The XSynchronize disablement is the most important here... didn't
realize it defaulted to enabled, which has been slowing down a *lot*
of stuff for a long time... not that there's much left that benefits
from disabling Synchronized XLib except this new terrible icon thing.

Keyop reported an issue via irc whereby a user that failed to download a file
would leave the node "hung" in "downloading via telnet" node status even
though the user had long since disconnected and the log reflected that the
terminal server was aware of this:

term Node 4 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 4 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 4 <user> external Timeout waiting for output buffer to empty
<minutes later>
term Node 4 connection reset by peer on send
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 !ERROR 32 sending on socket 102
term Node 4 disconnected
term Node 4 !ERROR 32 sending on socket 102

and

term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !Receive timeout (1 seconds)
term Node 3 <user> sexyz: !1152 zmodem_recv_raw TIMEOUT (10 seconds)
term Node 3 <user> sexyz: !zmodem_recv_header TIMEOUT
term Node 3 <user> external Timeout waiting for output buffer to empty
<minutes later>
term Node 3 connection reset by peer on receive
term Node 3 !ERROR 32 sending on socket 96

These nodes were then locked up in call to passthru_socket_activate(false)
as reported by gdb, e.g.

Looking at passthru_socket_activate(), the deactivation path (called at the
end of external() in this case), it was clear that this could be an infinite
loop in the case the user had disconnected:

    do { // Allow time for the passthru_thread to move any pending socket data to the outbuf
        SLEEP(100); // Before the node_thread starts sending its own data to the outbuf
    } while(RingBufFull(&outbuf));

These flush/purge loops aren't strictly needed if the user has disconnected,
but as can be seen by the above logs, the terminal server may not know that
(the socket may not indicate disconnect) before passthru_socket_activate()
is called by external().

So... worst case, just do the activation and deactivation buffer flushes
and purges for 60 seconds.

On Linux, this changes the program name shown in top.

This allows X11 stuff to work properly.

Actually install the colormap we create.
Remove the 48x48 icon.

As it happens, ChromeOS completely ignores the X11 icons and instead
does some weird magic to drag the icon .png file out of the VM and
uses that.  Basically, getting the icon to work appears to mean
putting some properly named files into magic directores.

USize was wrong, PSize wasn't set, and PBaseSize was set, but flag wasn't.

Also, set both _NET_WM_ICON and WMHint icon pixmap

It seems whatever WM XWayland uses doesn't actually use _NET_WM_ICON
like pretty much everything else for the last 30 years does, so we
need to go old-school or settle for the default pengion icon, which
offends me personally.

The bracketpaste "bit" was set to 0x16, not 0x10 or 16 as intended.
Erase line would erase the wrong line if the scrolling region didn't
start on line 1.

The sketchiest bit here is removing the uifc -> conio dependency
which, since it needs to depend on conio_sdl now means if something
is relying on that, it will need an explicity dependency...

We'll see what the pipeline says.

Maybe, who knows?

"I can't think of a reason I'd want scfg and echocfg to remain windows (gui) programs"
                                              -- Digital Man

While I'm here, hack up some SyncTERM vcxproj stuff (which almost
certainly doesn't work, but since I can actually test it now, I
may as well try)

Also, prevent unreachable and unleavable sectors.

For use with jsexec