All the news that fits, we print.
This is the 114th release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).
Typically I've been putting the latest news here in the introduction. This is bad for several reasons, most importantly it makes searching archives hard. Also, it's soon going to unfriendly to some scripts I run. So from now on I'm going to be adding news as the first section below.
|
This week, 297 posts consumed 1092 K. There were 67 different contributors. 39 (58%) posted more than once. 27 (40%) posted last week too. The top 5 posters of the week were:
|
| News: Wired Story, LindowsOS Preview | 01/14/2002 | Archive |
|---|---|---|
|
Alexandre tagged a new release of Wine - 20020122. In the announcement he noted:
There have been a ton of CVS commits after that. Jeremy White contributed a large patch to improve Office functionality. He didn't have time to break it up into pieces and asked for volunteers. Duane Clark, Huw Davies, and Dimitrie Paun responded and broke it up into 30+ patches. Alexandre also committed a patch from Huw Davies that uses the Xrender extension to support client side font rendering - thereby providing anti-aliased text. Mike McCormack also came up with a patch that to remove X borders and title bars on managed windows, so the Windows are still managed and they look like a normal Windows window. There's a couple of good articles about Wine this week. First, there's a story on Wired titled Can WINE Ferment Move to Linux? . There's some good quotes in there from Jeremy White. Also this week, Adam Wiggins describes how his entire office converted over to using open source desktops. In the second part Adam describes some of the applications he's using - CodeWeavers' CrossOver Plugin made the list. The other big Wine news this week appears over on NewsForge . Tina Gasperson reviewed the sneak preview release of LindowsOS. Tina found that the distribution basically consists of KDE, KDE apps, and WINE. She had a lot of trouble installing Windows applications, which shouldn't come as a huge surprise. However, the scariest part is the installation uses root as the main user. As Tina describes, Not only did the installation process not give us the opportunity to add users other than root, it didn't even explain that we *should* add users other than root, didn't tell us that the account was root, and even tended to discourage us from entering the optional security password for root, because, "if you lose this password it cannot be recovered." This is a huge security problem, I can't even imagine the amount of damage that could be done. With the vast array of user tools and configuration options available there is no reason for doing that. | ||
| Disk Error Fixed | 01/20/02 | Archive |
|---|---|---|
|
Rein Klazes submitted a patch with this note,
This fixes office 97 MSword error (disk full or write protected) when
saving files on a vfat partition. MSword calls Andreas Mohr replied: Ah ! :-))) I already suspected this to be the case. At least I already found due to some error code that some ftruncate() must have failed, and I think I thus called it an ftruncate problem. Oh, and yes, that error condition was in the server, too, so it must have been this ftruncate. And one more: In several cases, some guys reported that programs needed some "touch"ing before being able to save a file. What do you wanna bet that *this* is the problem that's now solved ?? :) In short: a very important fix, I think. I guess we can call you a Wine Master now ;) Guy Albertelli exchanged some emails with Rein about using it with a 2.2.12 kernel, This was a great catch. It was the reason Scandisk complained about OutlookExpress's files (see my message from 1/11/2001). However your fix still fails on my outdated kernel (2.2.12-20). The attached version seems to work better on this kernel. After looking at Guy's patch Lawson Whitney wondered why bothering to use ftruncate() at all when a combination of lseek() and write() would appear to fix the same problem. Rein explained that wouldn't work if you needed to shrink the file. | ||
| Patch to Improve Microsoft Office 2000 Functionality | 01/24/02 | Archive |
|---|---|---|
|
Jeremy White posted a huge patch to wine-patches to Office 2000 functionality. He didn't have time to split it up into smaller chunks or to verify it worked against the current CVS. He explained: The following large patch substantially improves the behaviour of Microsoft Office with Wine. Notes:
Duane Clark replied, I'll be happy to sync this to the current CVS, test it out with the apps I have, and chop it up into a series of patches, if no one else wants to take that on. Dimitrie Paun decided to take on some of it explaining, I suggest you pass the listview.c chucks over to me. I've just completed a major update to the ListView ctrl, and (a) none of the updates in the patch will apply, and (b) I have the code fresh in my mind. Dimitrie is currently working on some common controls stuff so Duane began splitting it out and sending it to him. A flurry of patches has begun arriving on wine-patches. | ||
| New SDL Driver | 01/26/02 | Archive |
|---|---|---|
|
Gavriel State put out some code TransGaming put together: We just put this together for some testing, and thought that someone might find it handy. I'm not submitting it to wine-patches, since we haven't tested it on the most recent winehq tree, but it should be pretty easy to integrate in. It's not 100% complete by any means, but it has both GDI bitmap and DDraw support. We can vouch that it runs some of the DDraw samples, but beyond that, who knows. That said, the SDL driver should be a useful alternative to the ttydrv for testing purposes. David Elliott replied: Very interesting. I was considering making an RFB (the VNC protocol) backend for Wine for about the same reason. That is that the only really decent driver is X11 right now since ttydrv is fairly useless. Hmm, maybe I should actually do that. As an added bonus since VNC is just basically a generic framebuffer it would allow a fairly easy port to another generic framebuffer interface such as LinuxFB (or whatever the new hot-shit FB project for Linux is these days). Gavriel went on to explain: Well, the sdldrv is a long way from being capable of that kind of thing. 8-) The big thing that's missing is a real GDI renderer. It's great to have something that can kind-of do a bitblt, but if you want to have windows and menus and such on the screen, a real renderer is needed. Aside from BitBlit-ing, it would need to handle polygons, brushes, pens, clipping, and most painfully, text. It's possible that some of Huw's recent work might help there, but I'm not sure - I think that XRender actually requires X... Now, the interesting thing is this: Once we have a GDI renderer, we can eliminate a *huge* amount of DIBSection cruft from the X11 driver. Currently Wine goes through astounding manipulations to get X to draw things for us when we should be doing it ourselves. This is very slow, and affects more apps than you might think (ie: WordPerfect). We actually have a co-op student (Hi Jonathan!) who we've asked to look into this a bit. He's quite new to Wine, and has some other duties as well, but I'm sure that he would be interested in sharing the work. 8-) Having just generic framebuffer support would be a huge step towards supporting embedded devices. However, this hasn't been focus by anyone and likely won't be for a long time. | ||
| Versioning as 1.0 Nears | 01/28/02 | Archive |
|---|---|---|
|
One topic that comes up from time to time, especially in online forums, is Wine's versioning scheme. Some people complain that releases named "20020122" mean nothing and wish Wine followed a format such as .80, etc. leading up towards a 1.0 release. One of the arguments in the past has been Wine is in continual development and rather than making a 0.8 release followed up with stabler releases it's better to keep adding new features. This time Dimitrie Paun started it with: ... I feel like starting a flamewar, just to get some traffic on this list :) Speaking of which, I figured I should rattle Alexandre's cage :) So here I go: Wine's been around for 8 (_eight_) years (how time flies)! It is my understanding that we're approaching the 1.0 status. I say, let's change the versioning scheme, just to give the outside world a feeling of progress. Really, I think the current scheme kindda hurts us on a PR level. We can start with something like 0.90.0. This should give us plenty numbers to the upcoming 1.0, don't you think? Eric Pouech summarized a lot of thoughts with:
IMO, what's important behind version numbers isn't the version in
itself, but rather:
Some folks were more interested in the a) approach. It's what TransGaming did (does) with a target on games (as applications). Some others may suggest (O|o)ffice applications (it seems CodeWeavers folks have been busy on this matter lately ;-) Some other (including Alexandre) were more in favor of the technical approach. This would include finishing the major hurdles. IIRC the discussion at that time, I think most of them have been removed
Anyway, on a more pragmatic term, let's see what needs to be done: from the a) view:
from the b) view:
David Elliott pointed out that if you want to know what's been fixed, then just read the ChangeLog or check out the Wine CVS archives. Jeremy White mentioned: It's funny, I've spent the last two years trying to convince Alexandre we should have an 0.9, but now I think I've reversed my original opinion and think we should stick with our current scheme until 1.0. Also, I think what's most important about 1.0 is not 1.0 itself, but it is the promise inherent in 1.1 - that 1.1 will do everything 1.0 did, and a little more. To that end, I agree that we should finalize the Wine server protocol, and it sure wouldn't hurt to have a nice regression system in place as well. Alexandre explained: Do you want me to commit patches, or do you want a flamewar? You can't have both <g> Seriously, it is planned to have a 0.9 version, but I don't want to use the name for any random version, otherwise it doesn't mean anything more than the current scheme. My plan is to have 0.9 mark the point where all the 1.0 features are in place and all that remains is bug fixing. Then the 0.9.x series will be a progressive code freeze (each release being a little colder than the previous one) converging towards 1.0. Eric Pouech wondered what was holding up a 0.9 release. Alexandre replied that inter-process window handling/window management and the continuing DLL separation were what was left. | ||
| Window Management Problems with Pajama Sam | 01/27/02 | Archive |
|---|---|---|
|
Ori Pessach was having a problem with window management in a game: I spent some time trying to hunt down the window management problems I reported a while ago (dialogs displayed by the game Pajama Sam appearing behind the main window, and sometimes not getting keyboard focus). I found that the game's main window simply wasn't managed. The game opens a window that covers the entire screen, and doesn't have a caption. is_window_managed(), in dlls/x11drv/window.c therefore returns FALSE for that window, and (I'm guessing here) since Wine is running in managed mode, it manages that window poorly. Switching desktops in KDE doesn't remove the window from the screen, it's impossible to get any window to display on top of the game window, and in general, several functions in x11drv/winpos.c behave badly when Wine has a mix of managed and unmanaged windows. Changing is_window_managed()'s default return value to TRUE makes the game behave much better, but not perfectly. The KDE panel stays on top of the game window - it can be hidden away, but Windows handles this differently, letting the game window obscure the task bar. I'm inclined to call this a KDE problem, rather than a Wine problem. Also, I don't know whether the tests in is_window_managed() cover all the cases in which a window should stay unmanaged. Right now, is_window_managed() tests for child windows and tool windows, and returns FALSE for those windows. Are there any other types of windows that shouldn't be managed? Ove KÃven replied with a pointer to a recent patch he submitted concerning stuff like this. Ori asked: Does anybody know how X toolkits display tooltips, popup menus, etc.? I would think that when running managed Wine, all window should be managed, and the distinction should be between decorationless windows and everything else, not managed windows and everything else. If nobody else wants to dig into this, I'll probably take a shot at it. Ori dug into the problem and reported back the next day: With three small changes to menu.c, tooltips.c and window.c, things I'm getting much better results with Pajam Sam et al, without getting WM decorations on tooltips and context menus. The changes are:
With these changes, Pajama Sam works correctly, except for the KDE panel problem. I tested another app (WinRAR) for tooltip and context menu behavior, and it worked fine. I'd be happier if somebody else tested this, too, before submitting the patch. If someone with a Windows machine could check the dwExStyle bits on menus somehow, that would be nice. I'll do it myself, as soon as I can get my hands on the necessary software. (Windows, mostly). | ||
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.
