Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

QB/VBDOS and C Libs (Sockets) 1

Status
Not open for further replies.
Apr 13, 2001
4,475
US
I can see why nobody ever bothered to mess with TCP/IP from QuickBasic/VBDOS much. In particular using the TCP/IP stack from Microsoft's Lan Manager for DOS package.

After a few years of searching I have finally gotten hold of the TCP/IP SDK for DOS. This has the C header files along with the all-important DOS_SOCK.LIB needed to interface with the SOCKETS.EXE TSR.

What I thought to be the greatest strength of this library is that the API it offers is very close to the common BSD Sockets API. What a fool I was!

In order to make use of DOS_SOCK.LIB you need to deal with numerous C structs, and in many cases you get returns from the API functions that are C pointers to C structs that contain C pointers to lists of other C pointers to things like C strings. Needless to say, one goes mad quite quickly breaking up LONG values into two INTEGERS to use in a DEF SEG and a couple of PEEKs, just to turn around and use the PEEKed results to do yet more DEF SEGs and PEEKs.

A simple thing like looking up a DNS name to get the IP address is a three-ring circus! Here's just a hint at the craziness:
Code:
    hostname = "localhost" + CHR$(0)
    host_entry_P = gethostbyname&(SSEGADD(hostname))
    BrkP host_entry_P
    h_addr0_P = _
      PFromPListAtP&(MakP&(ADD_SEG.O + h_addr_list_OFS, ADD_SEG.S), 0)
    h_length = _
      IntAtP%(MakP&(ADD_SEG.O + h_length_OFS, ADD_SEG.S))
    MemCpy MakP&(SADD(addr.sin_addr), SSEG(addr.sin_addr)), _
           h_addr0_P, h_length
Most of the insanity is due to the segmented memory model used in x86 real mode of course. But the BSD developers sure didn't help matters much when they created this API.


I know this may be a totally pointless question, but has anybody else come up with a good way to handle calls into C-oriented APIs from DOS Basics? I have the calls themselves figured out, with all of the SADD()s and SSEG()s passed to the API routines. The killer is the pointers and structs. Declaring records (TYPEs) doesn't help a lot either. Half the time you get back a pointer to a struct someplace inside the API (?) instead of the API call filling in a struct (record) you pass to it.

I could probably make it work the way I'm going, but I get the eerie feeling I'll be burning up half of the cycles I use just thrashing in my efforts to deal with all of this C crud.

Even trying to create some assembler routines to handle this doesn't appear to be a good option. I'd need routines that are aware of the various structs used in the Sockets API. Sort of an API to the API by the time I'm done. If I went that way I suppose I'd just build it in C instead of assembler.


I know about other DOS TCP/IP packages, and the interface/shim packages that let a DOS Basic program under Windows access Winsock. I'm interested in using the Microsoft TCP/IP package under native DOS instead.

I have to admit I'm losing interest fast though. ;-)
 
Also make sure you are calling (declaring) functions with BYVAL Arguments, or you won't get anywhere ;-)

Declare Function ACFunction%(BYVAL AVar As Integer)

Have Fun, Be Young... Code BASIC
-Josh
cubee101.gif


PROGRAMMER: (n) Red-eyed, mumbling mammal capable of conversing with inanimate objects.
 

Hi,

I'd be extremely curious to hear the tale of how you finally found a copy of the [TCP/IP SDK for DOS].

I too am on a quest to find a copy.

But rather than a practical usage, I'm just as interested in the story of how you got there.

It's hard to explain, but I'm interested in mindset and the history of how socket.exe and dos_socket.lib and such evolved. Getting a copy of the dos_socket.h file, I think, would go a long ways to helping to understand what they were thinking.

I lived through those years and tried and tried to comprehend BSD sockets, Winsock, Async, ect.. and feel I failed to get the big picture.. now I'm looking backwards at history and evolution trying to pick up the loose threads.

It's really a personal quest.. maybe compensation for a feeling of inadequate programming skill.

In any event.. would like to hear from you, here or via personal email.

Who knows perhaps I could contribute some long lost notes to add to what your trying to do.

- john w.
 
Not a really big mystery actually.

I had tried for years to figure out where it might be on a Microsoft web or FTP site, digging through every folder on the latter almost file by file.

KB articles on the subject have always been rare during the time I was looking for the SDK.

Somewhere along the way recently I did yet another Google search. One of the hits was an FTP site in China, and lo and behold there it was for the downloading. I'm not sure how this really happened because I didn't think FTP sites were normally indexed and referred by Google. Maybe it was a web site that redirects to an FTP site?

I never retained the URL.

I didn't pay much attention, being more interested in seeing what I actually had, whether the few documents were in readable English, and making sure there were no viruses embedded in the package. Then I started playing around with it.

After a very few days it became clear though that the library was not going to be of use from QB/VBDOS. It required a great deal of jockeying with pointers to lists of pointers.

There was a real "deal breaker" somewhere along the line - I don't recall just what right now. I think this was related to how the DOS_SOCK.LIB had been compiled. This caused me to set it aside without even compiling one program against the API.

There are header files aplenty:
[tt]IN.H
NETDB.H
SOCKDEFS.H
SOCK_ERR.H
SOCKET.H[/tt]

Also:
[tt]WSOCKDEF.H
WSOCKETS.H[/tt]

The "documentation" consists of little besides a brief README.TXT and two small DOS samples in C and two small "Windows" (3.x?) samples in C.

While copyrighted, the README states:
You may freely copy the contents of this diskette to your hard disk, taking care to preserve the include file directory structure. After indicating to your compiler and linker the location of the include files and sockets libraries, you should be able to completely build your application.
 
That's simply awesome.

I've often done the same.. finding more history archived in sites overseas than here.

Guess I'll just have to keep trying.

You sound a lot like myself in that even when told its hopeless you have to see the proof.. and then maybe not even then.

Some how I'm going to find a copy, somewhere..

I was a QB/VB programmer quite a bit in 1992-1995 or so.. slowly moving towards Turbo C/C++ lots of TSR writing and so forth. Finally jumping to VC++ around 1997 and GCC around 1998... now I swim in both ponds.. not much Carbon as of yet.

The "pointers" of "pointers" reference sounds enticing.. like maybe they were using an index of pointers and some type of Interrupt call and function to reference a lookup table.

It might be of interest that there are a couple good int.exe programs for DOS that let you pass Interrupt calls and memory addresses via a "shell" like command and return data to the calling program.

From QB or VB this would take a "system" call to run another program and then return. It's contrived I know, but an easy way to build up confidence before writing a full handler or loadable runtime module for the procedure.

"True" programming gods would probably scoff at the effort.. but I'm no such deity, and find comfort in toiling in the muck and myre of the past.

Thanks for the reply..
 
Gabby gabby gabby...

I just had to push my luck here.

Any chance you could share some ideas for proper
search keys for Google?

MSDOS TCP/IP SDK SOCKETS come to mind.. but I've
tried those before and had little luck.

Also, I noticed a fellows project to make an Ethernet
card accessible to Qbasic a while back.. its a lot
closer to the wire with regard to protocols and such..
he was actually building up frames if I recall in Qbasic.

(excuse the wordy explaination to follow)

You have the serial wire protocol which uses a transciever
on the ethernet card to process frames of data.. inside the
frames are IP data wrappers and inside those are TCP data
wrappers and so forth, until you get to the core of this
silly onion.. yer chewy data center

Abstracted programmers usually like to think from the other
direction.. make a TCP/IP socket.. stuff something in..
yank something out.. and let the SOCKETS.EXE worry about
all the fiddly details of molecular disassembly and
reintegration at both ends of the wire (I'm kidding of
course.. too much Stargate last Friday).

Anyways.. I became a fan of Tanebaum's explainations a
few years ago and just get goofy feelings messing around
with networks.. they're fun.

I'll happily dig up the URL if you'd like.

- john w.
 
Ok.. this is a little disappointing.. but think I found your link.

file was called [mstcpsdk.rar]

It was posted in a Blog on a Chinese website about two years ago.

2002-07-02

Unfortunately the link no longer works.. it gives terribly detailed and interesting slivers of source code.. and a link to /develop/article/files/mstcpsdk.rar

Clicking on it returns a 404 Error, and Googles wayback machine says the websites author used the norobots file to block archiving.

Very sad.. very very sad..

- john w.
 
I wish I had more to add.

I haven't found the location I downloaded the SDK from again, though I tried repeating the most recent searches I've done. In any case I found it to be fairly useless for DOS Basic progrmming.

Yes, there are other methods you might use if you want TCP/IP from a Basic program. Most of these use a library that talks to a packet driver.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top