Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Wed, 4 Sep 2002 17:00:26 +0400 From: egor duda Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <119161140988.20020904170026@logos-m.ru> To: Earnie Boyd Subject: Re: GetConsoleWindow In-Reply-To: <3D75F865.27083D77@yahoo.com> References: <3D74CE7E DOT FC9C5BDF AT ieee DOT org> <3D74E346 DOT 53082DA7 AT yahoo DOT com> <3D7537F8 DOT 1050105 AT netscape DOT net> <3D754D71 DOT 9DB9EEDA AT yahoo DOT com> <20020904111259 DOT C1213 AT cygbert DOT vinschen DOT de> <20020904113230 DOT E1213 AT cygbert DOT vinschen DOT de> <3D75F865 DOT 27083D77 AT yahoo DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Wednesday, 04 September, 2002 Earnie Boyd earnie_boyd AT yahoo DOT com wrote: EB> This change to Cygwin EB> =================================================================== EB> RCS file: /cvs/uberbaum/winsup/cygwin/ChangeLog,v EB> retrieving revision 1.1463 EB> retrieving revision 1.1464 EB> diff -u -r1.1463 -r1.1464 EB> --- winsup/cygwin/ChangeLog 2002/08/30 15:47:09 1.1463 EB> +++ winsup/cygwin/ChangeLog 2002/08/30 16:03:52 1.1464 EB> @@ -1,3 +1,9 @@ EB> +2002-08-30 Christopher January EB> + Christopher Faylor EB> + EB> + * tty.cc (tty_list::allocate_tty): Use GetConsoleWindow, if EB> available. EB> + Call FindWindow in a loop. EB> + EB> is what is causing the problems. The code needs conditionalized further, EB> because the function EB> doesn't exist pre W2K. The ChangeLog also needs adjusted to mention the EB> autoload.cc changes. EB> Yes, Cygwin is what is broken with this patch. Earnie, you are wrong. Cygwin have an ability to handle win32 functions which are present on some platforms and not present on others via autoload mechanism. It's essentially a lazy binding of symbols. It works as the following. For (almost) every function from OS API which cygwin uses, a stub is created in file autoload.cc. Each reference to w32api function in cygwin dll source code is actually pointing to this stub. When the function, say GetConsoleWindow(), is called first time, the control is passed to its stub. Stub tries to get actual function address via LoadModule() and GetProcAddress() calls, and if this operation succeeds, the stub is "patched" to pass control to actual address of GetConsoleWindow() in appropriate system dll, so that next time we won't have to load dll and perform address lookup in it again. If LoadModule() or GetProcAddress() fail, (and on nt4 the latter indeed fails because GetConsoleWindow() is not available in kernel32.dll), then stub is patched to always return 0. That is, almost all w32api functions are linked into cygwin dll dynamically, at runtime. This allows: 1) Speed up startup time. If application never uses socket functions, winsock dlls are never loaded. 2) Greatly simplify wincap system -- we don't need to have a separate capability for every win32 function 3) Allow single cygwin1.dll for all win32 platforms. The problem that Pierre encountered was the following: in autoload.cc GetConsoleWindow was defined as functions which takes 1 DWORD argument. In include files and in tty.cc it was declared and used correctly, as function without arguments. That is, stub in autoload.o was created for symbol GetConsoleWindow AT 4, while actual code had a reference to GetConsoleWindow AT 0. The reference was therefore resolved by kernel32.def instead of autoload.o. To all: Should I create how-autoload-works.txt ? Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19