WineHQ

World Wine News

All the news that fits, we print.

02/04/2005
by Brian Vincent
Issue: 260

XML source
More Issues...

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


This week, 256 posts consumed 1263 K. There were 78 different contributors. 44 (56%) posted more than once. 43 (55%) posted last week too.

The top 5 posters of the week were:

  1. 23 posts in 70K by Mike Hearn
  2. 15 posts in 35K by Alexandre Julliard
  3. 15 posts in 51K by Oliver Stieber
  4. 14 posts in 44K by Rob Shearman
  5. 10 posts in 28K by Paul Vriens

Window Management Rewrite Details 01/31/2005 Archive
Status Updates

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:

    Code optimizations

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


RichEdit Control Code 01/30/2005 Archive
Integration

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 and #251 ). 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 written 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 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:

  • editor.c contains a list of which messages/notifications/styles work and which don't
  • incomplete read-only mode
  • replacement of MSVCRT wcs functions with Win32 lstr
  • a modification flag
  • a shy attempt at starting undo
  • a #define to choose between my editor and the original RICHEDIT. It's not what I want it to be, but it's better than nothing.

Rob Shearman had some suggestions concerning "undo" functionality:

Undo should be pretty easy as long as you can 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 at 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 "! 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 further 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.)


Interlocked* Cleanup Completed 01/25/2005 Archive
Project Management

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 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

    The Interlocked cleanup is completed.


Software Freedom Law Center 02/01/2005 Archive
Project Management

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?


Debian WineTools Packages 02/02/2005 Archive
Utilities

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 .


Slick Build Output 01/27/2005 Archive
Build Process

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 that 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

    make VERBOSE=yes

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

    $(NICE_ECHO) " whatever"

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

    diff -urN wine-20050111 wine-20050111.new > make_patches

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.


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.