@MSGID: 51503.sync@1:103/705 2a68078e
@REPLY: 51502.sync@1:103/705 2a67f1e1
@TZUTC: -0700
@PID: Synchronet 3.20a-Win32 master/da9627ea5 Mar 24
202 MSC 1916
@TID: SBBSecho 3.20-Linux master/f2a017ec6 Mar 24
2024 23:24 GCC 12.2.0
@COLS: 80
@BBSID: VERT
@CHRS: CP437 2
@NOTE: FSEditor.js v1.105
  Re: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version?
  By: Fzf to Digital Man on Mon Mar 25 2024 02:18 pm

 > As I looked into what was going on I moved to lower and lower level
 > diagnostic programs until I finally just wrote my own to know exactly what
 > was being done on the program side.
 >
 >  DM> Would happy to try address whatever issues with the UART emulation
 >  DM> aren`t working for you, but please update to the latest and get
 >  DM> new/updated debug log output and share with me.
 >
 > I had downloaded the latest SBBSEXEC.DLL the morning after you made the
 > initialization change and have tried it out.  It`s working 100% along with
 > the version downloaded today!  Pushing the UART hard also no longer creates
 > any errors or even any unusual debug log entries.  Thanks again for fixing
 > this.

 The only problem I fixed after reading your message was the issue
with the UART not defaulting to COM1 parameters in all cases. Any other
fixes you observed were likely already made in the git repo (and would`ve
been included in the nightly builds of sbbs-win32).

 > There are a couple of other issues I would like to mention.
 >
 > 1. When SVDM uses an inherited socket (the -h option) no telnet negotiations
 > are done.  As a result, the connection is assumed to be in ASCII mode and
 > server side CR characters are translated to CR/LF.  Since most programs are
 > already transmitting a CR/LF this gets translated to CR/LF/LF with the
 > expected results.  When using an external socket in telnet mode, could SVDM
 > set the telnet.local_option and telnet.remote_option variables as so:
 >
 >   A. Assume both remote and local have already suppressed GA and set the two
 >      options accordingly
 >
 >   B. Set the remote telnet echo option to off and set the local telnet echo
 >      to follow the ServerEcho option from the .INI file
 >
 >   C. Set both remote and local BINARY_TX options to follow the ServerBinary
 > option from the .INI file
 >
 > I don`t think it`s unreasonable to assume these have already been set up
 > when the telnet connection was initially made.  If someone really wants to
 > change the behavior they could still do so by using the .INI file options
 > mentioned. The GA and echo options probably make no difference now but
 > leaving them unset might cause trouble somewhere down the line.

 I`ll be committing a change here to address that - basically send
the Telnet commands to re-negotiate those operating parameters (the same
sequence that happens when answering an incoming Telnet connection).

 > 2. Can anything be done to reduce the CPU usage?

I added 2 new .ini settings for you to play with:
- MainLoopDelay (default: 0, set to 1+ to add CPU yield)
- SocketSelectTimeout (default: 0, set to 1+ to add CPU yield)

 Perhaps one or both of these should default to a non-zero value,
but I`ll let you experiment with them and let me know your results
are.

 > 3. The VDMODEM isn`t importing target_ia32.props and thus is using SSE2
 > instructions.

That was unintentional - fixed.

 > Thanks yet again for all the work you`ve done on this and for fixing the
 > issue I was having.

Thank you! Your feedback is valuable,
-- 
                                            digital man (rob)

Synchronet "Real Fact" #114:
Weedpuller "Geographic" http://youtu.be/cpzBDVgmWSA
Norco, CA WX: 61.8°F, 51.0% humidity, 4 mph WSW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
SEEN-BY: 50/109 103/705 154/10 218/700 221/1
240/1120 280/464 301/1 113
SEEN-BY: 341/66 463/68 467/888 712/848 3634/12
5000/111 5005/49 5019/40
SEEN-BY: 5020/715 848 1042 4441 12000 5030/49 1081
5054/8 5060/900 5061/133
SEEN-BY: 5075/128 5083/444 5090/958
@PATH: 103/705 301/1 5020/1042 4441