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 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 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 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 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 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 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 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 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 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