Mail Archives: djgpp-workers/1998/07/23/13:36:34
Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz> wrote:
> [sorry about coming in late on this one, but I've been having alot of
> problems with email (until tonight-I finally got my mail working again)
> and a lot of mail got bounced (I appologise for any inconvenience
> caused)]
>
> Salvador Eduardo Tropea (SET) wrote:
> >
> > Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> >
> > >
> > > On Wed, 22 Jul 1998, Salvador Eduardo Tropea (SET) wrote:
> > >
> > > > I remmember I had some success using the Bill's driver that makes the
> > > > transfer buffer shared. But that's slow and needs the driver loaded.
>
> Hmm, why is it slow?
Because the applications makes some polls in the transfer buffer,
perhaps that isn't important in some cases, but when I tried a simple
program that transfers the keystrokes to the other (you type in one
DOS Box and you see the letters in the other ;-) I saw it was slow.
> How are you implementing your multi-tasking?
What Eli suggested and what I used for this experiment is Winblows.
> Are
> you doing the IOCTL (?? been too long since I looked at the code) every
> time you use the buffer?
No.
> You don't have to as it's not going to move
> about in memory.
The programs just call ioctl ones and then use the shared transfer
buffer.
> > >
> > > This mechanism will be used in interactive programs and in applications
> > > like an editor which lets the compiler run in the background. For
> > > example, Emacs' support for async subprocesses is implemented so that the
> > > output from a subprocess is only read if Emacs is idle. This means that
> > > if you are a very fast typist, or if you invoke a command that takes a
> > > long time to finish, you can almost block the compiler messages from being
> > > displayed in the compilation buffer. And yet when I use these Emacs
> > > facilities on Unix, I hardly see any slow-down.
> > >
> > > So I don't think speed is so much important in this case.
> >
> > But you are overlooking some very important fact: pipes are fast in
> > UNIX the methode I tried to comunicate 2 programs could be *very*
> > slow for small transfers.
> > But if you want to implement it is ok ;-)
>
> Hey!! *I'm* interested in seeing what you've done. I would like to see
> that driver being used for something. I no longer have a use for it
> (Windows is banned from the house and I don't use dos much anymore, so
> guess:), but I am certainly willing to pitch in with any help I can
> give. I may even be able to do some testing at work (I use a sun
> workstation, but there are others with w95 that may be willing to let me
> do some testing A/H).
If you want I can search where is a copy of it, but I think the int
31h or the direct longjmp solutions are better because they work in
DOS.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -