Mail Archives: cygwin-developers/2002/09/05/17:07:48
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 <chris AT atomice DOT net>
EB> + Christopher Faylor <cgf AT redhat DOT com>
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
- Raw text -