Hi Bret, thanks for explaining UPC/EAN.
>> Either way, using the UPC for copy protection of games is pretty >> much pointless, because you can easily copy that as well, so I >> still FIRST want to know whether games REALLY rely on that for >> their copy protection scheme. here we have the smart Eric from 2021 explaining the art of copy protection to the 1990 developers. I have no idea if copy protection was implemented by all/part of games using UPC or whatever else. neither has master Eric. reading the description of OAKCDROM and use this to make any conclusion is a bit premature. > Like you, I really doubt that's how they do it. But I suspect it > does have something to do with the sub-channel data. > My problem with Jack in this case is that he has only provided half > a driver -- it doesn't even support all the standard IOCTL functions > it's supposed to. If Jack would just provide a complete IOCTL > command set it would probably work just fine however they > implemented the copy protections scheme. this might be right. however he provided a driver that has worked for 15+ years without anybody complaining. we call this 'good enough' here ;) now that one single user complains about games you expect Jack to jump to fix this issue? I wouldn't either. now we have a problem: we need a person with a lot of time and motivation (obviously Eric), who is knowledgable in programming and debugging (by the style of his recommendations Eric again) to fix this without testing as he doesn't have these games. and Jack most likely doesn't have these games either. unlikely to have an easy solution. so I recommend Paul to use OAKCDROM and call it a day. Tom _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
