Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Wed, 22 Jan 2003 18:33:05 +0100
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: setregid() and setreuid() implementation proposal
Message-ID: <20030122173305.GL29236@cygbert.vinschen.de>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20030117120131 DOT GF1142 AT cygbert DOT vinschen DOT de> <20030116190119 DOT GD820 AT tishler DOT net> <20030117120131 DOT GF1142 AT cygbert DOT vinschen DOT de> <3 DOT 0 DOT 5 DOT 32 DOT 20030121202701 DOT 007db4f0 AT mail DOT attbi DOT com> <20030122014007 DOT GA23365 AT redhat DOT com> <20030122102919 DOT GA29236 AT cygbert DOT vinschen DOT de> <20030122154704 DOT GE4903 AT redhat DOT com> <20030122155757 DOT GA16081 AT cygbert DOT vinschen DOT de> <20030122161000 DOT GF4903 AT redhat DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030122161000.GF4903@redhat.com>
User-Agent: Mutt/1.4i

On Wed, Jan 22, 2003 at 11:10:00AM -0500, Christopher Faylor wrote:
> Couldn't we do a FILE64 trick?  Just create wrappers for all of the
> functions?  Or detect something about the FILE structure which would
> allow us to figure out which was being used?

Grmblbrmblandwhataboutnewlibinternallygrmblbrmbl?

> >May I dream?  Let's break binary compatibility with 1.3 and switch
> >over to 64 bit off_t/fpos_t etc and 32bit uid_t/gid_t once and for all.
> >No big chnanges to newlib needed then.  We could get rid of all
> >func32/func64 function pairs... sounds like holiday on Hawaii.
> 
> That would imply a cygwin2.dll.  Do we really want to go there?  I could
> get rid of my signal-compatibility hacks, too.  And the termios hacks,
> and...
> 
> [cgf takes quick gulp of coffee to "calm down"]

We shoudn't make haste... let's begin today with cygwin2.dll.

You surely remember your suggestion to switch over to cygwin2.dll with
cygwin1.dll being just a wrapper calling the functions in cygwin2.dll.
In cygwin1.dll we only keep function stubs, copying the datastructures
into the new form (32bit ids, 64 bit offsets) and calling the corresponding
functions in cygwin2.dll.

We could begin with cygwin2.dll w/o even to care for that backward
compatibility.  The first goal would be to have a stable cygwin2.dll
which can coexist with today's cygwin1.dll but without sharing any
datastructure (own process table etc).  If we have a stable cygwin2.dll,
we can begin to create the compatibility lib called cygwin1.dll.

We could get rid of so many kludges... see that I'm moved to tears? :-)

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.