Serial ports in protected mode are talked to using device drivers. That's what device drivers are for!
This code does not have a timeout:
while(!(inp(open_port + SERIAL_LSR) & 0x20)){}
It waits until the bit on that (virtual) port becomes set, or until you turn off the computer.
Maybe take a step backwards: What are you trying to do in the first place? Is there another way of accomplishing that?
@hplus0603 I am just trying to get 2 DOS applications running in DOSBox to connect to each other, and this is the function that is preventing this from happening. And no, there is not an easier way because Watcom is so old and there are not many networking libraries for DOS.
Anyway, are the virtual COM ports configured appropriately, as expected by this code?
Could you write your own library? Poking at a virtual NE-2000 ISA Ethernet card isn't all that hard, if you're into DOS / real mode stuff. (This depends on which virtual hardware is available in your emulator – which emulator are you using?)
Or use the NDIS drivers.
hplus0603 said:
Could you write your own library?
Im not really sure about what I would need to do. That's why I am testing out Borland code. I am not sure of what I need to do to connect because I am used to using WinSock or ENet.
hplus0603 said:
which emulator are you using?
DosBox. Are there other Emulators?
VMWare Workstation, Hyper-V, and VirtualBox come to mind as things that can run DOS as a guest.
VMWare Fusion and Parallels and VirtualBox could do it on macOS.
QEmu and VMWare Workstation can do it on Linux.
These have slightly different sets of “virtual hardware” they provide for you to talk to, so depending on what kind of support libraries you have available in your environment, some of them may work better than others. Also, they all have different costs (although you can often buy surprisingly-legitimate surplus VMWare enterprise-license keys on ebay for a low cost, and Hyper-V comes with Windows Pro for free, and QEmu and VirtualBox are also free software.)
@hplus0603 Yes, but the emulator is not the problem, I dont believe. I have gotten the program to work in Borland. I have gotten networking to successfully compile with the Borland C compiler in 16 bit real mode. But Watcom and its 32 bit protected mode are not working well with the code. The program worked perfectly in DosBox when I used the demo program that is from Andre LaMothe's “Black Art of 3D Game Programming" or whatever its called, and it worked just fine. Its when I tried to compile the same code in Watcom that everything began to not work properly. I honestly feel like Protected 32 bit mode has different required hex values than 16 bit real mode Microsoft C++ and Borland C++ do. And it all really seems to start with the initialization of the program. And I have narrowed it down to the one function I mentioned earlier.
I am not sure exactly what I could have done wrong. I would have thought that the values would have worked, as I am running the program on DOSBox just like I did with the demo application, but I must have guessed wrong.
So I fiddled around with it a bit more, and here is what I got:
I hope this is of some help…
