Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Wed, 19 Apr 2000 13:05:14 -0400
To: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: Cygwin 1.1.0 gdb troubles
Message-ID: <20000419130514.B15213@cygnus.com>
Reply-To: cygwin AT sourceware DOT cygnus DOT com
Mail-Followup-To: cgf AT cygnus DOT com, cygwin AT sourceware DOT cygnus DOT com
References: <C9A8E1D07093D111B76A0000F8C9918A03332F3D AT zrtpd003 DOT us DOT nortel DOT com> <7703 DOT 000419 AT is DOT lg DOT ua>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <7703.000419@is.lg.ua>; from paul-ml@is.lg.ua on Wed, Apr 19, 2000 at 04:53:38PM +0300

On Wed, Apr 19, 2000 at 04:53:38PM +0300, Paul Sokolovsky wrote:
>    If no cygwin people will agree with you, then at least me will.
>IMHO, win32 is undoubtfully POSIX by spirit, only having somewhat
>twisted upbringing. Almost any POSIX feature maps one-to-one to win32
>one and difference is only in some idiosyncratic details. As an
>example, DeleteFile() does exactly what remove() does with one
>difference: remove() explicitly states possibility of removing opened
>file, while DeleteFile() explicitly prohibits it. I can't believe
>there's some adequate reasoning behind DeleteFile()'s behaviour. I
>just can imagine some win32 architect reading POSIX spec and time to
>time exclaiming: 'And *here*, we'll do vice-versa!' ;-)

So, how do you work around this tiny little flaw then?  How does your
magic wand work?

>     Well, what idiosyncratic features of native pids would harden
>their usage as POSIX pisd as-is?
>
>1. While NT's pids are rather POSIX-correct as-is, 9x's ones are
>negative values, large (up to 10 dec digits) by module.
>2. There's no documented way to get ppid on NT.
>3. It's impossible to overlay image of current process. This means,
>when performing usual fork-exec chain, there will be three processes:
>parent, exec() implementer stub and execed child. So, between child
>and parent in POSIX terms there will be other process.
>
>    While these problems may seem denying original idea, they hardly
>do. The workarounds for them exist, working and confidently may be
>called more robust than maintaining additional superstructures,
>moreover shared between all processes.

I'd like to hear your workaround for these problems.  Really.  I'm eager
to incorporate your advanced thinking into cygwin's design.  Or are you
just here to poke fun and jeer?

>Well, *that*'s not most annoying feature of cygwin.  Just net version
>ago there might arise problems with just having cygwin work properly
>after installation, mostly because ungrounded default mount table
>setup.  But look - this version now takes care to ask user where he
>wants having root mount.  So, all consistently improving and maybe one
>day other areas also will be addressed.

Probably the most annoying feature of cygwin for me is that people seem
to be compelled to criticize it while offering only vague generalities
and smug assertions that they could do it better.

It is astounding to me that this is an open source project for which
patches have always been accepted but people like you find it acceptable
to criticize the way things are done.  If you don't like the way cygwin
handles things, feel free to redesign and improve.  As I stated, I would
be quite fascinated to see patches which illustrate your ideas.

Before you offer the standard response of "I'm too busy", just take a
moment to reflect on what that statement means.  If you are too busy to
actually investigate these "problems" and offer concrete solutions, then
why should I believe that your ideas have any merit whatsoever?  How can
you adequately criticize something that you don't understand?

Ah.  The next argument will be that you have already implemented your
own POSIX-on-Windows and know everything that Cygwin did wrong.  So,
ok.  I'm willing to listen to how you mapped UNIX signals onto what
Win32 offers.  I'll be interested in hearing how you got exec() working.
You probably have implemented a fork.  I'd be interested in hearing how
it differs substantially from what cygwin offers.  Hmm.  You disparage
the cygwin mount table.  Let's hear how you have tackled this problem.

I don't consider any of this off-topic for this mailing list.  I envision
that you will probably want to enlighten us all with a series of articles
on how it could all be done better, complete with actual code samples.

Since this will be a substantial work, I guarantee that I will set aside
a portion of my day, every day to read and analyze what you post.  In fact,
I'm quite looking forward to your submissions.  Although you're probably
too busy to provide cygwin patches, I expect that your insightful articles
will still provide substantial fodder for future cygwin development.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com