On Tue, 9 Jul 2002, Oliver Ob wrote: > Let me introduce you to the general scenario. I have been running > PC BOARD 15.22 under Dosemu 0.67 - where lredir yet worked as it > should, nowadays, as I can hurtingly see from my first test, you > are no longer allowed to boot from a physical dos partition, > which is mounted into Linux tree AND redirect it back to DOS > access - Bart, is that really a feature?
yes, and it has been true since dosemu pre0.53.55. DOSEMU 0.67 and 1.1.3 behave exactly the same in this respect: they refuse to use direct partition access if the partition is already mounted. > Running Dosemu, I used to boot from an hdimage, which I built > using the script included in the package. The hdimage consisted > ONLY of the necessary Dos 6.22 files to boot, meaning the > config.sys, command.com, io.sys and autoexec.bat. > > The next step has been the very first command in the autoexec.bat, > I had my physical DOS Partition mounted to /mnt/c already and now > redirected it to Dosemu - which apparently does no longer work. > Bart, is that correct or have I missed something over the years!?!? Yes. But this is not direct partition access -- this is accessing a Linux filesystem through Lredir and is safe. This still works. Moreover it is generally no problem to have multiple programs access the files at the same time. You could even use $_hdimage = "c" where c is a symlink that points to your mounted DOS partition, no problem, and no need for hdimages. What we do not allow is $_hdimage = "/dev/hda1" unless it is not mounted and you want to access it read only, and even then this is only possible if you have root privileges. > THIS redirection VIRTUALLY overwrote the autoexec.bat which > Dosemu was referring to, so the actual DOS-BOOT was ONLY AT FIRST > using the autoexec.bat inside the hdimage, THEN after redirection > ALL of the C: was visible to Dosemu and the rest of the ACTUAL > autoexec.bat on C: was executed. Sure - you can still do that. Where does it fail for you? > Another issue is the conventional memory which I have been able > to assign to Dosemu to almost 900k (need that for ISDN drivers!), > but as I see now, not more than 640k are possible?!? Has Dosemu > limits on this by now??? Nothing different from what it was. 900k conventional RAM is impossible now and as it used to be because the video RAM starts at 640K (or 736k if you don't need graphics). Beyond that there is between 64k and 192k space for UMBs, depending on whether you have an EMS page frame, use graphics, ... > I would LOVE to put all the Dosemu stuff (which means 5 tasks > for 5 nodes) into RAM Disk (calculating 1.2 MB for each node > this does 5 times 1.2=6MB RAM + extra data needed by Dosemu so > maybe 8 MB of RAM for that RAMDISK) to have it run faster - how to > do that at best? Probably no need for a RAM disk: the Linux caching mechanisms are quite good. > Also the booting should (we live in 21st century....) now > rather be done from a virtual image NO longer redirecting > EVERYTHING from physical drives - but there is another problem > which arises here: The BBS writes a lot of data, if it stores > this data to virtual image only, it's lost, sure. So how can > I for example store the logs and the new uploads on a type 83 > directory on the Linux tree - is that at all possible? Can Dosemu > write to NON-FAT partitions? That's the whole point of lredir. You can boot from and see any Linux directory from DOSEMU. lredir d: linux\fs/ and you have your whole Linux fs in d:\ with write access where you would normally have it too. similarly lredir e: linux\fs/home/ob_ok ... Now I say GEEEZ. How much more flexibility do you want? Bart - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
