World Wine News

You can run Linux along with Windows: You can run Linux along with Windows on a different partition. You can boot to Windows wherever you want. It is also possible to run Linux in Windows using emulator software like VMWare or MS Virtual PC. Likewise, it is also possible to run Windows applications in Linux using emulators like Wine (This Wine is different!).

That's all true. Even though your mileage may vary when trying to run Windows software under Wine.

Hi,
The Wine tests are now passing on a Windows XP machine (http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group_XP). Two of the other four only have 2 or 3 failures.

The 2003 group has 3 machines with 1 failure each (urlmon:protocol on one, user32:menu on the others).

Congratulations to everyone involved fixing the tests!

- Reece

Wow, that's awesome! A day seven years in the making...

2002: the C test suite is started:
http://source.winehq.org/git/wine.git/?a=commit;h=caa03388bcccc64f444f9b4ef664ec5039d5bf72

2003: winetest committed:
http://www.winehq.org/wwn/199#Winetest%20Integrated%20&%20Future%20Steps

2004: server to build winetest and parse winetest results set up
http://www.winehq.org/wwn/216#A%20Distributed%20Test%20Environment

2009: the test suite passes for somebody besides Alexandre on Wine:
http://www.winehq.org/wwn/355#Test%20Suite%20Passes!

Anyone have a graph of test suite size vs. time?

It's not the first one though. We had one or two the last weeks. The biggest problem besides getting to 0 is consistency.

Have a look at Alasdair's Wine box. It succeeded a few times but also has tests that intermittently fail. The same is true for a lot of Windows boxes.

Nonetheless, we are in a far better position than a few months ago. And after Juan's batch it will be even better.

Having a low rate of failures also lowers the burden for people to fix the last remaining ones instead of staring at a red page ;)

Just some numbers for my W95, W98, NT4, W2K, W2K3 and Vista boxes:

June-24-2008 : 21.7% test failures
Aug-26-2008 : 19.7%
Nov-14-2008 : 9.8%
And yesterday : 6.1%

--
Cheers,

Paul.

Actually, that was not the first time. On 20 Jan an XP machine passed: http://test.winehq.org/data/e9d8c9f572998054b1f9c386ea81a3570c65f2d2/#group_ XP
And on 27 Jan a 2003 machine: http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/#group_2003

Well, sort of. I found bugs in shell32, rpcrt4, comctl32 and wininet that I had to implement, stub and override my way past before it would render a page, but finally, here's the obligatory screenshot.

I have attached a script that identifies functions that should be made static (among other things). There are approximately 450 of them, there should be pretty few false positives, and I will look into them eventually. But if someone beats me to it I sure won't complain *g*.

So if you do try to tackle them you are likely to find that they fall into one of the following categories:

1) Unused debug functions.
For instance for dumping the contents of a structure to stderr. Although these are unused we probably want to keep them. Let me know about these and I will put them in an exception list.

2) Functions that should be exported by a spec file
It happens. Sometimes the developer implementing a function just forgets to add it to the spec file!

3) Generated functions
This typically happens with widl: it generates a bunch of functions for the client / server and proxy cases, but these functions may be unused. I have special code to not warn about these, but there may be other cases. For instance in the list below you will find a number of yy*() functions generated by lex. Either we can tell lex to make them static or to not generate them, or I should make another special case. If you find some of these, let me know.

4) Assembly functions
I believe there should not be any of these in the list below. So if you find one let me know.

5) Functions declared in a private header file but implemented and used from a single C file.
I'm in favor of removing these functions from the private header and making them static.

6) All the others should be pretty clear-cut.

hi folks, i promised i'd get python built under wine - and i'm happy to report that this goal has been successfully achieved.

http://bugs.python.org/issue4954 if anyone's interested. what has been achieved is that a python.exe, libpython2.5.dll, an implib libpython2.5.dll.a and a python2.5.def have all been successfully created using an entirely free software toolchain, along with the dynamic libraries (such as pyexpat.pyd - python for win32's convention is .pyd not .so).

running the regression testing has been... interesting :) several bugs in wine have been detected, along with faults in the header-files that need to be corrected. tmpfile() is faulty; MAX_LONG and MIN_INT #defines cause problems; the default file format CRLF instead of LF causes the builtin regression test to fail; _ctypes _utterly_ borks on c structure creation and manipulation but is using assembly-stuff (a copy of libffi is included in python) - there are a few more, but out of 350 tests, the majority of them succeed. amazingly.

anyway, the point of this message is primarily to let people know that this successful compile shows just how far along wine is coming, and it's like a really big hairy deal that python can now be compiled for win32 platforms, for native use on windows or on wine, _without_ having to have a proprietary operating system or a proprietary compiler to do it.

now it's possible to port things like pygtk2, pyqt4, pywebkit-gtk and numpy to win32 etc. (because of the header files and the implibs) - again, _without_ requiring proprietary technology. which is absolutely fantastic.
thank you to everyone on the wine team.
l.

All,

So it seems to be almost every other day now when somebody mentions how broken the appdb rating system is. This "broken-ness" has had several high level discussions on Wine-Devel. There have also been many, many proposed solutions to this problem.

I do not wish to discuss these problems or these solutions in this thread. It is time something was done about this. By done I mean agreed upon (probably the harder part) then implemented in code and published to the winehq server(s).

I'd like to arrange an IRC discussion for all those interested in finalizing an attack plan, and then assigning the responsibility of doing it to somebody who is capable and has the time (perhaps myself).

Lets (arbitrarily) set a time for the chat at:

When: 11PM UTC (6PM EST) 2/6/09 (Friday)
Where: #winehackers

If this arbitrary time seems to be poorly chosen for a large number of people then please propose an alternative well in advance so all are aware of it.

--Zach

I have made a wiki on winehq with an agenda which will be updated with the results (and maybe transcript?) of the conversation. https://wiki.winehq.org/AppDBUpgrades