Wine Traffic #95 For 13 May 2001

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.

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.

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

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.

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)

• Provide a pedump utility #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 I know there's sample code that does that already floating around so it should be relatively simple.
• wrc fails on preprocessed files #115: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=115 I believe it's just a grammar problem. You'll need to know (or to get cozy with) lex/yacc...
• CreateIcon does not resize bitmaps #175: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=175 I did a similar fix somewhere some time ago. I can provide a sample application and I might be able to point you in the right direction.
• winemaker: 'winemaker --nomfc' does not have the intended effect #227: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227
• winemaker: Ignores the '--with-{mfc,wine}' options once they are cached #225: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225 If you're familiar with autoconf and know how configure scripts should behave...
• StrokePath ignores PS_JOIN_xxx #11: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11 This should not be too difficult to fix but it would certainly help if you are familiar with GDI.
• Checking the differences between what's in the Windows dlls and what's in our spec files... and fix the contents of our spec files as appropriate. I already have a list of all the APIs in each of the dlls for Win95, Win98, NT4 and Wine2000, plus a script that can show the differences.
• Enhancing the above perl script.

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.

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

More precisely:

• CVS http://www.winehq.com/dev.shtml#CVS The best way to stay up to date.
• wine-patches http://www.winehq.com/mailman/listinfo/wine-patches It's best if you subscribe to wine-patches (otherwise each of your emails will go through the moderator)
• Wine Developer's Guide: Chapter 4. Submitting Patches http://www.winehq.com/Docs/wine-devel/patches.shtml All you need to know about submitting patches (I hope)

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

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

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)