Agreed. Can't we just delete HKEY_CLASSES_ROOT/Software/Wine or move it to another name?
In any case, at least from a technical point of view, going around such test ought to be fairly simple
If the mere existence of this key makes the validation fail, what's to stop a virus from simply adding this key as a way to stop legitimate users from downloading the security fix for that same virus? If MS is really doing what we think they may be doing here, I don't think they are going to be enjoying it for long. They are (what else is new?) shooting themselves in the foot (again?).
They're probably famous for that already ;-).
I don't think we want to go there. I demonstrated a way of checking for Wine to Rob last night that we really cannot fix or workaround, and if I can think of it they certainly can too.
I think I know what way you are thinking of. Not sure someone less versed in the way Wine works (it's an emulator, right?) would figure that one out, but I guess you are right. I'll try to catch you on IRC and see if we are, indeed, talking about the same thing.
Basically if we start integrating workarounds into Wine, it'll lead to an arms race we cannot possibly win.
Technically, it will probably cost them more than it will cost us. Then again, they also have more resources. I'll just point out that I don't think there is anything inherently wrong with MS wishing to keep the parts that truly are core Windows for Windows legal license users only. The main problem with MS is that what they call "core OS" can get quite absurd.
Better to ensure our users don't need anything from that website.
Amen to that. So, opengl, dcom, what else do we need? :-)
Write our own replacement. Try OpenGL first. We might have to clean-room reverse-engineer DCOM.
IMO, the `core' operating system (besides the CD!) is the main installation disks and service packs. Anything else is what I call a `program'.
Samuel Lauber
Hi,
On Fri, Feb 18, 2005 at 05:36:52PM +0100, Sam Lauber wrote:
Agreed. Can't we just delete HKEY_CLASSES_ROOT/Software/Wine or move it to another name?
Eh?? This is certainly a non-solution. Since they cared as much as actively checking for a Wine key and preventing downloads in the case of success (a thing that I'd never imagined they would do since it's quite likely illegal), they can enhance their checks anytime (remember: we're in the internet era with online updates occurring every other day...) with further Wine keys to check for.
This is like the fly trying to escape the fly killer until it finally gets screwed royally, despite all its useless attempts to escape.
IMHO we should re-examine the exact nature of this check (you really want to be sure in such critical matters), and if it is found to be deeply problematic (i.e. it is an *active* check for Wine containing the Wine registry key inside the Microsoft binary and it does block Wine under most circumstances), then think about whether we'll do anything about it.
Instead, we could just choose to set our winver to XP for this update program. And the fact that Wine users are blocked from non-system updates could lead to further Wine development, as others have pointed out already.
If however we decide that it is absolutely critical for us to have access to those updates, then we should do something about it: if it is a clear violation of the Sherman antitrust act (interoperability etc.) then we should ask Microsoft to remove this check in their next online update of the update program (an update which doesn't block Wine, that is!). If they don't comply even though they probably need to (and knowing MS too well they probably won't, but there might always be a big surprise), then legal proceedings might be in order. After all we don't want to end up like DR-DOS or WordPerfect or Novell (and countless others?) which have all been tricked by MS's API "changes", right?
But one thing is (almost) for certain: the current registry key will remain.
Andreas Mohr
-
Andreas Mohr -
Sam Lauber