On Mon, Mar 24, 2008 at 1:02 PM, Austin English <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 24, 2008 at 12:51 PM, James Hawkins <[EMAIL PROTECTED]> wrote:
> > On 3/24/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > http://bugs.winehq.org/show_bug.cgi?id=9484
> > >
> > >
> > > --- Comment
On Mon, Mar 24, 2008 at 12:51 PM, James Hawkins <[EMAIL PROTECTED]> wrote:
> On 3/24/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > http://bugs.winehq.org/show_bug.cgi?id=9484
> >
> >
> > --- Comment #9 from Austin English <[EMAIL PROTECTED]> 2008-03-24
> 12:43:54 ---
> > Can anyone t
On 3/24/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> http://bugs.winehq.org/show_bug.cgi?id=9484
>
>
> --- Comment #9 from Austin English <[EMAIL PROTECTED]> 2008-03-24 12:43:54
> ---
> Can anyone test this in wine 0.9.58? Some other copy protections are working
> better, and if this isn'
On Thursday 29 November 2007 14:00:00 Ben Hodgetts (Enverex) wrote:
> Just a thought but it may be a good idea to add a keyword to Bugzilla
> for issues related to debuggers or copy-protection, that would help
> group them all together as at the moment there seem to be many bugs
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just a thought but it may be a good idea to add a keyword to Bugzilla
for issues related to debuggers or copy-protection, that would help
group them all together as at the moment there seem to be many bugs
related to breakages from obscure debugger
t 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
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 suc
On 10/6/06, Kai Blin <[EMAIL PROTECTED]> 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 abo
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 dev
or simulate it. That easily covers both cases since copy
protection would presumably work on c: and disk utilities would work
with real disks.
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 mucki
ive letter has a device
associated with it. If it doesn't (c: doesn't), then either don't
allow it or simulate it. That easily covers both cases since copy
protection would presumably work on c: and disk utilities would work
with real disks.
If it's really about what drives the p
On 10/5/06, Vassilis Virvilis <[EMAIL PROTECTED]> wrote:
How about a loopback device in linux?
This is potentially already possible to do with wine. I use loopbacked
CD images, so loopbacked MBR's should be easy enough, with no change
to wine. Just set the device node link for the device to
To clarify my thoughts, and throw this out there... Here's how I'm
imagining this working:
Assuming there's no problem intercepting the raw disk i/o attempts,
the first time an app attempts a raw disk access, Wine can throw a
popup (I know, I hate them too) with something like the following
text
On 10/5/06, Christoph Frick <[EMAIL PROTECTED]> wrote:
the #2 folks are proficient enough with their systems to know what they
are doing. the #1 folks hope to get away from the world of #2 things
they are forced on the windows world when they change to unix.
Not nescessarily. I'm thinking spec
On 10/5/06, Mike McCormack <[EMAIL PROTECTED]> wrote:
UML has a COW (copy-on-write) layer [1]. If we had something like this,
conceivable we could allow Wine to read raw disks (or the COW file),
then write back to the COW file.
QEMU has nice support for several different COW and sparse format
Mike McCormack wrote:
Tim Schmidt wrote:
It sounds like a general framework for routing these kind of raw disk
i/o would be useful... probably configurable by app would be most
useful.
UML has a COW (copy-on-write) layer [1]. If we had something like this,
conceivable we could allow Wine
On Thu, Oct 05, 2006 at 04:25:38AM -0400, Tim Schmidt wrote:
> What we're talking about here is a class of applications that expect
> raw (or nearly-raw) disk access:
>
> - copy-protection that writes mysterious things to or near the MBR
> - various utility software (
Tim Schmidt wrote:
It sounds like a general framework for routing these kind of raw disk
i/o would be useful... probably configurable by app would be most
useful.
UML has a COW (copy-on-write) layer [1]. If we had something like this,
conceivable we could allow Wine to read raw disks (or t
It sounds like a general framework for routing these kind of raw disk
i/o would be useful... probably configurable by app would be most
useful.
thoughts?
I agree, a sandbox system where the 'litter box' (a sand box to put
all your crap) would hold potentialy dangerous direct disk accesses to
re talking about here is a class of applications that expect
raw (or nearly-raw) disk access:
- copy-protection that writes mysterious things to or near the MBR
- various utility software (virus scanners, disk defragmenters,
forensic tools, etc.)
- other possibilities?
Some of these tools - the fo
On Wed, Oct 04, 2006 at 07:10:41PM +0200, Kopfgeldjaeger wrote:
> 2. raw disk access normally requires root rights. It's very unlikely
> that Alexandre would permit anything which requires to run wine as root
> (even if those are only additional features)
and its very unlikely, that a sane perso
On 10/4/06, H. Verbeet <[EMAIL PROTECTED]> wrote:
On 04/10/06, Jesse Allen <[EMAIL PROTECTED]> wrote:
> Guys, Wine programs can write to the MBR already with correct permissions...
I think that should read "with wrong permissions" :-)
Yes, very wrong from a security standpoint :P
Le mercredi 04 octobre 2006 à 21:14 +0100, Martin Owens a écrit :
> It's a very very bad idea, I don't understand why linux doesn't
> protect normal users corrupting the disk at byte level that just seems
> really bad for security.
Every distro does AFAIK. However if people mess with their user's
On 04/10/06, Jesse Allen <[EMAIL PROTECTED]> wrote:
Guys, Wine programs can write to the MBR already with correct permissions...
I think that should read "with wrong permissions" :-)
On Wed, Oct 04, 2006 at 09:41:16AM -0500, Tom Spear wrote:
>
> I agree that we shouldn't write to the MBR, but I definitely think that we
> should get some legal guidance before we proceed with writing anything to a
> file (in this case), because
If it isn't a silly question, which part of the m
It's a very very bad idea, I don't understand why linux doesn't
protect normal users corrupting the disk at byte level that just seems
really bad for security.
On 10/4/06, Aaron Slunt <[EMAIL PROTECTED]> wrote:
Jesse Allen wrote:
> Guys, Wine programs can write to the MBR already with correct
>
Jesse Allen wrote:
Guys, Wine programs can write to the MBR already with correct
permissions...
http://bugs.winehq.org/show_bug.cgi?id=4672
I hope nobody needs to explain why that's a very bad idea...
On 10/4/06, Karsten Anderson <[EMAIL PROTECTED]> wrote:
why not just implement the write to MBR? figure out how the copy
protector does it and just implement it. as long as you know what
you're doing and where the O/S stores its stuff you should be alright.
put a few warnings on the instaeller a
Maybe someone from FSF could provide legal guidance on this issue.
http://www.fsf.org/about/contact.html
Hi,
Karsten Anderson wrote:
> why not just implement the write to MBR? figure out how the copy
> protector does it and just implement it. as long as you know what
> you're doing and where the O/S stores its stuff you should be alright.
> put a few warnings on the instaeller and whatnot that this
On Wednesday 04 October 2006 09:25, Karsten Anderson wrote:
> why not just implement the write to MBR?
The user running Wine more than likely won't have such write access to the
disk. Only root would be able to do that, and running Wine as root is far
from encouraged. Plus, fooling around with t
Quoting EA Durbin <[EMAIL PROTECTED]>:
What makes copy protection problematic to circumvent is not the math or the
technical stuff, it is the laws protecting it :-(
how does cedega do it?
They license the code for the copy protection detection from the likes
of macrovision.
--
D
What makes copy protection problematic to circumvent is not the math or the
technical stuff, it is the laws protecting it :-(
how does cedega do it?
t the user decide for himself :)
On 10/4/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> what keeps some nosy haxx0r from looking in the MBR (or some blocks
> later) if he wants to find out about the copy protection? if they store
> data like this unprotected (e.g. crypting the
> what keeps some nosy haxx0r from looking in the MBR (or some blocks
> later) if he wants to find out about the copy protection? if they store
> data like this unprotected (e.g. crypting them) then this is just
> security-by-obscurity (which is no security at all).
Copy protection IS
On Wed, Oct 04, 2006 at 04:09:51PM +0100, Martin Owens wrote:
> Anyone techinicaly adept could find the MBR, it's the 1st sector on
> the disk, this isn't about boot records but the MBR which is in a
> known place. I recon you could use linux tools on your windows hard
> drive to retrieve it easy.
On 10/4/06, Jonathan Ernst <[EMAIL PROTECTED]> wrote:
Le mardi 03 octobre 2006 à 15:51 -0500, Tom Spear a écrit :[...]>>> I'm by no means an expert on copyright law or copy protection, but I> think that using any method other than writing directly to the MBR
> with thos
at the same time, but it's just a thought. Anyone care
> to comment on that?
what keeps some nosy haxx0r from looking in the MBR (or some blocks
later) if he wants to find out about the copy protection? if they store
data like this unprotected (e.g. crypting them) then this is just
s
Technically yes, but the difference is that VMware actually writes
_everything_ into that one file vs wine proposing to write just what is
written to the boot sector into a file..
The reason it is different, is because it is much more difficult (if not
impossible) to tell what is boot sector and
Le mardi 03 octobre 2006 à 15:51 -0500, Tom Spear a écrit :
[...]
>
>
> I'm by no means an expert on copyright law or copy protection, but I
> think that using any method other than writing directly to the MBR
> with those copy protection measures would be illegal be
On 10/3/06, Martin Owens <[EMAIL PROTECTED]> wrote:
On 10/3/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote:> > I'm by no means an expert on copyright law or copy protection, but I think> > that using any method other than writing directly to the MBR w
On 10/3/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote:
> I'm by no means an expert on copyright law or copy protection, but I think> that using any method other than writing directly to the MBR with those copy> protection measures would be illegal because writing
On 10/3/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote:
> I'm by no means an expert on copyright law or copy protection, but I think
> that using any method other than writing directly to the MBR with those copy
> protection measures would be illegal because writing
I'm by no means an expert on copyright law or copy protection, but I think
that using any method other than writing directly to the MBR with those copy
protection measures would be illegal because writing to a file (registry,
wine-only proprietary db or any other type of file) as oppos
Hello
> Sure there are tools out there that crackers use
> that read the mbr and store it in a file, so that they can circumvent the
> copy protection, but that has nothing to do with wine.
IANAL but curcumventing for personal use using generic tools (wich wine is)
and with no bad i
On 10/3/06, Robert Lunnon <[EMAIL PROTECTED]> wrote:
On Tuesday 03 October 2006 02:18, James Courtier-Dutton wrote:> Martin Owens wrote:> >> Re Copy Protection.> >>> >> be quite hard to make this work I think?> >> > It would be quite dangerous to m
On 10/3/06, Robert Lunnon <[EMAIL PROTECTED]> wrote:
Part 3 Applies, however it could be read as being permissible for the purpose
of implementing a compatible interface. IE for the purpose of making the copy
protection work under Wine. I think it would be much safer to make the
protectio
On Tuesday 03 October 2006 02:18, James Courtier-Dutton wrote:
> Martin Owens wrote:
> >> Re Copy Protection.
> >>
> >> be quite hard to make this work I think?
> >
> > It would be quite dangerous to make this work.
> >
> > What about crea
dependently created
> computer program with other programs, and to the extent that doing so
> does not constitute infringement under this title or violate
> applicable law other than this section.
>
> Appears to grant specific permission for the kinds of work the Wine
> devs need to
On 10/2/06, Marcus Meissner <[EMAIL PROTECTED]> wrote:
We can't, this kind of circumvention is likely to be illegal in the US.
The relevant portion of the DMCA reads as follows:
(http://thomas.loc.gov/cgi-bin/query/F?c105:6:./temp/~c105bzNC4v:e11559:)
`(2) No person shall manufacture, im
On Mon, Oct 02, 2006 at 05:18:57PM +0100, James Courtier-Dutton wrote:
> Martin Owens wrote:
> >>Re Copy Protection.
> >>
> >>be quite hard to make this work I think?
> >
> >It would be quite dangerous to make this work.
> >
> >What about crea
On 10/2/06, James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
The easiest way round this is to simply recognise the executable with
the copy protection, and simply install a hook to catch the appropriate
file system or registry calls and divert them to a special handling
routine to satis
Martin Owens wrote:
Re Copy Protection.
be quite hard to make this work I think?
It would be quite dangerous to make this work.
What about creating a file say with a fake data map, wine thinks it's
the direct access to the hard drive where all this information is
held. all we do is ad
Re Copy Protection.
be quite hard to make this work I think?
It would be quite dangerous to make this work.
What about creating a file say with a fake data map, wine thinks it's
the direct access to the hard drive where all this information is
held. all we do is add the place where the
Am Montag, 2. Oktober 2006 04:49 schrieb Vitaliy Margolen:
> EA Durbin wrote:
> >> So the short story is that copy protection support is the
> >> gating issue here, and it's a serious PITA.
> >
> > What specifically keeps most copy protection from working w
EA Durbin wrote:
>> So the short story is that copy protection support is the
>> gating issue here, and it's a serious PITA.
>>
>
> What specifically keeps most copy protection from working with wine?
> Why does it work in some applications, such as Star Wa
So the short story is that copy protection support is the
gating issue here, and it's a serious PITA.
What specifically keeps most copy protection from working with wine? Why
does it work in some applications, such as Star Wars Jedi Academy and not
others?
Ok, I just verified that HAL works perfectly fine for what we want. In
fact, it does make thing easier for people as you don't have to mess
with those device symlinks :)
I don't suspect anything wrong with GCC 4.xx now, as I think the
ubuntu package is compiled with 4.0.3. I think the report on t
s been traced to be a cause of a problem with
copy protection before when using wine compiled with it. You could be
right that HAL has nothing to do it. I will check it all out when I
get that version of GCC running too.
Jesse
On 8/7/06, Marcus Meissner <[EMAIL PROTECTED]> wrote:
HAL should be of no importance here, there will be no visible
difference to static CDROM configuration.
Otherwise, no clue.
Ciao, Marcus
I'm going to try setting up ubuntu with HAL on a spare machine and see
what it does. I use slack an
On Sun, Aug 06, 2006 at 02:32:23PM -0700, Jesse Allen wrote:
> On 8/6/06, Marcus Meissner <[EMAIL PROTECTED]> wrote:
> >On Tue, Aug 01, 2006 at 11:25:12AM -0700, Jesse Allen wrote:
> >> Does anyone have HAL and SecuRom copy protection working? I'm starting
> >>
On 8/6/06, Marcus Meissner <[EMAIL PROTECTED]> wrote:
On Tue, Aug 01, 2006 at 11:25:12AM -0700, Jesse Allen wrote:
> Does anyone have HAL and SecuRom copy protection working? I'm starting
> to get support questions with people using HAL and I'm not sure how to
> help the
On Tue, Aug 01, 2006 at 11:25:12AM -0700, Jesse Allen wrote:
> Does anyone have HAL and SecuRom copy protection working? I'm starting
> to get support questions with people using HAL and I'm not sure how to
> help them. I need information now that HAL support is in Wine on
>
On 8/1/06, Jesse Allen <[EMAIL PROTECTED]> wrote:
On 8/1/06, Martin Owens <[EMAIL PROTECTED]> wrote:
> the important part is not that HAL supports SecuRom (which it won't IMHO)
> but if wine can use the direct access to the hardware in order to allow
> securom to work through wine.
>
>
Yes, that
On 8/1/06, Martin Owens <[EMAIL PROTECTED]> wrote:
the important part is not that HAL supports SecuRom (which it won't IMHO)
but if wine can use the direct access to the hardware in order to allow
securom to work through wine.
Yes, that is correct. However I'm not sure if Wine interprets the
Does anyone have HAL and SecuRom copy protection working? I'm starting
to get support questions with people using HAL and I'm not sure how to
help them. I need information now that HAL support is in Wine on
whether SecuRom works with it and how to get it to work as I don't
have HAL.
Jesse
Jonathan Wilson wrote:
From what I understand, there are 3 ways to do copy protection in WINE
(at least for copy protection that needs a kernel driver to work):
1.Implement a WINE implementation of that kernel driver (in the same way
various stock windows kernel drivers have been implemented
From what I understand, there are 3 ways to do copy protection in WINE (at
least for copy protection that needs a kernel driver to work):
1.Implement a WINE implementation of that kernel driver (in the same way
various stock windows kernel drivers have been implemented). Problem with
this is
Dustin Navea wrote:
Guys, bug 2895 got me thinkin.. If we only support a handful of games
that use copy protection, shouldnt we file a bug in Bugzilla and append
that to 1434 (Get games working perfectly)? That way we can attach any
copy protection related bugs to this metabug?
Yes I think
Guys, bug 2895 got me thinkin.. If we only support a handful of games
that use copy protection, shouldnt we file a bug in Bugzilla and append
that to 1434 (Get games working perfectly)? That way we can attach any
copy protection related bugs to this metabug?
If you are agreeable to to that
about the version of WC3, or
because I'd just upgraded to a 2.6 kernel, or because of the Wine
version (20040309), but having upgraded Wine to 20040505 it no longer works.
Some work was done to load the copy protection drivers, it would be very nice to
get this working again. Can you try wine-200
rsion of WC3, or
> > because I'd just upgraded to a 2.6 kernel, or because of the Wine
> > version (20040309), but having upgraded Wine to 20040505 it no longer works.
> Some work was done to load the copy protection drivers, it would be very nice to
> get this working again.
Hi,
On Tue, 11 Nov 2003 03:05:55 +0100, KJK::Hyperion wrote:
> At 02.11 11/11/2003, Steven Edwards wrote:
> >>Further run fails for Captive as 'secdrv.sys' is somehow broken driver as
> >>it does not provide any way to mount a filesystem. :-?
>
> secdrv isn't a filesystem, nor a volume driver.
At 02.11 11/11/2003, Steven Edwards wrote:
Further run fails for Captive as 'secdrv.sys' is somehow broken driver as
it does not provide any way to mount a filesystem. :-?
secdrv isn't a filesystem, nor a volume driver. Filesystems and volume
drivers, in Windows NT, are special, and secdrv is nei
At 18.17 09/11/2003, Steven Edwards wrote:
The problem is how emulate windows kernel internal behavior (ie assembly
tips as NtCurrentTeb)
We have been looking in to loading this driver under ReactOS and all of
the functions are implemented but it still returns STATUS_UNSUCESSFULL. I
think that t
Hello Jan!
--- Jan Kratochvil <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Mon, 10 Nov 2003 20:19:45 +0100, Raphaël Junqueira wrote:
> ...
> > > BTW, I have got as far with loading secdrv.sys as crashing on
> unimplemented
> > > IoCreateDevice. I believe the Io* functions will be the biggest
> problems
Hi,
On Mon, 10 Nov 2003 20:19:45 +0100, Raphaël Junqueira wrote:
...
> > BTW, I have got as far with loading secdrv.sys as crashing on unimplemented
> > IoCreateDevice. I believe the Io* functions will be the biggest problems.
It is no problem loading it and initializing it by Captive NTFS for GN
On Fri, 7 Nov 2003 05:59, Alexandre Julliard wrote:
> The DMCA does not require copyright violation, what is illegal is
> "circumventing" the protection measure, it doesn't really matter if
> the replacement code has the same functionality or not.
Decryption is a different matter - that's banned
On Thu, 6 Nov 2003 20:00, Shachar Shemesh wrote:
> I don't get it. As far as I understand, so long as the code in the Wine
> archives does not allow running copied discs, we are not violating the
> DMCA. If someone else takes Wine code and modifies it, that's where the
> DMCA violation happens.
I
Lionel Ulmer; Marcus Meissner
> > Cc: Alexandre Julliard; Wine Devel
> > Subject: Re: copy protection - was: Re: Is it time for playing games on
> > WINE?
> >
> > Well it's not really easy as the NT_HEADER only declare:
> > Characteristics: 0306
&g
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Raphaël Junqueira
> Sent: 10 November 2003 08:05
> To: Lionel Ulmer; Marcus Meissner
> Cc: Alexandre Julliard; Wine Devel
> Subject: Re: copy protection - was: Re: Is it time for pl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Le Lundi 10 Novembre 2003 08:11, Marcus Meissner a écrit :
> On Fri, Nov 07, 2003 at 07:46:58PM +0100, Lionel Ulmer wrote:
> > On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote:
> > > Lionel, could QEMU be used here? I guess the drive
On Fri, Nov 07, 2003 at 07:46:58PM +0100, Lionel Ulmer wrote:
> On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote:
> > Lionel, could QEMU be used here? I guess the driver expects to have
> > kernel level access to the machine, so we could either:
>
> Well, as I have no idea how .SYS loadi
Hello,
--- Raphaël_Junqueira <[EMAIL PROTECTED]> wrote:
> it is simple, only a PE module who work on kernel mode using os APIs:
>
> - -=(FeniX as [EMAIL PROTECTED])-(on tty2)-(at 13:39:31)=-
> -={$:'~'}=->winedump dump -j import
> /mnt/win_c2/windows/system32/drivers/
> secdrv.sys
> Contents of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le Friday 07 November 2003 19:46, Lionel Ulmer a écrit :
> On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote:
> > Lionel, could QEMU be used here? I guess the driver expects to have
> > kernel level access to the machine, so we could either:
>
Hiya Lionel,
--- Lionel Ulmer <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote:
> > Lionel, could QEMU be used here? I guess the driver expects to have
> > kernel level access to the machine, so we could either:
>
> Well, as I have no idea how .SYS loading w
On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote:
> Lionel, could QEMU be used here? I guess the driver expects to have
> kernel level access to the machine, so we could either:
Well, as I have no idea how .SYS loading working and how it interfaces with
the kernel, I cannot comment here.
Mike Hearn <[EMAIL PROTECTED]> writes:
> Alexandre - do these options sound sane?
I would suggest investigating the problems before we start designing
the solutions...
--
Alexandre Julliard
[EMAIL PROTECTED]
* Write a "wine for drivers". There is prior art in this area, it could
be done, but might be an awful lot of work.
* Maybe use QEMU to allow the driver to be run in a VM. Even if we can't
invoke code directly here, RPC shims would work, I doubt a copy
protection driver has high throug
On Thursday 06 November 2003 03:31 pm, Geoff Thorpe wrote:
> War crime tribunals, environmental protection treaties, privacy
> legislation, ... the ability to let chilling effects meet little or no
> significant organised obstacle has become the trademark of a certain
> breed of "freedom-loving" pe
>"the Copyright Office ruled that the DMCA does not block software
>developers from using reverse engineering to circumvent digital
>protection of copyright material if they do so to achieve
>interoperability with an independently created computer program."
So some people in the US do believe in
>In the mean time, (and as long as people in the US are involved in Wine,)
>we're stuck with them.
Not is we publish (Host) wine outside the US.
>I don't get it. As far as I understand, so long as the code in the Wine
>archives does not allow running copied discs, we are not violating the
>DMCA. If someone else takes Wine code and modifies it, that's where the
>DMCA violation happens.
Right, I think a lot of people would be happy to host
"Ann and Jason Edmeades" <[EMAIL PROTECTED]> writes:
> [Ever had the feeling you regret asking a question...]
>
> Possibly another question for Alexander then - Realistically do you believe
> that we can ever support copy protection, and if so how?
I definitely think
[Ever had the feeling you regret asking a question...]
Possibly another question for Alexander then - Realistically do you believe
that we can ever support copy protection, and if so how?
If we can work out how to load the driver in question (which remember is
safedisk specific, there's o
g,
> there can be no problem.
>
> >I think you would have a hard time convincing
> >someone that a dummy driver that returns magic values is not
> >circumventing part of the copy protection, even if the resulting
> >behavior is identical to the original.
>
> If the
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> If the code in Wine still doesn't allow unprotected CDs from running,
> there can be no problem.
No, it's not that simple. By providing a replacement driver, you are
circumventing a technical measure controlling access to the work. The
fact is that wi
ction or not.
If the code in Wine still doesn't allow unprotected CDs from running,
there can be no problem.
I think you would have a hard time convincing
someone that a dummy driver that returns magic values is not
circumventing part of the copy protection, even if the resulting
behavior
not. I think you would have a hard time convincing
someone that a dummy driver that returns magic values is not
circumventing part of the copy protection, even if the resulting
behavior is identical to the original. OTOH you can make a pretty good
case that a generic "Windows driver loader"
x27;t edit this Wine code to
circumvent the commercial driver" in a C comment won't jive). Perhaps
I've misunderstood something about the copy-protection model here, but
the law itself seems to preclude a general open source solution, no
matter how you slice it.
[snip]
How abou
1 - 100 of 118 matches
Mail list logo
