Wine Traffic #161 For 14 Mar 2003

This is the 161st release of the Wine's kernel cousin publication. It's main goal is to act as spam magnet for my email account. It also serves to inform you of what's going on around Wine (the Un*x windows emulator).

There were 40 different contributors. 26 posted more than once. 25 posted last week too.

TransGaming put together a preview release of WineX 3.0. The noted the following additions:

Hardware accelerated Vertex Shaders have been implemented. These are only supported on OpenGL drivers which implement the NV_vertex_program extension. The ARB extension will be supported in future releases (post 3.0 final)
Render to Texture and Cube Mapping support implemented for cool texturing effects.
Many installer related issues have been resolved; starting installs with autorun.exe should now work in many cases, multi disc installs should now have fewer issues with disc changing, and large installers are now supported. Additionally, significant effort has gone into making InstallShield 6 graphics update correctly.
Better handling of X11 Window Manager idiosyncracies - WineX 3.0 does a much better job of going into 'full-screen' mode.
Many texturing robustness fixes.
SecuRom copy protection speed has been improved by up to 50% in some instances.
A combination of optimizations should provide faster game play for some games.
A new ALSA sound driver backend has been provided although it is untested at this point.

They also announced the availability of The Sims on it's own - no need to buy the Mandrake distro just to run it. For more details concerning TransGaming, check out the March Development Status Report.

I've some major trouble with wine's thread implementation. We're porting a soundprocessing application to linux/wine. (It will run as Win32 app under wine in the first step). Sadly the wine thread implementation and/or the sheduler does not get the priorities right. The mission critical sound task will not get as much attention as it needs.

We've tried some hacks to improve it (increasing linux kernel priorities using set_sheduler/set_priorities) but this doesn't really fix the problem. Then we tried to make it even more ugly by creating a own thread using the clone() system call. This fixed the timeslice problem but opens up other strange problems. (Random crashes here and there). Most likely due to missing lock issues or something like that.

I would appreciate any hints which could make things run more smoothly! Basically 2 ways are left to go:

Fix the wine sheduler to obey priorities
Fix the thread (locking?) issues

Thanks a lot for any information!

Eric Pouech suggested some how working on the first idea might help with the problem. Florian wrote back with more details:

I've added some Enter/LeaveCriticalSections calls around the handler and it seems to make things much better (but still far from beeing perfect).

What prevents wine from distributing timeslices correctly? Even if i renice/boost linux kernel sheduler of the whole wine process(es) things go wrong a lot. The processing thread gets way to small amount of attention.

Do you have some hints on how to boost the processing thread a bit? I'm perfectly happy with an (even ugly) hack. I've tried to identify the wine sheduler, but was unsuccesful :( Maybe you can point me in to right direction (file, line #)?

As far as a "Wine scheduler" goes, Ulrich Weigand explained why he had a hard time locating it, " Actually, Wine does not have a scheduler as such (well, it has a scheduler for 16-bit tasks, but not for 32-bit processes/threads). Wine threads are just normal Linux tasks created with clone(). The usual Linux scheduling rules should apply ..."

So priorities from Win32 threading are pretty much ignored. Ove Kåven explained why, " The Linux scheduler, you mean? Wine doesn't schedule threads on its own, Win32 threads are just normal Linux threads. I'm sure we'd have done something with the Win32 priorities a long time ago if we thought it would work. But Linux doesn't allow a non-root process to increase its scheduling priority (and of course people shouldn't run Wine as root), so it mostly seemed to just be an exercise in futility, and that's why I think nobody has bothered. And I don't expect this to improve..."

David Laight thought the scheduler allowed scheduling priority to be decreased though. Reducing some threads and allowing others to run at the normal level might achieve the affect of making some threads a higher priority. But Ove thought there might still be a problem with that, " Yeah, I believe it does [let you reduce the priority], but I don't think it'll let you increase it back to the original level afterwards. Anyway, the problem with doing that is, if Wine would somehow reduce the priority of all "normal" priority thread, and let "high-priority" threads run at original priority, then Wine processes would be at a significant scheduling disadvantage relative to ordinary Linux processes, and this could be even worse than the status quo. It might make sense to do this for "low-priority" threads though, but very few apps would create those. "

Mike Hearn suggested something that might be possible, " Anyway, if this guy needs control of priorities for his app to work, then perhaps he just needs to run Wine as root and implement the priority switching code. Sucks, but then the whole root vs everybody else needs rethinking or improving anyway imho."

For the past few weeks, I've been working with John Kopplin on getting the Petzold examples compiling under Wine using his Gnu Makefile package, available from: http://www.computersciencelab.com/Petzold.htm

It took some work, but we've done it. The good news is that all (but 3) examples compile just fine. This has been accomplished while making absolutely _no_ changes to the original source, and very few (and obvious) changes to the GNU Makefiles.

This is very good news, as it shows we can have a common build system between Wine and Windows. The only samples that don't work just yet are those from Chap21 which build DLLs, and DLL creation is yet not supported by winegcc. I hope this will change in the near future.

The problems that needed fixing were very simple, and quite obvious. They fall into 2 categories:

The samples expect to link with the msvcrt, not the Unix libc, so we had to pass the -mno-cygwin flag to the compiler/linker. Under mingw this is the default behaviour. This change is actually beneficial for the Windows port as well, as it will allow the samples to be build using Cygwin's gcc also. As such, it should be considered a portability fix, rather than a Wine specific fix.
The filnames used mixed case (not matching the actual name on disk), and some includes use backslash (\), intead of forward slash (/index.html). This problem is typical and simple to address in a portable manner if you can modify the source. As we wanted to not touch the examples in any way, we had to find another way around it. Luckily, Unix accepts virtually any char in a filename (except / of course), as well as links. So we just created the appropriate symbolic links where necessary, or just renamed the file if it made more sense.

All these renames / symlinks creation was collected in a nice little intallation script. So, without further delay, here are the instructions on how to try the sample under Wine.

$ mount /mnt/cdrom $ mkdir petzold $ cd petzold $ cp -r /mnt/cdrom/* . $ wget http://www.computersciencelab.com/Petzold.zip $ unzip -a Petzold.zip $ bash Wine/install.sh $ make

Enjoy!

This patch probably shouldn't be applied... it's just to let everybody know where I'm at with the named pipes code.

The patch moves away from using unix pipes to implement named pipes, and instead implements pipes internally. This is necessary to implement message mode properly (without race conditions).

I don't have time to work on it this week, so don't expect anything new before the weekend. If anybody wants to play with it or comment, feel welcome.

I've started trying to pass some of Dan's tests, but it still fails... Dan, your test's coverage is great!

Since Mike's patch is a big rearchitecting that Alexander isn't totally comfortable with, how about something along these lines as a first step? To reflect the fact that freshly minted named pipes can be connected to, I added an fd_for_peer variable that is only set when a named pipe is first created, and added a new state 'ps_fresh_server' to mark pipes which have been freshly created, and arranged for find_partner to be able to find partners in multiple states.

I didn't bother dealing with refcounting of the fd_for_peer variable that holds the file descriptor.

George Plymale dropped a note to list problems he was having with Lightwave. Overall the application was very close to working. Mike Hearn suggested George start the debugging process to get to the real source of the problems: " To be honest, debugging is something best done by somebody familiar with the app, and who actually has a copy. I don't know how much experience with coding you have, but I'd suggest you read the the wine users guide and developers guide, those give an intro to debugging and sit down and work through the problems. For crashes, try using winedbg to get a backtrace, if you can get a good backtrace that can help with crashes. "

George discovered a demo was soon to be available and developers could download it to help improve compatibility:

I just spoke with Newtek this morning and they said that they are actually going to post a trial version of LightWave this week, around Wednesday or Thursday! So that's a real plus for this. Also, you are right it appears that they do use their own widget library, however Window's widgets do appear to be used for some dialogs.

Hopefully with this trial becoming available we can work through this.

Mike Hearn didn't think it would necessarily lead to any fixes, " As I have said before, you'll probably have to do this yourself. Unless you can find a developer to debug it for you, it's safe to assume we're all busy with other things. This happens every so often, sometimes somebody gets interested and pops up with some patches or notes, but it's by no means guaranteed."

Martin Wilck did some huge improvements to Winsock over the past year. This week he announced he won't be able to contribute as much:

I am sorry to announce that I won't be able to continue as wine's winsock maintainer. I will be lacking the time and power to fulfill a maintainer's duties appropriately. I guess I have already failed to do so in the last 2 months.

There have been few bug reports lately, so the code isn't completely broken for my successor, I hope. On the other hand, I would have liked to clean up some other things like the select() call and the transport provider interface. The fact that I didn't have the time to get going on these also shows that I'd better hand this off to someone else.

I'll be coming back here, and perhaps I'll have more time for contributions some time in the future. In any case, I'll be available for questions or complaints about the winsock code under this email address and under my private email, mwilck@freenet.de. I have certainly not lost interest in Wine, Linux, and Free Software.

Working with you guys has definitely been great fun and I have learned more than in years before.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	8 Mar 2003 - 14 Mar 2003	(1 post)	News: WineX 3.0 Preview
2.	11 Mar 2003 - 12 Mar 2003	(13 posts)	Thread Latency
3.	12 Mar 2003	(1 post)	Petzold Example Programs
4.	4 Mar 2003 - 9 Mar 2003	(3 posts)	Named Pipe Patch
5.	7 Mar 2003 - 11 Mar 2003	(7 posts)	Lightwave
6.	11 Mar 2003	(1 post)	Need New Winsock Maintainer

Wine Traffic #161 For 14 Mar 2003

By Brian Vincent