Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com From: Sam Edge To: cygwin@cygwin.com Subject: Re: cygwin.bat Date: Sat, 10 May 2003 21:04:28 +0100 Organization: . Reply-To: cygwin@cygwin.com Message-ID: References: <3EBC77C9.7090605@m8y.org> <3EBC793B.9000301@rfk.com> In-Reply-To: <3EBC793B.9000301@rfk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: Hamster/2.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h4AK4pT24855 "Larry Hall (RFK Partners, Inc.)" wrote in <3EBC793B.9000301@rfk.com> in gmane.os.cygwin on Fri, 09 May 2003 23:59:55 -0400: > >Could be my imagination, but even seems a > > little slower. > That *would* be your imagination. Maybe not. If you start up bash.exe directly by double-clicking it or by putting bash.exe in a shortcut, then only one process is created. If you use cygwin.bat, then under Windows NT/2k/XP you first have a CMD.EXE process created and then a bash.exe. The CMD.EXE sits around doing nothing until the bash.exe process exits. It will therefore take longer to get from the initial double-click to the cursor flashing at the bash prompt. On a slower PC this may be a discernable extra delay. The extra CME.EXE also uses system resources (virtual memory, kernel objects, etc.) and will therefore slow all other processes down by a very small amount, although I doubt whether this effect would be noticeable unless the PC was already heavily over-committed. -- Sam Edge -- 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/