Table Of Contents
|1.||(4 posts)||News: Beta Release, CrossOver Office 5.0|
|2.||(7 posts)||Beyond 0.9|
|3.||(4 posts)||Winecfg Drive Config Problem|
|4.||(11 posts)||Bugzilla: Closing Bugs|
|5.||(1 post)||Solaris Patches|
|6.||(1 post)||Dragon Naturally Speaking (v7) Recipe|
|7.||(4 posts)||Wine & Windows Vista Graphics Drivers|
This is the 297th issue of the Wine Weekly News publication. Its main goal is to celebrate a beta release! It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)
Mailing List Stats For This Week
We looked at 315 posts in 572K.
There were 110 different contributors. 61 posted more than once. 39 posted last week too.
The top posters of the week were:
1. News: Beta Release, CrossOver Office 5.0
(4 posts) Archive Link: "News"
People: Alexandre Julliard,�OSNew,�CodeWeavers,�Microsoft,�Slashdot,�News,�codeweavers,�Jeremy White,�DesktopLinux.com,�cvs
Do we really need to say what the headline is this week? Wait for it.. wait for it..
In the past, Wine releases followed a standard format. About every month Alexandre would release a CVS snapshot with the format of YYYYMMDD, such as wine-20050930. Those CVS snapshots were just that: a point in time where everything in CVS was tagged. Often those releases saw the bare minimum of testing, such as running the Wine test suite against it.
We're in different territory now. The beta release saw quite a few people hammer on it for almost a month before it was released. Bugs in Bugzilla were tracked, reviewed, and fixed.
Here's Alexandre announcement:
This is release 0.9 of Wine, a free implementation of Windows on Unix. After 12 years of development, this release marks the beginning of the beta testing phase. Everybody is encouraged to try it; while there are still bugs, most applications are expected to at least install and do something useful.
Because of lags created by using mirrors, this message may reach you before the release is available at the ftp sites. The sources will be available from the following locations:
Binary packages for various distributions will be available from:
You will find documentation on http://www.winehq.org/site/documentation.
You can also get the current source directly from the CVS tree. Check http://www.winehq.org/cvs for details.
Patches should be submitted to "email@example.com (mailto:firstname.lastname@example.org) ". Please don't forget to include a ChangeLog entry. If you submitted a patch, please check to make sure it has been included in the new release.
Wine is available thanks to the work of many people. See the file AUTHORS in the distribution for the complete list.
That AUTHORS file, by the way, was updated for this release and now contains 797 individuals.
We had an official press release (http://www.winehq.org/site/pr-09betarelease) about it. It's nice, light reading. I also put together a special edition of WWN, #296 (http://www.winehq.com/?issue=296) , to look at more of the technical background behind Wine 0.9. We've been on the verge of a beta release for a number of years and it seems like there's been some rather amorphous goals that were set to reach it. Well, we actually have a pretty good record of the major projects tackled over the past six years so I took a look back and summarized what some of the critical ones for the beta release were.
In other big news, CodeWeavers released CrossOver Office 5.0 on the same day. There's definitely a lot of new stuff under the hood with this release; a lot of which can be found in Wine 0.9. As usual, Jeremy White's announcement (http://crossover.codeweavers.com/pipermail/announce/2005-October/000030.html) is more interesting reading than the official press release (http://www.codeweavers.com/about/general/press/?id=20051025) . Outside of things like the window manager rewrite and other technical things, the big news here is Microsoft Office 2003 support. You can also find a new thing, bottles (http://www.codeweavers.com/products/cxoffice/bottles/) , that let you install applications into their own virtual Windows drive. Each bottle can contain its own custom configuration. Then you can package it up into and RPM for installation elsewhere.
Go buy it (http://www.codeweavers.com/store/?cat=cxof) now and give yourself the warm, fuzzy feeling of supporting free software development.
The media picked up on both of these items and over the next few weeks we'll definitely track that. Here's some of the ones I happened to notice this week (let me know if you see more):
One topic appearing on a lot of the discussion forums was what exactly a beta release means since a lot of people have been using Wine for a long time. Well, my $.02 is that we're no longer planning any big projects that will steal your lunch money. In the past we had things on the to-do list like "window management rewrite". Well, we knew that would break a lot of things. We don't really have anything like that on the list now. Sure, there's going to be some huge additions to individual DLL's that will certainly cause regressions, but hopefully those can just be worked out.
2. Beyond 0.9
(7 posts) Archive Link: "Talkback versions of wine"
Topics: Project Management
People: Alexandre Julliard,�Juan Lang,�Jonathan Wilson,�Mike McCormack
After 0.9 was released, the floodgates opened and lots of patches poured in. Notable additions included a ton of MSI improvements by Mike McCormack, more crypt32 work by Juan Lang, and oleaut32 additions from Alex Villac�s Lasso. You can expect a lot of additions in the near future as developers complete patches they've been working on during the past few weeks of freeze.
While the core internals of Wine are now complete, there remains a lot of work fleshing out various DLL's. In the course of discussion, Alexandre mentioned some of the things that need to get fixed before 1.0:
we still have a lot of work to do on usability issues (winecfg, desktop mode, cdrom support, systray, etc.), and we need better support for the various code obfuscation tools, it's probably the number one cause of apps not even starting today.
Jonathan Wilson asked if that last item meant support for Safedisc, Securom and other copy protection methods. Alexandre replied, " As far as possible, yes. I think the goal for 1.0 should be that anybody has to be able to try Wine and see that it's for real. This means they must not be stopped either by not being able to configure it, or by apps failing to even start."
In case you missed it, that's our roadmap for the next few months.
3. Winecfg Drive Config Problem
(4 posts) Archive Link: "winecfg dosdevices unusable"
People: email@example.com,�firstname.lastname@example.org,�Vitaliy Margolen
Someone ran into a problem using winecfg's drive configuration:
just getting into a fresh installation with 0.9
ran up winecfg and tried to add a device for my dvd burner.
editing the device name is unusable. No cursor , then after a first character is entered the edit seems to jump to insert mode and puts the cursor at the begingin of the line. There seems no way enter text normally to enter a device name.
This whole interface seems badly broken. I had to fall back to good old command line to sort out the mess made by winecfg and add the devices I need.
Someone else also noticed it and provided the workaround:
I noticed this as well last night when I was testing some Windows programs for compatibility. I'm glad Wino mentioned it here, because I almost forgot.
I went into the dosdevices directory and set up the links manually, because it's real hard to get non-fubar'd results with winecfg.
Vitaliy Margolen suggested just using the Browse button since it will fill in the appropriate entry.
4. Bugzilla: Closing Bugs
(11 posts) Archive Link: "Thank you for closing my bugzilla account..."
Topics: Project Management
People: Jonathan Ernst,�Dimi Paun,�Vijay Kiram Kamuju,�Ivan Leo Puoti
Digging through Wine's Bugzilla (http://bugs.winehq.org) tracker can be good way to learn things about Wine. Whether that's confirming an unconfirmed bug, finding something small to fix, or simply getting a feel for what areas need to be worked on.
Jonathan Ernst has been wrangling bugs for a few weeks now and was surprised when someone suspended his Bugzilla account:
It was then discussed that bugs that are FIXED and where resolution is not LATER or DUPLICATE or REMIND should be marked CLOSED as the fixes have been integrated in an official release (namely 0.9).
However it seems that ivanleo didn't like my CLOSING session because some of the bugs were not "fixed". Can someone tell me how a bug can be not fixed and marked as resolved-fixed (see my query) ?
Well, that seems to make sense. It's hard to think of a reason to have a ton of active bugs marked as fixed but not closed. That launched a bigger discussion about when and how bugs should get closed. Ivan Leo Puoti, who suspended Jonathan's account, then apologized for doing so but explained he did it because it wasn't clear any of the FIXED bugs had been verified. Well, that's rather hard with any free software project where there's no dedicated staff for QA work. (As opposed to free software projects that do have dedicated staff.) Dimi Paun thought some of the QA steps that would normally be separated should simply be considered combined together:
First, it is the responsibility of the reporter to verify the bug. It is totally unrealistic to think that others will go do the verification -- they lack the software, the context, and the motivation/
Second, we had close to a thousand bugs in that state. They do more harm then good lingering about. If the original reporter can not be bothered to verify it, they should be closed.
Vijay Kiram Kamuju thought another problem was Bugzilla itself made the issue confusing, " there was misunderstanding regarding the bug status, ie, RESOLVED LATER, RESOLVED CLOSED, VERIFIED, etc. It would be better if we could put some details regarding the bug status on the bugzilla or FAQ pages, as there are some differences in the explanation of these. I am used to a different bug management app (ClearDDTS) where there are only 4-5 states a bug can have. (NEW,ASSIGNED,OPEN,RESOLVED,VERIFIED)"
Jonathan gave a link to an explanation of bug statuses (http://bugs.winehq.org/bug_status.html) .
The end result of the discussion was Jonathan got his account restored and a bunch of FIXED bugs were officially CLOSED.
5. Solaris Patches
(1 post) Archive Link: "Solaris Updates"
People: Robert Lunnon
Robert Lunnon began posting a series of patches to get Solaris x86 back on track. Wine strives to be portable to as many architectures as possible, but most of the developers use Linux. As a result a lot of things sneak in that cause problems on other architectures. Fortunately folks like Robert take the time to work out those bugs. He described his series of patches on wine-devel:
I have posted my local patches to wine-patches.
Note that for 0.9 I have posted most of the patches that are likely to be essential to build a working Wine package (other than those previously rejected) regardless of the shape the code is in. Some of it is very ugly and lacks integration for other OSen, I have noted these. Since this code is maintained as a delta from CVS wine specific to Solaris and only used for binary packages, it's not necessary to start out with the niceties all there (This particularly happens when I get deep into week long debugging sessions).
Patches not sent are listed hereunder long with the reasons...
Possibly essential (Show stoppers)
ptrace stub patch
Recommended functionality patches
A complete set of patches (even the gross ones) are maintained at
6. Dragon Naturally Speaking (v7) Recipe
(1 post) Archive Link: "Clean , working installation of Nat. Speaking."
A few months ago Dragon Naturally Speaking was a hot topic on wine-devel. It seems version 8 doesn't really work with Wine, but version 7 can be coaxed into running. Someone (no name given) provided the recipe this week for making it work:
OK, I think I've cracked it.
After a lot of heaving and grunting I managed to reinstall Dragon Naturally Speaking into a fresh user account with the help of sidenet.
This time I carefully documented the steps I took so as to be sure it was reproducable.
That it in a nut shell , here's the log:
INSTALLATION NOTES FOR NATURALLY SPEAKING 7 PREFERED
chown <username> users
bash# ~/.wine $ wcmd
ln -s /mnt/dvd h:
bash # ~/.wine/dosdevices $ fixme:ddeml:DdeConnectList
fixme:ddeml:DdeQueryNextServer (0x1,(nil)): stub
fixme:ddeml:DdeQueryNextServer (0x1,(nil)): stub
fixme:ddeml:DdeDisconnectList (0x1): stub
err:wineboot:runCmd Failed to run command (0)
err:wineboot:ProcessRunKeys Error running cmd #1 (0)
~/.wine/c/Program Files/ScanSoft/NaturallySpeaking/Program $ wine natspeak.exe
"cannot find windows/system/comdlg32 "
$ wine natspeak
Able to complete general training and begin dictation into DragonPad. Excellent results.
HTH, Have fun
7. Wine & Windows Vista Graphics Drivers
(4 posts) Archive Link: "Wine project: Support third party LDDM graphic drivers"
People: Claude Mench,�Microsoft,�Krzysztof Foltman
The topic of using Wine to support various hardware drivers comes up quite a bit. In general, the recommendation is to develop a real Linux driver. This week Claude Mench came up with an interesting idea regarding graphics drivers:
I rencently read a whole lot of MSDN documentation about the LDDM infrastructure. The new Windows graphics vista driver model.
And what made me think we could have support for it in linux.
It seem to me that having the most important parts of the driver being in user mode would really help to use it on other systems.
>From what I read, the user mode driver would create the command buffer that would need to be uploaded to the GPU and a kernel module would need to schedule GPU access handle memory of the GPU and send the command buffer to it.
This would need the Wine Expertise of DirectX reimplementation as well as some good kernel hacker, but in the end maybe the struggle to have linux specific support from Graphics adapter vendors could be one for all removed if we had LDDM driver support and then and X build on top of it (same philosofy as Xgl).
it could also benefit to the wine project itself as we would have really windows driver being used, it should help to increase compatibility.
sorry if it sound crazy...
Well, that's not as crazy as a it seems. The new graphics model in Windows Vista will be completely different than any other version of Windows. Microsoft has a nice, concise description on MSDN:
The display driver model architecture for Microsoft Windows codename "Longhorn" is composed of user-mode and kernel-mode parts. The following figure shows the architecture required to support the Windows Longhorn display driver model. A graphics hardware vendor must supply the user-mode display driver and the display miniport driver. The user-mode display driver is a dynamic-link library (DLL) that is loaded by the Microsoft Direct3D runtime. The display miniport driver communicates with the Microsoft DirectX graphics kernel subsystem. For more information about the user-mode display driver and display miniport driver, see the Windows Codename Longhorn Display Driver Model Reference.
That's a pretty significant change: Direct3D being at the heart of the display. Reaction was mixed on wine-devel. Stefan D�singer was against the idea while Krzysztof Foltman was for it. From there the idea sort of died off.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.