UI bugs hampering porting effort for shaped window

[Rob]

Hello All,

Apologies if I'm not posting to the correct location. I am trying to port
our X-Lite (a leading free SIP softphone) application to run under WINE as a
first trial before we obtain the expertise to do a native application.
However, I am running into some issues because our application uses a
non-standard shaped window. One of our windows developers has created a test
application that demonstrates the non-compatible issues found in hopes that
someone may be able to help resolve the issues. As of yet, we do not have
the in-house expertise to fix the issues directly within WINE.

In addition to the UI issues listed below, a fix for bug 1541 is critical.
If anyone can help resolve these issues, I'd greatly appreciate the help in
getting another application that can run under WINE, and we can have one of
our windows developers assist in validation of any fixes.

Thanks,
Rob

Bugzilla Bug 1541
   WS2_32 version of gethostbyname with NULL argument doesn't follow
specification
http://bugs.winehq.org/show_bug.cgi?id=1541

...

This application demonstrates the issues we are having which will allow
X-Lite to run under WINE. Source and binaries are included.

Find the demo application at:
http://www.xten.com/files/winetest.zip

The show stopper bugs are B1, B2, B3, B4 and B5.

Issue B5, and B7 can be worked around, so they aren't as critical.

B1, B2, B3, and B4 can be fixed by putting a title bar on the application.
(See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.)

- B1. Focus does not appear to be on the application at start-up.  We do not
      receive keyboard messages, though we do receive many other messages,
      such as mouse-clicks.  Clicking on the square labelled "focus:"
      fixes the problem, by bringing up a message box -- when the message
      box is dismissed, the application has focus.  This appears to be the
      same problem as that discussed here:
      http://bugs.winehq.org/show_bug.cgi?id=292
- B2. No task bar item.
- B3. "System" commands do not appear to be working.  Examples:
         - we do not receive WM_CLOSE when the user presses Alt+F4
         - Alt+Space does not bring up the System menu
- B4. We are always on top, until a screen-saver kicks in.  (Also can be
      fixed by simply removing WS_POPUP.)  This appears to be the same
      problem as that discussed here:
      http://bugs.winehq.org/show_bug.cgi?id=1288
- B5. The application window is supposed to have a non-rectangular shape.
      The shape is made by setting a "region" from a mask bitmap, and
calling
      SetWindowRgn.  The problem under Wine happens when converting the
      2-bit color mask to a 24-bit color mask.  The black 2-bit pixels are
      properly converted to black 24-bit pixels, but the white 2-bit pixels
      are converted to a near-black, rather than white.  The sample app
      demonstrates 2 ways of working around the problem:
      method 1: fixes the problem by using a 16-color (4 bit per color) mask
                instead of a 2-color mask.  This gets around the bug in a
                reasonable way.
      method 2: fixes the problem by using near-black (instead of white) for
                the "transparent" color.  This exploits the bug and causes
                a bad (but correct) appearance on Windows.
- B6. Copy to the clipboard doesn't work (though pasting from the clipboard
      does work).
- B7. Attempting to bring up the right-click context menu causes the app to
      hang.

[Jerry Jenkins]

Rob wrote:
> The show stopper bugs are B1, B2, B3, B4 and B5.
>
> Issue B5, and B7 can be worked around, so they aren't as critical.
>
> B1, B2, B3, and B4 can be fixed by putting a title bar on the application.
> (See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.)
> - B1. Focus does not appear to be on the application at start-up.  We do not
>     receive keyboard messages, though we do receive many other messages,
>     such as mouse-clicks.  Clicking on the square labelled "focus:"
>     fixes the problem, by bringing up a message box -- when the message
>     box is dismissed, the application has focus.  This appears to be the
>     same problem as that discussed here:
>     http://bugs.winehq.org/show_bug.cgi?id=292
> - B2. No task bar item.

Patch at
http://www.winehq.org/hypermail/wine-patches/2003/09/0268.html
can fix these problems.

[Mike Hearn]

On Wed, 29 Oct 2003 16:59:59 -0800, Sir Rob scribed thus:
> Bugzilla Bug 1541
>    WS2_32 version of gethostbyname with NULL argument doesn't follow
> specification
> http://bugs.winehq.org/show_bug.cgi?id=1541

[mike@littlegreen working]$ cvs log -N -r1.135 dlls/winsock/socket.c
RCS file: /home/wine/wine/dlls/winsock/socket.c,v
Working file: dlls/winsock/socket.c
head: 1.138
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 138;   selected revisions: 1
description:
----------------------------
revision 1.135
date: 2003/09/02 18:12:20;  author: julliard;  state: Exp;  lines: +10 -0
Rein Klazes 
_ws_gethostbyname() and WSAAsyncGetHostByName() when called with a
null name, should use the name returned by gethostname().
=============================================================================

What version of Wine were you using? It seems this bug was fixed some time
ago, we just forgot to update bugzilla.
> B1, B2, B3, and B4 can be fixed by putting a title bar on the application.
> (See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.)

Yes they are caused by our use of override-redirect, which causes a LOT of
bug reports. I can't remember why Jerrys patch was not applied, but I
think Alexandre has very specific ideas about what to do in this area.
> - B6. Copy to the clipboard doesn't work (though pasting from the clipboard
>     does work).

What does a +clipboard trace show? Does the demo app show this?
> - B7. Attempting to bring up the right-click context menu causes the app to
>     hang.

Does the demo app show this? If so, perhaps one of us can get a backtrace
of the deadlock.

thanks -mike

[Rob]

Hi Mike,

bug 1541 is still *not* fixed correctly. See when passing in NULL in windows
to gethostbyname, it is guarenteed to return a list of local IP addresses
mapped on the box. However, with WINE, passing NULL causes gethostname to be
passed into gethostbyname and does *not* always return back the list of
local IP addresses on the box. This may work on some boxes, and not others,
depending on how the machine is configured and if the DNS lookup on the host
name resolves to the local IP addresses.

File: dlls/winsock/socket.c

static WIN_hostent * __ws_gethostbyname(const char *name, int dup_flag)
{
    WIN_hostent *retval = NULL;
    struct hostent*     host;
#ifdef  HAVE_LINUX_GETHOSTBYNAME_R_6
    char *extrabuf;
    int ebufsize=1024;
    struct hostent hostentry;
    int locerr = ENOBUFS;
#endif
    char buf[100];
    if( !name) {
        name = buf;
        if( gethostname( buf, 100) == -1) {
            SetLastError( WSAENOBUFS); /* appropriate ? */
            return retval;
        }
    }

whereas if (!name) should use SIOCGIFCONF - SIOCGIFADDR or something...

Jerry's patch *does* fix the UI issues actually - B1 through B4 - any idea
why it isn't applied to the CVS tree? We have the version out of CVS, which
definately has issues with B1-B4.

B5 is still broken, but not critical.

B6 is confirmed fixed now with CVS build.

B7 is still broken, but it's not critical as we have a work around solution.

-Rob

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Mike Hearn
Sent: October 30, 2003 1:22 AM
To: [e-mail]
Subject: Re: UI bugs hampering porting effort for shaped window

On Wed, 29 Oct 2003 16:59:59 -0800, Sir Rob scribed thus:
> Bugzilla Bug 1541
>    WS2_32 version of gethostbyname with NULL argument doesn't follow
> specification
> http://bugs.winehq.org/show_bug.cgi?id=1541

[mike@littlegreen working]$ cvs log -N -r1.135 dlls/winsock/socket.c
RCS file: /home/wine/wine/dlls/winsock/socket.c,v
Working file: dlls/winsock/socket.c
head: 1.138
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 138;   selected revisions: 1
description:
----------------------------
revision 1.135
date: 2003/09/02 18:12:20;  author: julliard;  state: Exp;  lines: +10 -0
Rein Klazes 
_ws_gethostbyname() and WSAAsyncGetHostByName() when called with a
null name, should use the name returned by gethostname().
============================================================================
=

What version of Wine were you using? It seems this bug was fixed some time
ago, we just forgot to update bugzilla.
> B1, B2, B3, and B4 can be fixed by putting a title bar on the application.
> (See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.)

Yes they are caused by our use of override-redirect, which causes a LOT of
bug reports. I can't remember why Jerrys patch was not applied, but I
think Alexandre has very specific ideas about what to do in this area.
> - B6. Copy to the clipboard doesn't work (though pasting from the

clipboard
>   does work).

What does a +clipboard trace show? Does the demo app show this?
> - B7. Attempting to bring up the right-click context menu causes the app

to
>   hang.

Does the demo app show this? If so, perhaps one of us can get a backtrace
of the deadlock.

thanks -mike

[Mike Hearn]

On Thu, 2003-10-30 at 18:59, Rob wrote:
> Hi Mike,
>
> bug 1541 is still *not* fixed correctly. See when passing in NULL in windows
> to gethostbyname, it is guarenteed to return a list of local IP addresses
> mapped on the box. However, with WINE, passing NULL causes gethostname to be
> passed into gethostbyname and does *not* always return back the list of
> local IP addresses on the box. This may work on some boxes, and not others,
> depending on how the machine is configured and if the DNS lookup on the host
> name resolves to the local IP addresses.

Ah OK, sorry about that, I reopened the bug. Would getifaddrs() do the
trick here? I've not done much work in our winsock code so I can't
really help here.
> whereas if (!name) should use SIOCGIFCONF - SIOCGIFADDR or something...

Could you write a patch perhaps, as you seen to know what needs to be
done.
> Jerry's patch *does* fix the UI issues actually - B1 through B4 - any idea
> why it isn't applied to the CVS tree? We have the version out of CVS, which
> definately has issues with B1-B4.

I'm not sure. It might have broken other apps, the window management
code is extremely tricky to get right but Alexandre is the expert here.

thanks -mike

[Rob]

Hi Mike,
> > bug 1541 is still *not* fixed correctly. See when passing in NULL in

windows
> Ah OK, sorry about that, I reopened the bug. Would getifaddrs() do the
> trick here? I've not done much work in our winsock code so I can't
> really help here.

Likely, I don't know the correct cross-platform *nix way of doing it. I only
saw source from a STUN server on vovida.org which does SIOCGIFCONF - but I
don't know if that is proper way of doing it. Basically, it must return all
local IPs on the box, if getifaddrs on *nix does that - then it will work.
> Could you write a patch perhaps, as you seen to know what needs to be
> done.

I would do so if I know what I were doing when it came to doing it the right
cross-platform-*nix way. I'd more likely introduce more issues than solve,
or introduce some kind of compilation issue on various *nix platforms. My
background is from windows, so I'm not sure the correct way of doing it on
*nix.
> I'm not sure. It might have broken other apps, the window management
> code is extremely tricky to get right but Alexandre is the expert here.

I can only imagine how tricky this is... However, the current way is
definitely broken too - I guess it's the lesser of the two broken evils...
Our application is basically useless on WINE without Jerry's fix.

-Rob

[Jerry Jenkins]

Rob wrote:
> Jerry's patch *does* fix the UI issues actually - B1 through B4 - any idea
> why it isn't applied to the CVS tree? We have the version out of CVS,

which
> definately has issues with B1-B4.

I know it fixes B1, B2, and partially B4, but I'm not so sure about B3.
WINAMP still has issue B4 even with my patch applied.

The patch is a little tricky :-). I intended to place a button on the
taskbar for a popup window. M$'s document says application windows and popup
windows which not owned will be displayed on the taskbar - When I open the
web page today, I found it says a button is placed on the taskbar for a
windows that isn't owned without mentioning that it has WS_POPUP style,
seems my mistake. As I happened to know that a managed window on WINE is
displayed on the taskbar and noticed that WINDOWS wouldn't change a popup
window's style to have it displayed on the taskbar, I changed these windows'
managed state. But I am not sure that it is the right way to get things
work.

[Rein Klazes]

On Thu, 30 Oct 2003 10:59:40 -0800, you wrote:
> Hi Mike,
>
> bug 1541 is still *not* fixed correctly. See when passing in NULL in windows
> to gethostbyname, it is guarenteed to return a list of local IP addresses
> mapped on the box. However, with WINE, passing NULL causes gethostname to be
> passed into gethostbyname and does *not* always return back the list of
> local IP addresses on the box.

When I implemented the case that name == NULL ( another call for help, I
wasn't aware of your bug report, sorry), the only reference I could find
was this:

| If null is provided in the name parameter, the returned string is the same
| as the string returned by a successful gethostname function call.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win...

Small detail: gethostbyname does not return a string, but this is what I
guessed the intention of the writer was.

Can you point to any documentation where this guarantee is specified?

Rein.

[Rob]

Hi Rein,
> When I implemented the case that name == NULL ( another call for help, I
> wasn't aware of your bug report, sorry), the only reference I could find
> was this:
>
> | If null is provided in the name parameter, the returned string is the

same
> | as the string returned by a successful gethostname function call.

I can't remember where I saw it (as I have been developing with winsock for
years), all I do know that it's well known among windows winsock developers.
In fact, since passing gethostname into gethostbyname is guarenteed to
return back local IPs in Windows, you can therefor logically deduce that
passing in NULL guarentees that local IPs are returned as well. In fact, I
would say you should be checking for NULL and return back local IPs AND you
should also do your own call to gethostname and if that equals the string
passed into gethostbyname, then you should return a list of local IPs as
well. On *nux, this behaviour is not guarenteed, like it is on Windows.

Our application relies on this behaviour to function under all OSes (98
through XP). If Microsoft were to change how this worked, it would break our
application and many others. Only on Windows CE do we have to pass the
results of gethostname() into the function to get correct results as WinCE
doesn't like NULL. WinCE has many conflicts with the Win32 API - so this
isn't surprising. We can pass in the results of gethostname into the
function and it will return local IPs as well - the trouble is that on Linux
gethostname passed into gethostbyname doesn't always work as it does in
windows (i.e. returning back local IPs). Certainly, documented or not, the
results from passing in NULL should be identical to the windows platform.

One more thing, 127.0.0.1 is filtered in the results when passing in NULL -
at least on Windows 2000. It's a safe bet to screen for it since any
developer would have to anticipate the loopback address missing from the
results even if other Win OSes included the loopback (which is doubtful they
return this result either).

-Rob

-----Original Message-----
From: Rein Klazes [mailto:[e-mail]]
Sent: October 31, 2003 3:01 AM
To: [e-mail]
Cc: Mike Hearn; [e-mail]
Subject: Re: UI bugs hampering porting effort for shaped window

On Thu, 30 Oct 2003 10:59:40 -0800, you wrote:
> Hi Mike,
>
> bug 1541 is still *not* fixed correctly. See when passing in NULL in

windows
> to gethostbyname, it is guarenteed to return a list of local IP addresses
> mapped on the box. However, with WINE, passing NULL causes gethostname to

be
> passed into gethostbyname and does *not* always return back the list of
> local IP addresses on the box.

When I implemented the case that name == NULL ( another call for help, I
wasn't aware of your bug report, sorry), the only reference I could find
was this:

| If null is provided in the name parameter, the returned string is the same
| as the string returned by a successful gethostname function call.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win
sock/gethostbyname_2.asp

Small detail: gethostbyname does not return a string, but this is what I
guessed the intention of the writer was.

Can you point to any documentation where this guarantee is specified?

Rein.
--
Rein Klazes
[e-mail]

[Rein Klazes]

On Thu, 30 Oct 2003 10:59:40 -0800, you wrote:
> Hi Mike,
>
> bug 1541 is still *not* fixed correctly. See when passing in NULL in windows
> to gethostbyname, it is guarenteed to return a list of local IP addresses
> mapped on the box. However, with WINE, passing NULL causes gethostname to be
> passed into gethostbyname and does *not* always return back the list of
> local IP addresses on the box. This may work on some boxes, and not others,
> depending on how the machine is configured and if the DNS lookup on the host
> name resolves to the local IP addresses.

After an experiment on win2k is don't see any difference in the result
of gethostbyname(NULL) and gethostbyname(name_returned_by_gethostname).
Each returns a single struct hostent, which contain a list of ip
addresses.
> whereas if (!name) should use SIOCGIFCONF - SIOCGIFADDR or something...

How sure are you that the problem does not lie with the
gethostbyname(name_returned_by_gethostname) part?

On my system everything works as expected: I get a list of all ip
addresses. That is with valid /etc/hostname and /etc/hosts entries.

What systems go wrong?

Rein.

[Rob]

hi Rein,
> On my system everything works as expected: I get a list of all ip
> addresses. That is with valid /etc/hostname and /etc/hosts entries.

That's the trouble. Not every *nux box has the correct results - some do
(like yours) - in fact I'd say many do not. We have done many Linux and
Lindows installs, and none of them had the correct settings in /etc/hostname
and /etc/hosts by default, except one. Incomplete install/configuration or
not, the trouble is that windows guarantees this behaviour and *nix does
not. In the real world, the results are lucky at best we get the correct
results. Those who have tried our product offsite running under WINE run
into the same issue - over and over, the results from gethostname passed
into gethostbyname do not work as it does under windows all of the time.
Worse, they sometimes return the external IP instead of internal IP
addresses. Since we are a windows app - we can't adjust ourselves to bogus
set up /etc/hostname configurations since we have no specific knowledge we
are running under a *nix flavour (as we should not). In order to be
compatible, you MUST guarantee the results from passing NULL or
gethostbyname return a list of local IPs using a different method than
/etc/hostname and /etc/hosts which isn't working right on all *nix machines.
Seems that most people with external IPs had the correct results, but most
people with internal IPs did not. This isn't always the case, but seems to
be a common theme.

-Rob

[Rein Klazes]

On Fri, 31 Oct 2003 09:50:48 -0800, you wrote:
> hi Rein,
> > On my system everything works as expected: I get a list of all ip
> > addresses. That is with valid /etc/hostname and /etc/hosts entries.
>
> That's the trouble. Not every *nux box has the correct results - some do
> (like yours) - in fact I'd say many do not. We have done many Linux and
> Lindows installs, and none of them had the correct settings in /etc/hostname
> and /etc/hosts by default, except one. Incomplete install/configuration or
> not, the trouble is that windows guarantees this behaviour and *nix does
> not. In the real world, the results are lucky at best we get the correct
> results. Those who have tried our product offsite running under WINE run
> into the same issue - over and over, the results from gethostname passed
> into gethostbyname do not work as it does under windows all of the time.
> Worse, they sometimes return the external IP instead of internal IP
> addresses. Since we are a windows app - we can't adjust ourselves to bogus
> set up /etc/hostname configurations since we have no specific knowledge we
> are running under a *nix flavour (as we should not). In order to be
> compatible, you MUST guarantee the results from passing NULL or
> gethostbyname return a list of local IPs using a different method than
> /etc/hostname and /etc/hosts which isn't working right on all *nix machines.
> Seems that most people with external IPs had the correct results, but most
> people with internal IPs did not. This isn't always the case, but seems to
> be a common theme.

Uhh, I've seen several other windows programs that did not rely on the
NULL feature, perhaps because it is documented poorly. These programs do
gethostname() and then gethostbyname(). We will probably need a check in
the gethostbyname path to catch those programs as well.

In short: even a native linux program that does gethostname() ->
gethostbyname() is unlikely to get you these days something else then
127.0.0.1 Dhcp clients whose information is not available is one cause I
think.
Circumventing that when the program is running under wine is the
challenge.

Rein.

[Rob]

> Uhh, I've seen several other windows programs that did not rely on the
> NULL feature, perhaps because it is documented poorly. These programs do
> gethostname() and then gethostbyname(). We will probably need a check in
> the gethostbyname path to catch those programs as well.

Correct, NULL and gethostname passed into gethostbyname are supposed to
operate identically. Hence either way is supposed to be valid. Yes, it is
documented poorly. Regardless, the correct thing to do is check if the
string passed into gethostbyname matches the result from gethostname OR the
string passed is NULL - if it does match or is NULL - then return a list of
local IP addresses. This will ensure applications running under WINE, using
either the NULL or gethostname method operate as expected, even if native
*nix applications can't rely on that behaviour.

-Rob