Hi Bernd... > > Hi, I got some strange problems with DEVLOAD: > > If I use it to load any of my ramdisks, FreeDOS > > becomes unable to "cd .." or "cd \"...
> Which kernel, shell, himem and emm386 versions, Newest himem / emm386 and two of the 2035* kernels tested... > contents of config.sys and autoexec.bat, MEM /C, MEM /D... Lots of things - but the problem already happens with minimal drivers loaded as far as I can tell (tested in F8 mode). > Which ramdisks? > *xsmdsk.exe commandline, > *xmsdsk.exe config.sys (DEVICE=), > *xmsdsk.exe config.sys (INSTALL=) > *xmsdsk.exe devload, As told, only DEVLOAD is affected. I usually load XMSDSK as DEVICE with the /t option, but found that this causes troubles with MS Win3.1 EMM386 (4.44), while loading XMSDSK from commandline does not cause those troubles. Anyway, the "I can no longer do cd .." problem ONLY happens for DEVLOAD. Did not test with INSTALL but I assume same results as for commandline there. If you have time, please test all four styles both with and without FreeDOS EMM386. Thanks... > *MS RAMDRIVE.SYS which of above mentioned loading methods? Don't have it. > *TDSK, which methods? Not sure if I tested DEVLOAD, but the problem does NOT show up with the normal commandline and DEVICE= loading styles for sure. > *Deskwork ramdisk, which methods? This ramdisk is a sys file, so you can only use DEVLOAD (and work- alikes) or DEVICE=, and the "cd .. problem" only happened with DEVLOAD. > *SHSHUfdrv.exe, which methods? Did not test. If you have time, test. Same for SRDISK. > How is the behaviour on MSDOS? I only own Windows 3.1, not MS DOS. > How is the behaviour on DRDOS? Don't have that installed, sorry. Just the EMM386 of it - but I should make clear that all the DEVLOAD tests focus on FD EMM386 and on no-EMM386 environment. It may or may not help to use other EMM386, but it would be VERY interesting to hear whether DEVLOAD works better with non-FreeDOS kernels for ramdisks. By the way, I never noticed "cd .. problems" after DEVLOADing USB-stick drivers. > other commandline devicedriver loaders, like CTLOAD or > DEVICE.COM (from Qemm) or DYNALOAD If you have time and have those loaders, please test. > > size of 15000k, which should default to 468 clusters > > fat12, 32kb per cluster, 1 fat, 512 root dir entries. > "should" ? what's the actual geometry then? Ramdisks do not technically have a geometry, but yes, I did use the syntax DEVLOAD filename 15000. > EMM386 is not a factor in the problem? or is it? I assume it is not, although there is a separate problem: AuGoS reboots when you ask it to play against itself if a ramdisk is loaded as DEVICE= and the EMM= option of EMM386 is used. All other combinations now work with AuGoS :-). (e.g. no ramdisk, commandline ramdisk, no EMM= option, no EMM386) I hope this helps with testing. If you multiply all factors, you would get far too many test-runs, but you can do a linear test: Use FD kernel / himem / emm386, DW ramdisk, but use something else than DEVLOAD. If that helps, good to know. Use non-FD kernel, FD himem / emm386, DW ramdisk, devload. If that helps, the problem is kernel. Otherwise probably devload. Use newest fdos.org kernels and apart from that, the usual stuff. If that helps, we should probably release an improved kernel on SF.net, as most people (me neither) do not do weekly kernel sys updates from fdos.org... Newest can mean either stable or devel. The debug-kernels do not seem to work, as you said (too big in RAM, too many messages?) and the 386-kernels might still be emm386-incompatible (please test if you have time - it MIGHT also be yet another "32bit register changed during init or some xms/a20/umb function" problem caused by emm386, but my gut feeling blames the kernel ;-)). You should get the idea - keep most factors constant and change one at a time until the cd .. problem stops happening. Then check if using the "seems to cause cd .. problems" component can work properly in non-FreeDOS environment - if so, more than one component is involved. But the "change things until problem goes away" test would already be very useful even if you do not do the test whether the component "gets more stable outside FreeDOS". Eric PS: Make sure to take notes on paper to avoid double-testing ;-). ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
