Subj : SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version? To : Fzf From : Digital Man Date : Mon Mar 11 2024 19:32:10 Re: SVDM - Which SBBSEXEC.DLL and DOSXTRN.EXE version? By: Fzf to All on Mon Mar 11 2024 02:34 pm > I am attempting to get SVDM working outside of an SBBS environment and am > having some trouble with different versions of the files mentioned in the > message title. Both SVDM01 and SVDM03 are showing the same results. All of > the following errors are happening on XP SP3, Windows 7 SP1, and Windows 10 > 22H2. All are 32-bit OS versions using the native NTVDM. The copy of > SBBSEXEC.DLL in System32 always matches the DLL version I am attempting to > use. > > The program I'm attempting to use to get the debug log entries is simply DSZ > called with the following: > > svdm.exe DSZ.EXE port 1 d t > > Each program I've tried has the the same results described below. > > Using the versions of SBBSEXEC.DLL and DOSXTRN.EXE included in the SVDM > archives works properly when using FOSSIL or Int 14h communications. > However, when attempting to use the UART emulation (which is what I am > after) things fall apart. From a user's point of view the NTVDM simply > locks up as soon as any communications are attempted. Looking into things > using DbgView shows a number of nonsense reads and writes to the emulated > UART registers followed by an endless stream of emulated hardware interrupts > which also do not make sense. I can include a debug log of this, but frankly > it's lengthy and is 100% reproducible. How did you determine the read/writes were "nonsense"? > Another oddity - When using the included SBBSEXEC.DLL, the UART emulation > defaults to base address 0x000 and interrupt 0x0. That is interesting. I'll see if I can reproduce that. Looking at the source, the default uart settings are initialized as a part of VDDInitialize(). But as I recall, not all versions of Windows use/call that function. So that's a bug. > The lockups do not occur > when this is left as-is but none of the UART emulation does anything. > Setting a ComPort in a [UART] section of SVDM.INI or SBBSEXEC.INI does > change the I/O address and IRQ to an expected value. But this isn't > necessary. The mere existence of one of those two INI files, even if empty, > sets the UART to the expected default of 0x3F8/IRQ4. The debug entry is > always as follows when left without any INI file: > > [180] SBBS: Virtualizing UART (0x0, IRQ 0) > > Changing the SBBSEXEC.DLL to the one included in the SBBS 3.19b update > package does allow things to work mostly as expected. UART emulation and > the virtual modem both work properly until pushed somewhat hard (such as a > file transfer or sending a text file of more than a few screens). > Eventually a number of read errors occur, followed by failure to communicate > with the UART at all. The NTVDM does not lock up but no further > communications are possible. The debug log shows an endless stream of these > entries when this has happened: > > [208] SBBS: !input_thread: ReadFile Error 122 (size=0) > [208] SBBS: !input_thread: ReadFile Error 122 (size=0) > [208] SBBS: !input_thread: ReadFile Error 122 (size=0) That's interesting. From https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499- ERROR_INSUFFICIENT_BUFFER 122 (0x7A) and from https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile If ReadFile attempts to read from a mailslot that has a buffer that is too small, the function returns FALSE and GetLastError returns ERROR_INSUFFICIENT_BUFFER. The latest sbbsexec.c source has more detail in that error/log message that would help get to the bottom of that error more quickly: !input_thread: ReadFile Error %d (space=%d, count=%d) > Using SBBSEXEC.DLL from SBBS 3.19c has the same behavior as when using the > DLL included in the SVDM distributions. The latest and greatest sbbsexec.dll and dosxtrn.exe can be find in the nightly builds of Synchronet for Windows: https://wiki.synchro.net/install:dev#pre-built_executables > Using the DOSXTRN.EXE file from SBBS 3.19b vs the 3.19c/SVDM distribution > does not seem to make any difference in behavior. However, I don't want to > add any mix-n-match problems into the equation. > > Any ideas on which is the 'correct' combination of these files to use for > reliable UART emulation with SVDM? The latest should be the best, but that doesn't necessarily mean bug free. Would happy to try address whatever issues with the UART emulation aren't working for you, but please update to the latest and get new/updated debug log output and share with me. Thanks, -- digital man (rob) Steven Wright quote #22: What happens if you get scared half to death twice? Norco, CA WX: 55.7øF, 68.0% humidity, 4 mph W wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .