On Wed, 13 May 1998, Derek Fawcus wrote:
>   Grabbed it and had a (quick) look,  still a lot of background reading to
> do though...

BTW, I recommend _Systems Programming for Windows 95_ by Walter Oney and
_Unauthorized Windows 95_ by Andrew Schulman.  The former is more
immediately useful in doing VxD programming, but the latter gives a better
overview of why Windows 95 is the way it is.

For building, you need the Windows 95 DDK (which means an MSDN
subscription) and DJGPP.

>   The compiled stuff I'm not too interested in yet (since my server is
> currently down awaiting a PSU and new disks),  however I would like to
> have a look over the source for mc.vxd & mcstub.vxd.
> 
>   One question I've got already:  Why is the relay.exe process being
> used?  Is it the case the (for some reason) we're unable to select
> on the direct file descriptor for the open device (mc.vxd) and thus
> have to go via relay.exe,  or is this simply a debug aid?

It's a debug aid.  The select() at the core of relay.exe is just as
complicated--no less--than the core select() in venus.exe would
be--basically, it waits on network sockets and the minicache
file descriptor, subject to a timeout.  (Of course, neither sockets nor
the minicache connection are actually file descriptors in the Unix sense:
the DOS I/O calls don't work on them.  There are libc hacks that make
direct calls into the respective VxDs to transfer data and to perform
select().)

It proved to be very useful to decouple the kernel code from venus.
First, relay displays a dump of the packets going between venus and the
kernel, which is extremely valuable.  Second, having relay separate
permits changing the minicache code without restarting venus.

In the long run, relay should go away.

Michael