Date:	Thu, 13 Jan 2000 09:30:37 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Richard Dawe <richdawe AT bigfoot DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Building a VxD for win95 for zero page protection
In-Reply-To:	<387D06D6.37ACD589@tudor21.net>
Message-ID:	<Pine.SUN.3.91.1000113093011.9693J-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 12 Jan 2000, Richard Dawe wrote:

> I think writing a VxD like this could be very useful. It might be possible
> to use it to implement shared memory between DOS boxes, which would allow
> a number of problems to be solved, e.g.
> 
> 1. Arbitrarily long command lines (no transfer buffer limit)

If this is a real problem, it can be solved today, in more than one
way.  The library sources already include a working version of code
that allocates a DOS buffer if the command is longer than what the
transfer buffer can hold.  That code is disabled for now, but it can
be enabled if there is a real problem; you will then have a 600KB
limit.

If that isn't large enough, you could pass the command line through
protected-mode memory.  Since in DPMI 0.9 all clients share the same
LDT, all you need is to pass the selector and offset of the command
line to the child program, and it will be able to access it with
movedata.  This is partly implemented (and disabled) in the startup
code, but not in dosexec.

> 2. Possible fork() support?
> 3. Easy Unix domain sockets (rather than using the mailslots as in
> libsocket) or other interprocess communication
> 4. Shared memory

These are the real benefits from such a VxD, IMHO.

- Raw text -