Anyone know how to establish a TCP connection over a network via a 16-bit assembly program?
I'm basically using TCP connection to pass Assembly Pervasive dbase file I/O data to 'c' which performs
TCP connmection to Java app to log serial incremental backup data. Rewriting the 16-bit assembly app
to some other high-level language is not an option at this time as it contains aprox 80,000 lines of
code that would have to be re-written.
I frist tried to accomplish this linking to a 'c' program that established TCP connection and it worked for
the most part, except a bug in the 'c' portion which forces a network disconnect at midnight, checked 'c'
documentation and this is a known problem which I am unable to fix. So I'm switching gears to see if I can
just forgo the 'c' code and accomplish the same TCP connection goal to our network all from 16-bit assembly.
thanks in advance.
-Dale
That sounds like heaps of fun. What TCP stack are you using? (WATTCP, Trumpet?) What network cards/drivers are you using? DOS Box in Windows?
http://www.erickengelke.com/wattcp/
http://www.trumpet.com.au/index.php/products/tcpip-driver.html
http://personal.redestb.es/josepfeb/solotext/guide/enh00400.htm
http://alumnus.caltech.edu/~dank/trumpet/
It's been years since I did IPX/SPX in DOS, and then it was a matter of getting a DOS driver for the network card, and loading a bunch of Novell driver code. The whole TCP/IP stuff was a lot more clumsy, and a quick Google doesn't suggest it less so in the last decade. Personally I'd look for something that exported Berkeley Sockets, used them a lot across a lot of platforms and embedded systems.
It's pretty easy to bind 16-bit C code to assembler, and back again. If you're having a problem with that, doing it all in assembler isn't going to make it any easier. If binding an application together isn't practical, the other approach would be to make a driver to handle all the transport ugliness and hook to it via the application.