I'd prefer to run Darwine (a.k.a. Wine for OX) because it will allow me to run just the Windows applications that I want without Windows, but in the mean time Boot Camp will suit me just fine. Boot Camp will certainly be a boon for Intel Mac customers and is sure to drive sales of Apple's newest iron.

Now, however, White said, "sadly, it'll take a bit of the buzz out of our own Mac product launch [which is coming soon], but what the heck, we compete with dual booting on Linux OK."

He's said he's "not sure" what the overall effect Apple's move will have on CodeWeavers and the Linux desktop, but "I hope it means more people buy Macs; I crave a world with far more OS diversity than we have today."

Just found by random web search...

http://www.microsoft.com/genuine/downloads/FAQ.aspx?displaylang=en

...
Q: Will systems running WINE pass WGA validation?
A: Wine is an implementation of the Windows 3.x and Win32 APIs on top of X and Unix. When WGA validation detects WINE running on the system, it will notify users that they are running non-genuine Windows, and it will not allow genuine Windows downloads for that system. Users of WINE should consult the WINE community for WINE updates. It is important to note that WINE users, and other users of non-genuine Windows, can continue to download updates for most Microsoft applications from Microsoft application-specific sites, such as Office Update.

It's not ALSA vs OSS, but changes in the pipe code at about that time changed how tasks waiting on pipes were scheduled due to code by Linus and Ingo. Hence why I'm suggesting testing 2.6.17-rc1 because I noted this could cause scheduling problems and modified the code recently to fix this and it was pushed into 2.6.17-rc1. This should cause an improvement in latency with any tasks that wait on pipes.

This patch gives me rock solid audio in Imperium Galactica 2. No more white noise, clicking or destabilising half way through.

It exposes a race that I'll send a fix for later, for now I am hacking around it with a sleep(1) at the end of RtlUserCreateThread. The race is that you can do this:

hthread = CreateThread(...);
SetThreadPriority(hthread ...);

and the set_thread_info server call will occur before the thread has fully initialized, so, we don't know the UNIX tid and cannot set the priority. My current idea is to fix the race by forcing RtlUserCreateThread to wait for the thread to sync with the server using an event.

This patch only implements support for TIME_CRITICAL threads. Mapping priorities at a finer level of granularity is still on the todo list.

Final thing - there has been on/off discussion about the security implications of this in the past. But, this code needs to be implemented anyway, regardless of outcome, and on SuSE at least I think AppArmor can be used to allow for thread prio raising without full root access. So IMHO the permissions debate layers on top of this. Until an acceptable solution is found some users may wish to just run Wine as root and play their games, which they know are trustable.

Until it crashes your box of course... I really don't think we want to encourage running as root, or give Windows apps a way to screw up the system. If we have to require people to upgrade their kernel to get the feature that's fine; at least then when the box dies we can blame the kernel guys ;-)

If a Windows program has a habit of hard freezing the system then the user will learn not to run that program.

As it is, right now _many_ games suffer this problem with corrupted audio and it's very unpleasant (loud bursts of white noise). Makes the games unplayable, in fact.

I'd rather make the games playable and give developers an incentive to find a better privilege model than leave this to coast along for another few years with only a bunch of talk, ideas and non-mainline patches.

Right now there are no good solutions for this we can implement in Wine itself (except maybe making wineserver suid root and drop privs), and SCHED_ISO isn't merged into the mainline kernel, so telling users to upgrade won't solve much.

I agree that it's not good, but this patch makes the best of a bad situation and it's better for the users this way. If they don't want to run as root, they don't have to, and if - like me - they know the game is safe and wish to have some fun this evening then they can.

Just using the JACK audio driver won't ensure that we won't see stuttering sound. If dsound is performing hardware emulation then it has its own internal thread that is performing mixing and other dsound events. If this thread gets held off then you'll have no sound to give to the jack audio drive when it runs.

Increasing the size of this dsound buffer and ensuring that it runs seems like the easiest ways to fix issues with the dsound thread being held off and should work for all audio interfaces assuming their threads also run reliably.

Just tested Mike's patch with realtime-lsm. Running Wine as regular user now gives perfect audio with no stutter for every application I tried so far. So yes, realtime-lsm actually does the trick - me happy! ;) I load realtime-lsm with "gid=18 mlock=1 allcaps=1" (gid 18 is audio), and set wineserver to root:audio. Easy solution, great results!

SCHED_ISO is a stable, mostly realtime solution for normal users. The one scenario that SCHED_FIFO was required _over_ the capabilities of SCHED_ISO is only professional audio sampling/capture work where one process may require almost 100% cpu for bursts of many seconds. Therefore for audio playback, SCHED_ISO is more than qualified.

While I'm pleased that SCHED_ISO fixes the problem for many people on this thread, I have to tell you that it is not the solution to your problem for a number of reasons. My motivation for creating this scheduling class was for transparent realtime performance to be attainable for an ordinary desktop user without their knowledge or previous setup. The reason is that the current system for giving realtime privileges to ordinary users is complicated and not set up properly by hardly any distributions. This is the real time rlimits capabilites which is already in the kernel.

I do not believe you are going to need real time scheduling to get audio to work properly. This really is overkill in my opinion. However if you really want to go down this path you need to use the kernel infrastructure that is already in place. The realtime rlimits is there and works. Getting modern distributions to have it set up by default properly is the first challenge. I have not investigated to see who has done this, but if they are not then pinging the distribution maintainers or even helping them set it up is the thing to do here. Providing walk-throughs on setting it up (until the distros catch up) and using the system from within wine seems appropriate.

Works _much_ better with 2.6.17-rc1(-g6246b612). Though I still sometimes hear 'spikes' or 'bursts' (short pulse, high frequency), don't know what produces them but it really hurts my ears, they usually appear when the CPU is under heavy load (when WoW loads world data from the harddrive or when I switch from/to the workspace where WoW runs, but here I suspect wine's window handling code to block somewhere for too long), but now much less now, in fact, it appeared only once/twice in 10 minutes playing which is really great.

As some of you may have heard, last month Coverity set up http://scan.coverity.com as a site dedicated to scanning open source projects for defects. In just 1 month, over 4500 defects have been examined by various open source developers, and from what we can tell, it seems that there have been over 2500 patches to the scanned code bases! Due to popular request, I'm happy to announce that we've added Wine to the list of projects scanned on the site. For those of you not familiar with "scan" yet and by way of introduction ...

I'm the CTO of Coverity, Inc., a company that has technology that performs static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (the "Stanford Checker"). The reason I'm writing is because we have set up a framework internally to continually scan open source projects and provide the results of our analysis back to the developers of those projects. To see the results of the project, check out:

http://scan.coverity.com

My belief is that we (Coverity) must reach out to the developers of these packages (you) in order to make progress in actually fixing the defects that we happen to find, so this is my first step in that mission. Of course, I think Coverity technology is great, but I want to hear what you think and that's why I worked with folks at Coverity to put this infrastructure in place. The process is simple -- it checks out your code each night from your repository and scans it so you can always see the latest results.

Right now, we're guarding access to the actual defects that we report for a couple of reasons: (1) We think that you, as developers of Wine, should have the chance to look at the defects we find to patch them before random other folks get to see what we found and (2) From a support perspective, we want to make sure that we have the appropriate time to engage with those who want to use the results to fix the code. Because of this second point, I'd ask that if you are interested in really digging into the results a bit further for your project, please have a couple of core maintainers and/or developers reach out to us to request access. As this is a new process for us and still involves a small number of packages, I want to make sure that I personally can be involved with the activity that is generated from this effort.

So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to register on our site or email me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too.

If this is the wrong list, my sincerest apologies and please let me know where would be a more appropriate forum for this type of message.

A few of these are more tricky. EG:

• One was wrong, it didn't track the fact that the given variable was initialized by a subroutine
• Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I don't think we want to add lots of missing NULL arg checks in the public API implementations. An application will never pass NULL to this function directly as otherwise it'd not work at all, so, a crash with a NULL arg here probably is revealing some other bug.
  
  I'd rather it crashed cleanly in a debuggable way than silently return error code and continue, in other words ...
• It has identified a codepath through the server window station code where a struct desktop could be dereffed without being initialized. But I am not sure if this codepath is logically possible. Somebody more familiar with that code (eg Alexandre) would have to check if it could actually ever be taken or not.
• Some of these are bugs that aren't really a high priority, eg leaks in winegcc (which doesn't live very long anyway)

Still. A real treasure trove of data here. Thanks Ben!

Wine's build time dependency on FontForge is causing a bit of a problem, as can be seen by browsing the wine-devel archives for the last month.

I propose that a small sfd2ttf utility be written and used instead of FontForge to eliminate the dependency, and make everybody a little happier.

George Williams, the author of FontForge, is happy for us to use his code under LGPL, providing that we give the correct attributions. He'd probably like to sign off on the final code though.

Alexandre agrees with the idea of an sfd2ttf utility, and is likely to accept it into the Wine tree, provided that is small enough (read 1/2 files) and is appropriately cut down.

As I'm busy with my day job at the moment, we're only missing somebody to write it. Any volunteers?

I thought I'd give an overview of the status of the ddraw merge. Well, basically it's progressing nicely, and the first huge part of the merge has been done. The necessary type changes were made to include/wine/wined3d_types.h and include/wine/wined3d_interface.h, so ddraw can now use the wined3d interface header.

I have uploaded an updated patch against Wine from yesterday, 23:30 to my website (http://stud4.tuwien.ac.at/~e0526822/). It contains a few fixes, like yet another refcounting cleanup( Ihope that this works fine now :) ), and the performance issue on my radeon card, as well as the mipmap issues(all cards) are fixed :)

What is next? I will send patches which create the new WineD3D methods needed for ddraw. These patches won't contain the implementation, but just the entry in the vtable and a stub function. So if someone disagrees with a method, then we don't have to discuss about the bare existance of a method and it's implementation at the same time :)

Additionally, I will now start writing a lot of test cases for all DirectX versions, with an eye for reference counting, in hope that we can fix the refcounting crashes finally. I have a test for some unimplemented functions in my local tree too, like ProcessVertices.

Once the function stabs are in, and the tests show where we have to go to, I'll send the implementation of the functions. After that, all that is left is to merge the ddraw.dll code, but first some regression testing has to be done. I'll ask then for some testing help here and at wine-users, so we can catch regressions before they can occur :)

Thanks for all the help with testing and coding so far :)

The 2006 SourceForge.net Community Choice Awards have been announced ... and it seems the Desktop Winner is:

"WINE ..... for Darwin and Mac OS X"

Strangely enough, our project directly does not appear to be listed at all in the "Desktop" category.

Still considering whether to be sad or happy.

I have now added us to the "Desktop environment" category.

Could someone clue me in to just what this means and why it is:

err:virtual:NtProtectVirtualMemory Unsupported on other process

A quick Google comes up that function is undocumented, so I don't have much info on it.

From the wine source:

if (!is_current_process( process ))
{
ERR("Unsupported on other process\n");
return STATUS_ACCESS_DENIED;
}

And that's self explanatory, but why is it "Unsupported on other process"?

There is already a lookup in the server, but there is no cross-process syscall for NtProtectVirtualMemory (and in fact for all of the other virtual memory functions). The cleanest fix is to get the kernel to support this. One suggested way of fixing this and other cross-process problems in Wine without kernel support is to change the context of the target process to set up a call to the relevant function and restore the registers afterwards. AFAIK, no one has tried to implement this yet.

The wineserver would have to trigger some code in the client, either by having a signal or a generic background thread that could do it on behalf of the other process.

Such a scheme has been discussed before for things like CreateRemoteThread and friends.

That would be usefull too for multithreaded direct3d. Somehow we have to bring another thread to releasing the glxContext, so we can re-use it in a new thread.

Any chance we can do this with signals? e.g. SIGUSER1 to call a wine-provided callback function, which calls callbacks registered by the various dlls?

After discussing this at length on IRC with another coder, we think that the easiest solution would be to have one GL context per thread (and multiple contexts can share the same rendering target and also texture handles). If we add 'intelligent' (i.e. 'lazy' or 'just in time' :-) ) state change evaluation it could even be pretty efficient code-wise (maybe not so efficient in the GL driver though as it may lead to more 'pipeline flushes' than the 'hacky' solution). After we just have to rely that this is properly implemented at the GL driver level...

I once wanted to toy with this in the DDraw code base but well, seeing that it will phased out pretty soon I did not do any work on it. On the other hand I could try for some specific games (like DungeonSiege) as an experiment to then port it over to WineD3D.

I have started adding gphoto2 support to twain.dll.

My current work (before a otherwise busy week begins again), is attached.

I started to break up the currently very sane centric view.

Alexandre/Aric, can I do it this way? Some other general comments?

(The code btw works as-is for detection at least.)