When a resize event is serviced, cache the new scaling factor.  Next time
the event queue is empty, attempt to lock vstatlock.  If that succeeds,
apply the new scaling.  If not, wait for the queue to drain again.

This may cause the scaling to be slightly delayed, but should completely
solve this deadlock.

This deadlock likely never affected FreeBSD since FreeBSD has deadlock
detection, and the return value of pthread_mutex_lock() isn't tested.  The
result would have been a silent failure to lock, and an update of the scaling
factor regardless, followed by a silent (again untested) failure of the matching
pthread_mutex_unlock() call.

by sdl_ufunc_mtx.  Fix up the sdl_ufunc_mtx usage to help prevent errors.

Also, work around a deadlock on Win32 where a video resize event while a
redraw event is later in the queue would deadlock on the vstatlock mutex.

This problem is *not* completely resolved yet.  I think the new scaling
will need to be cached, then applied the next time the queue is empty.

Reported by Digital Man

Reported by Digital Man.

"Connection Type: Type of connection"

Reported by "Digital Man", Sysop of the German "Confidence" BBS (per Google
Translate)

and 'List-Post') header fields to exported posts at PSI-Jack's suggestion.

every key input as well as every return from a UIFC function that waits for
input.

This also fixes what appears to have been a bug in renaming an entry which
could have broken things if you tried to enter a zero-length BBS name.

There may still be weird edge cases where the quit button doesn't work, but
this should fix most of them.

WIN_EXTKEYS special.

your return value anyway.

item enqueing stuff which has been carefully preserved and equally carefully
never used.

call free() when processing for a js_peek() call with the old manual
serialization.  Obviously, it hasn't been used since the update to the JS
internal serialization stuff, and the new fix doesn't need it.

js_peek() calls js_decode_value() which would free the data for successive
js_peek() or js_read() calls to choke on.

Thanks for the report MCMLXXIX!

to use multisock.

if the lock or unlock operation was successful (the opposite of the expectation
of the BOOL return value).
The current callers of these functions are not checking the return value, so no
actual observable bug is fixed with this commit. These are not the bug-fixes
you are looking for.

the caller.

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

(the default).  If the program doesn't already handle CIO_KEY_EXIT, waiting
a half-second isn't going to help, and if it does, it should turn off the
reaper.

possible with minimal code changes.  The close button will not work in some
places still though... noteably during file transfers and when in most menus
except the main one.

At least it doesn't hang anymore... it will ignore the close request and keep
going.

A proper fix for this will require UIFC to do some "right thing" for close
requests.

ensures the program quits when the user presses the exit button and the program
doesn't handle CIO_KEY_QUIT.

This still isn't the best way to do things.

located speciously designated as "\\?\" but displayed and input as ""
since that's how Windows users think of it.