James at superbug.co.uk
Fri Oct 6 06:56:55 CDT 2006
Tim Schmidt wrote:
> On 10/6/06, Kai Blin <kai.blin at gmail.com> wrote:
>> On Friday 06 October 2006 10:19, Tim Schmidt wrote:
>> > Again, works for me. I believe the only part missing for this case is
>> > the simulation. Of course, there's the added possibility that apps
>> > will go mucking about with data other apps care about, in which case a
>> > per-executable simulated device would be best.
>> Wouldn't that break on Windows, too? If I have have two apps that
>> muck about
>> in my mbr, I expect them both to work, so they better do whatever
>> they do in
>> a sane way. I don't see how this would be different for a simulated
> Yeah. you're right. I just don't trust every app that mucks about
> with the MBR to be courteous and correct ;)
Messing with the MBR might be the windows way, but last time I looked,
even windows apps cannot access the HD directly.
In Linux, any access by a user app to the MBR should never happen,
except maybe by cfdisk,lilo grub and friends. Certainly NOT a wine
No one in their right mind would run wine as root, knowing how many
viruses windows has.
I would suggest that these applications are not actually writing to the
MBR, but instead there is a bug in wine causing it to happen.
The only way to fix this whole MBR issue, is to find an application with
copy protection, and actually get it to work. We will then have 100%
accurate data regarding what feature we would actually need in wine to
allow these copy protected applications to be compatible with wine.
End the speculation.
More information about the wine-devel