Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "cygwin" <cygwin AT cygwin DOT com>
Subject: RE: Mozilla 1.3 built on cygwin?
Date: Thu, 27 Mar 2003 23:58:50 +0100
Message-ID: <002301c2f4b4$6e378c60$80cf06d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal

>> Having Mozilla itself running under Cygwin might not be useful
>> to a lot of people but the fixes that Cygwin might have to go
>> through to make this happen could pave the way for other X apps
>> that come later.
>
>like we have encountered while porting KDE to cygin/xfree.
>
I remember a very good example and this is Kdevelop. We have build an alpha
release of kdevelop. Yes it runs mostly.
You can configure, compile and debug an application with it, but you need a very
very fast computer for a real production environment.
I have tested it with a PIII/700MHz Toshiba Satellite Pro 4300 Laptop with 320
MB RAM and W2K. The result wasn't very joyfull.
I don't know the exact reason(s), because there are several things involved,
like process creation and forking, network, pipe and file io, graphic
performance and so one (which are mostly identified by the cygwin developers),
but it is very complicated to separate the influence and the fraction of each
issue to identify the most annoying. :-(

I can't prove a fact, that forking is the most anonying problem and there were
some initial work from some people (I remember  Chris Faylor, Chris January and
other) to identify the problems and to implement a new copy-on-write semantic,
which will be much faster, for example in
http://sources.redhat.com/ml/cygwin/2002-04/msg01071.html, but is issue seems to
me as a very hard wall, which couldn't be broken by single people, because of
it's complexitivity. I assume that this could only be fixed by a team of
memebers with different skills. At first especially people are needed, which
have the time and the knowledge to analyse the current state and all the needed
thing, followed by some people with the skills to design a new implementation,
which could be implemented than by the coders.

For kde3 at first I've thought about replacing all fork() calls with native
win32 calls, but recognized this as the wrong way, because this would start a
never ending support story in every furture application. Unfortunally I haven't
the skills to start this job, but perhaps there are other people with limited
skills and time like me, who like to see this issues fixed, so I'm currently
hoping, that this team will be existant sometime in the future. A good starting
point would be, if someone could give an overview about the background, the
problems and possible designs.

Other issues are already fixed. I remember the ld auto-import stuff, which was
initiated with the porting of kde/cygwin and the linking time problem with big
libraries/application, which was fixed by the direct-linking-to-dll feature. See
the related thread in this list. The KDE3/cygwin release on which I'm currently
working will be based on this ld features, which reduces the linking time of
more than 50-70%. (For small libraries this isn't a very strong factg, but it
makes a different for big libraries, if the linking time is 3 minutes or 40
seconds). libtool support for this direct-linking-to-dll feature is in work, so
that other package could use this in the future. (implied, that this functionaly
is general accepted for libtool).

Another point is the cygwin ipc support. For the kde3 port I have planned to use
the cygwin ipc support, not the deprecate cygipc packages like I've done for
kde2, but unfortunally is seems to be broken in current cvs. (I can't get
running this stuff, it fails in shmget. It seems to be caused by the coming 64
bit support, but I'm not sure).
Additional I remember Robert Collins saying last year, that there is some
outstanding work to do, but I can't say what.

ipc-support is needed for pixmap caching, which will improve the graphical
performance. KDE uses also the Xfree Xshm support, which isn't enable by default
by the cygwin/xfree releases (because of the deprecated cygipc package), so a
patched release is needed for kde. (KDE will work without, but with lesser
performance).
If xfree would use the cygwin ipc support, this patched release would be
obsolate. I'm very interested to get this stuff running and I'm able to give
some feedback about performance and general functionality in relation to the
functionality kde requires.

Cheers
Ralf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/