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.
Why do I get the error message
!ERROR 11001 calling getaddrinfo() on :: when running Synchronet v3.17 on Windows XP?
Synchronet v3.17 defaults to assuming that your operating system supports IPv6. Windows XP does not support IPv6 by default (only IPv4). You can either install IPv6 services on Windows XP (e.g. using the command-line:
netsh int ipv6 install) or set the
Interface key values in your
sbbs.ini file to exclude the IPv6 all-intefaces address: