Michael James | 9 Feb 08:19 2009
Picon

[PATCH] w32api fixes

Some corrections to w32api I needed while porting an application to
mingw in this patch.

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/winsup/w32api/ChangeLog,v
retrieving revision 1.985
diff -r1.985 ChangeLog
0a1,12
> 2009-02-08  Michael James  <james.me <at> gmail.com>
>
>       * include/wingdi.h (CLEARTYPE_QUALITY): Define.
>       * include/winuser.h (WM_KEYLAST): Alternative definition when
>       _WIN32_WINNT >= 0x0501.
>       (WM_UNICHAR,UNICODE_NOCHAR): Define.
>       * lib/comctl32.def (DefSubclassProc <at> 16,GetWindowSubclass <at> 16,
>       RemoveWindowSubclass <at> 12): Add exports.
>       * lib/gdi32.def (GetDCBrushColor <at> 4,GetDCPenColor <at> 4): Add exports.
>       * lib/msimg32.def (GetDCBrushColor <at> 4,GetDCPenColor <at> 4): Remove exports,
>       belong in gdi32.def originally in msimg32 due to bad documentation.
>
Index: include/wingdi.h
===================================================================
RCS file: /cvs/src/src/winsup/w32api/include/wingdi.h,v
retrieving revision 1.61
diff -r1.61 wingdi.h
361c361
< //http://www.pinvoke.net/default.aspx/Structures/LOGFONT.html
---
> /* http://www.pinvoke.net/default.aspx/Structures/LOGFONT.html */
(Continue reading)

Michael James | 25 Feb 00:38 2009
Picon

[PATCH] w32api fixes commctrl.h listview

A simple patch. My application was misbehaving only when built with
mingw. It turned out that this incorrect header value was at fault. I
am also submitting this patch to the mingw patch tracker on
sourceforge.

Does anyone have an estimate on how long these patches take to be
incorporated into the main repository?

Index: include/commctrl.h
===================================================================
RCS file: /cvs/src/src/winsup/w32api/include/commctrl.h,v
retrieving revision 1.66
diff -r1.66 commctrl.h
1059c1059
< #define LVIF_COLUMNS 256
---
> #define LVIF_COLUMNS 512
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/winsup/w32api/ChangeLog,v
retrieving revision 1.986
diff -r1.986 ChangeLog
0a1,4
> 2009-02-24  Michael James  <james.me <at> gmail.com>
>
>       * include/commctrl.h (LVIF_COLUMNS): Fix definition.
>

Christopher Faylor | 25 Feb 03:33 2009

Re: [PATCH] w32api fixes commctrl.h listview

On Tue, Feb 24, 2009 at 03:38:56PM -0800, Michael James wrote:
>A simple patch. My application was misbehaving only when built with
>mingw. It turned out that this incorrect header value was at fault. I
>am also submitting this patch to the mingw patch tracker on
>sourceforge.
>
>Does anyone have an estimate on how long these patches take to be
>incorporated into the main repository?

FYI, you don't have to cc w32api patches to cygwin-patches.  They are handled
by the MinGW team.

cgf

Pierre A. Humblet | 26 Feb 05:03 2009
Picon

[Patch] gethostbyname2

I tried to compile Exim with IPv6 enabled and Cygwin 1.7, but it 
needs gethostbyname2.
Here is an implementation of that function.
In attachment I am including the same patch as well as a short test function.

Pierre

2009-02-25  Pierre Humblet <Pierre.Humblet <at> ieee.org>

	* net.cc: Include windns.h.
	(gethostbyname2): New function.
	* cygwin.din: Export gethostbyname2.

Index: cygwin.din
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/cygwin.din,v
retrieving revision 1.202
diff -u -p -r1.202 cygwin.din
--- cygwin.din	19 Feb 2009 09:22:51 -0000	1.202
+++ cygwin.din	26 Feb 2009 03:54:30 -0000
 <at>  <at>  -635,6 +635,7  <at>  <at>  _getgroups = getgroups SIGFE
  _getgroups32 = getgroups32 SIGFE
  gethostbyaddr = cygwin_gethostbyaddr SIGFE
  gethostbyname = cygwin_gethostbyname SIGFE
+gethostbyname2 SIGFE
  gethostid SIGFE
  gethostname = cygwin_gethostname SIGFE
  _gethostname = cygwin_gethostname SIGFE
Index: net.cc
===================================================================
(Continue reading)

Corinna Vinschen | 26 Feb 10:52 2009

Re: [Patch] gethostbyname2

On Feb 25 23:03, Pierre A. Humblet wrote:
> I tried to compile Exim with IPv6 enabled and Cygwin 1.7, but it needs 
> gethostbyname2.
> Here is an implementation of that function.
> In attachment I am including the same patch as well as a short test function.
>
> Pierre
>
>
>
> 2009-02-25  Pierre Humblet <Pierre.Humblet <at> ieee.org>
>
> 	* net.cc: Include windns.h.
> 	(gethostbyname2): New function.
> 	* cygwin.din: Export gethostbyname2.

This is way cool!  I have this function on my TODO list for ages.

But there's a problem.  You're using DnsQuery_A directly, but this
function only exists since Win2K.  Would it be a big problem to rework
the function to use the resolver functions instead?  They are part of
Cygwin now anyway and that would abstract gethostbyname2 from the
underlying OS capabilities.

The implications of having this function... for instance, we can
implement gethostbyname then in terms of gethostbyname2 and honor
the RES_USE_INET6 flag.  We could even drop relying on the Winsock
implementation of getaddrinfo/getnameinfo and use the Stevens
implementation exclusively.  Wow.

(Continue reading)

Pierre A. Humblet | 26 Feb 16:29 2009
Picon

Re: [Patch] gethostbyname2

At 04:52 AM 2/26/2009, Corinna Vinschen wrote:
| >On Feb 25 23:03, Pierre A. Humblet wrote:
| > > I tried to compile Exim with IPv6 enabled and Cygwin 1.7, but it needs
| > > gethostbyname2.
| > > Here is an implementation of that function.
| > > In attachment I am including the same patch as well as a short test function.
| > >
| >
| >This is way cool!  I have this function on my TODO list for ages.
| >
| >But there's a problem.  You're using DnsQuery_A directly, but this
| >function only exists since Win2K.  Would it be a big problem to rework
| >the function to use the resolver functions instead?  They are part of
| >Cygwin now anyway and that would abstract gethostbyname2 from the
| >underlying OS capabilities.

I was afraid of that. Using res_query was my initial thought, but I realized that when using the
Windows resolver I would undo in gethostbyname2 all the work done in minires.

I am wondering if gethostbyname2 should not be moved out of  net.cc and integrated
with minires. We could design shortcuts to use the most appropriate method.

I have read RFC 2133, section 6.1 . Do we want to implement having a
RES_OPTIONS in the environment,  in  /etc/resolv.conf, or only by setting the
appropriate flag in _res? What does Linux do?

I am still fighting one issue with Windows. On XP, when using the native gethostbyname
I can resolve computers on my local net (through NetBIOS or such). But I can't get
them with DnsQuery, except my own computer, despite what I think the doc says.
Any insight?
(Continue reading)

Corinna Vinschen | 26 Feb 17:05 2009

Re: [Patch] gethostbyname2

On Feb 26 10:29, Pierre A. Humblet wrote:
> At 04:52 AM 2/26/2009, Corinna Vinschen wrote:
> | >On Feb 25 23:03, Pierre A. Humblet wrote:
> | > > I tried to compile Exim with IPv6 enabled and Cygwin 1.7, but it needs
> | > > gethostbyname2.
> | > > Here is an implementation of that function.
> | > > In attachment I am including the same patch as well as a short test function.
> | > >
> | >
> | >This is way cool!  I have this function on my TODO list for ages.
> | >
> | >But there's a problem.  You're using DnsQuery_A directly, but this
> | >function only exists since Win2K.  Would it be a big problem to rework
> | >the function to use the resolver functions instead?  They are part of
> | >Cygwin now anyway and that would abstract gethostbyname2 from the
> | >underlying OS capabilities.
> 
> I was afraid of that. Using res_query was my initial thought, but I realized that when using the
> Windows resolver I would undo in gethostbyname2 all the work done in minires.

I'm sorry, but I really don't understand what you mean.  How are you
undoing work in minires when using minires in gethostbyname2?!?  Why
isn't it just possible to call res_query from there?

> I am wondering if gethostbyname2 should not be moved out of  net.cc and integrated
> with minires. We could design shortcuts to use the most appropriate method.

I must be missing something serious here.  I'm puzzled why it matters
where gethostbyname2 is.  I was thinking of the resolver being basic
functionality.  The idea was to implement practically all subsequent
(Continue reading)

Dave Korn | 26 Feb 17:23 2009

Re: [Patch] gethostbyname2

Pierre A. Humblet wrote:

> I am still fighting one issue with Windows. On XP, when using the native
> gethostbyname I can resolve computers on my local net (through NetBIOS or
> such). But I can't get them with DnsQuery, except my own computer, despite
> what I think the doc says. Any insight?

  Are you running / not-running the "DNS Client" service?  What happens if you
do the opposite of however it is now?  (Or even just restart it, if already
running, sometimes it gets persistently confused).

    cheers,
      DaveK

Pierre A. Humblet | 26 Feb 18:55 2009
Picon

Re: [Patch] gethostbyname2


----- Original Message ----- 
From: "Corinna Vinschen"
To: <cygwin-patches>
Sent: Thursday, February 26, 2009 11:05 AM
Subject: Re: [Patch] gethostbyname2

| On Feb 26 10:29, Pierre A. Humblet wrote:
| > At 04:52 AM 2/26/2009, Corinna Vinschen wrote:
| > | >On Feb 25 23:03, Pierre A. Humblet wrote:
| > | > > I tried to compile Exim with IPv6 enabled and Cygwin 1.7, but it needs
| > | > > gethostbyname2.
| > | > > Here is an implementation of that function.
| > | > > In attachment I am including the same patch as well as a short test function.
| > | > >
| > | >
| > | >This is way cool!  I have this function on my TODO list for ages.
| > | >
| > | >But there's a problem.  You're using DnsQuery_A directly, but this
| > | >function only exists since Win2K.  Would it be a big problem to rework
| > | >the function to use the resolver functions instead?  They are part of
| > | >Cygwin now anyway and that would abstract gethostbyname2 from the
| > | >underlying OS capabilities.
| >
| > I was afraid of that. Using res_query was my initial thought, but I realized that when using 
the
| > Windows resolver I would undo in gethostbyname2 all the work done in minires.
|
| I'm sorry, but I really don't understand what you mean.  How are you
| undoing work in minires when using minires in gethostbyname2?!?  Why
(Continue reading)

Corinna Vinschen | 26 Feb 19:03 2009

Re: [Patch] gethostbyname2

On Feb 26 12:55, Pierre A. Humblet wrote:
> From: "Corinna Vinschen"
> | I'm sorry, but I really don't understand what you mean.  How are you
> | undoing work in minires when using minires in gethostbyname2?!?  Why
> | isn't it just possible to call res_query from there?
> 
> It is possible of course. But the sequence would be the following
> 1) External DNS server sends compressed records to Windows resolver
> 2) Windows resolver uncompresses the records and puts them in nice structures
> 3) Minires takes the nice structures and recompresses them to wire format
> 4) Gethostbyname2 uncompresses them into nice structures
>     then 5) calls dup_ent,  which copies them in the tls.locals
> I would like to streamline the process:
> - With Windows resolver: 1, 2, 5  (that's the current patch, ~20% of  which is
>          cut&pasted from minires and could be restructured to use a common function)
> - Without: Straight fom wire format records to the tls.locals memory block
>                  Or: have a routine 2a) in minires that replaces 2. Then it would be 1, 2a, 5.

Uh, I see.  Well, you could change the minires code so that there is an
internal interface which can be used from net.cc or, FWIW, any other
part of Cygwin to optimize the above process.  If you really think
it's necessary to move gethostbyname2 to the minires sources, go for it.
However, in the long run I think it's better to keep gethostbyname2 in
net.cc and to have an optimized internal resolver interface for this
kind of call.

> | I never used the DnsQuery functions myself.  There's a DnsQuery flag
> | called DNS_QUERY_NO_NETBT documented in MSDN, maybe there's something
> | switched off on your machine so that's the default?
> 
(Continue reading)


Gmane