Hi all,
Finally I gave FreeDOS a try with my overly complex [FD]CONFIG.SYS:
FCBS=1
STACKS=0,0
LASTDRIVE=J
COUNTRY=359
DOSDATA=UMB
DOS=HIGH,UMB
DEVICE=C:\DOS\UMBPCI.SYS /I=D400-EFFF
DEVICE=C:\DOS\HIRAM.EXE
DEVICEHIGH=D:\SRC\FDUTILS\BIN\FDXXMS.SYS
DEVICEHIGH=C:\DOS\BITDISK.EXE
DEVICE=C:\PCM\CNFIGNAM.EXE /DEFAULT
DEVICEHIGH=C:\PCM\PCMSSIT.EXE
DEVICEHIGH=C:\PCM\PCMCS.EXE
DEVICE=C:\PCM\PCMRMAN.SYS
DEVICEHIGH=C:\PCM\PCMATA.SYS
DEVICEHIGH=C:\DOS\VIDE-CDD.SYS /D:CD001
DEVICEHIGH=C:\DOS\NANSI.SYS /S
DEVICEHIGH=D:\SRC\FDUTILS\BIN\LBACACHE.SYS BUF 32
INSTALLHIGH=C:\DOS\SHSUCDX.EXE /D:CD001
INSTALL=C:\DOS\XMSDSK.EXE 188416 /T /Y
INSTALL=C:\DOS\CTMOUSE.EXE
INSTALLHIGH=C:\DOS\ISOCYRH.COM
SHELLHIGH=C:\4DOS\4DOS.COM C:\4DOS /P
The results are mostly satisfying with two exceptions, small and *BIG*:
0) No worry: SS365SL.EXE didn't work so I replaced it with PCMSSIT.EXE.
1) Small worry: INSTALLHIGH didn't load high but that's nothing to the
2) *BIG* worry: Drive letters are sequentially assigned to block device
drivers, but when all DEVICEs are processed (in the above config, E: for
BITDISK.EXE, and F: & G: for PCMATA.SYS, the CD-ROM driver (SHSUCDX.EXE)
starts again with letter E! After a day of investigation I finally found
a way to fix this, changing the 10th line from the bottom of init_device
--- KERNEL\MAIN.C- 2003-06-18 20:27:40.000000000 +0200
+++ KERNEL\MAIN.C 2003-06-22 11:47:00.000000000 +0200
@@ -569,7 +569,7 @@
if (!(dhp->dh_attr & ATTR_CHAR) && (rq.r_nunits != 0))
{
- dhp->dh_name[0] = rq.r_nunits;
+ blk_dev.dh_name[0] += dhp->dh_name[0] = rq.r_nunits;
update_dcb(dhp);
}
Why I did this patch? On the final buffer allocation in init_kernel()
( PostConfig();
LoL->nblkdev = 0;
update_dcb(&blk_dev);
), blk_dev.dh_name[0] was still = dsk_init() (25 lines ago) so any added
block devices were actually discarded when we update_dcb(&blk_dev). So
updating blk_dev.dh_name[0] in init_device() fixes this - now all drive
letters are properly assigned (H: to SHSUCDX.EXE, and I: to XMSDSK.EXE).
So far so good...
But with this patch applied, any access to drives beyond D: crashes the
kernel (divide by zero, stack 0051 FFFF 0246 2EEA 0000 24F1 0000 A4F6...
and so on). Normally this happens as early as in InitializeAllBPBs() but
even if I remove the call to it, it happens as soon as I try to access a
drive beyond D: (E:, F:, G:, H:, I:). I've tried to fix it for one more
day but failed - because I'm not really so acquainted with the internal
workings of the kernel [yet]. That's why I ask you for help. Please help
me help you fix this. Maybe my patch is wrong? I only tested build 2030.
I don't know if that's a long lasting bug or just newly introduced, but
I hope Bart or Tom can much more easily find the reason for it than me.
Thanks a lot in advance!
Luchezar Georgiev, Bulgaria
==^================================================================
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
==^================================================================
