> To test whether UPC features are accessed, my proposed
> experiment is a binary patch to break the UPC read call
> in OAKCDROM and see whether that is enough to make the
> copy protected game refuse to run,
good idea. as you have obviously a lot of time to spend why don't you
do this yourself?
> as specified in my
> original OAKCDROM related email here.
a lot of your emails are longer then my tolerance of boreness
> Of course I could also patch CDRCACHE to intercept UPC
> access and show whether and which values are read from
> the real CD (not possible with UDVD2 yet) but also to
> return arbitrary injected UPC values etc. I think this
> would be a second step after the much simpler experiment
> with the binary patch mentioned above shows whether the
> call is relevant at all.
both are excellent ideas. just go ahead.
> Actually people already give negative youtube reviews
'people give negative youtube Reviews' ?
wow. that's really impressive.
> when
> they simply have to download extra drivers to make things
> work, so it would be a bonus to have it in UDVD2 *if* it
> turns out that it would make a difference for games.
so you reasoning is like:
IFF the real cause of games misbehaving is lack of UPC support
THEN (
making kernel memory management better
encourage Jack to implement UPC
maybe games work better
)
ELSE
a lot of wasted developer time
use OAKCDROM
so it starts with resolving the IFF.
good luck. you seam to have the required time, so that's not an excuse
Tom
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
