Weird.

one or the other.

*sigh*

Backspace (the "Delete" key on a MacBookPro keyboard) is treated the same
as ESC (exit).
Make the help status bar more clear in Mac OS X builds that the '+' key
may be used in place of the INSert key to add itesm and that fn-DELete key
sequence is used to delete items (or the '-' key, though that isn't stated).

treat the same Delete Char. This is for systems were there is no "Delete Char"
key (e.g. Mac) or where the Delete and Backspace keys send the reverse key
codes. On a Mac, the Backspace key is actually labeled "Delete", so treat
the key-code sent as "Delete item", consistent with the status bar/help
indicator.

on a Mac keyboard and although that key sends the ASCII DEL char (127), we're
converting it to backspace (^H) here. But if the user actually wants the
"delete character" key functionality, there is no dedicated key, so treat
Ctrl-Delete (on a Mac) as Delete (not backspace).

don't need it.

This should fix OS X (and other systems) doing weird things when they
exit SyncTERM.  We were forcibly preventing atexit() handlers from running,
and pretty much everything installed some of them.

reply code.  Maybe this used to be on the same line as the BBS name?

Make resume only perform any actions if curses is suspended.
This may fix the Syncterm OS X raw on exit in -iC mode.
(But may not either)

May fix OS X stack clobbering issue.

never maintened or used since. So... remove from CVS.

Log free disk space errors to sbbsecho.log (as well as print to stdout).

We don't store (findable) hostnames in the file, so don't search for them.
Don't search file if the host is listed in the spamblock_exempt.cfg file.
If you have a really large spamblock.cfg file, this could result in the
unnecessary reading of potential many megabytes of data for each inbound
SMTP connection. We might want to read this file even less frequently and
store the list in a searchable str_list_t or something.

"Application" is not a registered category.
Add TerminalEmulator and Dialup categories.

  I think that > 1MB post data is supported, but the http_request.post_data
  property won't be created if the length > MAX_POST_LEN. Perhaps would just
  store the post data in a file (uh, it already is?) and expose the filename to
  JS scripts? It'd be a lot cleaner than storing the data in a file and then
  reading (or mem-mapping) the file and then copying the contents into a JS
  property.

Allow the JS http_request.post_data property to contain NULs.

open_post_file() will now open the post file (and return the FILE*) even if
  session->req.post_data is NULL, it just won't try to write to the file if the
  post_data is NULL.

mem-map the large post data files using XPMAP_WRITE (read/write) rather than
  XPMAP_READ (read-only) - without this change, this line in read_post_data()
  would cause an exception:
    session->req.post_data[session->req.post_len]=0;
  Now, we seem to have the potential of an off-by-one here (if the length
  mem-mapped is not post_len + 1), but that isn't happening. <shrug>

Fixed a couple of FILE pointer/descriptor leaks if post_to_file() failed.

Changed name of post data file to SBBS_POST.*.*.data (it's not necessarily
html).

So now, uploads > 1MB work, but questions remain:
- wouldn't PUT be a more appropriate method (than POST) for file uploads?
- how can we support post_data > MAX_POST_LEN (now 4MB) in JS?

(don't pass a NULL pointer to fwrite() which can assert or crash).

sub-board (if there was one) which pointed to the cut-sub.

(or deleted) or a group of sub-boards was deleted, and any of the deleted/cut
sub-boards belonged to a configured QWKnet hub, that QWKnet sub-board would
end-up pointing to the next sub-board in the configuration (possibly in another
message group, possibly not part of the QWKnet in question). Now, if a
QWKnet sub is deleted/cut, remove it (correctly) from any QWKnet hubs using
a common (new) function: remove_sub(). The bug was: the remaining sub-board
pointers were moved *before* the remove-sub pointer was compared against the
list of QWKnet hub subs (and NULLed), so while the effort *was* made to address
this problem, it didn't actually work in practice. Thanks for the bug report.

not defined" exception, just report the load() exception - whatever it was
(e.g. could not open load-file).

smb_freemsgmem():
bounce() is using a strange method of copying a message header in memory
(not using smb_copymsgmem) and when it frees the message, ends up with a
double-free of the 2 new smbmsg_t members (not header fields): text_subtype
and text_charset.