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.

Instead, just set bar to the end and let ulist() sort it out.  It
sucks, but it sucks less.

Microsoft wants us to use a manifest for this, but I really don't
feel like digging into however one uses manifest files when not
using the Microsoft build files.

Details here: https://docs.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process

This may solve issue where using Windows "DPI scaling" forces the
window to be scaled.

New text.dat string:
- EditExtDescriptionQ

Removed text.dat string:
DeleteExtDescriptionQ

Was passing the address string twice, so the port appeared as an invalid number.

Altere reported via IRC:
!ERROR -1 (113) connecting to passthru socket

It might be helpful to know the address the passthru socket is bound to and the connection is being attempted on, so log that with the error.

This is the likely cause of Phil's reported errors when removing files:
access=-110 info=smb_removefile name not found

The only way I was able to reproduce these errors was to attempt to remove the same file multiple times in the same file listing. In other worse, use 'R', remove a file, then 'P'revious back to the first file and try to remove it again. Or to remove it a file from the batch flag prompt and then attempt to remove it again. <shrug>

This eliminates any ambiguity about what exact version was in use when each error is logged.

CID 330960, 330967, 330988

If the file doesn't already have a description, f->desc may be NULL.
Remove the redundant user name in the "removed file" log message.

This may have contributed to plt's file editing woes.

Fix issue reported by Jay Crutti.

CID 331582

Make it the default.