UI bugs hampering porting effort for shaped window
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.
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.
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(a)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 <rklazes(a)xs4all.nl> _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
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: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org]On Behalf Of Mike Hearn Sent: October 30, 2003 1:22 AM To: wine-devel(a)winehq.com 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(a)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 <rklazes(a)xs4all.nl> _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
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
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
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.
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. -- Rein Klazes rklazes(a)xs4all.nl
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:rklazes(a)xs4all.nl] Sent: October 31, 2003 3:01 AM To: cto(a)xten.com Cc: Mike Hearn; wine-devel(a)winehq.com 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 rklazes(a)xs4all.nl
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. -- Rein Klazes rklazes(a)xs4all.nl
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
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. -- Rein Klazes rklazes(a)xs4all.nl
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
participants (4)
-
Jerry Jenkins -
Mike Hearn -
Rein Klazes -
Rob