Answers to Frequently Asked Questions regarding Synchronet and Microsoft Windows operating systems.
Why don't DOS programs (e.g. editors, door games) run on my Windows Vista, Windows 7, Windows 8 or Windows 10 32-bit (x86) operating system?
There are 2 new requirements for 16-bit DOS programs to work under Synchronet-Win32 on Windows Vista+ 32-bit (x86) operating systems:
- You must have
SBBSEXEC.DLLrev 38 or later (this is included in SBBS v3.14a).
- You must copy
SBBSEXEC.DLLto your Windows
Beginning with Windows 8, Microsoft disables support for 16-bit (DOS) programs by default. Search for “16-bit Application Support” in the Windows Control Panel and enable that setting. This setting only exists in 32-bit versions of Windows 8 and Windows 10.
64-bit (x64, amd64) editions of Windows cannot run 16-bit DOS programs from Synchronet. See the next FAQ item for the details.
Why won't DOS programs run on my 64-bit computer running a 64-bit version of Windows?
Microsoft does not include Virtual DOS Machine (NTVDM) support in their 64-bit operating systems. Synchronet for Windows relies on NTVDM for 16-bit DOS program support, so you need to either run a 32-bit Windows version (e.g. re-install, use dual-boot, or run in a Virtual Machine) or forgo DOS programs on your BBS. Yes, you can run 32-bit Windows versions of Synchronet on a 64-bit (x64) system.
As of March 12, 2014, you can disable DOS program support in a single instance of Synchronet with the
NO_DOS option in the
Options value of the
[BBS] section of your
sbbs.ini file. Or uncheck the “DOS Program Support” checkbox in the “Terminal Server Configuration” dialog of the Synchronet Control panel:
Note: The Synchronet Terminal Server assumes external programs are 16-bit DOS programs by default. In order to indicate that a program is a native (e.g. 32-bit) program, you must either set the corresponding SCFG
Native Executable option to
Yes (for each instance the program is used in a command-line in SCFG) or add the program name (as used in the command-line) to the SCFG→External Programs→Native Program List:
╔════════════════════════════╗ ║ Native Program List ║ ╠════════════════════════════╣ ║ │cmd.exe ║ ║ │sh ║ ║ │csh ║ ║ │bash ║ ║ │node ║ ║ │smbutil ║ ║ │zip ║ ║ │unzip ║ ║ │pkzip25 ║ ║ │mp3info ║ ║ │ ║ ╚════════════════════════════╝
How do I keep external programs (doors) from popping up windows and stealing the keyboard/mouse focus?
Why do external programs that use socket I/O (e.g. Synchronet Blackjack, Synchronet BBS List, DoorMUD, SEXYZ) not work on my BBS?
Some “security” software (e.g. firewall and anti-virus programs) will interfere with the inheritance of socket descriptors between processes. One such program is the ZoneAlarm Security Suite. Another is NOD32. I don't know if this is an intentional security “feature” or a design flaw. If you have this (or similar) software installed, it may need to be disabled or completely un-installed for socket inheritance to work again.
Another potential cause of this Windows problem is malware (viruses, trojans, etc.) which disable the Windows Firewall Service. Even if/when the malware is successfully removed, the damage done to Windows (and specifically the registry) remains. One recent sighting of this problem was rectified with the following steps (found here):
- In Registry Editor, browse to the key
- Right-click SharedAccess, and select Permissions…
- Click Add.
- In the “Enter the object names to select” field, type “NT SERVICE\mpssvc”. Then click Check Names. The name should change to
- Click OK.
- Check Full Control checkbox in the Allow column.
- Click OK.
How do I setup my BBS to support dial-up modems/users?
Use the SEXPOTS utility in combination with Synchronet for Windows.
Why is the console output of some 16-bit DOS programs not intercepted/redirected and sent to the remote user's terminal?
Check that your
C:\WINDOWS\SYSTEM32\CONFIG.NT file does NOT include Microsoft's
ANSI.SYS console driver. Use of this
ANSI.SYS driver defeats the interception of console output from some 16-bit console I/O programs.