To: caldera-opendos AT rim DOT caldera DOT com, opendos AT delorie DOT com References: Message-Id: From: "Arkady V.Belousov" Date: Thu, 11 Sep 1997 03:09:12 +0400 (MSD) Organization: Locus Reply-To: ark AT mos DOT ru Subject: Re: CDD driver Lines: 70 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Precedence: bulk X-Comment-To: Steven D. Sybesma Hi! 10-σΕΞ-97 11:44 sybesma AT dimensional DOT com (Steven D. Sybesma) wrote to caldera-opendos AT rim DOT caldera DOT com: > On Wed, 10 Sep 1997, Arkady V.Belousov wrote: > > What about universal ATAPI CDD driver? Have Caldera plans for it? Most > > "partial solutions" are (1) problematic (incompatability) and (2) memory > > greedy (5K for ACER CDD driver, 30K for Sony CDD driver). > Wouldn't a universal CD-ROM driver be memory greedy by nature? Not neccessarily. You think, 5K for Acer CDD driver too many? Not forget - they work not only for Acer CDD... > The ideal situation would be to use the driver provided by the manufacturer. Of course, but - (1) they can be too big, (2) they can be buggy or incompatible with some soft, or (3) they can be missed. > You don't want code for a bunch of different CD-ROMs loading into memory > along with the code for just your CD-ROM drive. The smaller the better. I ask only about ATAPI CDD, but _good_ programmer can write code, which keep in memory only required code from "a bunch" (if they don't want to combine they to one code). > Case in point: I have a Toshiba XM-5302 4x ATAPI drive. > The driver from Toshiba has the smallest memory footprint of any I've found. How many? > The Oak Technology driver that came with my drive is the worst memory hog of > all three I've tried. There is no more functionality that I've found in it [...] > Now, if you could get the complete specs on a particular drive and write the > driver specifically for it, that would be the ideal situation. On one of my machine with Intel's Triton chipset (licensed from Triones) I use Triones' _universal_ CDD driver with 7.5K in size. What about this? Who wrong - Oak or Triones? > The only thing that Caldera can do is improve the NWCDEX.EXE program, which > is not really a driver but is a type of DOS extension to allow the drive to > communicate with DOS. This not only "extension", this is _very_ big and _buggy_ extension. :( NWCDEX eat 2-3 times more memory, than MSCDEX, but with NWCDEX don't work, for example, Acer Sertek's CD Pro 2.7 CD player. :( I think, integrating to NWCDEX _additional_ (but optional) universal CDD driver be great. Also as integrating HIMEM.SYS to EMM386.EXE. 10-σΕΞ-97 14:37 pbranna AT clemson DOT edu (Paul W Brannan) wrote to caldera-opendos AT rim DOT caldera DOT com: > > Wouldn't a universal CD-ROM driver be memory greedy by nature? > > The ideal situation would be to use the driver provided by the manufacturer. > > You don't want code for a bunch of different CD-ROMs loading into memory > > along with the code for just your CD-ROM drive. The smaller the better. > With TSR's, it is not a requirement that the entire TSR remain resident, > only that there is enough memory to load the TSR all at once. The problem > I see is that the universal CD driver is going to be large at first, but > will shrink, and so getting it to fit into an upper memory block on > machines where UMB's are scarce or scattered might be a challenge. You both forget "selfloading" techniques, used, for example, in smartdrv. Hower, smartdrv also have bug :( - they load high two module (10K and 13K), and second module placed high only when there are more than 20K! Sucks...