dilettante
MIS
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:
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. ;-)
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_lengthI 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. ;-)
Red-eyed, mumbling mammal capable of conversing with inanimate objects.