Other solution is just to detect this and ask the user to rerun Wine as root. I don't think that'd be a big deal.
But then that brings up the issue of users not being able to run wine merely because they don't have root access, i.e. users on a Linux system in a business environment, or remote X/telnet access on a server with wine (for various reasons).
These people probably wouldn't be running scheduling sensitive tasks.
The idea of having to run under root was one of the ones why people avoid SVGAlib nowadays, and setuid/root will be a deep security risk considering what kind of apps we're looking at here. If we say, run notepad, we have a root editor application -- capable of messing with config files on the Linux setup -- something that the Linux admin might not want.
You can make Wine suid root and then sandbox it back down to standard user level privs + scheduling using SELinux, so it'd only be a security "problem" for a short while.
Given that we know of no Windows apps self-aware enough to escape the emulation I don't even see what security problems it can cause on home machines where the user has root access anyway. I guess if you got owned via Internet Explorer or something it would give attackers access to your configuration files but the chances of this happening and being taken advantage of are tiny.
If this is implemented, shouldn't this be a warning, not a forced thing? So that a normal user could (try and) run wine without root access? And I presume that this would be 2.6 specific detection - otherwise, there's not really a need (since Wine worked OK under 2.4 and such). We could say something like: "Wine has dectected that you are running Wine as a normal user under Linux kernel 2.6+. Due to changes in the scheduling mechanism in 2.6, which includes preempting and a change in the way process priorities are handled, Wine may not work properly, or different parts may work at different speeds, causing desyncronization of your application and/or it's components. You are suggested to <(run wine as root) or (downgrade and use a (2.4 kernel) AND/OR <supported kernels list>) or (list other workaround information)>."
Well, ideally it'd be only displayed when we detected a mismatch between the apps requirements and the underlying kernel scheduling. Which may not even exist: we haven't *proven* anything yet, just thrown theories around. Unfortunately the people most qualified to diagnose the problem are all as much in the dark as we are :(
Random point: the wording of that warning is terrible I'm afraid :) There's no way we could ever throw such a complex message in the users face, nobody would understand it! A much better way to word such a message would be:
"In order for this program to run correctly, you must run Wine with root priviledges. The program will proceed but you may notice audio stuttering or performance problems."
Even that's not ideal. It requires the user to:
a) Understand the concept of root == administrator user that should not normally be used, which is a non obvious mapping. It's one of those things you just "have to know", and we're trying to cut the number of these things as much as possible.
b) Understand what Wine is - obviously we can't get away from this entirely but long term I'd like to see Wine become just another Linux subsystem that does its job so well the user doesn't ever notice it
c) Understand *how* to run Wine with root privs. If you just su to root and run it, you can't start your app as you're now running with a different virtual Windows drive and registry. It's really not obvious how to do this even for experienced Linux users (answer, set WINEPREFIX)
Anyway. That's todays usability lecture over with :)
I presume that if someone wanted to get started writing a patch now using any one of these ideas, then we could just test it and see how it does among us, and then if it's okay, submit it, get it through CVS, see what happens, get it through a release if that happens, and then we can finish this debate only when performance issues or something else needs to be done about this.
I think we should get a much clearer idea of what's going wrong here first before trying to write patches or get code into CVS.
thanks -mike