> The main topic of my off-list exchange with Jim was something > else: Jack not wanting to add UPC read support to UDVD2, being > upset about Jim hinting at a compatibility problem with UDVD2 > after my OAKCDROM comparison, where I suspected that Lukas' copy > protected games might be looking for UPC data, which is mostly unqualified speculation, but still ...
> which is one of > the notable differences between both drivers. Whether UPC checks > make sense for those games is VERY questionable, but they still > are something I would like to be tested by some DOS gamers. I have to admit that I don't even know what UPC is. OTOH this should be tested by a developer who is at least able to detect if UPC features are even searched for by these games. both in a OAKCDROM and UDVD2 environment. Jack is absolutely right to refuse to implement UPC just in case it might be required by some games. > So while discussing this personal topic off-list, I had > brought up the point what Jack's drivers WOULD be able to > have a FAR lower DOS memory footprint if FreeDOS had better > HMA and UMB compatibility to MS DOS and other DOS brands. > Which is a problem which has been known for years. Those > features in his drivers work well, but you can not enjoy > them on FreeDOS. DEVLOAD can be a workaround in few cases. that's exactly the point. DEVLOAD does provide a work around in most (I'd had said 'all') cases. it's mostly a problem with UDVD (and friends) insisting on being a device driver that causes this problem. modern (>1990) programs are TSRs, not device drivers. > So we are missing out on existing features of the drivers > because OUR side, necessary kernel features, are missing. while true, kernel memory handling at init time is far from trivial (you may call it contrieved). I remember that it took me quite some time to move the kernel to HMA (and UMB) at all. I also remember Bart doing quite a lot of changes (and I assume spending quite some time) to arrange memory slightly different to have MEM/MSD better reporting what portions of memory are attributed to what driver. I know what Jack is missing, and I think it is far from trivial to implement and keep everything else together and thus time (and motivation) is lacking. so DEVLOAD is the proposed solution. Tom _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
