delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/10/01/17:44:49

Date: Thu, 02 Oct 1997 09:42:44 +1100
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: DJGPP, interprocess communication, and DPMI
In-reply-to: <m0xGNAZ-000S20C@inti.gov.ar>
To: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
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
Comments: Authenticated sender is <billc AT blackmagic DOT tait DOT co DOT nz>

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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019