Date: Fri, 22 Jan 1999 19:35:22 -0500 (EST) From: Michael Callahan X-Sender: mjc AT evelyn DOT smith DOT edu To: DJ Delorie , djgpp-workers AT delorie DOT com cc: "Peter J. Braam" Subject: Coda has TCP/IP and annonymous mmap for DJGPP on W95 In-Reply-To: <199901222352.SAA32322@envy.delorie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com I and the Coda filesystem project at CMU have some code which we would like to contribute to the DJGPP project. I did a port of the Coda client to Windows 95 which has been subsequently been further developed by CMU. The Coda client consists, on both Unix and Windows platforms, of a kernel-level minicache manager that handles simple filesystem requests and forwards more complicated requests to a very large, complicated user-level program called Venus. Venus is written to the usual Unix API. Most of this API is supported by the DJGPP libc already, but there were too important holes that I had to fill: - access to Windows 95's built-in TCP/IP networking - support for a limitted form of mmap(2) We would now like to contribute these extensions back to the core distribution. The TCP/IP support allows a DJGPP program to access the Windows 95 kernel networking stack using a Berkeley sockets API. The bulk of the code is a VxD that implements the Berkeley sockets API using the semi-documented in-kernel TDI API to the W95 networking stack. The Coda client needs a very particular kind of mmap() support: namely, it needs to be able to allocate memory at a fixed location in the program's flat address space. There is no way to do this using W95's built-in DPMI server implementation, so I wrote another VxD to permit a DJGPP DPMI client to reserve a large segment of virtual memory and then commit swap-backed memory pages to fixed locations in this address range. This permits Venus's built-in persistent OODB to work. (Note that this means that I do not support using mmap() to map the contents of a file.) The mmap support consists of the already-mentioned VxD plus changes to the program image startup C and assembly code. Peter Braam, cc'ed on this message, is the tech lead for the Coda project and will get the ball rolling when we are told what to do. Please copy him and me on messages related to this code, since we are not on djgpp-workers right now. I should note, by the way, that there are still some very obvious holes in these extensions. For example, there's no resolver library for TCP/IP, and there are doubtless some bugs. However, I think it is still a very useful starting point for someone who wants to fill in the gaps. Michael --- Michael Callahan mjc AT rodagroup DOT com