Name: jagmafer Date: October 14, 2005 at 09:44:42 Pacific Subject: No Emulation Boot... OS: Multi CPU/Ram: 160MB/450MHZ
Comment:
Greetings! I have a question about bootable cd's, particularly as relates to no emulation mode... I've been working on making a live cd of Win95 for data recovery purposes, so that I can take a CD with me and help people get their stuff back. (Don't worry - I won't run it in two places at once.) It's gone quite well. However, I've only used HD emulation mode, so the CD loads as a hard disk, and after all files that I need are in RAM, the CD is no longer necessary - but the drive can't be unloaded. So, I'd like to be able to hotswap CD's (esp. for laptops - one cd drive, and no floppy). However, in order to do this, I would have to have a bootable CD which loaded a "DOS bootstrap" of sorts into memory (probably with MSCDEX, etc.) and then passed control to it. Although the project has been successful enough, this would be a great aid. Any suggestions?
This is very hard to do because however you do it, IO.SYS is on the CD and calls will be made to it... whether in WIN or DOS. you can make fewer calls to the CD by copying command.com to the root of your ramdrive and "set comspec=X:\COMMAND.COM (where X: is your ramdrive. Command on the ram will make things much quicker and smoother and the CD will likely spin down... but remove it and swap for another is unlikely.
One could make multiple cd's if DOS is residing on each CD (or in the ram)and the boot area is identical with the one booting the system.
One of my friends actually did what you want- I have his stuff here somewhere... boots with alot of error calls, but finally does it- I elected not to use his method as it requires boot into windows and I prefer or rather require the ability to stop the boot and get to DOS. I will dig around and find/disect his boot process.
As an aside, as your disk improves, you are likley to want a 98se disk- if for no other reason than for the superior support for USB for CDwriter and External Hdds and a greater selection of programs.
If you would like to discuss further, feel free to E at roamer_1 -at- yahoo.com
JM> ...the CD loads as a hard disk... ...but the JM> drive can't be unloaded. I'd like to be able JM> to hotswap CD's... Any suggestions?
I may not get you right so i'll simply describe my own CD. I built one which loads DOS v6.2 in order to ignore multi Gb Hard-Disks, specifically, but i can remove it once it's finished booting. DOS and the applications could have been copied to a 48 Mb (or larger) RAMDisk if i wanted and i set some DOS environment variables to help it out. The ComSpec variable does point to `Command.COM' at all times, but using a bootable diskette was more appropriate for me because many legacy PCs can't boot from CDs anyway. A multi-boot menu allows me to adjust the RAMDisk size and the command interpreter is always found. There's no doubt in my mind that you would be able to transpose the configuration files for a later version of DOS that can manage large drives, i'm wondering about Hard-Disk mode configurations, nonetheless. I'll read you with much interrest...
OK, i think that the CD *is* still needed after loading into memory, as any normal harddrive would be. (io.sys is certainly one reason...) . I can't see a way around that.. but..how's about having a *second* external scsi, parrallel, or USB storage device (cdrom, preferably) with drivers for it on the live cd..connect it up and load it at the same time you boot the live cd?
Yes, it is possible to hook up USB storage and CD-rom (even rw). I have had success in both DOS and Mini98, though the Mini is much better to work with...
The main reason I went to the mini was DOS memory... there's just not enough to run all the drivers needed... and the mini can see deep dirs too.
Even for typically DOS functions, the added memory and multi-tasking make it much more comfortable in the Mini than in real DOS (when possible). For instance, one can run NTFSPRO from within a DOSBOX and run F-prot DOS from that and get a much nicer result than from DOS. The same goes for AVP (Kaspersy) for DOS, and Nod32DOS.
Of course, the Win ver of fprot runs from the mini too, but I didn't know it then...
The biggest problem with a fixed (no detect) mini98 is getting the correct board drivers into it, which I have found easier to do with DOS - injecting the correct driver as the mini builds using batches and regedit (same with NIC, could be used for vid and sound too.)...otherwise one must leave detection "on" which is not useful for a quick boot.
Once you get around the board drivers (to get USB), the storage/cd drivers are cake, as one would be likely to have drivers for the usb drives one personally has.
I am experimenting with redirecting the mini98 reg to a thumbdrive so one may have a "saved configuration". Then one would let the thing detect on the first go at a new box, but would save the config files on the thumb and disable detect till the next box comes along. It would also be a nice spot to put Mozilla FF profile (or Arachne) and would allow for an address book, invoice system, etc...
A good place to start would be Http://www.winimize.com
P&S: IMHO, Not really true that a Linux disk is more reliable... Actually the most reliable for hooking to damaged NTFS is DOS...
I have retrieved alot of files with the NTFSDOS driver where nothing else could see the drive. It has a helper that will load the driver to WIN as well.
Second best is the mini98 running a Paragon NTFS r/w driver, which works great for cleaning viruses etc...and for $30 is is more do-able than it's Winternals cousin which is now only available in the Admin Pak.
The mini is rock solid, boots in 15 secs (after the call to load it)... and is terrifically quick, being only 15 megs on an uncompressed ramdrive.
The biggest issue is carving down programs to run on it- needs much more technical expertise than a linux disk. Most any WIN3 will run on it, but one must be picky with 9x stuff as much relies on IE which can't be present without getting rather big.
The copyright issues are a minefield too- Linux is much better that way with little pick and choose... everything is GPLd. But there are alot of good GPL'd for WIN too.
But then, I'm a DOS dawg... don't like linux as much- all the slashes run the wrong way. :)
Thank you for your responses. However, none of them fully answered my question. To get a little better understanding (or just for kicks), check out http://www.geocities.com/freedatarecovery/ I just posted this to explain the process for making the Win95 live cd.
If you are booting the CD, you cannot take it out because (at least) IO.SYS is in the emulated floppy on the CD and cannot be re-directed or moved (everything else could be).
The only ready work-around(s) is to boot from a floppy instead (then IO.SYS would be on the floppy), or to live with it and rely on a secondary CDROM device(like a USB one) for your cd-romming pleasure.
Other (remote) possibilities:
One could attempt booting like a BART disk does (It's emulation is shoved into a ramdrive using a linux (?)MBRloader before handing the boot over to NT... But I suppose you will fail at that- IO.SYS doesn't like booting from anything except A: B: and C: -though you are certainly welcome to try, there may be a patch somewhere...
One could also attempt to copy the boot files off the floppy into a directory on the ramdrive and use the DOS SUBST command to "tie" it to the floppy, trying to fool IO into thinking it is still residing on the floppy; but my own experiments with this method have been dismal- It is not a stable solution...
There may be some way to use drivespace to fire the thing... I don't know.
P&S: What could possibly be more DOS than IO.SYS? Remember: Boot process and boot disks are Ok by JW... Just trying to help the guy out.
Jag, the page you sent was pretty good- I understand that you are using Hdd emulation rather than floppy emmulation, but my answer applies just the same. If you need more help, or wanna shoot the breeze, send me an E.
The information on Computing.Net is the opinions of its users. Such
opinions may not be accurate and they are to be used at your own risk.
Computing.Net cannot verify the validity of the statements made on this site. Computing.Net and Computing.Net, LLC hereby disclaim all responsibility and liability for the content of Computing.Net and its accuracy.
PLEASE READ THE FULL DISCLAIMER AND LEGAL TERMS BY CLICKING HERE
