Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: Sam Edge To: cygwin AT cygwin DOT com Subject: Re: cygwin.bat Date: Sat, 10 May 2003 21:04:28 +0100 Organization: . Reply-To: cygwin AT cygwin DOT com Message-ID: References: <3EBC77C9 DOT 7090605 AT m8y DOT org> <3EBC793B DOT 9000301 AT rfk DOT 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 DOT 9000301 AT rfk DOT 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/