Synchronet now requires the libarchive development package (e.g. libarchive-dev on Debian-based Linux distros, for more info) to build successfully.

  1. 05 Apr, 2021 1 commit
  2. 04 Apr, 2021 1 commit
    • Rob Swindell's avatar
      A poll() failure with EINTR does not mean a socket is closed. · fcf58640
      Rob Swindell authored
      This won't impact Synchronet as it has a separate signal handling
      thread, but we still need to behave properly for processes that
      don't.  I'm also saying that ENOMEM does not indicate a disconnection,
      though it may be better to pretend it was disconnected...
  3. 02 Apr, 2021 1 commit
    • Deucе's avatar
      Initial work on setTimeout() · ad635a64
      Deucе authored
      This appears to work and the event handler *should* work on other
      event types already.
      Note, this is *nix-only due to the use of poll().  select() will
      need to be used for Windows to keep XP compatability.
  4. 18 Feb, 2021 1 commit
  5. 24 Jan, 2021 1 commit
    • Rob Swindell's avatar
      JS module command-lines now supported quoted arguments (w/white-space) · 47f8c020
      Rob Swindell authored
      Command-line: ?showargs   " a b c "d "e f"
      argc = 3
      argv[0] = ' a b c '
      argv[1] = 'd'
      argv[2] = 'e f'   
      This resolves a long-standing TODO comment.
      Also, fixed a problem where multiple spaces between the module name and the first argument would result in argv[0] being set to an empty string.
  6. 26 Nov, 2020 1 commit
  7. 06 Nov, 2020 1 commit
    • Rob Swindell's avatar
      Replace ctype.h function calls with new MSVC-safe XPDEV macros · 8a7b7308
      Rob Swindell authored
      I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.
      This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).
      The new macros names are bit more descriptive as well.
  8. 04 Nov, 2020 1 commit
    • Rob Swindell's avatar
      Always evaluate js.on_exit() installed expressions. · 175d0fbc
      Rob Swindell authored
      I noticed that when executing an external JS with the new "Use Shell / New Context" option set to "Yes", that any expressions (strings) installed via js.on_exit() were not being executed upon exit from the script. These on-exit strings are important for restoring global state information (e.g. control key pass-through, console mode) to the original state before the JS mod made any changes.
      I'm not sure why the special treatment of "scope == NULL" is through-out this function. Going back to v3.16, it appears this was special treatment for JS mods invoked via global hot key event (when scope != NULL). When invoking an xtrn JS mod with the new Context option, the scope argument is not NULL, so this check was defeating the parsing of the "exit_code" and the evaluation of any js.on_exit() installed expressions for no apparent reason. I can't think why global hot key events should be excluded from this logic either.
  9. 30 Aug, 2020 3 commits
    • Rob Swindell's avatar
      External program "use shell" option can be used to use a new JS context · 1decdc69
      Rob Swindell authored
      Rather than introduce yet-another-external-program/config flag to enable
      the "new JS run-time/context" per invocation of any particular JS command,
      I'm using the XTRN/EX_SH ("Use Shell") option as it had no function for
      JavaScript command-lines and the concept is similar.
      So if you want to invoke a JS external program/timed-event in its own
      "sandbox", enable the "Use Shell / New Context" option for that
      program/command in SCFG. There may be performance penalties when running
      JS mods in this way, but you get the benefit of isolating one JS module
      from all others, if/when necessary.
    • Rob Swindell's avatar
      Previous commit fixed issue with JS_GC before JS_ENDREQUEST · 25625186
      Rob Swindell authored
      So revert the order back to the way it was in aa2bcd61
      (don't you love these git references?).
      Also, the previous fix for js_execfile() calls for global hot-key events also
      fixed the EX_JS_CX feature I was working on (js_execmodule)!
    • Rob Swindell's avatar
      Fix JS global object corruption when invoking JS global hotkey handlers · cb5188bd
      Rob Swindell authored
      As reported by Ragnarok and The Lizard Master, invoking a JS global
      hot-key handler (e.g. hitting Ctrl-U or Ctrl-P with the privatemsg
      or nodelist modules installed as handlers) would lead to the global
      object being cleared/corrupted so other scripts would then fail to
      run correctly (e.g. Error: can't open sbbsdefs.js: No such file or directory)
      This probably explains the JS_GC/JS_ENDREQUEST change needed when
      the hotkey-specific JS runtime/context/scope was introduced last year.
      Should revisit that too.
  10. 16 Aug, 2020 1 commit
  11. 01 Aug, 2020 1 commit
    • rswindell's avatar
      An experimental external() mode flag that runs JS modules in their own... · b898eb73
      rswindell authored
      An experimental external() mode flag that runs JS modules in their own separate runtime and context - currently does not work (appears to corrupt the shared JS context). Not actually used currently.
      The reason I wanted to run a JS module (actually JS doorgame) in its own context was to get useful error messages (filenames and line numbers) when the module throws an exception. Currently, the error is just reported as occuring in xtrn_sec.js, which isn't helpful or correct.
  12. 08 May, 2020 2 commits
    • rswindell's avatar
      More mouse hot spot stuff: · e821783a
      rswindell authored
      - User Defaults menu mousified
      - When all hot spots have scrolled off the screen, clear the hot spot list
      - Insert new hot spots in the front of the list so they will take precedence
        over any previously defined duplicate hot spots
      - Numeric hot spot commands end in a carriage-return
      - No auto-acceptence of numbers when there are keys in the keyboard buffer
      - Baja UNGETKEY function now inserts keys into the "front" of the keyboard
        buffer (next to be consumed)
      - Hot key @-code command text supports C-style escape sequences
        (allows encoding of ctrl chars, spaces, etc.)
    • rswindell's avatar
      Add mouse hot spot support: · 87c9982c
      rswindell authored
      - hot spots are clickable screen areas (e.g. in menus and prompts) that   generate key-strokes
      - commands may be from 1 to 127 ASCII-characters in length
      - currently using the X10 mouse reporting mode, may change
      - all mnemonics strings (~Example) are automatically hot-spots
      - The new ~ @-code defines a hot spot
      - Any screen-clear operation clears all hot spots
      - sbbs now tracks the current screen (cursor position) row
      - eliminated the old "tos" (top-of-screen) boolean (row == 0 indicates "tos")
      - created an sbbs_t::ungetstr() method
      - keep track if in pause (hit a key) prompt, for special mouse behavior
      new JS console object:
      - row property
      - tos property is now read-only (and deprecated)
      - new methods:
      redrwstr() gets some UTF8 touch-ups as part of this commit. <shrug>
  13. 11 Apr, 2020 1 commit
    • rswindell's avatar
      Two unrelated changes, but since they touched sbbs.h, I'm committing them · 0d73dbc4
      rswindell authored
      together to keep things atomic:
      1. Eliminate eprintf() as sbbs_t::lputs() and sbbs_t::lprintf() do the
         "right thing" (e.g. log to the event log when called from the event_thread).
      2. Moved upload_stats() and download_stats() from ftpsrvr.c to getstats.c where
          I plan to make use of them for JS-based upload/download file support.
  14. 24 Oct, 2019 1 commit
    • rswindell's avatar
      Invoking a JavaScripot global hot key event handler (e.g. nodelist.js) *while* · c912ee30
      rswindell authored
      running a JavaScript module would crash (e.g. segfault) sbbs:
      Create and use a separate JS runtime, context, and global object/scope for
      global hotkey events. This means that the hotkey won't benefit from any
      previously loaded/required scripts, possibly effecting the performance of the
      first invocation of the hotkey handler. Subsequent JS hotkey events will reuse
      the same runtime/context/global, so they'll execute fast(er).
      One questionalbe change to js_execfile():
      With the JS_GC (garbage collection) call *before* the JS_ENDREQUEST() call, the
      process would crash in libmozjs. Moving the JS_GC() call to *after* the
      JS_ENDREQUEST() resolved this issue and I'm not clear why. This 'js_cx'
      parameter here is not always sbbs_t::js_cx. When called to handle a JS hotkey
      event, it's sbbs_t::js_hotkey_cx, so it shouldn't interfere with the
      sbs_t::js_cx being used by the currently executing JS module (shell or door).
      <scratches chin>
  15. 10 Sep, 2019 1 commit
  16. 28 May, 2019 1 commit
  17. 09 May, 2019 1 commit
  18. 21 Feb, 2019 1 commit
  19. 03 Nov, 2018 1 commit
    • deuce's avatar
      Fix new error with Clang 6.x: · cb1d932f
      deuce authored
      exec.cpp:438:8: error: case value evaluates to 2684500526, which cannot be narrowed to type 'int32_t' (aka 'int')
                      case 0xA0023A2E:
      The switch cases were unsigned, but the passed value was an int32.
  20. 05 Oct, 2018 1 commit
  21. 16 Nov, 2016 1 commit
    • rswindell's avatar
      Leave the console-abort status intact when returning from executing a Baja · 932fae30
      rswindell authored
      module. This is a reversal of the revision 1.102 commit (Jan-2-2016), but only
      for Baja (JS is left with the new behavior). As the commit message said
      "We'll see", and what we saw was that the yesnobar.bin and noyesbar.bin
      long-standing Baja modules no longer returned "No" when the user hit Ctrl-C.
      So at least for now, we have different behavior with regards to the console
      abort (ctrl-C) flag between JS and Baja. :-/
  22. 23 Apr, 2016 2 commits
  23. 02 Jan, 2016 1 commit
    • rswindell's avatar
      Clear the console-abort flag upon return from executing a JS or Baja module. · c22063f9
      rswindell authored
      This solves the problem of a JS-external program (e.g. SyncWX) being aborted
      at a pause prompt with Ctrl-C or Q and that abort status propagating back to
      the external program's menu. If there is a module which needs to propagate
      the console-abort status up to the parent(s), then this could introduce a
      problem. We'll see.
  24. 04 Dec, 2015 1 commit
    • rswindell's avatar
      Resolve FAQ: · 7a96e2b3
      rswindell authored
      Don't report a JavaScript warning ("Disconnected") until the OperationCallback
      has been executed 10 times with the user offline. This gives the executing
      script ample time to recognize the disconnected state and exit gracefully.
      Script that do not check/notice that the user has disconnected will still be
      auto-terminated (by default) and this warning will still be logged in those
      cases. The value 10 was picked at random and appears to work fine.
  25. 20 Aug, 2015 1 commit
    • deuce's avatar
      Update to 3.17a · dbbfabf1
      deuce authored
      New Features:
      - Multiple bindings for each service
        Use comma-separated interfaces on Interface= lines in the ini file.
        Default is now ",::"
      - IPv6 support
      - TLS support for the webserver and (non-static) services
        New TLS option in services.ini (ie: Options=TLS)
      - Decrease LEN_SCAN_CMD to 35 chars, increase the CID field to 45 chars,
        and rename the MAIL_CMD string to IPADDR.  I think this frees up the
        note field for SysOp use.
  26. 25 Apr, 2015 1 commit
    • deuce's avatar
      Fix exit() behaviour by introducing the new js.scope value which is the · f3256d81
      deuce authored
      scripts global scope (as opposed to which is the instance global
      scope), and having exit() define exit_code in js.scope instead of
      This also sets exit_code in js.scope to null when preparing to execute a new
      script.  If a new script starts in the same scope as an old one, the old
      exit_code value will be destroyed.
      This should only impact scripts where != js.scope (bbs.exec()ed,
      and mailsrvr)
  27. 03 Nov, 2011 1 commit
  28. 28 Oct, 2011 1 commit
  29. 09 Oct, 2011 1 commit
  30. 08 Oct, 2011 1 commit
  31. 10 Sep, 2011 1 commit
  32. 02 Jul, 2011 1 commit
  33. 01 Mar, 2011 2 commits
  34. 02 Apr, 2010 1 commit
  35. 15 Mar, 2010 1 commit