WineHQ

World Wine News

All the news that fits, we print.

02/28/2003
by Brian Vincent
Issue: 159

XML source
More Issues...

This is the 159th release of the Wine's kernel cousin publication. Its main goal is to inform you of what's going on around Wine (the Un*x Windows emulator).


This week, 267 posts consumed 784 K. There were 61 different contributors. 32 (52%) posted more than once. 24 (39%) posted last week too.

The top 5 posters of the week were:

  1. 40 posts in 126K by Dan Kegel
  2. 24 posts in 66K by Mike Hearn
  3. 21 posts in 59K by Eric Pouech
  4. 18 posts in 42K by Dimitrie O. Paun
  5. 17 posts in 40K by Alexandre Julliard

News: Compiling with MS VC++, CodeWeavers & Taratella, MS Paint 02/22/2003 Archive
News

File this one under the "As Seen on Slashdot" category. Combine this with the instructions below from Dan Kegel and you'll have some good tips for using MS VC++ tools. Jonathan Grant wrote an article for Codingstyle.com about MS VC++ tools under Linux. The commandline executables are run under Wine. The advantage:

Using Visual C++ on GNU/Wine gives me all the benefits of being able to develop a 100% compatible MS-Windows version of the game, while saving me the time of maintaining another Win2k machine version of the source and moving to that machine to compile. It has been a great time saver for me and I strongly expect this information will be very useful to myself and others in the future.

CodeWeavers has a deal with Tarantella to serve up apps. Combined with CrossOver Office you get something with functionality like Citrix or MS Terminal Server. The actual press release came out on Monday, CodeWeavers explained the cost savings:

With CrossOver Office Server Edition, those cost savings can be furthered by allowing Windows applications to be run on Tarantella ia Server Edition, rather than MS Terminal Server. Server Edition delivers the same core Windows productivity applications that users need, but at a fraction of the cost of MS solutions. In addition, users free themselves from the need for MS Windows OS licenses, as well as the need to license individual CALs for each thin-client station.

Frank's Corner mentioned where to download MS Paint:

If you don't have Windows, but really like to play around with MS Paint, you can download it here: ms paint Just type wine mspaint95.exe to install it.

There's a ton of stuff for download in that directory. Nothing jumped out as being very interesting, but there very well could be something useful in there.


Threading Work 02/27/2003 Archive
Patches

This week Alexandre has been committing some large patches into CVS that have to deal with threading. They're pretty much over my head, and I didn't really understand the direction, but I was able to decipher the bits about integrating with the new Linux threading. Thankfully someone asked a question this week and Alexandre supplied a little insight into what the plans are. Stefan Jones offered to help:

I have started reading up the wine source code and understand basics of the wineserver message passing and the TEB / tls system. I know little about windows programming though. Any hint on what I can work on, help, to get this working again?

Alexandre gave a general outline of his work:

generic pthreads simply doesn't offer the functionality we need. It's possible to use the glibc nptl pthreads, but that's only because of the way they are implemented on top of kernel threads; this isn't a general property of pthreads, so a 100% POSIX threaded Wine is not possible.

Once I get the nptl support working there will probably be a number of things that can be done to take better advantage of the new threading support, and any help with that is welcome. But in all cases such code can only be added as an option, it can't replace the existing code since we have to run on older kernels as well as on other systems.

So, future kernels can take advantage of the Linux NPTL threading. Everything else will stay the same - standard old pthreads haven't and won't work for Wine. Along the same lines, someone asked about the shared memory wineserver. TransGaming developed a test implementation that showed dramatic speedups. It was last discussed back in issue #154 and at the time its main deficiency was pointed out - the ability for a badly behaving application to crash Wine. Alexandre explained why he didn't like it:

It's a neat hack, but it doesn't preserve the core idea behind the server design, which is that processes are properly isolated. With the shm server you basically go back to the Win9x days where any buggy process can trash the system structures; and I don't think that this is where we want to go.


Commandline MSVC 02/22/2003 Archive
Patches

Dan Kegel posted a small patch to Wine's cmd replacement. With it he noted the following:

OK, so there's msvcmaker, but I don't use guis, so I threw together a way to build the wine tests using cl and nmake. I have the following files in ~/bin:

nmake:

    wine -- wcmd /c F:\\bin\\nmake.bat "$@"

nmake.bat:

    call f:/bin/vcvars32.bat
    echo on
    nmake %1 %2 %3 %4 %5 %6

vcvars32.bat:

    same as normal one, but without quotes

nmakemaker:

    (attached)

Then in any dll/tests directory, I can type

    nmakemaker > foo.mak
    nmake /f foo.mak

and build all my tests with msvc. Each test is built as a separate executable, but that's the way I like it for testing anyway.

Now I guess I'll submit patches to make everyone else's tests actually *compile* under msvc.

It was real funny to see that article on slashdot appear as I was doing this. I seem to have gone a bit further than that guy, since I don't have to use that awful, horrible wcmd window.


X11Drv / NTDll Separation 02/22/2003 Archive
Graphics

David Fraser asked about DLL separation. It's an issue that hasn't come up much lately because a lot of it is done. Some really hard parts remain but it's not as high a priority as it once was. (Those really hard parts would include the x11drv, user32, gdi32, and kernel32 DLLs.) Anyway, he wondered about x11drv:

I was wanting to do some work on x11drv dll separation. The last remaining dll separation between x11drv and ntdll is VIRTUAL_SetFaultHandler. This is called from X11DRV_DIB_CreateDIBSection, where it tries to set the fault handler to X11DRV_DIB_FaultHandler, with addr=dm.dmBits and arg=res.

From reading the code it seems that this is done because it is not known whether the calling app requires read or write access to the data in bmp. If the app then tries to read or write and doesn't have the appropriate access, this will generate an exception which will then raise the X11DRV_DIB_FaultHandler which would then set the appropriate access, in a way that ensures data gets handled correctly.

I presume I'm misunderstanding this, because looking at MSDN for CreateDIBSection, it says:

    The CreateDIBSection function creates a device-independent bitmap (DIB) that applications can write to directly.
and further down...
    Windows NT: You need to guarantee that the GDI subsystem has completed any drawing to a bitmap created by CreateDIBSection before you draw to the bitmap yourself. Access to the bitmap must be synchronized. Do this by calling the GdiFlush function.

So it would seem apps could always be given read-write access to this bitmap.

Why is the special fault handler needed? What is the best way to approach getting rid of it?

If it was easy, it would have been done, right? David Hammerton explained where the difficulty was:

I wrote some documentation a while back on this when we (TransGaming) submitted our dibengine to rewind/winehq.

You can read the docu at:

Basically its beacuse a DIBSection is like a mixture of a DIB and a HBITMAP, in that it has properties of both: The app can write directly to the pixel data while also being able to perform GDI operations on it, which we do through X. Because of the way X works we therefor have to have two copies of the DIBSection hanging around, and be able to sync them when required (eg, if the most 'up to date' version is in X, we need to know when the app tries to write to / read from the DIB so as we can sync them).

And really - the best way to get rid of it is to finish the DIB engine :)

Eric Pouech explained the same thing and mentioned where the offending fault handler comes into play, basically, both the app and X11 are used to read and write into it (each DIB is associated to an X11 pixmap, and, for example, when the app writes to the DIB section, there's a need to update the pixmap. on the other way aroud, GDI operation on the DIB, are in fact done on the X11 pixmap. then modifications have to be updated into the bits of the DIB. the fault handler is used to synchronize both accesses

After the comments about the "only" thing needed was a DIB engine Johan Gill mentioned, And I have it in my tree :) It should be ready for submission in a few months from now.

Mike Hearn was concerned there might be a duplication of the work done by TransGaming, but Johan clarified that, It is their work, but I'm doing heavy changes.

David then explained why he was interested in separating it out, What stage is the implementation currently at? According to the TransGaming docs, there are still a number of functions to fill in... I would be interested in seeing a patch no matter how much/little is implemented ... because my main aim in getting rid of the fault handler is so that the x11drv can be ported to Windows...

Mike Hearn picked up on it and asked:

Would that actually let you drop a file into MS Windows and suddenly allow any windows app to be export via X11 at the API level?

If so, then all I can say is "whoa". If not, then, well, that'd be a cool hack some day :)

David then explained more issues with making that happen:

Yup, that's the point ... will take quite a bit of work but until the x11drv and gdi32 dlls are separated out it's not even feasible ... if you're interested see http://sources.redhat.com/XOpenWin/ which is a currently quite dormant project to try do this. The relevant bugs for dll separation are:

http://bugs.winehq.org/show_bug.cgi?id=538
DLL Separation: x11drv from gdi32
http://bugs.winehq.org/show_bug.cgi?id=540
DLL Separation: x11drv from user32 (clipboard)
http://bugs.winehq.org/show_bug.cgi?id=542
DLL Separation: x11drv from user32 (misc)
http://bugs.winehq.org/show_bug.cgi?id=543
DLL Separation: x11drv from ntdll (FILE_DupUnixHandle)
http://bugs.winehq.org/show_bug.cgi?id=545
DLL Separation: x11drv from ntdll (VIRTUAL_SetFaultHandler)


Libwine Portability 02/26/2003 Archive

In the course of discussion on a patch to wrc, Dimi remarked, BTW, can we have a little static lib that we can link to wrc where we can put the getopt_long code? It's needed in a bunch of places...

Alexandre replied, Sure, but there's no need for a getopt-specific library, it can use the normal portability mechanisms of libwine (though I'm planning to split the portability bits of libwine into a separate lib, but that's a different issue...)

Steven Edwards wanted to know if the interfaces in libwine would be frozen soon and Alexandre mentioned, It's unlikely they will get frozen before 0.9. We should probably start to use symbol versioning by 0.9 too, but I'm not sure how well this would work on ReactOS...

Symbol versioning is a way for the dynamic linker to determine that the libraries loaded contain the functions that an application needs. Or, more likely, that the function performs as expected - over time a function might change in the way that arguments are passed to it or the return value is different. Mike Hearn felt it might be overkill to implement and just changing the name of the library might be enough. Alexandre explained why it might be better:

The wine internal libraries are still about a megabyte of code, and it's silly to duplicate all of that whenever a single function changes. Symbol versioning is much better solution to that problem, and I don't see much reason for not using it (except on platforms that don't support it of course).

In this case, Dimi wanted to know if he should write a getopt_long function. Alexandre said yes, Yes, that's the way to do it, except it has to be implemented, not stubbed out. The idea is that port.[ch] provides an emulation of the missing functions so that people writing the code don't need to worry about whether they exist or not. But if the replacement is broken then we very much want the caller to be aware of that; which is why I put the #ifdefs in wrc so that it's explicit that long options don't work if configure didn't find getopt_long().


Using Clientside Fonts 02/15/2003 Archive
Fixes

Marc Williams complained about font handling:

I have a question about Wine's font handling. I am experiencing behavior in Wine that I don't believe is normal. At the very least, it is not desirable.

Ever since the first time I installed Wine over a year ago and up until the present, I couldn't figure out why Wine would, seemingly at random, decide it had to rebuild the font metrics when starting a Windows app. And this takes a fair length of time on my older machine with quite a few MS fonts installed. Sometimes, I would go a week or more without it having to rebuild the font metrics; other times it would be almost after every reboot. I couldn't figure out a pattern. Until this morning.

It seems to be Java related.

So here's my question: Is this normal?

Duane Clark explained the problem and the solution:

What is happening is that a default set of fonts are known to the font server, presumably xfs. When Wine is run, it checks that list of fonts and caches them.

When you run Java, it registers some additional private fonts with xfs. Now when you run Wine, it sees that the list of fonts has changed and reruns the caching.

You have a couple of alternatives. With that version of RedHat, you really don't need to have Wine use the xfs font server ("server side" font rendering). If you install a collection of TrueType fonts into your windows/Fonts directory, wherever you have your fake C: drive installed, then Wine should do direct rendering of fonts("client side" font rendering). When Wine does direct rendering, you will never cache fonts again. Yea! ;)

You can get fonts from the C:\windows\Fonts directory on a real Windows installation, and also from here:

Alternatively, if you want to continue to use "server side" font rendering, figure out where the Java fonts are located, and add that path to the default search path for xfs, so that xfs (and therefore Wine) already knows about them. Assuming it has not changed since RH7.3, the font paths are set in the file /etc/X11/fs/config.

Marc reported success.


Finding Missing Locks with Smatch 02/22/2003 Archive
Debugging

Michael Stefaniuc continued some work from last week with Smatch. He posted a small patch for a missing LeaveCriticalSection which prompted Dmitry Timoshkov to ask, Michael, I'm just curious, how hard it would be to adapt your SMATCH script for finding EnterCriticalSection/LeaveCriticalSection pair matching to do a similar work with wine_tsx11_lock/wine_tsx11_unlock, GDI_GetObjPtr/GDI_ReleaseObj, DC_GetDC[Ptr|Update]/GDI_ReleaseObj, USER_Lock/USER_Unlock, WIN_GetPtr/WIN_ReleasePtr, WIN_FindWndPtr/ WIN_ReleaseWndPtr and some other internal Wine locks?

The next day Michael had it working:

Not hard at all, I've created a new script http://people.redhat.com/mstefani/wine/smatch/wine_locks.pl that takes care of locks of the form:

    lock(this);
    do_something();
    unlock(this);

and put all of the above locking pairs into it. To add a new locking pair all that's needed is to add an entry for it in the %locks hash.

Running wine_locks.pl requires this patch http://people.redhat.com/mstefani/wine/smatch/smatch.pm.diff for smatch.pm because it treats every ARGV entry as filename (i'll contact the smatch author to find a solution that doesn't require this hack).

Besides some NOTABUG's in the CriticalSection locking i found only this:

    wine/windows/win.c 104 127 create_window_handle(31) 1 USER_Lock not released

I'm not sure if it's a bug or not.


Making Config Tools 02/21/2003 Archive
Configuration

Mike Hearn wanted to know what was going on with creating some configuration tools:

That reminds me, on the Wine 0.9 TODO it says "expect a preview of the wine config applets in the second week of 2003". Anybody know what the status of these are? I think it makes sense to start pro-actively targetting 0.9 tasks, and having control panel applets for Wine seems like a good idea.

Hmmm, do we even have a control panel? Presumably programs can install control applets (capplets in gnome-speak), but I don't see any way to see them other than executing the cpl files manually.

A few months ago Jaco Greeff had mentioned he was working on it, we covered that back in issue #148 . The tool was advanced enough for Jaco to show off a screenshot. Dimi replied to Mike:

Last time I talked to Jaco, he was busy finding work. Hopefully he'll resurface soon, maybe he has a nice surprise for us :).

Thing is, that particular configuration applet is the key to our autoconf efforts. Once that's in place, we can do C1 right away, as well as C3. C5 seems to be just a matter of getting some work done, as the proposed solution appears to be working just fine. C6 seems to be simple, once all the other pieces are in, while C7 looks like it's in a usable state already.

What he's referring to are items off the to-do list. In particular C1 and C3 are merging configuration into the registry and making the defaults good enough to allow starting of the control panel without other configuration. Wine has had the ability for quite some time to use it's registry (similar to Window's registry except text editable) to store program data. However, without tools to actually edit the thing - and vi doesn't count - it just hasn't been worth abandoning the traditional config file.

Jeff Smith gave a pointer towards another tool that comes with Wine, Try 'wine control'. That is our winelib control panel app if I am not mistaken.


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.