• Re: Door game fight and error at logon

    From bryandj23@bryandj23@gmail.com to alt.bbs.synchronet on Sun Apr 26 11:53:26 2020
    From Newsgroup: alt.bbs.synchronet

    Hi DM. Hope you're having a nice weekend.
    Since you still have those RESOURCE.00x files, that indicates that MCINSTAL.EXE was not run to create the necessary directories. No biggie though - your test was exactly what I needed to keep down the troubleshooting road.
    I spent some time cleaning up and modifying my code in the game, and finally got back around to trying this out. I reconfigured the door exactly how you have it configured (door in xtrn directory instead of C:\Doors, SCFG set exactly as you have it), and still - only launches locally.
    Sidenote: I've had this issue with other doors, and the fix is to configure the door for FOSSIL support; which unfortunately I cannot do with DoorSource.
    So, I started changing settings in SBBSEXEC.ini. Pertinent settings here are all default. I did enable debugging, but haven't gone that route yet. So, Virtualize=true, Comport=1. I tried switching virtualize to false; but no change. In fact, my other doors kept working even after changing to false.
    I ran process monitor against loading the BBS, and never once did I see a process try to read the SBBSEXEC.ini file. Perhaps I wouldn't see anything here, depending on how it's actually read. Just found it interesting.
    SBBSEXEC.dll is 48kb, dated 9/5/2005, 10:31pm. SBBSEXEC.VXD is 27KB, dated 7/20/2001. Perhaps something here?
    I may attempt a complete new SBBS install on a new VM. Hmm. Just thought of something.
    The image of SBBS that I'm running is a (someone else)-customized version that strips most of the menuing system; as I'm using SBBS as a Doorgame server behind Worldgroup/MBBS. Been quite awhile since I installed it, but I believe it was a "DOOR SERVER" build of SBBS. (Instructions followed were here: http://dmud.thebbs.org/wg/setup.htm).
    I also had found the "SBBS-Uart-Patch" and had installed that in an attempt to fix that issue.
    Can you think of anything else I may be missing?
    Meanwhile, I'll try a fresh SBBS install on another VM and report back.
    Thanks again!
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From bryandj23@bryandj23@gmail.com to alt.bbs.synchronet on Sun Apr 26 18:50:46 2020
    From Newsgroup: alt.bbs.synchronet

    Update..

    So I learned the VXD file is for Win9x installations, not WinNT as I'm running.

    Fresh install of 2003 R2, fresh install of latest SBBS 3.17b

    "Mission Control" runs fine locally. When launched with DOSXTRN, I get an Overflow error in the DS3 (Doorsource) module. Hmm. New road to look down.

    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From bryandj23@bryandj23@gmail.com to alt.bbs.synchronet on Sun Apr 26 19:09:59 2020
    From Newsgroup: alt.bbs.synchronet

    Update v2:

    Executing the door via shell, using a batch file to call:

    mc10.exe mc.cfg door.sys

    Seems to be working for me on 3.l7b! (Still unsure why the overflow via DOSXTRN). Going to try this on the older version.
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Digital Man@digital.man@vert.synchro.net.remove-11z6-this to bryandj23 on Sun Apr 26 20:09:00 2020
    From Newsgroup: alt.bbs.synchronet

    To: bryandj23
    Re: Re: Door game fight and error at logon
    By: bryandj23 to alt.bbs.synchronet on Sun Apr 26 2020 04:53 am

    From Newsgroup: alt.bbs.synchronet

    Hi DM. Hope you're having a nice weekend.
    Since you still have those RESOURCE.00x files, that indicates that MCINSTAL.EXE was not run to create the necessary directories.

    Yeah, I ran that. And even tried answering both Y and N to the prompt, but no directories were created.

    No biggie
    though - your test was exactly what I needed to keep down the troubleshooting road.
    I spent some time cleaning up and modifying my code in the game, and finally got back around to trying this out. I reconfigured the door exactly how you have it configured (door in xtrn directory instead of C:\Doors, SCFG set exactly as you have it), and still - only launches locally.
    Sidenote: I've had this issue with other doors, and the fix is to configure the door for FOSSIL support; which unfortunately I cannot do with DoorSource. So, I started changing settings in SBBSEXEC.ini. Pertinent settings here are all default.

    The defaults (e.g. if the sbbsexec.ini file is missing) should normally work just fine. But for what's worth, here's is the sbbsexec.ini file I had in place when I ran your door:

    ; exec/sbbsexec.ini

    loglevel=info

    [UART]
    Virtualize=true

    ;[bre]
    ;YieldInterval=0.05

    [dsz|gsz]
    YieldInterval=3

    [war]
    CanDisconnect=false

    [war.UART]
    Virtualize=true

    [sinkem.UART]
    virtualize=true

    [yt]
    YieldInterval=0.01

    [fdsz]
    loglevel=debug

    [lore]
    virtualize=false
    loglevel=debug

    ;[cmd.exe.UART]
    ;virtualize=false

    I did enable debugging, but haven't gone
    that route yet.

    You would need to use a Windows debug log viewer to see the debug output.

    So, Virtualize=true, Comport=1. I tried switching
    virtualize to false; but no change. In fact, my other doors kept working even after changing to false.

    Virtualize is only for the UART feature, so enabling/disabling that function would have no impact on programs that use/work with FOSSIL.

    I ran process monitor against loading the BBS, and never once did I see a process try to read the SBBSEXEC.ini file. Perhaps I wouldn't see anything here, depending on how it's actually read. Just found it interesting. SBBSEXEC.dll is 48kb, dated 9/5/2005, 10:31pm.

    Yeah, that's pretty old now. The latest build of sbbsexec.dll is from 2011. The copy of that file that matters is the one in your Windows/System32 directory (not the one in sbbs/exec, if there is one) - but only if you're running Windows Vista or later. If you're running pre-Vista Windows, then the copy/version in your sbbs/exec is used. But I would just have it both places and make sure they're in sync.

    SBBSEXEC.VXD is 27KB, dated
    7/20/2001. Perhaps something here?

    VXD's are only used on Windows 9x. So you can safely delete that file now. :-)

    I may attempt a complete new SBBS install on a new VM. Hmm. Just thought of something.
    The image of SBBS that I'm running is a (someone else)-customized version that strips most of the menuing system; as I'm using SBBS as a Doorgame server behind Worldgroup/MBBS. Been quite awhile since I installed it, but I believe it was a "DOOR SERVER" build of SBBS. (Instructions followed were here: http://dmud.thebbs.org/wg/setup.htm).
    I also had found the "SBBS-Uart-Patch" and had installed that in an attempt to fix that issue.

    What patch is that? Do you mean the DOSXTRN.EXE?

    Can you think of anything else I may be missing?
    Meanwhile, I'll try a fresh SBBS install on another VM and report back. Thanks again!

    Okay.

    digital man

    Synchronet "Real Fact" #54:
    The Synchronet source code consists of over 500,000 lines of C and C++.
    Norco, CA WX: 85.3øF, 34.0% humidity, 7 mph ESE wind, 0.00 inches rain/24hrs --- Synchronet 3.18a-Win32 NewsLink 1.112
    * Vertrauen - Riverside County, California - telnet://vert.synchro.net
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From bryandj23@bryandj23@gmail.com to alt.bbs.synchronet on Sun Apr 26 20:22:53 2020
    From Newsgroup: alt.bbs.synchronet

    Update v3:

    Would not work on my install of 3.13a configured the same as on 3.17b.

    --Copied DOSXTRN.EXE, SBBSXTRN.DLL and SBBSXTRN.INI from the 3.17b install to the 3.13a install.

    The game is now working, with "Use Shell to Execute".

    DM: I'll still compare your INI to mine, as it still leaves me curious why your mileage varies.

    Thanks again for the help-think I'm finally satisfied. LOL!!
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Digital Man@digital.man@vert.synchro.net.remove-dh8-this to bryandj23 on Sun Apr 26 21:07:59 2020
    From Newsgroup: alt.bbs.synchronet

    To: bryandj23
    Re: Re: Door game fight and error at logon
    By: bryandj23 to alt.bbs.synchronet on Sun Apr 26 2020 12:09 pm

    From Newsgroup: alt.bbs.synchronet

    Update v2:

    Executing the door via shell, using a batch file to call:

    mc10.exe mc.cfg door.sys

    Seems to be working for me on 3.l7b! (Still unsure why the overflow via DOSXTRN). Going to try this on the older version.

    Make sure you get/use the latest dosxtrn.exe.

    digital man

    Synchronet "Real Fact" #96:
    Synchronet v3.14a was released in December of 2006 (1 year after v3.13a). Norco, CA WX: 87.2øF, 35.0% humidity, 9 mph ENE wind, 0.00 inches rain/24hrs --- Synchronet 3.18a-Win32 NewsLink 1.112
    * Vertrauen - Riverside County, California - telnet://vert.synchro.net
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Digital Man@digital.man@vert.synchro.net.remove-x2z-this to bryandj23 on Sun Apr 26 21:11:35 2020
    From Newsgroup: alt.bbs.synchronet

    To: bryandj23
    Re: Re: Door game fight and error at logon
    By: bryandj23 to alt.bbs.synchronet on Sun Apr 26 2020 01:22 pm

    DM: I'll still compare your INI to mine, as it still leaves me curious why your mileage varies.

    I don't think it's the .ini file. It's more likely that I'm running a different version of Windows (i.e. Windows 7). And of course, that ancient v3.13a build of Synchronet could have all kinds of bugs that could cause you issues.

    digital man

    This Is Spinal Tap quote #23:
    David St. Hubbins: I envy us.
    Norco, CA WX: 87.2øF, 35.0% humidity, 9 mph ENE wind, 0.00 inches rain/24hrs --- Synchronet 3.18a-Win32 NewsLink 1.112
    * Vertrauen - Riverside County, California - telnet://vert.synchro.net
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From bryandj23@bryandj23@gmail.com to alt.bbs.synchronet on Mon Apr 27 13:35:49 2020
    From Newsgroup: alt.bbs.synchronet

    Agreed; ultimately need to upgrade. I'm a bit concerned with following the upgrade path, given that this is a "customized" build so to speak; but will snapshot the VM prior to each to verify everything's kosher.

    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Gamgee@gamgee@PALANT.remove-i4v-this to bryandj23 on Mon Apr 27 21:30:00 2020
    From Newsgroup: alt.bbs.synchronet

    To: bryandj23
    bryandj23 wrote to alt.bbs.synchronet <=-

    Agreed; ultimately need to upgrade. I'm a bit concerned with
    following the upgrade path, given that this is a "customized"
    build so to speak; but will snapshot the VM prior to each to
    verify everything's kosher.

    Agreed about..... what? You didn't quote anything or provide any
    context, so nobody knows what you're talking about here.

    I realize you're posting from Usenet, but you'll need to try
    harder.



    ... Would you like to wake up from this dream?
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    --- Synchronet 3.18a-Win32 NewsLink 1.112
    * Vertrauen - Riverside County, California - telnet://vert.synchro.net
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From bryandj23@bryandj23@gmail.com to alt.bbs.synchronet on Tue Apr 28 21:44:02 2020
    From Newsgroup: alt.bbs.synchronet

    On Sunday, April 26, 2020 at 5:11:44 PM UTC-4, Digital Man wrote:

    I don't think it's the .ini file. It's more likely that I'm running a different >version of Windows (i.e. Windows 7). And of course, that ancient v3.13a build of Synchronet could have all kinds of bugs that could cause you issues.

    digital man



    Agreed. Need to upgrade.
    --- Synchronet 3.18a-Linux NewsLink 1.113