Vincent Povirk > If Wine is running on Linux, it can always be detected by making Linux syscalls. Wine cannot fix this. Other than the fact the secuirty systems of Linux can watch syscalls. So calling 1 that wine don't use equal dead application. Yes it is even possible to block sys-calls from inside wine loaded exe's from the Linux system itself while allowing the dll.so files of wine perform syscalls. I do keep my eyes on what prototype secuirty systems exist. Wine could make it simpler by the way. Method is what LUK has been doing. Add a set of syscalls to the OS kernel itself for wine. Using anything else could be disregard. Since the syscalls would be emulations of windows it would effectively render you blind. It is foolish to claim something cannot be fixed in software. Software everything basically can be fixed its a pure question of time and resources. Wine does not need to fix this at this stage due to OS secuirty. I was not claiming wine contained a sandbox. Wine can be sandbox by the secuirty system in Linux. So leading to problems. Its so simple to think just because you detect wine that you can now do whatever you like. This is not windows. Doing whatever you like equals dead applications. Problem with detecting wine without asking is if wine is sandboxed you end up doing things that get programs terminated. Most people planing work around most likely are planing to reach out to native code that can major upset the secuirty system of Linux. If your work around sticks to wine and windows based code you are not going to get on the wrong side of the secuirty system. Both wine and the secuirty system of linux are evolving. There is a correct path that will never harm. Ask. You are looking at wine alone and forgetting the OS around it. Not a wise move. David Gerard and austin987 the bug clean outs don't happen often. Its simple case of search ability of database bigger the database the slow it is to search. Result is always a risk of a number being recycled from it. You can depend that a open bug number will never move. You cannot depend that the bug number in like 8 years time will refer to the same bug. Bugs are designed to be temporary records not record for all time. Also recycling of the number does not happen straight a way. You are talking years at least from the time it was taken from closed and sent to void before its reused. Problem here we still have people wanting to run in wine programs from windows 3.11. So any application using wine could be still in use in a 100 years time at the rate things are going. Since it been on codeweavers server have been taken care of the bugzilla its been the most stable in its history. Problem here you do have to think longer time scales than even the time codeweavers has assisted wine. Before locking yourself into something. Wine version numbers are for all time. Those will never be deleted from record due to needing to search. So never risk being recycled by mistake. One case of bug recycle was caused by server crash by the way was not noticed for a few months then it was corrected. That could be enough to really screw up an application. History tells us not to trust bug numbers absolutely. They are data and open to problems. Wine has a really long history and only 6 major upsets in that time is a really low number. Its very much like earthquakes. If you are in a zone they can happen you build house earthquake resistant. Thinking longer than 5 years is something really different to what normal windows coders have to do. This is where we are butting heads. I am thinking huge timescales and history.
