Wine Traffic Brian Vincent

This is the 95th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Next week's issue will likely arrive on Tuesday, or possibly later depending on how many threads there are. I'll be on vacation next week. On a related note, does anyone have any suggestions as to what to see or do at Lake Powell, UT?
CodeWeavers Transgaming TransGaming

Alexandre has unleashed a new snapshot unto the world. On Thursday Wine-20010510 was cut and made available. The source is available via http at http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010510.tar.gz or through ftp at ftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/Wine-20010510.tar.gz.

The main changes include:

  • a ton of printing enhancements (check out last weeks issue about the addition of CUPS support)
  • graphics driver restructurations
  • changes to facilitate a port to NetBSD
  • and lots of other fixes for bugs

Also out this week were a pair of interesting stories in the press.

The first one, from GameSpy.Com, is titled Ports vs. Wine. As Linux Today describes it, "GameSpy takes on the question of whether Linux gamers are better off waiting for Linux ports (which aren't as plentiful as many would like) or getting behind Wine. Includes commentary from Gavriel State of Transgaming, which is working on bringing DirectX to Wine; and an assortment of pro-ports people including Scott Draeker of Loki, who maintain that compatibility layers are bad news". This is what Gavriel had to say in the article:

TransGaming doesn't see WineX as competition for source level porting efforts from companies such as TribSoft and Loki. Rather the opposite: WineX compliments the existing Linux games market by keeping Linux users in Linux to play their games, even when the developer or publisher has decided against a direct Linux port. TransGaming is certainly not going to be spending any effort on games that have already been ported by Loki or TribSoft.

Keep in mind also that WineX can be used for source level compatibility (aka Winelib) to speed up the process of recompiling games using Linux-based compilers and development tools, and thus taking advantage of Linux-specific features where they make sense. In fact, internally we use the Winelib approach for regression testing with the various Microsoft Direct3D samples.

It's not an either/or situation. We'll see some games being played under the Wine binary loader, some ported"natively" to Linux using Winelib and some direct access to Linux APIs, and others rewritten from the ground up using APIs like SDL.

The true strength of Linux and Open Source lies in diversity and choice, and having multiple approaches to game portability is just one more aspect of that strength.

Also included in the article is a nice screenshot of Shiny's Sacrifice running with WineX.

The second article out this week is "Plug-ins to enhance browsers of Linux-based appliances" from EETimes. It starts off:

Looking to narrow the gap in features between Windows- and Linux-based platforms, CodeWeavers Inc. has developed a series of browser plug-ins such as Shockwave and QuickTime for Linux-based Internet appliances.

CodeWeavers' Crossover plug-in software, scheduled for a May 15 launch, will be offered to Internet appliance manufacturers building platforms that run Linux or any Unix-like operating system.

And then further down:

In addition to the Crossover plug-ins, CodeWeavers plans this fall to launch Crossover display, which will let an Internet appliance start up a Windows application installed on a nearby PC with a click of a button, but without a Windows OS. And Crossover server, scheduled for release in mid-2002, is a complete Windows-compatible Linux-based server.

Damjan Lango posted note about speeding up the wineserver:

Some time ago here was a discussion about speeding up the communication between the wineserver and the application with various kernel patches. I was reading "Unix Network Programming, volume 2 - IPC" and ran over a "doors" IPC api that is implemented on Solaris and has the lowest latency. According to the book it is ~3 times faster than pipe. Actual values for Solaris 2.6 in the book are: (in miliseconds)

    doors: 121
    sysv msgq: 260
    pipe: 324
    unix dom. socket: 465
    posix msgq: 584

...

There is also a link to a Linux implementation of doors on: http://www.rampant.org/doors/

On this link you will find also more info on doors.

But according to the performance tests that the author made, the linux pipe is somewhat the same speed as doors so maybe it could be optimized more or maybe is Linux's pipe already so optimized that doors are unnecesary.

So what do you think, would this be useful for speeding up wine? I apologoize if you already know about this...

Marcus Meissner replied with:

What a coincidence ;)

I just did a patch changing the critical section handling to become more of a spinlock.

I have attached it. This should reduce the critical section based reschedules between:

    wine <-> wineserver <-> wine

to:
    wine <-> wine

Since critical sections are thought to be 'fast' and 'short time' locking primitives, and Win32 threads should not sleep in a critical section, we can just give up our timeslice and wait for the other thread that has the lock to continue.

This is a preliminary version, but it works. It uses 'LockSemaphore' as differentation between process-local and global critical sections.

It uses 'sched_yield', which is a POSIX feature, to give up the timeslice. How does one force a reschedule on another UNIX? Is

select(0,NULL,NULL,NULL,shorttimeout);
reliable?

This patch can give spinning processes on SMP systems, but I do not consider this a real problem at this time.

I would like to know if there is something wrong with the concept ;)

At least winword feels a bit snappier now.
codeweavers

Sean Callahan sent a message that asked what could be done to help out with Wine. Francois Gouget sent a lengthy reply that listed a lot of items:

Hmmm, I think I can also find a list of bugs in bugzilla that could easily be fixed by someone new to Wine:

Easy:

  • Builtin msvcrt mishandles the cmdline to argv conversion #234: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=234 This prevents 'wine /mnt/win/Program\ Files\whatever\foo.exe' from working if you're using the builtin msvcrt!
  • I'm almost 100% certain that there's another bug in the same function in its handling of the environment variable.
  • PrgWin95/98: System metrics differ from the Win9x values #48: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=48 One day I'll fix this one... I swear. Unless you want to work on it first. In that case I'll provide you with my test application and dumps of the metrics for Win95, Win98, NT4, ...
  • The doc about the command line arguments and the config file is out of date. I'm sure there are plenty of other things that are out of date.
  • Get the VXCL samples, test them with Wine and report the bugs in the bugzilla database. I know there's lots of them. Then people (or yourself) can start fixing these bugs in a distributed fashion.
  • PrgWin95: Listbox getting a recessed border instead of a flat one #56: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=56 (I can provide you with the sample application)
  • I think it would be nice to add a tool that displays the dlls version information like 'About' does in the windows explorer. I have some code you could use as a starting point and I think it could be merged with winver. In fact this would be almost stabdard windows programming.
  • There's a bug in the drawing of the border of the common control tabs. Fixing each of the four instances of the code is easy. It would be interesting to find a way to factorize some of this code.

Medium (I expect these would take longer or be a bit harder)

But let us know also what kind of work you would like to do and what kind of things you're best at:

    - C programming
    - Debugging
    - Windows programming
    - tweaking shell scripts
    - writing/fixing documentation
    - doing web stuff

It also depends on what motivates you: getting an application to work, implementing some new functionality, getting applications to compile, fixing scripts, fixing documentation or writing new documentation...

And the last parameter is how much time you have for Wine work. In any case it's probably better to start with something simple to see if you like it.

And in a completely different thread it was asked how to submit code once something has been fixed. Francois also replied to that with:

> Have a look at http://www.winehq.com

More precisely:

Should you run out of FIXMEs (!), don't hesitate to ask for ideas of things to hack on this list.

Ove Kåven Eric Pouech

Ove Kåven posted a patch on the wine-patches list with updates on some code he wrote for using gdb to debug Wine apps:

For any sufficiently disillusioned Wine hackers, here's my current experimental code for letting GDB attach to a Wine process. It's reasonably featured (exceptions are caught, changing threads work, single-stepping works, software breakpoints work, you can do backtraces, change registers and variables, etc). You can also do "info shared" to get a list of loaded .sos, and use the "sharedlibrary" command to load their symbols, but I strongly recommend against loading symbols for libpthread.so, or you'll destroy the neat "info thread" display.

This code has helped me quite a bit in my debugging, actually, when winedbg couldn't be used...

Apply autoconf after patching. Engage with ./configure --enable-remote-gdb

I assume Alexandre isn't going to like some of the stuff in here, but I suppose it's up to him whether to take it or leave it...

He was right, Alexandre responded with:

How did you guess I wouldn't like it? ;-)

Actually I think it's a neat hack, but it doesn't belong in the server at all. You should be able to do the same thing as a client-side process using the Win32 debugging API. It could be either a stand-alone Winelib app, or a special mode inside winedbg so that you can reuse some of the code in there.

Ove responded to this and said that he could attach and detach gdb to a running process whereas the winedebugger can't do that. Eric Pouech cleared this up with some instructions:

> winedbg can't, at least nobody knows
> how to attach winedbg to a running process.

well, winedbg can... and now everybody *SHOULD* know

start winedbg without any argument on commande line then, use command

    walk process

you'll get a list of running processes using the command

    attach <pid>

really attaches to the running process

the only drawback of the method (compared to gdb interface) is that the Win32 API doesn't allow to detach the debugger from a running process the only issue is to kill the debuggee (or the debugger)