Bart Oldeman wrote: > You mean the current CVS sources (which were indeed last updated three > days ago)? Just so I know what you mean?
Exactly. Initially I downloaded them from the Web interface but then I realised that I would have to do it many times from now on and did it the *right* way (using CVS ;-) > I'll have another look; for me a high-loaded tdsk.exe (2.30) works so you > might want to keep it simple first by trying an empty config.sys which just > has something like > > dos=high,umb > device=fdxxms.sys > device=umbpci.sys > devicehigh=tdsk.exe > > and then try some permutations (himem instead of fdxxms, emm386 instead of > umbpci) and so on. You're right, but I usually play the Yes/No game with F8 instead. The permutations are too many, but the essential result is that BITDISK (TDSK Jr.) works for me too, when loaded low *and* high, unlike the other drivers which appear to work when loaded low but not high. I suspect this is because of a problem I found now, similar to the previous one I found, about which in a while... > Which compiler do you use to compile the kernel by the way? Initially I played with Borland C++ 4/5 but when I figured out that its code was buggy (or at least the kernel is not optimised for it) I moved to Watcom. So I use Open Watcom 1.0 now. But I compile for 386. And now to let you know what I've found. I've got a copy of a little but excellent DOS utility called DUMPDOS (the author is unknown to me but he had done a great job as you will see) which you can download from my website (http://linux.tu-varna.acad.bg/~lig/dumpdos.exe) that dumps all the DOS internal data structures including the LoL, MCBs, DPBs, buffers, and many more. Using DUMPDOS with the original build 2030, I found that all the installable drivers had dpb_unit of zero, but dpb_subunit was correct. But now (with your patches applied) I've found exactly the opposite - the dpb_unit is correct, but dpb_subunit is zero! And this is persistent, no matter if the drivers are loaded high or low. I can't see any updates of the global number of block devices blk_dev.hs_name[0] after the initial call of dsk_init() in main.c (which is done before installing the drivers from CONFIG.SYS). Maybe this is done indirectly when the passed "dhp" to init_device is &blk_dev?! But then I don't see such a call. I think that the problem may result from blk_dev.dh_name[0] not being updated to reflect the real number of drives after config.sys is processed. Lucho ==^================================================================ This email was sent to: [EMAIL PROTECTED] EASY UNSUBSCRIBE click here: http://topica.com/u/?b1ddyi.b3hwCs.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] TOPICA - Start your own email discussion group. FREE! http://www.topica.com/partner/tag02/create/index2.html ==^================================================================
