Wine Traffic #260 For 4�Feb�2005

By Brian Vincent

Table Of Contents

Introduction

This is the 260th issue of the Wine Weekly News publication. Its main goal is to search for a string of boats. 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 256 posts in 1263K.

There were 78 different contributors. 44 posted more than once. 43 posted last week too.

The top posters of the week were:

1. Window Management Rewrite Details

31�Jan�2005�-�1�Feb�2005 (14 posts) Archive Link: "Re: wine/dlls x11drv/x11drv.h x11drv/winpos.c x11d ..."

Topics: Status Updates

People: Alexandre Julliard,�Dimitrie Paun,�Lionel Ulmer,�Jeremy White,�Oliver Stieber,�,�Huw Davies,�Microsoft,�Aric Stewart,�Jason,�Rob Shearman,�Mike Hearn,�Mike McCormack

There's some massive changes going on right now with the Wine tree. Some we've covered, some we haven't. For instance, Mike Hearn and Rob Shearman have been sending steady updates about their DCOM work and the direction it's headed. Besides that, we've got the DirectX guys, particularly Jason Edmeades, implementing Direct3D 9 using a brand new library that will eventually be used by D3D8 as well. Aric Stewart and Mike McCormack are busy fleshing out the Microsoft Installer library. Huw Davies has greatly improved the widl IDL compiler.

Finally, a long awaited project is being tackled by Alexandre - the window management rewrite. Another set of WM patches came out this week, including one with this changelog:

Only create an X window for top-level windows, not for child windows. Get rid of the X client window too, it's no longer needed.

It led Dimi to ask if the window management rewrite was completed. Alexandre replied, " The bulk of the architectural work is done, yes. There are still many loose ends to tie up, and some missing performance improvements. Plus of course fixing all the regressions that this change will cause, notably with OpenGL..."

Dimi asked, " If it's not too much trouble, it would be nice if you list all the known loose ends/bugs/optimisations/regressions so that (1) we can explicitly track them, and (2) we get a sense of where we are and how things are going. And last, but not least, there is the off chance that someone might lend a helping hand (yeah, I know, chances are slim to none, but still ... :))"

Alexandre described some of the remaining work:

It's a bit hard to build a complete list, I mostly make it up as I go... The main optimisation I know about is the repainting on window moves that needs to copy the bits instead of invalidating the whole window. The loose ends are mostly related to dll separation, the exported functions in user32.spec can give you a rough idea of what remains to be done. For OpenGL what we need is to implement proper clipping when drawing to a child window. There are also a number of window management hacks in the Crossover tree that need to be cleaned up and brought over.

Lionel Ulmer described some of issues with OpenGL:

Basically, the problem with OpenGL is that there is no way (that I know of) in OpenGL to do non-simple clipping (what I mean by 'non-simple' is non-rectangular). Ie if a (non top-level) OpenGL window is obscured by another (non top-level) window, there is no way (that is not a hack) to prevent GL to draw over the obscured window.

The best way to fix this would be to have the X server export via a GLX extension its hardware clip-list implementation (which is something that I need to discuss with the FreeDesktop guys as this would be something that could help all the 3D X servers implementations which people are working on as, basically, it's exactly the same issue).

The other way is to do indirect rendering for GL contexts not associated to top-level windows: basically, draw in a Pixmap (or a PBuffer) and then use the plain Wine 'DIB' code to blit this back-buffer to the screen (doing then the clipping). This should work easily at the price of some performance (especially on cards / drivers who do not support accelerated off-screen rendering).

The additionnal advantage of the latter solution is to solve also the 'multiple windows / different GL attributes' problem.

With regards to window management, Oliver Stieber ran into a problem getting the window ID of a child window. Mike McCormack explained it was because of the recent commits Alexandre had done. Jeremy White explained why it might have been easy to miss the change:

If Alexandre committed a patch that converted the entire code base from C to pure assembler, his changelog would read:

(Although if he could find a way to say it in one word, he would) <grin>

2. RichEdit Control Code

30�Jan�2005�-�4�Feb�2005 (9 posts) Archive Link: "RICHEDIT once again"

Topics: Integration

People: Krzysztof Foltman,�Mike McCormack,�Robert Shearman,�Boaz Harrosh,�,�Rob Shearman

A few months ago we covered some work that had been done by Krzysztof Foltman to begin a RichEdit 2.0 control (see WWN issues #250 (http://www.winehq.com/?issue=250#No%20RichEdit20A%20Window%20Class) and #251 (http://www.winehq.com/?issue=251#RichEdit%20(con't)) ). This week Krzysztof announced he was making available what he had so far:

My rich text control is still far from even semi-complete, but I think too much is done to start over, so I'm releasing it today. The number one reason of its incompleteness is that I put more emphasis on making things work exactly like in the original than on implementing more functions.

It's been neglected for weeks, and only recently I've fixed some old bugs and slowly started implementing the simplest parts of the RICHEDIT control API. I'm still not done with the basic stuff, like undo stack, so there is not much to hack on. On the other hand, it's likely I've made some bad decisions during design, and having someone experienced to look at that seemed to be a good idea to me.

Some things look really tricky to implement with the current architecture, like the printing API (it will likely be an ugly hack, but I expect the same from the original, as screen formatting and print formatting may be very different). Some things just need time. I will probably need others' help to do the RTF parser. It's just way too much work.

So, if anyone cares:

Compile using the recent-ish mingw (plus original SDK richedit header file).

Mike McCormack was impressed:

Fantastic. This is good work. I haven't reviewed the code in depth, but I think the way forward is to submit an implementation of dlls/riched20 then make that work, and after it's debugged and worked out, rip out the old dlls/riched32 code and forward it to the new completed riched20 code.

Code review notes:

You've writen the code to deal with unicode as default, which is good, but you need to deal with both ASCII and unicode messages in the window procedure.

It might be better to use libwineunicode and kernel32 unicode string manipulation functions rather than msvcrt ones. eg lstrlenW, lstrcpyW, etc. instead of wcslen, wcscpy, etc. Avoid the TCHAR type in Wine code.

Similarly, you'll need to use "winbase.h" and friends instead of "windows.h".

From what I can see in the old riched32 code, the rtf parser looks quite good, so don't try rewrite that (which from my quick check you haven't). We can merge the parser into the riched20 code quite easily... it's just enters the text into the existing control using EM_SETSEL and some formatting messages.

I have a test I can send to you if you wish. Again, my preference is to get this into the Wine CVS sooner rather than later, so others can start helping improve it.

Krzysztof made some changes based on Mike's notes and put another version up:

I'll see what can be done. As soon as there is a minimal text manipulation API (based on RichEdit API, not on function calls), I can separate the control into a DLL and move the app code in the test directory.

So far, the next version is available at:

Main changes are:

Rob Shearman had some suggestions concerning "undo" functionality:

Undo should be pretty easy as long as you can represent easily represent user actions in a transactions stack. A user doing something will then cause an action to be pushed onto the stack (although you would probably want some coalescing so that you don't have to undo each character you typed, you can just undo a sentence). The undo command will pop a transaction of the stack and apply the inverse. I've written a fairly nice implementation of this before in Java and it didn't take me very long.

Krzysztof explained a little more about how undo needed to operate, " Yes, I know the undo basics. The most recent source has the basic stack structure. :) It's still a bit complex, as, first, we have formatting to store on the stack (linked actions are the way to go), and it's easy to miss something, making undo fail in unusual circumstances. "

Later in the week Krzysztof followed up with another patch and announced more work:

It seems that I already have something useful. I've added multilevel undo/redo, GetCharFormat/SetCharFormat (very incomplete) and modify flag, and cleaned up the code a lot. The source code is downloadable from here:

I'll try to add handlers for basic editing messages (like WM_SETTEXT) and maybe notifications too, DLLize it and then make a Wine patch out of it. Is that OK ?

It's not like everything is done the way it should be (for instance, coordinate system is still pixel-based and not twips-based), but in this stage the risk of having to constantly rewrite everyone else's code is much lower.

Mike McCormack encouraged Krzysztof to submit the code as a formal patch against riched20.dll and offered to help integrate it.

Boaz Harrosh gave a pointer to another project that had some code that might be useful:

I have been using in a few projects, Windows side and Linux, a great rich edit control, I'm sure everybody knows, and used even if he doesn't know. "Scintilla (http://www.scintilla.org/) "! It has anything a RichEdit control needs (and much more but that does not have to be used). It even has the export to RTF function. (And to HTML for clipboard operations) It has 95% EditBox emulation. It is very stable, heavily used and debugged, and highly portable. The License is a BSD type license so I don't think it will be any problem. The only things missing are the RTF parser and the MS-RichEdit emulation (Data types and message translations). But it looks like these two are what above patch and existing code has. I am almost positive that if such a parser (And emulation layer) is submitted to the Scintilla project it will be farther maintained by the project. One more thing good about it, that makes a lot of sense, is its popularity, which means there are a lot of people that know this code-base and can help fix problems. (And it does compile under wine out of the box.)

3. Interlocked* Cleanup Completed

25�Jan�2005 (1 post) Archive Link: "[Janitorial] Interlocked* cleanup completed"

Topics: Project Management

People: WineHQ,�Paul Vriens,�,�cvs

We've had a janitorial project for a few months to use the Interlocked functions for thread safety. The actual project says this:

Most OLE objects should be threadsafe, which requires use of the thread-safe increment and decrement functions InterlockedIncrement(&This->ref) and InterlockedDecrement(&This->ref) instead of This->ref++ or This->ref--. See an example patch (http://cvs.winehq.org/patch.py?id=15239) of how to fix this problem.

To be consistent, references to This->ref in TRACE's should be avoided as well.

Paul Vriens has spent the past few weeks consistently sending patches in and announced this week he'd completed the whole thing:

If there are not objections I'll send the attached patch to wine-patches.

Changelog

4. Software Freedom Law Center

1�Feb�2005�-�4�Feb�2005 (4 posts) Archive Link: "Software Freedom Law Center"

Topics: Project Management

People: Jeremy White,�

Jeremy White wrote in to get some feedback about a new Open Source Development Labs initative:

There is an exciting announcement out today:

Essentially, OSDL has funded a community oriented pro-bono legal service for Free and Open Source Software Projects. The Center is led by Eben Moglen, the chief counsel for the FSF.

I've been speaking privately with Eben Moglen about this new effort, and he tells me that they would like to have the Wine Project as one if their very first clients.

Candidly, this seems fantastic to me; one of the difficult things that I face when promoting Wine is peoples Fear, Uncertainty, and Doubt about the legality of Wine. Having an opportunity to clarify these legal issues is probably the most important thing that could happen for Wine, in my opinion (well, okay, maybe it's less important than support for Pirates! <grin>).

However, before I go off to request the services of the SFLC, I thought I would post this announcement here and open it for any discussion. I'd particularly like to hear if folks can think of any reasons why this might be a bad thing.

Finally, the key objectives from my standpoint are as follows:

  1. Get an opinion written on Wine and copyright issues (imho, we have no IP issues here)
  2. Get some legal research done on Patent issues I don't know how this will turn out, so I think we should wait for the research.
  3. Investigate the legal doctrine surrounding what use a monopoly can make of its patents; I know that US antitrust law provides some restraints, but it would be great to have a legal opinion on the matter.

Thoughts? Comments?

If you happen to have any Fear, Uncertainty, or Doubt, maybe it's a good time to drop an email to wine-devel or Jeremy and let them know what could be improved. Anyone ever run into legal issues they need clarified?

5. Debian Winetools Packages

2�Feb�2005 (1 post) Archive Link: "Winetools Debian Package!"

Topics: Utilities

People: Scott Ritchie,�,�WineHQ

Scott Ritchie announced the availability of the Winetools package for Debian. Winetools sets up a custom configuration and lets you install various Windows programs:

Ok, I finished up the winetools Debian packages.

It's on the same repository as the Wine packages at WineHQ, so you should be able to install it easily from there.

To run it simply type "winetools" or use the (hopefully created) menu entry.

One day I hope to have a man page and such, but for now it seems good.

For more information, see the new Debian download page (http://www.winehq.org/site/download-deb) .

6. Slick Build Output

27�Jan�2005�-�31�Jan�2005 (18 posts) Archive Link: "Slick build output"

Topics: Build Process

People: Jason But,�Alexandre Julliard,�Marcus Meissner,�,�Jason

Jason But did some work to make Wine's build system a little easier on the eyes:

Not really related to the actual wine development but more to the make/build/install environment.

Remembering the most wine users will not necessarily be developers we should consider improving the output of running (./configure && make) to make it more user friendly. Hopefully it should also be less confronting and confusing to non developers. I propose something similar to the way the Linux kernel currently compiles. The included patch changes make so that a regular make will produce much nicer output while for those die-hards who prefer the original output this can be achieved by executing

I personally prefer the neater output even for development work, the compile output doesn't scroll off the screen as quickly and warnings/errors can be more easily spotted.

This patch doesn't do the complete job, instead only produces output for the compile (gcc) stages. In fact, (make install) will produce no output at all! If people think this is a good idea, simple extensions will lead to complete output, just add the necessary

to the proper places in each Make*.in file

I am willing to do this if it is deemed to be good.

In another email, Jason showed off his work by compiling some directories:

Making in libs/wine/
���� Compiling�����������config.c
config.c: In function `init_server_dir':
config.c:120: warning: right shift count >= width of type
config.c:125: warning: right shift count >= width of type
���� Compiling�����������debug.c
���� Compiling�����������ldt.c
���� Compiling�����������loader.c
���� Compiling�����������mmap.c
���� Compiling�����������port.c
�� Creating Library������libwine.so.1
�� Creating Library������libwine.so

Alexandre wasn't in favor of it though, " I think it's a lot more important to make it useful for developers, which is what it is now. Users who get intimidated by the make output should use a binary package. " Later he added, " Our makefiles are already complicated enough to not add such gratuitous complexity. "

Other developers had mixed reactions. Quite a few were in favor of adding it, others were against it. Alexandre wasn't persuaded. Marcus Meissner pointed out one other problem:

The developer can use "make -s" if he wants to see less.

vis and emacs automatic errorline jump will also stop working.

Jason provided the patch in case anyone wanted to use it:

I will not bring this up any more after this email.

I note that while the patches are extensive they are merely the addition of one ECHO line to each rule.

For those who are interested, I attach the patch here (hoping it works this time) for the completed output cleanup. I ran

where wine-20050111/ is the directory with the current wine sources and wine-20050111.new/ is the patched directory

All the changes are to the Make*.in files.

Closing off my input now.

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.