vDos has gotten me so close to an end goal, but I just ran into the proverbial brick wall.
I am using NetSerial to create a virtual com port that is passed through to a telnet connection. The virtual comport essentially acts as the modem for the software I'm running.
If I set in the config COM4="COM4":, then NetSerial immediately recongizes a connection the moment vDOS is loaded. It shouldn't recognize the connection until the Virtual Com Port acting as a modem is initialized by the software I run. This has resulted in nothing but vDOS crashes.
If I don't set it in the config, but instead use SETPORT com4="Windows Device": I get. "Com4: Could not link to Windows device (error 2) - Windows device.
vDOS is obviously communicating with NetSerial as NetSerial can see the communication when it's set in the config, but I'm guessing, because it's a virtual com4 and not a physical com4, when trying to set it to Windows Device, it can't actually do so, though everything sounds like that is what I need, so that the software can initialize the virtual device on the virtual com4 rather than already having some kind of data on the virtual communication line.
Is there any other way to leave a com port in an idle state, so that the software can initialize the virtual modem properly? If I can get that I should be on easy street.
I do understand, from another thread I read, that serial communications is currently experimental, so I'm not actually expecting to be able to do what I'm looking to do right now, but if the "Windows Device" can be modified to accept Virtual com ports as well as physical com ports, that would get me closer to the end goal. I'm not sure if this way of communication through a virtual serial port that passes to a telnet client/server has been considered before. I figure, it never hurts to ask. :)
Thanks,
- RJ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
COM4 = "COM4": instruct vDos to open/claim the Windows COM4 (right hand) device, and relay DOS COM4 (left hand) communications to that. vDos itself doesn’t try to send anything by its own, NetSerial will merely detect the virtual Windows COM4 port being opened.
Testing by me in the past was done by also using virtual COM ports. vDos crashes means it apparently stalls? That could be caused by your program initializing the DOS COM port, vDos just ignores that (the port has to be set/initialized before vDos starts). If the program then inquires the COM port settings, it could conclude they are not correct (as set before), and ends up in a loop of initializing and checking. Another cause could be that the serial communications is interrupt driven, while vDos only supports polling. If there’s a setting for that, set it to polling.
SETPORT is no vDos command (vDosPlus?), "Windows Device": would have to be substituted by an actual Windows device. Virtual or physical doesn’t matter to vDos of course.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you may have hit the nail on the head. Modems were always interupt driven as far as I'm aware. Com 4, IRQ3 2E8h, were ever the only settings in communication software. Or maybe it's just BBS and Terminal programs.
Yes, it is actually vDOSPlus, which as I understand is merely to set controls through a batch file rather than through the config, but I had read a thread over there with someone else also talking about programs that communicate with the com port as what I've always known serial communications to be, which was for modem communications. I've personally never heard of modems polling and modem communications software of the 80's and 90's always communicated as Com1/3, IRQ 2 Addr: 2E8H Com2/4 IRQ 3 Addr: 3E8H and those were only ever the settings available to set. In that thread they had said the communications methods were not changed between vDOS and vDOSPlus, so ask in the vDOS Discussion, which is why I ended up over here instead of over there.
Modem communications shouldn't be "opened" until a connection is made, which a connection can't be made until after it's innitialized by the software. At least that explains why the software freaks out. Because it's purely there for printing style communications and not modem communications, which shouldn't be active at all until the software initializes the modem, which can't happen because 1. IRQ, 2. Port already opened.
Well, it was a dream anyway. Was hoping to make a lot of people happy as a work-around for the lack of 16bit support in W10.
I wonder, with the com ports being experimental, is there any chance this will ever be changed to be configurable to be used with a modem? IRQ driven, Set Idle till software opens the port? After all, netserial is not purely a virtual com port, but also acts as the modem and can receive modem commands like ATA - Answering the phone, ATH0 - Hanging up the phone, AT&C1&D2 - Initializing the modem. Etc. Then it takes the data received on either end and transfers it to the other end. Either from Telnet to virtual com port or virtual com port to Telnet.
Hmmm... I don't think vDOS or vDOSPlus will be able to do the job without changes to how it communicates with the com ports. Would you agree with that?
Last edit: Russell Wiley 2018-03-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There’s no such thing as being idle until, or DOS software (at a low level) opening a COM port. A program can open (and close) a DOS device like COM2, but it will then communicate with the device using (high level) DOS Int 21 calls. And it then ought to function just fine.
A DOS program can address a COM port/UART directly, not the device that is connected to it, like a modem.
A DOS program has to implement routines handling the COM IRQ’s. Dedicated/specialized communication software will to guarantee to keep up with high transmission speeds, other software simply don’t go into the trouble of additional code/libraries. A program w/o code to handle the IRQ’s will inquire a serial port frequently (polling). Bytes received by the UART could theoretically be lost if it’s not done frequent enough, but modern UART’s have large enough buffers to avoid that. A specialized DOS communication program will have code that is activated by an interrupt when the UART wants attention.
If a DOS program implements code to handle COM IRQ’s, that code will simply not be activated since vDos doesn’t emulate those interrupts. If you start vDos with the /log option (vDos.exe /log), you can check if the generated vDos.log file has one or more lines like Int 0B => xxxx:xxxx, Int 0C => xxxx:xxxx. Indicating the program installed his interrupt routines.
Mind, serial communications in the vDos virtual PC has nothing to do with what’s actually happening in the ‘real’ world, with the ‘real’ UART, ‘real’ interrupts... I did two attempts in the past to support interrupt driven serial communications. Those failed because both vDos users (with appropriate software and hardware) that were testing it, just abandoned the experiments. So I gave up with that, won’t try again, while it’s actually only needed by a few specialized programs. Certainly not for printing purposes or modem usage like dialing out. vDos works fine for that.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's all interesting and you'd probably know a whole lot more than I do on the programming side of things.
When i say idle, I mean, in the days of old. If there nobody connected, the modem does nothing. The modem does nothing unless it's given a command to do so. As far as I'm aware, it's not constantly talking with the software. Maybe talking with the computer, but not the software. When it runs in vDos or vDos plus (used for long filenames only), the software acts like it's latched onto a single already and goes nuts because it doesn't know what to do with the signal it has.
In the NetSerial documentation it tells me that the connection should be empty until software initializes the modem, but if you put the com4="com4": in the config.txt and run vDos, it immediately recognizes some kind of signal. It doesn't leave it empty and wait for the software to initialize it, so there's something going on with the virtual port immediately rather than waiting for software to initalize the virtual modem.
Hopefully that explains why I'm looking for the com port to be idle or doing nothing until the software initializes the virtual modem.
I've never personally used serial for printing. For me, it's always been a modem communications port and I've never known any modem to have activity going on without software telling it to do so. Whether that be BBS software expecting an incoming call, which is what this is all for or a terminal program sending AT commands. Even real modems just sit there quietly until the software tells them what to do. Constantly polling a port just seems wrong in this environment, but admittedly I don't know enough about what it's really supposed to do, just what I expect it to do and what I've seen decades ago when I was running a multi-line BBS back in those days.
The rest of that is all greek to me other than a vague recollection about changing out a UART chip or flashing it to get a better baud rate out of the same modem.
I've already talked to one old school BBS System Operator who is going to be checking out vDOS as a viable option in a Win10/64 environment, but so far, there's road blocks and brick walls everywhere. Can't use Netfoss because of the 64bit environment and can't use NetSerial because something is off in the way com ports are being handled in vDos. Both leaves us out of options for incoming Telnet to old school modem communications in the software. Either one will work in Win7 or XP, but neither will work in Win10. Netfoss may work in a Win10/32 environment with vDos to run the software, but I don't have a 32 bit version to even try and see. :(
The only option left to try is Linux with DOSEMU I suppose, but I'll need another box for that one. I need my main system to stay Windows for work purposes. UGH!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even if a modem is idle, it will continuously signal the UART what’s going on. No carrier detected, no ring, etcetera. vDos only opens/claims the COM port that is controlled/simulated by NetSerial, it needs to do so since it can’t address any hardware directly. So NetSerial will of course detect this, but nothing is communicated between vDos and NetSerial. A modem shouldn’t have an established connection the moment software will address the UART since it doesn’t expect that, and the connection has to be broken for the modem to return in command mode.
The only concern should be whether the software is polling the UART, or is interrupt driven. That could be checked in the vDos.log file. If it is interrupt driven, without an option to switch to polling, it ends for vDos since it doesn’t simulate COM port interrupts and the communication routines of the program won’t be activated/called.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
.....The software is not even capeable of printing, so why does it thinkit's trying to print?
Here's what was actually occurring compared to the log.
change to d:\slbbs\
Run Config.exe
|--- change config to use com port
Run slbbs.exe
|--- runs login.exe from slbbs.exe
|----it auto-exited due to setting in config that exit's to dos if no user is present
Run config.exe
|---- Change to not exit software upon logoff
Run slbbs.exe
|---- Software goes nuts displaying weird and having strange lines at the bottom of the screen when out of the blue a the Windows Print Screen pops up like I'm trying to print something. At some point it runs login.exe
Run config.exe
|--- Change so the software doesn't communicate on any port
Run slbbs.exe
|---It comes up and sits idle like it's waiting for a call. Apparently it does load login.exe as part of it's waiting for call process since it did go to a waiting for call state. Login.exe is ran from within slbbs.exe and not something that is called upon directly. This is the only one that operated like it should, but it doesn't have any com ports setup at all which functionally disables all external communications.
vDos 2017.08.01
C: => (Local) D:\vDos\
Execute: DP26YI.EXE - /s
Int 1B => 2a0d:0004 (Delayed logging w/o DOS call)
Int 22 => f000:0003 (Delayed logging w/o DOS call)
Int 1B => f000:0000 (Delayed logging w/o DOS call)
D: => (Local) d:\bbs\
Execute: config.EXE
Int 0 => 1fd7:010c
Int 23 => 1fd7:0113
Int 24 => 1fd7:00db
Int 3F => 1fd7:0104
Int 3F => 1f81:02e6
Int 1B => 1f0f:0142
Int 23 => ae9:0000
Int 23 => 1fd7:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: slbbs.EXE
Int 0 => a6b:010c
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 1B => 9d4:0142
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 21 unhandled call C7FF
Int 23 => a6b:0113
Int 1B => 9d4:0142
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: \SLDEMO\LOGIN.EXE
Int 0 => 3da5:010c
Int 23 => 3da5:0113
Int 24 => 3da5:00db
Int 3F => 3da5:0104
Int 3F => 3c5c:02e6
Int 22 => a3e:0201 (Delayed logging w/o DOS call)
Int 1B => 3bce:0142
Int 23 => 1f60:0000
Int 23 => 3da5:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 0 => a6b:010c
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 7E => 0:0000
Int 79 => 0:0000
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 22 => f000:0003 (Delayed logging w/o DOS call)
Execute: config.EXE
Int 0 => 1fd7:010c
Int 23 => 1fd7:0113
Int 24 => 1fd7:00db
Int 3F => 1fd7:0104
Int 3F => 1f81:02e6
Int 1B => 1f0f:0142
Int 23 => ae9:0000
Int 23 => 1fd7:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: slbbs.EXE
Int 0 => a6b:010c
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 1B => 9d4:0142
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 21 unhandled call C7FF
Int 23 => a6b:0113
Int 1B => 9d4:0142
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: \SLDEMO\LOGIN.EXE
Int 0 => 3da5:010c
Int 23 => 3da5:0113
Int 24 => 3da5:00db
Int 3F => 3da5:0104
Int 3F => 3c5c:02e6
Int 22 => a3e:0201 (Delayed logging w/o DOS call)
Int 1B => 3bce:0142
Int 23 => 1f60:0000
Int C => 668:04d9
Int C => f000:0000
Int C => 668:04d9
Internal printing 20 bytes
Int C => f000:0000
Int 23 => 3da5:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 0 => a6b:010c
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 7E => 0:0000
Int 79 => 0:0000
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 22 => f000:0003 (Delayed logging w/o DOS call)
Execute: config.EXE
Int 0 => 1fd7:010c
Int 23 => 1fd7:0113
Int 24 => 1fd7:00db
Int 3F => 1fd7:0104
Int 3F => 1f81:02e6
Int 1B => 1f0f:0142
Int 23 => ae9:0000
Int 23 => 1fd7:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: slbbs.EXE
Int 0 => a6b:010c
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 1B => 9d4:0142
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 21 unhandled call C7FF
Int 23 => a6b:0113
Int 1B => 9d4:0142
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: \SLDEMO\LOGIN.EXE
Int 0 => 3da5:010c
Int 23 => 3da5:0113
Int 24 => 3da5:00db
Int 3F => 3da5:0104
Int 3F => 3c5c:02e6
Int 22 => a3e:0201 (Delayed logging w/o DOS call)
Int 1B => 3bce:0142
Int 23 => 1f60:0000
Int 23 => 3da5:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 0 => a6b:010c
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 7E => 0:0000
Int 79 => 0:0000
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 22 => f000:0003 (Delayed logging w/o DOS call)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Int C => 668:04d9
Interrupt 0Ch (IRQ 4, COM1 or COM3) is set to program code starting at address 668:04d9. That would be started if vDos would simulate IRQ4 and the (virtual) UART is programmed to generate an interrupt.
Int C => f000:0000
Interrupt 0Ch is reset to the original (dummy) code.
Int C => 668:04d9
Interrupt 0Ch is set again.
Internal printing 20 bytes
W/o a corresponding directive in config.txt, all communication with COM1-9 and LPT1-9 is by default considered to be a printjob. The program writes 20 bytes to one of these ports. You can look for the #COM|LPT1-9.asc file, what port (COM1 ?) that was and what was sent. Since nothing seems to be set for this port, vDos wants to print whatever was sent.
Int C => f000:0000
Interrupt 0Ch is reset again.
But even if you set the port in config.txt, your program will expect the UART to generate an IRQ that is handled by the code fragment installed for interrupt 0Ch. Since vDos doesn’t simulate that IRQ, that code will never get activated/called.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So you're saying that it is possible that the virtual com port UART could generate it's own IRQ, but you default to print job, so it tries to print. I at least need to test it, so I need to find where in the config to change it so it's not a print job.
The #COM3.ASC file contains the initialization string sent by the BBS software. So it's trying to print the init string. Yeah, I at least need to test it not being configured as a print job.
If the Virtual com port UART generates the interupt then it just might work, but we could never find out because it's being treated like a print job by default.
Hmm. I'll see if I can find it.
Edit:
I've gone through the entirety of the config.txt and don't see anything that states, COMx is not a print job. Everything under the Printing Section is commented out.
The only thing I have added is...
COM2="COM2":
COM3="COM3":
COM4="COM4":
I haven't added a COM1 just because I still need to figure out why I'm showing I have a physical COM1 so I can disable it for use with the BBS software through Virtual Com port rather than physical com port. I can handle that on my own. If I can get it work on one of those 3 ports, I can get it to work on all of them.
In what context can I add "COMx is not a print job"?
Last edit: Russell Wiley 2018-03-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There would be no need for the virtual vDos serial UART to generate an (virtual) IRQ. ‘Just’ to mimic the process: Pause the program, and start the corresponding installed interrupt service routine when the Windows device driver has something to report, and provide for the correct control values/lines when the UART is read out by that routine. But vDos doesn’t.
COM3="COM3": should tell vDos that COM3 is not for printing: Sent data is to be redirected to the Windows device driver, reading should invoke reading from that device.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So you're saying that it would still be a fruitless venture to continue to try? I'm not sure how NetSerial handles IRQ's.
Even having COM3="COM3": it still brings up the print window and writes out to a #COM3.ASC file, which is just the init string, which is why I thought there must be some other way to say, This is not for printing.
This almost makes me want to try something entirely crazy just to see if it would work. Using the Linux Subsystem under Win10 to run DOSEMU, which I know the fossil drivers work in DOSEMU. It's a little crazy, but worth a shot. It would require running the Linux version of the software I have answering the Telnet connection, but that's not a big deal. Not sure how stable it would be. Win10-Linux Subsystem - DOSEMU, that's a lot of crazy going on. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
COM3="COM3": should prevent vDos to consider it as a printjob. But that was all once only basic tested, also using virtual COM ports. Perhaps I missed COM3.
Since vDos doesn’t support/mimic serial IRQ’s, it ends for interrupt driven communication programs. Netserial provides for virtual COM ports, could be it invokes eventually installed serial communications routines. But it surely has nothing to do with IRQ’s inside the virtual vDos PC.
You mentioned Netfoss, if your program can use a Fossil driver instead of the COM port roundabout - I guess you won’t use an actual serial port -, you could try a virtual Windows 32-bit machine with Netfoss.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, there are people running it through VMWare, but that's really just using an earlier OS. XP or 7 is common. If I'm going to do that I might as well run that OS. I don't see the point of running XP or 7 under VMWare.
I'm looking for a solution that brings the old into the new era rather than a solution that keeps the old on the old. It's just a personal pet project. If it can't be done, it can't be done, but if If it's possible to find a way to do it, then I'll keep chugging along with it till I come up with a solution.
DosBox was a nogo before I barely started with it because it doesn't support SHARE, which is needed for the multi-line aspect, which is where I ended up trying vDOS in the first place, which was able to passify the software's SHARE requirement. It just got hung up on actual communications.
Shame that interupt driven communications can't work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you don’t plan to use actual serial ports, your program communicating with a (v)DOS virtual serial UART, that is linked to a virtual Windows port, then translated to TCP (?) communications is an absurd complex and error-prone roundabout. If your program can however use a fossil driver, and I suppose it can and that’s what NetFoss provides for, you would do without all the messy COM communications.
So a virtual Windows 32-bit machine seems the direct way to go since it runs NetFoss.
Probably ideally, one (not me) would write a NETFOSS.COM (the NetFoss FOSSIL TSR Interrupt handler) alternative component for vDos. Certainly doable since all about COM ports can be dropped.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Enough brainstorming and we're bound to find another way. I found another fossil driver that looks like it's a 16bit Telnet fossil driver. I don't know if it will communicate with the 64bit side of things, but it's worth a shot. I doubt it, but can't hurt to try and see what happens.
RLFOSSIL is an implementation of multi-line
serial port driver corresponding to the
Fido/Opus/Seadog level 5 specification and
a simple HAYES-compatible modem emulator.
It allows applications usually worked through
BBS's to run on the Internet, or in IP-based
local net.er, and rlogin and telnet emulation
using IP services numbers 513 & 23.
RLFOSSIL allows combined work with other
FOSSIL drivers (X00,BNU etc.).
It's promising, I just don't know how much yet.
I agree, the 32bit OS route is probably the best way to go. I'm just looking to see if there's any way whatsoever on a 64 bit system. If the 16 bit fossil driver can communicate wit the 64 bit telnet connection, then it may work. eh... worth testing anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is 16-bit software, so it can’t run directly in Windows 64-bit, moreover, there’s no NTVDM (DOS/BIOS facilities) anymore.
If it is run in vDos, it will at some moment have to communicate (by means of more drivers) with the NIC in the virtual PC, and there’s none.
Using a genuine Windows BBS program isn’t an option?
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure that's always an option, but where's the fun in that? :)
In all seriousness, we (me and a long-time friend) have multiple boards setup already. This particular one is a pet project of mine because it's the software I used to run back in the 90's. It's also the only BBS software to fully implement RIPScrip graphics (EGA/VGA graphics on a Bulletin Board System) It's intended to show the power of what RIPScrip can do as well as a bit of nostalgia for me personally. There are so few active boards running this software these days. I've only found 2 so far and one of the 2 has RIPScrip disabled, so it's ANSI only. All modern BBS's are ANSI only, which is a shame. The internet came along at a really bad time. Right when RIPScrip was taking off and it pretty much destroyed the company who invented it, even if it did take another 10 years to do finish it off. I'd really like to have the representation of what it was and the potential it had. Especially in light of it's inventor passing away.
If worse comes to worse, we will end up setting it up in Linux under DOSEMU which we already have running other fossil based programs, so in theory it should work or on a Naitive 32/16bit system, probably Windows 7, but that is a last resort option. because I'd have to buy it it's own box because I'm not going to run it under VMWare. There's already known issues with running it under VMWare, so it's own dedicated box would be the way to go. I'll exhaust all other options before we go that route.
I haven't tried the DOS fossil driver yet. Work has been a bit busy the last couple days.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DOS was once the operating system, fully in control of the PC. It no longer is, and certainly -emulated or not - can’t control hardware aspects of a modern PC controlled by a non-DOS OS. Even when booting in actual DOS, you’ll have problems with that.
DOS programs can’t address actual hardware, it’s all emulated in vDos, as far it’s provided for of course.
Don’t expect a direct relation between DOS and Windows functionality at whatever level. DOS isn't Windows.
Jos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
vDos has gotten me so close to an end goal, but I just ran into the proverbial brick wall.
I am using NetSerial to create a virtual com port that is passed through to a telnet connection. The virtual comport essentially acts as the modem for the software I'm running.
If I set in the config COM4="COM4":, then NetSerial immediately recongizes a connection the moment vDOS is loaded. It shouldn't recognize the connection until the Virtual Com Port acting as a modem is initialized by the software I run. This has resulted in nothing but vDOS crashes.
If I don't set it in the config, but instead use SETPORT com4="Windows Device": I get. "Com4: Could not link to Windows device (error 2) - Windows device.
vDOS is obviously communicating with NetSerial as NetSerial can see the communication when it's set in the config, but I'm guessing, because it's a virtual com4 and not a physical com4, when trying to set it to Windows Device, it can't actually do so, though everything sounds like that is what I need, so that the software can initialize the virtual device on the virtual com4 rather than already having some kind of data on the virtual communication line.
Is there any other way to leave a com port in an idle state, so that the software can initialize the virtual modem properly? If I can get that I should be on easy street.
I do understand, from another thread I read, that serial communications is currently experimental, so I'm not actually expecting to be able to do what I'm looking to do right now, but if the "Windows Device" can be modified to accept Virtual com ports as well as physical com ports, that would get me closer to the end goal. I'm not sure if this way of communication through a virtual serial port that passes to a telnet client/server has been considered before. I figure, it never hurts to ask. :)
Thanks,
- RJ
COM4 = "COM4": instruct vDos to open/claim the Windows COM4 (right hand) device, and relay DOS COM4 (left hand) communications to that. vDos itself doesn’t try to send anything by its own, NetSerial will merely detect the virtual Windows COM4 port being opened.
Testing by me in the past was done by also using virtual COM ports. vDos crashes means it apparently stalls? That could be caused by your program initializing the DOS COM port, vDos just ignores that (the port has to be set/initialized before vDos starts). If the program then inquires the COM port settings, it could conclude they are not correct (as set before), and ends up in a loop of initializing and checking. Another cause could be that the serial communications is interrupt driven, while vDos only supports polling. If there’s a setting for that, set it to polling.
SETPORT is no vDos command (vDosPlus?), "Windows Device": would have to be substituted by an actual Windows device. Virtual or physical doesn’t matter to vDos of course.
Jos
I think you may have hit the nail on the head. Modems were always interupt driven as far as I'm aware. Com 4, IRQ3 2E8h, were ever the only settings in communication software. Or maybe it's just BBS and Terminal programs.
Yes, it is actually vDOSPlus, which as I understand is merely to set controls through a batch file rather than through the config, but I had read a thread over there with someone else also talking about programs that communicate with the com port as what I've always known serial communications to be, which was for modem communications. I've personally never heard of modems polling and modem communications software of the 80's and 90's always communicated as Com1/3, IRQ 2 Addr: 2E8H Com2/4 IRQ 3 Addr: 3E8H and those were only ever the settings available to set. In that thread they had said the communications methods were not changed between vDOS and vDOSPlus, so ask in the vDOS Discussion, which is why I ended up over here instead of over there.
Modem communications shouldn't be "opened" until a connection is made, which a connection can't be made until after it's innitialized by the software. At least that explains why the software freaks out. Because it's purely there for printing style communications and not modem communications, which shouldn't be active at all until the software initializes the modem, which can't happen because 1. IRQ, 2. Port already opened.
Well, it was a dream anyway. Was hoping to make a lot of people happy as a work-around for the lack of 16bit support in W10.
I wonder, with the com ports being experimental, is there any chance this will ever be changed to be configurable to be used with a modem? IRQ driven, Set Idle till software opens the port? After all, netserial is not purely a virtual com port, but also acts as the modem and can receive modem commands like ATA - Answering the phone, ATH0 - Hanging up the phone, AT&C1&D2 - Initializing the modem. Etc. Then it takes the data received on either end and transfers it to the other end. Either from Telnet to virtual com port or virtual com port to Telnet.
Hmmm... I don't think vDOS or vDOSPlus will be able to do the job without changes to how it communicates with the com ports. Would you agree with that?
Last edit: Russell Wiley 2018-03-12
There’s no such thing as being idle until, or DOS software (at a low level) opening a COM port. A program can open (and close) a DOS device like COM2, but it will then communicate with the device using (high level) DOS Int 21 calls. And it then ought to function just fine.
A DOS program can address a COM port/UART directly, not the device that is connected to it, like a modem.
A DOS program has to implement routines handling the COM IRQ’s. Dedicated/specialized communication software will to guarantee to keep up with high transmission speeds, other software simply don’t go into the trouble of additional code/libraries. A program w/o code to handle the IRQ’s will inquire a serial port frequently (polling). Bytes received by the UART could theoretically be lost if it’s not done frequent enough, but modern UART’s have large enough buffers to avoid that. A specialized DOS communication program will have code that is activated by an interrupt when the UART wants attention.
If a DOS program implements code to handle COM IRQ’s, that code will simply not be activated since vDos doesn’t emulate those interrupts. If you start vDos with the /log option (vDos.exe /log), you can check if the generated vDos.log file has one or more lines like Int 0B => xxxx:xxxx, Int 0C => xxxx:xxxx. Indicating the program installed his interrupt routines.
Mind, serial communications in the vDos virtual PC has nothing to do with what’s actually happening in the ‘real’ world, with the ‘real’ UART, ‘real’ interrupts... I did two attempts in the past to support interrupt driven serial communications. Those failed because both vDos users (with appropriate software and hardware) that were testing it, just abandoned the experiments. So I gave up with that, won’t try again, while it’s actually only needed by a few specialized programs. Certainly not for printing purposes or modem usage like dialing out. vDos works fine for that.
Jos
That's all interesting and you'd probably know a whole lot more than I do on the programming side of things.
When i say idle, I mean, in the days of old. If there nobody connected, the modem does nothing. The modem does nothing unless it's given a command to do so. As far as I'm aware, it's not constantly talking with the software. Maybe talking with the computer, but not the software. When it runs in vDos or vDos plus (used for long filenames only), the software acts like it's latched onto a single already and goes nuts because it doesn't know what to do with the signal it has.
In the NetSerial documentation it tells me that the connection should be empty until software initializes the modem, but if you put the com4="com4": in the config.txt and run vDos, it immediately recognizes some kind of signal. It doesn't leave it empty and wait for the software to initialize it, so there's something going on with the virtual port immediately rather than waiting for software to initalize the virtual modem.
Hopefully that explains why I'm looking for the com port to be idle or doing nothing until the software initializes the virtual modem.
I've never personally used serial for printing. For me, it's always been a modem communications port and I've never known any modem to have activity going on without software telling it to do so. Whether that be BBS software expecting an incoming call, which is what this is all for or a terminal program sending AT commands. Even real modems just sit there quietly until the software tells them what to do. Constantly polling a port just seems wrong in this environment, but admittedly I don't know enough about what it's really supposed to do, just what I expect it to do and what I've seen decades ago when I was running a multi-line BBS back in those days.
The rest of that is all greek to me other than a vague recollection about changing out a UART chip or flashing it to get a better baud rate out of the same modem.
I've already talked to one old school BBS System Operator who is going to be checking out vDOS as a viable option in a Win10/64 environment, but so far, there's road blocks and brick walls everywhere. Can't use Netfoss because of the 64bit environment and can't use NetSerial because something is off in the way com ports are being handled in vDos. Both leaves us out of options for incoming Telnet to old school modem communications in the software. Either one will work in Win7 or XP, but neither will work in Win10. Netfoss may work in a Win10/32 environment with vDos to run the software, but I don't have a 32 bit version to even try and see. :(
The only option left to try is Linux with DOSEMU I suppose, but I'll need another box for that one. I need my main system to stay Windows for work purposes. UGH!
Even if a modem is idle, it will continuously signal the UART what’s going on. No carrier detected, no ring, etcetera. vDos only opens/claims the COM port that is controlled/simulated by NetSerial, it needs to do so since it can’t address any hardware directly. So NetSerial will of course detect this, but nothing is communicated between vDos and NetSerial. A modem shouldn’t have an established connection the moment software will address the UART since it doesn’t expect that, and the connection has to be broken for the modem to return in command mode.
The only concern should be whether the software is polling the UART, or is interrupt driven. That could be checked in the vDos.log file. If it is interrupt driven, without an option to switch to polling, it ends for vDos since it doesn’t simulate COM port interrupts and the communication routines of the program won’t be activated/called.
Jos
I almost forgot about this part.......
"Internal printing 20 bytes"
.....The software is not even capeable of printing, so why does it thinkit's trying to print?
Here's what was actually occurring compared to the log.
change to d:\slbbs\
Run Config.exe
|--- change config to use com port
Run slbbs.exe
|--- runs login.exe from slbbs.exe
|----it auto-exited due to setting in config that exit's to dos if no user is present
Run config.exe
|---- Change to not exit software upon logoff
Run slbbs.exe
|---- Software goes nuts displaying weird and having strange lines at the bottom of the screen when out of the blue a the Windows Print Screen pops up like I'm trying to print something. At some point it runs login.exe
Run config.exe
|--- Change so the software doesn't communicate on any port
Run slbbs.exe
|---It comes up and sits idle like it's waiting for a call. Apparently it does load login.exe as part of it's waiting for call process since it did go to a waiting for call state. Login.exe is ran from within slbbs.exe and not something that is called upon directly. This is the only one that operated like it should, but it doesn't have any com ports setup at all which functionally disables all external communications.
vDos 2017.08.01
C: => (Local) D:\vDos\
Execute: DP26YI.EXE - /s
Int 1B => 2a0d:0004 (Delayed logging w/o DOS call)
Int 22 => f000:0003 (Delayed logging w/o DOS call)
Int 1B => f000:0000 (Delayed logging w/o DOS call)
D: => (Local) d:\bbs\
Execute: config.EXE
Int 0 => 1fd7:010c
Int 23 => 1fd7:0113
Int 24 => 1fd7:00db
Int 3F => 1fd7:0104
Int 3F => 1f81:02e6
Int 1B => 1f0f:0142
Int 23 => ae9:0000
Int 23 => 1fd7:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: slbbs.EXE
Int 0 => a6b:010c
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 1B => 9d4:0142
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 21 unhandled call C7FF
Int 23 => a6b:0113
Int 1B => 9d4:0142
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: \SLDEMO\LOGIN.EXE
Int 0 => 3da5:010c
Int 23 => 3da5:0113
Int 24 => 3da5:00db
Int 3F => 3da5:0104
Int 3F => 3c5c:02e6
Int 22 => a3e:0201 (Delayed logging w/o DOS call)
Int 1B => 3bce:0142
Int 23 => 1f60:0000
Int 23 => 3da5:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 0 => a6b:010c
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 7E => 0:0000
Int 79 => 0:0000
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 22 => f000:0003 (Delayed logging w/o DOS call)
Execute: config.EXE
Int 0 => 1fd7:010c
Int 23 => 1fd7:0113
Int 24 => 1fd7:00db
Int 3F => 1fd7:0104
Int 3F => 1f81:02e6
Int 1B => 1f0f:0142
Int 23 => ae9:0000
Int 23 => 1fd7:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: slbbs.EXE
Int 0 => a6b:010c
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 1B => 9d4:0142
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 21 unhandled call C7FF
Int 23 => a6b:0113
Int 1B => 9d4:0142
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: \SLDEMO\LOGIN.EXE
Int 0 => 3da5:010c
Int 23 => 3da5:0113
Int 24 => 3da5:00db
Int 3F => 3da5:0104
Int 3F => 3c5c:02e6
Int 22 => a3e:0201 (Delayed logging w/o DOS call)
Int 1B => 3bce:0142
Int 23 => 1f60:0000
Int C => 668:04d9
Int C => f000:0000
Int C => 668:04d9
Internal printing 20 bytes
Int C => f000:0000
Int 23 => 3da5:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 0 => a6b:010c
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 7E => 0:0000
Int 79 => 0:0000
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 22 => f000:0003 (Delayed logging w/o DOS call)
Execute: config.EXE
Int 0 => 1fd7:010c
Int 23 => 1fd7:0113
Int 24 => 1fd7:00db
Int 3F => 1fd7:0104
Int 3F => 1f81:02e6
Int 1B => 1f0f:0142
Int 23 => ae9:0000
Int 23 => 1fd7:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: slbbs.EXE
Int 0 => a6b:010c
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 1B => 9d4:0142
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 21 unhandled call C7FF
Int 23 => a6b:0113
Int 1B => 9d4:0142
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Execute: \SLDEMO\LOGIN.EXE
Int 0 => 3da5:010c
Int 23 => 3da5:0113
Int 24 => 3da5:00db
Int 3F => 3da5:0104
Int 3F => 3c5c:02e6
Int 22 => a3e:0201 (Delayed logging w/o DOS call)
Int 1B => 3bce:0142
Int 23 => 1f60:0000
Int 23 => 3da5:0113
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 0 => a6b:010c
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 24 => a6b:00db
Int 3F => a6b:0104
Int 23 => 199:1bba
Int 1B => 199:1bba
Int 1B => 9d4:0142
Int 23 => a6b:0113
Int 7E => 0:0000
Int 79 => 0:0000
Int 0 => f000:0000
Int 1B => f000:0000
Int 23 => 118:0000
Int 24 => 118:0110
Int 3F => f000:0000
Int 22 => f000:0003 (Delayed logging w/o DOS call)
To comment:
Int C => 668:04d9
Interrupt 0Ch (IRQ 4, COM1 or COM3) is set to program code starting at address 668:04d9. That would be started if vDos would simulate IRQ4 and the (virtual) UART is programmed to generate an interrupt.
Int C => f000:0000
Interrupt 0Ch is reset to the original (dummy) code.
Int C => 668:04d9
Interrupt 0Ch is set again.
Internal printing 20 bytes
W/o a corresponding directive in config.txt, all communication with COM1-9 and LPT1-9 is by default considered to be a printjob. The program writes 20 bytes to one of these ports. You can look for the #COM|LPT1-9.asc file, what port (COM1 ?) that was and what was sent. Since nothing seems to be set for this port, vDos wants to print whatever was sent.
Int C => f000:0000
Interrupt 0Ch is reset again.
But even if you set the port in config.txt, your program will expect the UART to generate an IRQ that is handled by the code fragment installed for interrupt 0Ch. Since vDos doesn’t simulate that IRQ, that code will never get activated/called.
Jos
So you're saying that it is possible that the virtual com port UART could generate it's own IRQ, but you default to print job, so it tries to print. I at least need to test it, so I need to find where in the config to change it so it's not a print job.
The #COM3.ASC file contains the initialization string sent by the BBS software. So it's trying to print the init string. Yeah, I at least need to test it not being configured as a print job.
If the Virtual com port UART generates the interupt then it just might work, but we could never find out because it's being treated like a print job by default.
Hmm. I'll see if I can find it.
Edit:
I've gone through the entirety of the config.txt and don't see anything that states, COMx is not a print job. Everything under the Printing Section is commented out.
The only thing I have added is...
COM2="COM2":
COM3="COM3":
COM4="COM4":
I haven't added a COM1 just because I still need to figure out why I'm showing I have a physical COM1 so I can disable it for use with the BBS software through Virtual Com port rather than physical com port. I can handle that on my own. If I can get it work on one of those 3 ports, I can get it to work on all of them.
In what context can I add "COMx is not a print job"?
Last edit: Russell Wiley 2018-03-14
There would be no need for the virtual vDos serial UART to generate an (virtual) IRQ. ‘Just’ to mimic the process: Pause the program, and start the corresponding installed interrupt service routine when the Windows device driver has something to report, and provide for the correct control values/lines when the UART is read out by that routine. But vDos doesn’t.
COM3="COM3": should tell vDos that COM3 is not for printing: Sent data is to be redirected to the Windows device driver, reading should invoke reading from that device.
Jos
So you're saying that it would still be a fruitless venture to continue to try? I'm not sure how NetSerial handles IRQ's.
Even having COM3="COM3": it still brings up the print window and writes out to a #COM3.ASC file, which is just the init string, which is why I thought there must be some other way to say, This is not for printing.
This almost makes me want to try something entirely crazy just to see if it would work. Using the Linux Subsystem under Win10 to run DOSEMU, which I know the fossil drivers work in DOSEMU. It's a little crazy, but worth a shot. It would require running the Linux version of the software I have answering the Telnet connection, but that's not a big deal. Not sure how stable it would be. Win10-Linux Subsystem - DOSEMU, that's a lot of crazy going on. :)
COM3="COM3": should prevent vDos to consider it as a printjob. But that was all once only basic tested, also using virtual COM ports. Perhaps I missed COM3.
Since vDos doesn’t support/mimic serial IRQ’s, it ends for interrupt driven communication programs. Netserial provides for virtual COM ports, could be it invokes eventually installed serial communications routines. But it surely has nothing to do with IRQ’s inside the virtual vDos PC.
You mentioned Netfoss, if your program can use a Fossil driver instead of the COM port roundabout - I guess you won’t use an actual serial port -, you could try a virtual Windows 32-bit machine with Netfoss.
Jos
Yes, there are people running it through VMWare, but that's really just using an earlier OS. XP or 7 is common. If I'm going to do that I might as well run that OS. I don't see the point of running XP or 7 under VMWare.
I'm looking for a solution that brings the old into the new era rather than a solution that keeps the old on the old. It's just a personal pet project. If it can't be done, it can't be done, but if If it's possible to find a way to do it, then I'll keep chugging along with it till I come up with a solution.
DosBox was a nogo before I barely started with it because it doesn't support SHARE, which is needed for the multi-line aspect, which is where I ended up trying vDOS in the first place, which was able to passify the software's SHARE requirement. It just got hung up on actual communications.
Shame that interupt driven communications can't work.
If you don’t plan to use actual serial ports, your program communicating with a (v)DOS virtual serial UART, that is linked to a virtual Windows port, then translated to TCP (?) communications is an absurd complex and error-prone roundabout. If your program can however use a fossil driver, and I suppose it can and that’s what NetFoss provides for, you would do without all the messy COM communications.
So a virtual Windows 32-bit machine seems the direct way to go since it runs NetFoss.
Probably ideally, one (not me) would write a NETFOSS.COM (the NetFoss FOSSIL TSR Interrupt handler) alternative component for vDos. Certainly doable since all about COM ports can be dropped.
Jos
Enough brainstorming and we're bound to find another way. I found another fossil driver that looks like it's a 16bit Telnet fossil driver. I don't know if it will communicate with the 64bit side of things, but it's worth a shot. I doubt it, but can't hurt to try and see what happens.
RLFOSSIL is an implementation of multi-line
serial port driver corresponding to the
Fido/Opus/Seadog level 5 specification and
a simple HAYES-compatible modem emulator.
It allows applications usually worked through
BBS's to run on the Internet, or in IP-based
local net.er, and rlogin and telnet emulation
using IP services numbers 513 & 23.
RLFOSSIL allows combined work with other
FOSSIL drivers (X00,BNU etc.).
It's promising, I just don't know how much yet.
I agree, the 32bit OS route is probably the best way to go. I'm just looking to see if there's any way whatsoever on a 64 bit system. If the 16 bit fossil driver can communicate wit the 64 bit telnet connection, then it may work. eh... worth testing anyway.
It is 16-bit software, so it can’t run directly in Windows 64-bit, moreover, there’s no NTVDM (DOS/BIOS facilities) anymore.
If it is run in vDos, it will at some moment have to communicate (by means of more drivers) with the NIC in the virtual PC, and there’s none.
Using a genuine Windows BBS program isn’t an option?
Jos
Sure that's always an option, but where's the fun in that? :)
In all seriousness, we (me and a long-time friend) have multiple boards setup already. This particular one is a pet project of mine because it's the software I used to run back in the 90's. It's also the only BBS software to fully implement RIPScrip graphics (EGA/VGA graphics on a Bulletin Board System) It's intended to show the power of what RIPScrip can do as well as a bit of nostalgia for me personally. There are so few active boards running this software these days. I've only found 2 so far and one of the 2 has RIPScrip disabled, so it's ANSI only. All modern BBS's are ANSI only, which is a shame. The internet came along at a really bad time. Right when RIPScrip was taking off and it pretty much destroyed the company who invented it, even if it did take another 10 years to do finish it off. I'd really like to have the representation of what it was and the potential it had. Especially in light of it's inventor passing away.
If worse comes to worse, we will end up setting it up in Linux under DOSEMU which we already have running other fossil based programs, so in theory it should work or on a Naitive 32/16bit system, probably Windows 7, but that is a last resort option. because I'd have to buy it it's own box because I'm not going to run it under VMWare. There's already known issues with running it under VMWare, so it's own dedicated box would be the way to go. I'll exhaust all other options before we go that route.
I haven't tried the DOS fossil driver yet. Work has been a bit busy the last couple days.
DOS was once the operating system, fully in control of the PC. It no longer is, and certainly -emulated or not - can’t control hardware aspects of a modern PC controlled by a non-DOS OS. Even when booting in actual DOS, you’ll have problems with that.
DOS programs can’t address actual hardware, it’s all emulated in vDos, as far it’s provided for of course.
Don’t expect a direct relation between DOS and Windows functionality at whatever level. DOS isn't Windows.
Jos