Table Of Contents
|1.||18�Dec�2004�-�24�Dec�2004||(2 posts)||News: CrossOver Office 4.1|
|2.||22�Dec�2004||(7 posts)||Safedisc and ntoskrnl|
|3.||20�Dec�2004||(1 post)||WineTools Updated|
|4.||20�Dec�2004�-�22�Dec�2004||(13 posts)||WINEprobe Initiative|
|5.||21�Dec�2004||(1 post)||File Optimization|
|6.||23�Dec�2004�-�24�Dec�2004||(4 posts)||Launching Apps|
This is the 254th issue of the Wine Weekly News publication. Its main goal is to debate the Christmas Paradox: naughty or nice. 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 131 posts in 425K.
There were 46 different contributors. 25 posted more than once. 25 posted last week too.
The top posters of the week were:
1. News: CrossOver Office 4.1
18�Dec�2004�-�24�Dec�2004 (2 posts) Archive Link: "News"
People: Jeremy White,�Peter Seebach,�CodeWeavers,�,�codeweavers,�News,�developerWorks
CodeWeavers announced CrossOver Office 4.1 (http://crossover.codeweavers.com/pipermail/announce/2004-December/000028.html) this week. You won't find support for any new applications, but there's a ton of bugfixes. As always, CodeWeavers recommends keeping your existing installation if everything is working fine for you. Check out the changlog (http://www.codeweavers.com/site/products/cxoffice/change_log) for a description of the bigger fixes. One of the big problems in 4.0 included high CPU usage for iTunes. It seems that problem has been fixed and responsiveness is greatly improved. Version 4.1 has been slated for quite a few weeks now, but CodeWeavers does quite a bit of QA work before letting something out the door. Apparently this release almost got delayed again at the last minute as Jeremy White explained:
Seriously, we were all ready to go to gold, with the plan being to ship this afternoon, when we got a beta report that made us nervous.
I woke Alexandre up and asked him to look into it, with the hopes that we could understand the issue well enough to go ahead and ship. So we'd either ship in 30 minutes if he figured it out, or we'd ship tomorrow, after working feverishly through the night... <grin>.
But the good news is that Alexandre did figure it out and we shipped
More interesting were Jeremy's comments in the announcement about some of the development on the next version:
You'll be happy to know that we're already hard at work on 5.0, with Office 2003 support. We're also seeing that the major Window management overhaul that Alexandre is in the middle of is addressing a lot of the nasty painting issues we've had through the years, so that will be exciting to bring you next year.
We're also ready to launch a whole new set of tools around regression testing and broader Wine testing; I'm hopeful that next year is the year that Wine really hits is 'tipping' point, with most things starting to 'just work'.
IBM's developerWorks website has some of the best tech writing around. This week an article showed up discussing emulation, Write emulator-friendly Linux code (http://www-106.ibm.com/developerworks/library/l-emulat.html?ca=dgr-lnxw02EmulatorCode) . It's actually a topic that I've discussed quite a bit with different people and it's particularly interesting when you consider the recursive Wine Is Not an Emulator acronym. When you begin implementing a PE loader and mask system calls, it really is a form of emulation, right? Peter Seebach does a nice job of describing the different emulation mechanisms and uses Wine as an example:
In the world of emulation, software emulators are where life gets interesting. A software emulator is not running your program on a virtual machine -- it's running it on the fly without a virtual machine. These programs work by setting up an environment in which a program's code can run normally, but attempts by the program to access the operating system get routed through an emulation layer of some sort. WINE is a great example (albeit for Windows), although it is officially not an emulator.
Speaking of IBM, they just published one of their infamous Redbooks titled, Linux Client Migration Cookbook (http://www.redbooks.ibm.com/abstracts/sg246380.html?Open) . See if you can spot the passing references to Wine. I guess this proves IBM knows Wine exists.. could you guys throw a development team our way?
2. Safedisc and ntoskrnl
22�Dec�2004 (7 posts) Archive Link: "Re: Add ntoskrnl.exe.so"
People: Ivan Leo Puoti,�Mike Hearn,�Steven Edwards,�,�WineHQ,�ReactOS,�cvs
Ivan Leo Puoti put together some patches this week that were pretty interesting. If you dig into Windows NT, you'll see there's a low-level kernel mode that's normally off-limits to applications. Lots of interesting things happen at this level, including controlling device drivers. At the core of this system lies ntoskrnl.exe. Now, Wine hasn't really needed to implement this because device drivers are handled as separate components that interact with the underlying operating system. The Safedisc driver for copy protection (used by tons of games) is an exception - it's something that's best implemented by just using the native Windows driver. To do this requires a limited subset of ntoskrnl.exe. Ivan Leo Puoti submitted some patches this week trying to put that all together.
Steven Edwards pointed out that the new ntoskrnl shouldn't import any functions from kernel32. Instead, the proper way to do it would be to move kernel32 functionality into ntoskrnl. Mike Hearn disagreed though, " This isn't ReactOS, ntoskrnl is just another DLL from the SafeDisc perspective. Its implementation details shouldn't matter. "
Steven thought it would allow for more codesharing between Wine and ReactOS, but Mike didn't think there was much to share. Steven still thought it might be worth considering, " SafeDisc itself really needs very little but in the future we might support more than just this one driver. I admit the amount of code we might be able to share is limited I am just suggesting that we look at it now. "
At any rate, Alexandre didn't commit the patches nor did he weigh in on the conversation. Will ntoskrnl get added? Stay tuned to a WineHQ cvs server near you.
3. WineTools Updated
20�Dec�2004 (1 post) Archive Link: "[Wine]Announcement of WineTools"
People: Joachim von Thadden,�
I'll admit, I don't really read the wine-users (http://www.winehq.org/hypermail/wine-users) mailing list. This little newsletter is about Wine development after all. However, every once in a while I check for interesting posts and this week I found one by Joachim von Thadden:
I want to announce the newly born WineTools. WineTools is an menu driven installer for installing Windows programs under wine. This software lets you install the following Windows software for Linux under WINE:
It also sets up your .wine directory in the correct way, downloads the files to install from the web (only the free and shareware ones for sure), installs Windows fonts and lets you uninstall and configure your software. And it does much more than Sidenet, although it uses a part of the configuration for IE6 (thanks for that!).
WineTools was initially written by Frank Hendriksen <frank_at_franksworld.net> and was extended by me (Joachim von Thadden <thadden_at_web.de> It is licensed under the GPL.
The actual version wt207jo works with wine-20041019 and wine-20040914. Look at
to get more informations and to download. Note that you should definitely start with the "Base setup" and create a new fake Windows drive. If you want to save your old .wine directory, you can use the backup function of WineTools.
4. WINEprobe Initiative
20�Dec�2004�-�22�Dec�2004 (13 posts) Archive Link: "Approving of the WINEprobe initiative"
Topics: Project Management
People: David Gumbel,�Brian Vincent,�,�Scott Ritchie
David G�mbel wanted some opinions about a project being launched in the Stuttgart region of Germany:
as my colleague Stefan Munz has already pointed out recently on this list, Wirtschaftsforderung Region Stutgart GmbH (WRS) and us (ITOMIG) are launching an initiative called WINEprobe. Its goal is to make local software vendors aware of the potential bussiness opportunity in a WINE-based port or a WINE/Linux version of their software.
WRS is quite committed as far as Open Source is concerned, and is pushing OSS in the region since quite a time. It has co-organized, among others, the KDE World Summit 2004 in Ludwigsburg near Stuttgart. The Perlworkshop 6.0 , GUADEC6 (GNOME Conference) , ApacheCon Europe and more than 40 other Open Source Events in the Stuttgart Region are organized or supported by the WRS as well. (You can find a description of WRS at the bottom of this mail.)
In order to make the WINEprobe initiative beneficial for the WINE project as much as possible, three things are in the making:
Mr. Schmid from WRS has asked me (please see the mail below) to provide some information about this initiative to the WINE community. He thinks (and I agree ;) that it would help us a great deal in making the campaign a success if the WINE community somehow "officially" (as official as a community can be :) approved of this initiative. So my question, on behalf of Mr. Schmid, is simply if there are objections against us saying that this initiative is approved of by the WINE community?
 http://www.mail-archive.com/wine-devel%40winehq.org/msg11549.html (http://www.mail-archive.com/wine-devel%40winehq.org/msg11549.html)
 WINEprobe means be something like WINEtasting in english an maybe "degustation de WINE" in french.
 See http://opensource.region-stuttgart.de/ (http://opensource.region-stuttgart.de/) (.de only, sorry)
 http://conference2004.kde.org/ (http://conference2004.kde.org/)
 http://2005.guadec.org/papers.html (http://2005.guadec.org/papers.html)
 http://www.mail-archive.com/wine-devel%40winehq.org/msg11630.html (http://www.mail-archive.com/wine-devel%40winehq.org/msg11630.html)
 http://www.winehq.org/hypermail/wine-devel/2004/11/0647.html (http://www.winehq.org/hypermail/wine-devel/2004/11/0647.html)
A bit of discussion followed, mostly involving the name WINEprobe. Scott Ritchie suggested using PortWINE which has a nice connotation in both English and German. I had a small suggestion about the endorsement they asked for:
So as far as official endorsement.. I'm sure someone in the Wine community will speak up if they disagree with anything. (Conversely, they won't speak up if they agree.) The three projects you mentioned all sound great and they're things that really should be worked on. So in the sense that stuff should get done - I think we all want that. That leads up to your question of whether the Wine community approves of the initiative? Well.. I'm not qualified to answer that question.
If you do contribute to Wine, we'll gladly add you to our acknowledgements page ( http://www.winehq.org/site/acknowledgement (http://www.winehq.org/site/acknowledgement) ). Then you can say things in press releases like, "WRS, an acknowledged Wine contributor, ....." Anyone disagree with that idea?
5. File Optimization
21�Dec�2004 (1 post) Archive Link: "Some performance stats"
People: Dmitry Timoshkov,�
Anyone want an optimization project? Dmitry Timoshkov uncovered something that should be looked at:
While debugging one of applications I'm working on I noticed a lot of GetPrivateProfileString calls with the same file name but in different case causes profile code to open and parse system.ini again. I sent a patch which helps to find a cached file in that case and do not parse it again.
I had a thought that another speed improvement might be to use FindFirstFileW instead of CreateFileW/GetFileTime to retrieve last modification time of a file. I wrote a test under Windows to see which of FindFirstFileW or CreateFileW is faster. The test is attached.
Here are the results (for 10000 loops) running the same binaries in Wine and Windows 2000 SP4 (hard disks are the same in both systems):
CreateFileW is only 1.5 times slower in Wine than in Windows, that's really not bad (especially taking into account Wine boot time), but still there is a possibility for an improvement.
FindFirstFileW is 3 times slower in Wine than CreateFileW, while it's only 1.5 times slower in Windows. This needs to be optimized.
6. Launching Apps
23�Dec�2004�-�24�Dec�2004 (4 posts) Archive Link: "Interface for working directories/launchers"
People: Mike Hearn,�Alexandre Julliard,�
Sometimes just launching an app can be a lot of trouble. Mike Hearn had an idea for making that easier and how to integrate it with the desktop:
Wine currently creates launchers (.desktop files) with an Exec line like this:
But, some games expects to be run from its working directory. As working directory typically doesn't matter to UNIX apps, some desktop environments like GNOME don't let you set it. Really, this is a Wine specific issue.
So I'm wondering how we should fix this. The most obvious is a way to tell Wine to change the working directory to the path of the EXE file before running it, but we can't introduce command line switches any more and an environment variable for this doesn't make much sense.
My proposal is to have a new winelib app "winemenulauncher" which simply takes the working directory, program and arguments, and runs the program but switching current directory first, ie the menu entry would look like:
Exec=wine winemenulauncher c:\games\supreme supreme.exe
Hopefully this should let us fix the case of games like Dungeon Keeper which actually crash when run from their install directory.
Does this sound sensible?
Alexandre had a different idea using a mechanism already in place, " The right way is to use start.exe on the .lnk file. "
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.