Date: Thu, 02 Oct 1997 09:42:44 +1100 From: Bill Currie Subject: Re: DJGPP, interprocess communication, and DPMI In-reply-to: To: "Salvador Eduardo Tropea (SET)" Cc: djgpp AT delorie DOT com Message-id: <199710012139.JAA22095@teleng1.tait.co.nz gatekeeper.tait.co.nz> Organization: Tait Electronics Limited MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Comments: Authenticated sender is Precedence: bulk On 1 Oct 97 at 14:49, Salvador Eduardo Tropea (SET) wrote: > My example uses packets similar to network ones, seems that here the > solution is use the channel as a Level 0 layer of a net. Another I agree. Do we go for best effort or reliable delivery? I think it sould be best effort and the applications can implement the reliability. This means that the driver could get quite complicated! (either delivery method) This is because I feel the driver should help out with the synchronisation. The only problem I can see is obtaining the PID (or whatever is used) of the destination. But then again, we could always use ARP or something similar, but what do we use for the higher level addresses?. For the low level, we can either use 16 bit addresses (the PID, int 2f/1683) and use 0 as a broadcast address, or go for 24 or 32 bit addresses with 0-65535 as normal addresses and 65536-16M or 4G for broadcast and multicast addressing. > thing Michael have some problems to get TB working under W95, any > idea?, your own TSR works. I think mine works under w95 because it is loaded long before windows is and (as I understand it) drivers that get loaded before windows are common to all virtual machines, unless they tell windows otherwise (via the int 2f/1605 windows init callout). NOTE: I haven't actually tried my tb under w95, only msdos 6.?? and opendos 7.01. Hey! this is getting interresting. I'm getting all sorts of ideas on how this could work. The driver can have a total buffer size of say 32k and can use 16k for inter process communication and the other 16k as a per-process transfer buffer (via windows instancing). The application can then put its data into the pp (per-process) buffer and request the driver to `transmit' the buffer to the destination processes. The driver then copies the data from the pp buffer to the ip buffer (inter process buffer), changes to the destination virtual machine (int 15/1685), and copies the ip buffer to the pp buffer, maybe with a callback to the destination program. The question then is: does the driver return to the calling vm? broad/multicast addressing would be slightly more complicated (and a lot slower) but the driver can just go through the possible PID's (maybe there's a better way?). the pp buffer will probably have to be split into an incoming and an outgoing section. Bill -- Leave others their otherness.