• Please review our updated Terms and Rules here

DOS TCP/IP programming in quickbasic

M

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
just letting people know, if they are quickbasic programmers and wish to start using TCP under true DOS to program some network apps for their ancient PC's i have been developing a set of routines that you might just find extremely useful :mrgreen:

not TOTALLY finished yet, but everything required to connect to a remote computer and send/receive data is 100% functional.

i don't know how many people here program in quickbasic(NOT qbasic) but i'd assume a decent amount since this site is dedicated to ancient machines. here's a link to my code:

http://rubbermallet.org/qb
 
Quickbasic programs go like stink on a 486!! did a load of real time kaleidoscope routines a few years back. glad to see it's still alive and kicking (bottom)
 
What version of QuickBasic are you using?

Duh, never mind. I downloaded your QB-TCPIP.ZIP file and actually read the README.TXT file!!! :)
 
Last edited:
Another programmer - Awesome!

Just in case there are some people wondering what the big deal is ..

TCP/IP on a DOS machine requires three things:
  • Ethernet card and Packet Driver for that card - the Packet driver is a DOS TSR that lets other software send and receive data to the Ethernet card. It's a very low level interface, and it just lets that other software send raw bytes.
  • TCP/IP stack: This 'sits on top' of the Packet driver and provides the code that makes TCP/IP connections, sends and receives TCP/IP packets and UDP/IP packets, retransmitts data that didn't make it, etc.
  • Application: This is the last piece, and it uses TCP/IP to get stuff done. This might be a telnet program, web server, FTP program, chat program, etc.

What Mike has here is QuickBasic code that will help your code use the TCP/IP code (the Watcom piece) more easily. Instead of getting the Watcom C compiler environment setup you can use QuickBasic instead, which is a much easier language to start with.

More people should play with this stuff. It's really fascinating and rewarding to write your own programs, and being able to do it on vintage hardware while still being able to communicate with the latest and greatest hardware makes it worth while. Using Mike's setup here you could write TCP/IP apps that are just as good as those running on a modern Windows or Linux box .. A simple telnet BBS would be a great project.


(Mike - see the 'Joys of file sharing' thread. I've been working on a TCP/IP stack using Borland Turbo C++ 3.0. I just got my first TCP/IP socket connection last week.)
 
i'm glad you all are interested in this... quickbasic really is a good language as far as DOS programming goes. you can literally make anything with it, except it'll be slower than C software lol.

i posted this at a quickbasic forum, and nobody seemed to have any clue what to do with it.

i am working on an IRC client for DOS. i'll release what i have so far maybe tomorrow. i know there are existing DOS clients, but all them are outdated and only do the basics. it's my goal to make the best DOS client out there :cool:
 
But there exists some QuickBasic compiler? I have a vague memory of hearing about a such thing (with a BRUN library component), maybe only supporting part of the language. Of course you would only compile it when it is fully working.
 
carlsson said:
But there exists some QuickBasic compiler? I have a vague memory of hearing about a such thing (with a BRUN library component), maybe only supporting part of the language. Of course you would only compile it when it is fully working.
Click to expand...

you're thinking of QBasic, which is only an interpreter and does not compile. QuickBASIC is 100% compaible with the QBasic language and syntax, but it includes an integrated EXE compiler.
 
An IRC client is on my todo list, but given that I'm writing the TCP/IP layer too it's going to take a while.

I really do expect my TCP/IP to be a rocket. Well, relatively speaking at least. Some features such as IP packet fragmentation and defragmentation I'm not going to support, which shouldn't be a big deal. Other features, such as the size of the ARP cache will be configurable at compile time. I've been avoiding memory moves like the plague (since they are very time consuming on an 8088), and I've written the IP checksum procedure in ASM with help from a friend who knows this hardware very well.
 
mbbrutman said:
An IRC client is on my todo list, but given that I'm writing the TCP/IP layer too it's going to take a while.

I really do expect my TCP/IP to be a rocket. Well, relatively speaking at least. Some features such as IP packet fragmentation and defragmentation I'm not going to support, which shouldn't be a big deal. Other features, such as the size of the ARP cache will be configurable at compile time. I've been avoiding memory moves like the plague (since they are very time consuming on an 8088), and I've written the IP checksum procedure in ASM with help from a friend who knows this hardware very well.
Click to expand...

that sounds pretty cool... i'm assuming that other than the checksum stuff you're writing this mostly in C? you'll have to post it when you're finished for us all to check out.

the only things my qb routines are missing are dns resolution and opening a socket for listening (so that you would also be able to write server programs, instead of just clients)... i might work on that stuff tonight and see if i can get it going
 
The whole project is written in C, and is functionally equivalent to WATTCP. My code is packaged as a library that you link to. To use your QB code on top of it I'd need to make a TSR version that could be accessed via software interrupt and we'd need a slightly different amount of 'glue code' in the BASIC code to call those software interrupts.

I don't have DNS resolution either, but that's just a simple UDP protocol, isn't it? Listening presents a problem ... I presume that WATTCP has you poll to see if you have a new connection. If so, that wouldn't be bad.
 
Mike Chambers said:
you're thinking of QBasic, which is only an interpreter and does not compile. QuickBASIC is 100% compaible with the QBasic language and syntax, but it includes an integrated EXE compiler.
Click to expand...

Actually actually Carlsson, you're probably thinking of QB45(??) which was the compiler for qbasic (?), it's code runs a lot slower than quickbasic, but then it was probably written for a pure 8086, and can't use the knobs and whistles of newer processors. I last used it about 12 months back.
 
This is all very interesting! I've been an applications programmer for over 24 years now, but I've never done any systems-level programming. I've already downloaded and unzipped Mike's QuickBasic code, and am eagerly reading that. I would also be interested in mbbrutman's Turbo C++ code, when he thinks it is ready for general consumption.
 
Cold day in hell on my part .. :)

I changed my incoming packet buffering scheme last night to allow an application to hang onto an incoming buffer as long as it needs it. That involved changing from a ring buffer to manage the incoming packets to a stack of free packets, a ring buffer for packets to be processed, and a new mechanism for giving user code packets and letting the user code return the packets.

The new code worked fine, but was 20% slower. After two hours of tearing my eyeballs out I figured out that I made a stupid 1 line mistake up in the application layer. All of the critical lower level stuff was just fine ..

So based on that rate of progress, it's going to be a while.

I never used Qbasic or QuickBasic. In 1985 or so I purchased Zbasic from Zedcor, which was a basic compiler. It was light and fast compared to the standard BASICs at the time, and Qbasic/QuickBasic were still on the horizon. However, the concepts were the same. Digging out QuickBasic and playing with TCP/IP using this code should be doable by any apps programmer. A Linux box to serve as a target makes debugging easier, but that's not required. (The Linux tcpdump utility is a good packet tracer.)
 
web server (turbo) in c without any dll, How can i do this

web server (turbo) in c without any dll, How can i do this

mbbrutman said:
Another programmer - Awesome!

Just in case there are some people wondering what the big deal is ..

TCP/IP on a DOS machine requires three things:
  • Ethernet card and Packet Driver for that card - the Packet driver is a DOS TSR that lets other software send and receive data to the Ethernet card. It's a very low level interface, and it just lets that other software send raw bytes.
  • TCP/IP stack: This 'sits on top' of the Packet driver and provides the code that makes TCP/IP connections, sends and receives TCP/IP packets and UDP/IP packets, retransmitts data that didn't make it, etc.
  • Application: This is the last piece, and it uses TCP/IP to get stuff done. This might be a telnet program, web server, FTP program, chat program, etc.

What Mike has here is QuickBasic code that will help your code use the TCP/IP code (the Watcom piece) more easily. Instead of getting the Watcom C compiler environment setup you can use QuickBasic instead, which is a much easier language to start with.

More people should play with this stuff. It's really fascinating and rewarding to write your own programs, and being able to do it on vintage hardware while still being able to communicate with the latest and greatest hardware makes it worth while. Using Mike's setup here you could write TCP/IP apps that are just as good as those running on a modern Windows or Linux box .. A simple telnet BBS would be a great project.


(Mike - see the 'Joys of file sharing' thread. I've been working on a TCP/IP stack using Borland Turbo C++ 3.0. I just got my first TCP/IP socket connection last week.)
Click to expand...



Mr mbbrutman
Can u tell me how can i write c code for webserver and client program in windows with out using any dlls or any header files(ex.winsock.h) -(turbo C)
 
yeah, i don't think that would be possible without using microsoft's stuff there... unless you re-wrote it yourself, which would be a huge waste of time.

wow this thread is a blast from the past! my old wattcp code lol.

mike b, i have been working on a DOS IRC server the past few days. i thought you'd be interested to know that. i'll upload it this weekend hopefully, and have it running on the XT or maybe a 286 for people to connect too. problem is, TCPDRV and NTCPDRV only allow up to 8 sockets to be used at a time.

apparently it's hardcoded to not use anything out of the range of 0 to 7 as a socket handle. BAD news for me and this project. i've been looking at the packet driver spec, and have been considering just writing a whole TCP/IP stack myself kind of like you did in TC, but for QB programmers to use. i'd make sure to use 16-bit handles to allow up to 65k concurrent sockets. that would take a TON of memory for buffers, in fact i don't think an XT would be able to handle that. i would probably have to tap into extended memory. i doubt more than a few thousand would be possible on 640 KB when you consider memory DOS uses and then the packet driver TSR on top of that. plus the rest of my program not including the buffers.

8 connections will probably do the trick for my little DOS IRC server i doubt there'd be more than that many people from here ever connected to it at once but thats still terrible for an chat server.


EDIT: i thought i would point out that currently this thread has 1,337 views. thats 1337.
1337views.png
 
Last edited:
Eight sockets is a little limiting. For an IRC server 32 or 64 would be nice. For any other type of server, 8 is probably about right .. an XT can't do much more. Besides the control information for each socket, you need to allocate a buffer. Even with a modest buffer of 512 bytes or 1K, things will add up quickly.

Don't even think of trying to do a TCP stack in QB. Even with years of programming experience getting ARP, IP, UDP and TCP running well was challenging. And I still have more to do. You can do it in QB, but the performance will quickly disappoint you. The language just isn't well suited to that kind of project.

Check out some of the smaller TCP/IP implementations if you are interested. There are two or three out there. Not high performance, but they are compact.
 
mbbrutman said:
Eight sockets is a little limiting. For an IRC server 32 or 64 would be nice. For any other type of server, 8 is probably about right .. an XT can't do much more. Besides the control information for each socket, you need to allocate a buffer. Even with a modest buffer of 512 bytes or 1K, things will add up quickly.

Don't even think of trying to do a TCP stack in QB. Even with years of programming experience getting ARP, IP, UDP and TCP running well was challenging. And I still have more to do. You can do it in QB, but the performance will quickly disappoint you. The language just isn't well suited to that kind of project.

Check out some of the smaller TCP/IP implementations if you are interested. There are two or three out there. Not high performance, but they are compact.
Click to expand...

oh, i know the performance would be garbage especially on an XT. i think it'd be ok on any 386+

i could possibly use a VGA card's memory area as a "cheat" if i were running it on an XT, to get more buffer space. that is pretty corny to have to install a VGA card for a TCP implementation.

i'm sure i could get a very usable framework going in QB given some time. it's not something i am really planning on doing... it was more of just a thought. i have quite a bit of experience in both the basic language and network protocols.
 
I am looking for a PCI card and packet drivers for it

I am looking for a PCI card and packet drivers for it

I have a Pentium 3 with only PCI slots. No ISA. I have an SMC NIC card, but PKTPWR.COM says no card is found. Any suggestions?
 
You must log in or register to reply here.
Back
Top