Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
X-Authentication-Warning: abomination.cygnus.com: mdejong owned process doing -bs
Date: Thu, 13 Apr 2000 07:29:22 -0700 (PDT)
From: Mo DeJong <mdejong AT cygnus DOT com>
To: "Parker, Ron" <rdparker AT butlermfg DOT com>
cc: "'cygwin-developers AT sourceware DOT cygnus DOT com'" <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: Windows 9x environment space solution
In-Reply-To: <200003312008.MAA28255@cygnus.com>
Message-ID: <Pine.LNX.4.10.10004130727590.27135-100000@abomination.cygnus.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Ron, the env space problems I was running into on Win 95 have
gone away with the most recent installer.

Thanks.

Mo Dejong
Red Hat Inc.

On Fri, 31 Mar 2000, Parker, Ron wrote:

> In an attempt to steer the whole "Mo" discussion back to the original
> problem, here is what I intend to do. (I am not mad, nor am I upset. It may
> just read that way.)
> 
> I am _not_ setting up a full Unix-style environment for this release. I was
> told that the release would be "soon" and I see a lot of suggestions for
> feature creep. If DJ or Chris want to authorize some serious changes to the
> KISS philosophy that I was applying to the installer, then I will consider
> it. 
> 
> Did or did we not want to leave it up to the end-user to decide which
> packages to install? Was I not told to save a more sophisticated installer
> for a later date? As much as I would like to have MS-GINA replaced with xdm
> and an inetd that is loaded before even logging on, I am taking the simplest
> route I can find for now. 
> 
> So, with that in mind, here is how I am going to attempt to correct the
> out-of-environment-space issue. I will add a file to setup's resources. This
> will be a preset shortcut that has the "Initial Environment" set at the
> upper limit of 4096. I will copy it to the proper location on the machine
> and then modify the paths and other settings in this shortcut. For now, it
> will still call the same batch file that setup is creating. I used this
> technique with success on the "Solutioner" project at work about 3 years
> ago.
> 
> Now the rationale.
> 
> Why a preset shortcut? There is no API or COM Interface in Windows that
> allows you to programmatically change this value. After much searching, I
> even broke down and loaded the 1997 MSDN Library Archive to look at the
> Program Manager DDEML interface,  then I recalled doing this on the other
> project.
> 
> Why not a setting in /etc/profile or similar? There are numerous ways a
> shell may be started. Not all of them read the same initialization files and
> there is no initialization file that bash reads under all cirumstances, I
> checked the info file. Also this presents the chicken or the egg scenario,
> the user must know the location of the shell file in the Windows file
> system, because it is not in the path, and they must call it with the
> --login switch to source /etc/profile, so that bash can set PATH. Yuck.
> 
> Why not modify autoexec.bat or the NT registry? There are a few reasons. 
> *	It requires a system reboot. Who doesn't hate software installs that
> make them reboot?
> *	It is very difficult to uninstall properly and fully.
> *	There is an issue with Windows find program versus /usr/bin/find.
> Don't laugh but batch file programmers tend to expect the brain-dead version
> of find to be called. You can also bet that they would expect bash to call
> /usr/bin/find. 
> *	In NT the user would get the Cygwin tools when they call one from
> the command prompt. This might be a problem if what they really wanted was
> one of the NT POSIX subsystem programs <insert wretching sound effect>. ;^)
> 
> While it is not ideal, and nothing is, having a batch file that contains all
> of the necessary changes provides a nice starting point for the user if they
> want to alter the system environment or make changes to how bash is started.
> Also, if they screw up their environment, they are responsible, not us. (Yes
> I know we'll hear about it on the cygwin list.)