PDA

View Full Version : DOS TCP/IP programming in quickbasic



Mike Chambers
September 2nd, 2006, 01:37 AM
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

nige the hippy
September 2nd, 2006, 04:19 AM
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)

DoctorPepper
September 2nd, 2006, 04:23 AM
What version of QuickBasic are you using?

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

mbbrutman
September 2nd, 2006, 07:15 AM
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.)

TroyW
September 2nd, 2006, 08:33 AM
wow, well done. Looks like I might just have to dust off my old QuickBasic disks... :)

Mike Chambers
September 2nd, 2006, 01:47 PM
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:

carlsson
September 2nd, 2006, 01:58 PM
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.

Mike Chambers
September 2nd, 2006, 02:14 PM
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.

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.

mbbrutman
September 2nd, 2006, 02:53 PM
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.

Mike Chambers
September 2nd, 2006, 04:05 PM
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.

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

mbbrutman
September 2nd, 2006, 04:11 PM
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.

nige the hippy
September 3rd, 2006, 05:26 AM
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.

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.

DoctorPepper
September 3rd, 2006, 05:42 AM
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.

mbbrutman
September 3rd, 2006, 07:40 AM
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.)

athidi
June 9th, 2008, 11:29 PM
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.)



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)

mbbrutman
June 10th, 2008, 03:27 AM
It's probably not possible.

Mike Chambers
June 14th, 2008, 03:27 PM
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.
http://rubbermallet.org/1337views.png

mbbrutman
June 14th, 2008, 05:12 PM
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.

Mike Chambers
June 14th, 2008, 09:35 PM
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.

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.

teccs
March 1st, 2010, 06:31 PM
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?

Ole Juul
March 1st, 2010, 07:36 PM
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?
First, welcome!
Second, are you programming in quickbasic (as per the thread title), or are you just looking for a driver? I guess it's for DOS, so look at the crynwr selection: http://www.crynwr.com/drivers/ I've found that for DOS it is sometimes better to look for a driver and then find the card. :) BTW, why are you using a P3?

teccs
March 1st, 2010, 07:45 PM
Hi Ole,

Thanks for the quick reply.

I am a QuickBASIC programmer on and off since 1989. I want to see what I can do with web pages served up in QuickBASIC. I looked at the driver list and downloaded one that is for an SMC NIC card, but it says that it can't find and ethernet card when I run the driver. I only have SMC slots available and so I have to find a card and driver that will work. 2 are listed on that list that are for SMC. The one I downloaded for SMC just says it is for SMC cards, but doesn't say if it works for the SMC PCI cards. So, I will find one that is SMC PCI from that list and get one of those cards. I found some on ebay. Just wanted to see if anyone had any further insight on this problem. The pentium 3 is only for speed. I run Desqview and QEMM. Awesome products. If you have suggestions about a better computer, I am open. I have worked on computer since the days of the Apple 2. Also an awesome computer. Listening to iWoz (Steve Wozniak's autobiography) last month sure brought back lots of memories. Is there a problem with using a P3 that I should know about?

teccs
March 1st, 2010, 07:49 PM
I got that wrong. I found the one in the list that did say SMC PCI, but it would not work with mine. Sorry for the brain fart.

Ole Juul
March 1st, 2010, 08:38 PM
OK, I see you got the right thread. :) I'm not knowledgeable about quickbasic myself though.

Is there a problem with using a P3 that I should know about?
I doubt it. I run DOS as my daily OS on a P1 and things are instant so I was just wondering. It was a vintage flavoured question. :)

Regarding the drivers. I've wondered about PCI support as well. It would be handy, but I don't know what driver (if any) that works. I see people in the DOS world collecting 16 bit cards just so they have stock. There are a few drivers floating about out there but crynwr is the pedestrian link from everyone. I did however, find a nice little collection on a Waterloo TCP/IP boot disk. There are three SMC drivers there. I'll put the whole collection up for you to try, just give me a few minutes. :) Go to my CGS (http://cgs.coalmont.net) site and pick it up (http://cgs.coalmont.net/wtnbdrv.zip)(122K) now as I'll probably remove them again after a few days.

Mike Chambers
March 1st, 2010, 10:25 PM
teccs, welcome to the forum. i'm not sure if that SMC packet driver works for a PCI card. i think it might be for the ISA ones, but could be wrong. there are packet drivers for other PCI cards though, i know for a fact. for example i've used a packet driver with a dynex DX-E101 (can't believe they supplied one) and i've done it with a couple older 3com PCI cards.

Ole Juul
March 3rd, 2010, 09:43 PM
I got that wrong. I found the one in the list that did say SMC PCI, but it would not work with mine. Sorry for the brain fart.
Did any of the ones I posted work? Did you find any others?

BTW: I did a search of my HDD and found three DOS NIC drivers for PCI although for other cards. At least now I know there are PCI drivers.
1/ 3Com EtherDisk 3C90x EtherLink 10/100 PCI NIC Family
2/ D-Link DFE-530TX Fast Ethernet Adapter Packet Driver
This card comes in PCI so I guess this driver will work.
3/ Lucent Agere Proxim Classic Orinoco Gold wireless PCMCIA

wiwa64
March 4th, 2010, 01:10 PM
Cold day in hell on my part .. :-)
. . . (The Linux tcpdump utility is a good packet tracer.)Just in case that you haven't got a Linux box at hand: You could also try my ETHTOOLS packet which you find in another thread of this forum or here: http://www.bttr-software.de/products/jhoffmann/ Of course it cannot compete with a full-blown project like ETHEREAL/WIRESHARK but it runs under native DOS, using the same kind of environment your Programs will use and it might do the job.


(My appologies for this little commercial break ;-))

teccs
March 11th, 2010, 07:09 PM
In the code for quikserv, Mike opens files first as binary then opens them for input. Why is this?

Example below from his code:

OPEN "MIMES.INI" FOR BINARY AS #1: CLOSE #1
OPEN "MIMES.INI" FOR INPUT AS #1
DO UNTIL EOF(1)
INPUT #1, p1$
IF LEN(p1$) > 0 THEN
LINE INPUT #1, p2$
mimetot = mimetot + 1
mime(mimetot, 1) = UCASE$(p1$)
mime(mimetot, 2) = LCASE$(p2$)
END IF
LOOP
CLOSE #1

Ole Juul
March 11th, 2010, 08:25 PM
@teccs: I'm puzzled that you didn't answer my question. Anyway, I found an SMC driver which I actually tested on the SMC1211TX-50 which is PCI.
http://www.smc.com/files/AR/DR_SMC1211TX_all.zip

teccs
March 11th, 2010, 08:39 PM
Hi Ole Juul,

I apologize for not answering. I did not have email notification of responses turned on and overlooked your entry when I came back to post mine. I used NICSCAN.EXE from http://www.georgpotthast.de/sioux/packet.htm to see what NIC card was in my dos computer. I found it to be an Accton card so I downloaded those drivers from http://www.georgpotthast.de/sioux/packet.htm. I got quikserv running and got the source code to compile and run as well. Amazing what QuickBASIC will do. Thank you for posting a reply and packet drivers. Again, I apologize for not responding. I must have been finding drivers and NICSCAN while you were sending me a reply.

teccs
March 11th, 2010, 08:46 PM
Has anyone modified Quikserv to allow it to support the other 3 HTTP methods besides GET?