Op 5-8-2011 19:45, Georg Potthast schreef: > > I am a bit overwhelmed by the discussion following my post. I will try to > address some points.
hehe, the discussion was already going, just added our contributions to your feedback as well. DOS386 also had some very usefull feedback that I'll have to take into consideration. >> Is there any driver for read-mounting harddisk images (maybe SHSUFDRV) in a >> situation where you boot from a separate bootdisk, access the CD and mount >> this (single-partition) harddisk image? > El-Torito is meant to be used to boot from and the disk can usually just be > accessed when supported by the BIOS. Windows XP cannot do it by the way. Yeah there exists some specific tools to extract boot image from a CD, unfortunately I can't remember any of these. > I think most BIOS versions support El-Torito. If the BIOS can boot the OS > from an El-Torioto CD which is set up as a floppy disk emulation it can also > boot from a CD that is set up as a hard disk emulation, both are included in > the El-Torito standard. So you do not need a new PC for that. You can > download one of my Live-CDs and test, just enter CTRL-C at the first prompt > and you skip all the USB stuff. Just what I tried last night. Trying DIR > OUT.TXT already crashed the entire thing due to C: being emulated harddisk(-partition) on CD-ROM, and thus by definition read-only. Size of C: surprised me as well as DIR /S showed all contents doesn't even add up to 2.88MB. > It took me quite a while to figure out how to make such a CD, but I > documented it: > To set up a El-Torito hard disk emulation CD please look at chapter 4 of my > Bochs tutorial: > http://peter-bochs.googlecode.com/files/Bochs%20-%20a%20Guide%20and%20Tutorial%20for%20Windows.pdf might be an interesting read :) > >> Wait for the DEVLOAD developers to release a version (3.24?) with that bug >> fixed. > Regarding the drive letters and devload: I do not think this is a bug in > devload here. On my Live-CDs I use devload in the autoexec.bat file and it > assigns a new drive letter just fine. Depends what you load inbetween. DEVLOAD seemed to overwrite redirector drives. Try loading CD drivers first, and SUBST, MS Client etc, then try DEVLOAD some driver that assigns driveletters. >> please try if skipping JEMMEX solves both > I do not really care if Jemmex is loaded or not, I just feel if this CD > shall become a major FreeDOS distribution, there should be no crashes. Also > loading a keyboard driver should not cause a crash. Ofcourse you're right there. Being worked on, just as many more issues. > DOSUSB has a problem to query the BIOS to find out if DOS was booted from a > USB device and where this device is connected to before starting its own USB > support. Only a few BIOS versions will allow to retrieve the information > that drive C is a USB disk and still I do not know where the disc is > connected to, so I did not implement that. I recommend to exclude that > controller manually after figuring out where the boot disk is connected to. > This works for embedded applications but remains a general problem. If a > customer would like to have that I would look into it again but so far this > never came up except by Eric. The usual trick is creating a ramdrive, copying files to there, adjust path and other settings (comspec), start a continuation batchfile from there including DOSUSB loading. I experienced the same thing of drives disappearing under my feet (thus hanging system) when loading TDSK from CD drive. It simply hijacked the driveletter. A real issue is BIOS presenting drives to kernel followed by kernel happily mapping the drives to driveletters. Instead it's much more convenient to only assign driveletter for current drive, and have the other ones added later on by some driver. > As for the keyboard and mouse driver, I agree that one could add more > features to DOSUSB but that is still on the todo-list. I'd consider it pretty essential. Lack of PS/2 keyboards on modern systems while your driver overrides legacy emulation. A machine which you can't give input to is severely limited in its actions. Anyway, thanks for your feedback in a fruitful discussion :) > Georg Bernd ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
