Wine's goal with regard to copy protection is to run the copy protection correctly. If, for example, a program requires the original CD to run on Windows, it should require the original CD to run on Wine as well. However, there are many forms of copy protection that Wine cannot run at all. In this case, the software will normally refuse to run. Where this issue usually comes up in relation to Wine is when a user wants to run a program in Wine that has copy protection that Wine cannot run. In these cases, bypassing the copy protection (using e.g. a no-cd patch) can sometimes enable the program to run. However, Wine itself does not aid the user in doing this. The user would have to install software in Wine that circumvents the copy protection. > Can someone please explain to me where the issue in that post I linked to above, came from? What was the issue orignally? You should look at who is the author of that post. I haven't read the entire thread containing that post, so I don't know the details, but I think that sort of discussion has come up multiple times in the past. Wine has the technical ability to provide a replacement for any .dll, .exe, or device driver, whether they are shipped with Windows or not. For example, Wine ships its own openal32.dll that works based on the native openal libraries. Windows doesn't include openal32.dll, but some games do. Wine uses its own version of openal32.dll in preference to the version shipped with those games. For some kinds of copy protection, it may be possible for Wine to replace important components with versions that circumvent them, or to behave in a way that is specifically designed to make copy protection fail. Alexandre Julliard is the only person who can approve changes to Wine, and it is his policy not to allow changes designed to circumvent copy protection.
