Hello Everyone:

This posting is sure to incur the wrath of Christopher Faylor. While I'm sorry about that, this time it just can't be helped.

After many years of developing GNU tools and infrastructure for Windows CE 3.0+, we have decided that we need the functionality that Cygwin provides. We already have an extended newlib that we've built that gives us significant POSIX functionality on CE. But what we really want to do is run Bash, and that means we need fork()/vfork() and the other more advanced functionality that only Cygwin provides. Thus, we are setting out to create "Cygwince".

We are not naive in trying to do a Cygwin port to CE.  We know that:

1. CE has no console device. This does not bother us because we will be using the system primarily via rlogin as our CE device has no screen. We'll have to "plumb around" the missing console device, but that is not expected to be a big problem.

2. Implementing fork() on CE was well nigh impossible until very recently. But as of "CE.NET" 4.0, the all-important DuplicateHandle() system call is now available and supposedly has the expected behavior. We believe this means that CE 4.0+ has the required infrastructure to support the Cygwin fork()/vfork() implementation.

We are pretty sure that we can get the Cygwin DLL to run well on CE 4.0+. We have only some questions about X86 "asm" statements in the fork() implementation. We would like one of the experts (e.g. cgf) to annotate (with source code comments) the "asm" statements in the fork code. This is all we need - we just need to understand what these statements are supposed to do so that we can make the same things happen on Xscale.

We are going to be starting with the mingw version of Cygwin - MSYS - primarily to try to keep the size of the DLL down. Another reason for starting from this distribution is that MSYS has a version of bash and the utilities that all come together in a fairly tidy bundle.

The Cygwin people should make a decision as to whether we should submit patches for Windows CE to the Cygwin project. We are of course going to make all the results of our efforts publicly available, after all we have to do this. But we are also willing to cooperate with the Cygwin project to the extent that is deemed necessary/desirable.

Best regards,
craig vanderborgh
voxware incorporated

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



Reply via email to