Hi,
I'm attempting to set up a OSX testbot and I'm currently trying to get as many tests to work as possible. The following is a list of tests that fail currently. I'm hoping for comments if anybody knows more about them:
(This is a 2006-era iMac, OSX 10.6, using the stock X server)
dinput8/device.c
device.c:87: Test failed: We're not able to inject input into Windows dinput8 with events Fails sometimes, succeeds sometimes.
gdi32/dc user32/monitor
No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for that already. Should we change it to skip(), or ignore it until we have a quartz driver? User32/monitor also fails because it can't change the display mode.
kernel32/change ntdll/change ntdll/directory
Lots of test failures. I'm not sure what those tests do tbh
ntdll/exception
"Test failed: Execution of data memory succeeded." Do I have to do anything special to enable NX support on OSX?
mmdevapi/capture
Various Set*Volume calls fail
tests/shlexec
Random failure: "shlexec.c:1023: test failed: Expected success (33), got failure (11), lpFile: C:\users\pts\Temp\wtb6bf.tmp\test file.shlexec"
urlmon/url
winmm/mci
Test failed: mci resume waited Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close)
ddraw/visual d3d8/visual d3d9/visual
I'll investigate those. I bet they are GPU dependent.
ws2_32/sock
A mixture of test failures and unexpected successes.
ddraw/d3d
The window message test can't cope with the resolution change failure. I'll fix it. Using a virtual desktop works around the problem
ddraw/dsurface
Crashes sometimes during cleanup in fbo-related GL calls.
d3dx9_36/math d3dx9_36/texture
I just sent patches for those. There was an issue with NaN sign bits and some GPU limitations the tests didn't account for.
On Sep 20, 2011, at 3:11 PM, Stefan Dösinger wrote:
gdi32/dc user32/monitor
No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for that already. Should we change it to skip(), or ignore it until we have a quartz driver? User32/monitor also fails because it can't change the display mode.
Key words: "stock X11 server". XQuartz has much better support for this. You should be using that.
kernel32/change ntdll/change ntdll/directory
Lots of test failures. I'm not sure what those tests do tbh
I wrote a message to the list about fixing those tests once. The problem is that the functionality they test (well, at least the */change tests) isn't implemented on Mac. And none of our options for implementing it look good (c.f. "Failing kernel32:change and ntdll:change tests on Mac OS").
ntdll/exception
"Test failed: Execution of data memory succeeded." Do I have to do anything special to enable NX support on OSX?
No. It's just that the kernel for some reason only supports NX on stacks in 32-bit code. They fixed it in Mac OS 10.7.
mmdevapi/capture
Various Set*Volume calls fail
I know that some CoreAudio devices actually don't have software volume controls. Optical out, for example. For these devices, Set*Volume will always fail. Not sure if that's what 's happening in your case, though.
ws2_32/sock
A mixture of test failures and unexpected successes.
From what I can tell, Wine's WinSock implementation seems to depend on several nuances of Linux's BSD sockets implementation that are different from the original 4.xBSD implementation (from which most others, including WinSock itself, are derived).
Hope that helps.
Chip
On Tue, 20 Sep 2011, Charles Davis wrote:
On Sep 20, 2011, at 3:11 PM, Stefan Dösinger wrote:
gdi32/dc user32/monitor
No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for that already. Should we change it to skip(), or ignore it until we have a quartz driver? User32/monitor also fails because it can't change the display mode.
Key words: "stock X11 server". XQuartz has much better support for this. You should be using that.
That's what I have been told too so I documented it there: http://wiki.winehq.org/ConformanceTests#MacOSX
However XQuartz 2.6.3 (the latest) would systematically become 'non responsive' at some random point during the tests on my Leopard Mac Mini (GMA 950 graphics). So I downgraded to XQuartz 2.6.1 which at least lets me complete the WineTest run.
[...]
mmdevapi/capture
Various Set*Volume calls fail
I know that some CoreAudio devices actually don't have software volume controls. Optical out, for example. For these devices, Set*Volume will always fail. Not sure if that's what 's happening in your case, though.
My Mac Mini uses an optical audio connection and indeed I cannot set the volume on the Mac. Yet I have no failures in mmdevapi/capture (or in any other sound test for that matter).
ws2_32/sock
A mixture of test failures and unexpected successes. From what I can tell, Wine's WinSock implementation seems to depend on several nuances of Linux's BSD sockets implementation that are different from the original 4.xBSD implementation (from which most others, including WinSock itself, are derived).
That's my impression too given that it fails on Solaris and FreeBSD too (quite a paradox as that should be the original 'BSD sockets' <g>).
Note also that the firewall will also ask whether to allow incoming network access for some of the tests. I would really like information on how to best deal with that.
Also the OOB tests are not reliable at all, even on Windows, so this test won't be reliable anywhere until that's fixed: http://test.winehq.org/data/tests/ws2_32:sock.html
On Sep 21, 2011, at 2:58 AM, Francois Gouget wrote:
Note also that the firewall will also ask whether to allow incoming network access for some of the tests. I would really like information on how to best deal with that.
That sounds like Mac OS X's application firewall which is Apple's primary firewall instead of a more traditional packet filtering firewall. The application firewall is based around which local applications and services are trusted to accept in-bound connections rather than which external sources are trusted to deliver packets. From a security standpoint, I'm not sure that's a good approach, but it is what it is.
For what it's worth, Mac OS X still has ipfw or, with Lion, PF, so you can enable/configure that and disable the application firewall, if you want. You can disable the application firewall in System Preferences > Security > Firewall. There's no built-in GUI for enabling or configuring the packet filtering firewall, so you have to use the command line or third-party tools.
Anyway, the application firewall is based on code-signing. The user's permission to allow a program to accept incoming connections is tied to the program's signature. If a program wasn't code-signed by its vendor, then the system will ad-hoc sign it. If a program changes in a way that invalidates its signature, then the past permission is ignored and the system asks again. For ad-hoc-signed programs, just about any change will invalidate its signature.
Since regularly testing Wine entails constantly rebuilding it, the signature never survives for long and the system asks for permission with every new build.
Regards, Ken
On Wed, 21 Sep 2011, Ken Thomases wrote: [...]
That sounds like Mac OS X's application firewall which is Apple's primary firewall instead of a more traditional packet filtering firewall. The application firewall is based around which local applications and services are trusted to accept in-bound connections
[...]
You can disable the application firewall in System Preferences
Security > Firewall.
Yes that's the one that brings up this dialog. For instance if I run ws2_32:sock with the firewall enabled I get asked whether I want to allow 'wineserver' (!) to accept incoming network connections. Interestingly if I don't answer and look into the firewall configuration after ws2_32_test.exe is done, I see that wineserver did got added with 'Block incomming connections'. So in the next run I am not asked that question again but then the connections are presumably really blocked.
A related question is whether it is actually known to have an impact on the test results or not. Again, looking at the ws_32:sock results I saw no difference, even over multiple runs. Looking at the full results of a pair of runs on winetest.org the only difference I saw is an unrelated failure in d3d9:device.
http://test.winehq.org/data/b6153354dd28c57fb1f92f85df1f1ba751794fc1/index_M...
Is what's saving us that the firewall always allows connections originating from the local IP address (e.g. 192.168.0.42 to 192.168.0.42)?
Windows XP / Vista / 7 pop up similar dialogs and I don't know if they cause trouble either. I suspect not and this may be the reason why too.
Anyway, the application firewall is based on code-signing. The user's permission to allow a program to accept incoming connections is tied to the program's signature.
[...]
Since regularly testing Wine entails constantly rebuilding it, the signature never survives for long and the system asks for permission with every new build.
Exactly. So should the application firewall be causing trouble, the only solution would be to disable it :-( I guess there's no way to automatically authorize / sign the application?
On Wednesday 21 September 2011 12:59:17 Francois Gouget wrote:
I guess there's no way to automatically authorize / sign the application?
I think that would defeat the purpose of such a firewall.
On Sep 21, 2011, at 5:59 AM, Francois Gouget wrote:
On Wed, 21 Sep 2011, Ken Thomases wrote:
Anyway, the application firewall is based on code-signing. The user's permission to allow a program to accept incoming connections is tied to the program's signature.
[...]
Since regularly testing Wine entails constantly rebuilding it, the signature never survives for long and the system asks for permission with every new build.
Exactly. So should the application firewall be causing trouble, the only solution would be to disable it :-( I guess there's no way to automatically authorize / sign the application?
You can, but it requires a digital certificate. I don't know if a self-signed certificate can be used. I think they can to a certain extent. A program signed with a self-signed certificate will allow for the application firewall to recognize it as the same program which was previously granted permission by the user. It would require a certificate traceable to a trusted root certificate for the application firewall to _implicitly_ trust the program and not require even the initial permission from the user.
The command-line tool to do the code-signing is "codesign". There's a man page, of course, and also Apple's documentation: https://developer.apple.com/library/mac/documentation/Security/Conceptual/Co...
-Ken
On Wed, 21 Sep 2011, Francois Gouget wrote: [...]
A related question is whether it is actually known to have an impact on the test results or not. Again, looking at the ws_32:sock results I saw no difference, even over multiple runs. Looking at the full results of a pair of runs on winetest.org the only difference I saw is an unrelated failure in d3d9:device.
http://test.winehq.org/data/b6153354dd28c57fb1f92f85df1f1ba751794fc1/index_M...
Is what's saving us that the firewall always allows connections originating from the local IP address (e.g. 192.168.0.42 to 192.168.0.42)?
I have done some tests with netcat that confirm this theory for Mac OS X Leopard, Windows XP and Windows 7 (so I guess it also holds for Windows 2003, Vista and 2008). That's one less worry. I have updated the Wiki accordingly.
On Wednesday 21 September 2011 02:29:31 Charles Davis wrote:
No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for that already. Should we change it to skip(), or ignore it until we have a quartz driver? User32/monitor also fails because it can't change the display mode.
Key words: "stock X11 server". XQuartz has much better support for this. You should be using that.
Indeed, Xquartz supports Xrandr these days. Unfortunately the GammaRamp tests still fail. Either There's no Xvidmode(afaik there's no gamma in xrandr), or it doesn't work.
I also wondered if Xquartz brings it's own X11 headers and libraries. I haven't found any, so I'm still using /usr/X11/include and /usr/X11/bin.
On Sep 21, 2011, at 3:35 PM, Stefan Dösinger wrote:
On Wednesday 21 September 2011 02:29:31 Charles Davis wrote:
No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for that already. Should we change it to skip(), or ignore it until we have a quartz driver? User32/monitor also fails because it can't change the display mode.
Key words: "stock X11 server". XQuartz has much better support for this. You should be using that.
Indeed, Xquartz supports Xrandr these days. Unfortunately the GammaRamp tests still fail. Either There's no Xvidmode(afaik there's no gamma in xrandr), or it doesn't work.
I thought Xrandr 1.2 and up supported gamma control (see XRRCrtcGamma struct and XRR*Gamma functions in <X11/extensions/Xrandr.h>).
I also wondered if Xquartz brings it's own X11 headers and libraries. I haven't found any, so I'm still using /usr/X11/include and /usr/X11/bin.
Xquartz puts its include and lib files in /opt/X11/include and /opt/X11/lib, respectively.
Chip
On Wed, 21 Sep 2011, Charles Davis wrote: [...]
I also wondered if Xquartz brings it's own X11 headers and libraries. I haven't found any, so I'm still using /usr/X11/include and /usr/X11/bin.
Xquartz puts its include and lib files in /opt/X11/include and /opt/X11/lib, respectively.
That does not sound right. I have installed XQuartz 2.6.1 on my Leopard machine and I have no /opt/X11 directory. In fact I don't really know where XQuartz installed itself. I suspect it overwrote the files in /usr/X11.
I have /Applications/Utilities/X11.app but that looks more like Apple's X server and it does not contain any Xlib.h file for instance.
Actually, the Xlib.h files I have are:
/System/Library/Frameworks/Tk.framework/Versions/8.4/Headers/X11/Xlib.h /usr/X11/include/X11/Xlib.h
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Tk.framework/Versions/8.4/Headers/X11/Xlib.h /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/X11/Xlib.h /Xcode2.5/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Tk.framework/Versions/8.4/Headers/X11/Xlib.h /Xcode2.5/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/X11/Xlib.h
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Tk.framework/Versions/8.4/Headers/X11/Xlib.h /Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/X11/Xlib.h
MacPorts: /opt/local/include/X11/Xlib.h /opt/local/var/macports/software/xorg-libX11/1.4.3_0/opt/local/include/X11/Xlib.h
22 sep 2011 kl. 11:49 skrev Francois Gouget:
On Wed, 21 Sep 2011, Charles Davis wrote: [...]
I also wondered if Xquartz brings it's own X11 headers and libraries. I haven't found any, so I'm still using /usr/X11/include and /usr/X11/bin.
Xquartz puts its include and lib files in /opt/X11/include and /opt/X11/lib, respectively.
That does not sound right. I have installed XQuartz 2.6.1 on my Leopard machine and I have no /opt/X11 directory. In fact I don't really know where XQuartz installed itself. I suspect it overwrote the files in /usr/X11.
The Leopard releases go into /usr/X11 (can't remember the exact reason). Starting with Snow Leopard they go into /opt/X11.
If you installed it using macports it probably goes into /opt/local. Try sudo port contents xorg-server in that case.
Regards,
On Sep 22, 2011, at 4:49 AM, Francois Gouget wrote:
On Wed, 21 Sep 2011, Charles Davis wrote: [...]
I also wondered if Xquartz brings it's own X11 headers and libraries. I haven't found any, so I'm still using /usr/X11/include and /usr/X11/bin.
Xquartz puts its include and lib files in /opt/X11/include and /opt/X11/lib, respectively.
That does not sound right. I have installed XQuartz 2.6.1 on my Leopard machine and I have no /opt/X11 directory. In fact I don't really know where XQuartz installed itself. I suspect it overwrote the files in /usr/X11.
XQuartz installs differently on Leopard vs. later versions of the OS. On Leopard, it was considered the upgrade path for the built-in X11, so it does replace it. On later versions of the OS, the built-in X11 is considered a system component which is only upgraded by Software Update, and then only rarely for things like security updates. It's intended to be a stable component of the system. XQuartz installs in a separate location, /opt/X11, so as not to interfere with the built-in X11 or anything which relies on it.
-Ken
-
Charles Davis -
Francois Gouget -
Ken Thomases -
Per Johansson -
Stefan Dösinger