Should anyone care (mostly I think it would be the "power users"), I've taken most of these suggestions and combined them together to take them to an even higher level.
On the same machine, I can get into DOS several different ways. I can boot straight to DOS, and even have several different manufacturers of DOS on the same machine (MS, IBM, DR, Free, etc.) and different versions of the same manufacturer (especially MS & IBM). On the same machine, I can also get into DOS from virtual machines (DOSBox, VMWare, Virtual PC, etc. -- in my case, the virtual machines are always under Windows rather than *nix). No matter how I get into DOS, though, I want it to have the same basic "feel", and only want _one_ copy of the utilities and programs and files that I normally use on the computer. I do not want to have multiple copies floating around, nor want to get into them in different ways depending on which DOS I'm using at the time. To do this you have to logically decouple the boot drive from the data drive, and also decouple the boot process (AUTOEXEC) from the boot drive. For example, when I boot straight to DOS, C: is the boot drive (the first partition on the physical hard drive), and here are the contents of C:\AUTOEXEC.BAT (for MS-DOS 6.22): @Echo OFF SET Eco=OFF C:\MSDOS6.22\SUBST S: C:\ C:\MSDOS6.22\SUBST T: C:\Batch C:\MSDOS6.22\SUBST U: C:\Util C:\MSDOS6.22\Subst V: C:\MSDOS6.22 SET RealDOS=Yes CALL S:\Boot\AutoExec >From VMWare (which is the virtual machine I use most of the time), I can't >access the first partition on the physical hard drive as C: any more. VMWare >only allows you to boot from an image, not a physical disk, so the image >becomes C:. I've set up VMWare to mount the first partition on the physical >disk as D:, which puts all of the DOS stuff I care about on D: instead of C:. Here are the contents of C:\AUTOEXEC.BAT on the VMWare image (again, for MS-DOS 6.22). I also have a copy of the entire MSDOS6.22 directory in the VMWare image (under C:\DOS) in case I need them when things aren't booting correctly: @Echo OFF SET TZ=MST7MDT SET Eco=OFF C:\DOS\SUBST S: D:\ C:\DOS\SUBST T: D:\Batch C:\DOS\SUBST U: D:\Util C:\DOS\SUBST V: D:\MSDOS6.22 SET VMWare=Yes CALL S:\Boot\AutoExec The "System" drive is S: instead of C:, so when I'm at the DOS prompt I normally see S:\> instead of C:\>. The main (and messy) AUTOEXEC.BAT file is in S:\Boot rather than C:\, and contains a few lines that start with things like: IF RealDOS!==Yes! This way, no matter which version of DOS I'm using or how I started it, I always use the exact same AUTOEXEC.BAT file, and there is only one copy of the utilities and programs and files that I need. When I change something, I don't have to worry about copying (or deleting) it in all of the other places it may be stored. ********* I also create and use batch files for almost everything, and my PATH normally looks like this: PATH=T:;U:;U:\USB;U:\FreeDOS;U:\Norton;V: Batch files are ALWAYS first in the PATH, since they are used to override the "default" values for most programs. External utilities come next, since they can sometimes be used to override DOS utilities with the same name. DOS utilities come last in the PATH. "Simple" utility programs are thrown into U:. "Complicated" programs (that have multiple files) are put into their own subdirectory (under U:, S:, or S:\Apps) and are started with a batch file stored in T:. Here's an example of a relatively complicated batch file (ETHERNET.BAT) which loads the appropriate packet driver based on the circumstances (Note: the MAPMEM, MARK, RELEASE, MARKNET, and RELNET utilities are part of the free TSRCOM utility package). When I want to run a program that needs a packet driver (like Arachne or Dillo), the ARACHNE.BAT or DILLO.BAT file calls this ETHERNET.BAT file (of course, I can also run the ETHERNET.BAT file all by itself if I want to for some reason): @ECHO %Eco% PushDir U: PushDir IF %VirtualPC%! == Yes! GOTO VirtualPC IF %VMWare%! == Yes! GOTO VMWare GOTO RealHW REM ===================================================== REM MS VirtualPC REM ===================================================== :VirtualPC IF NOT %1!==! GOTO UninstV :InstV MapMem /Q /C DEC21140 IF NOT ErrorLevel 2 GOTO Done \Ethernet\DEC21140\DEC21140 0x60 GOTO Done :UninstV MapMem /Q /C DEC21140 IF ErrorLevel 2 GOTO Done \Ethernet\DEC21140\DEC21140 -u GOTO Done REM ===================================================== REM VMWare REM ===================================================== :VMWare IF NOT %1!==! GOTO UninstW :InstW MapMem /Q /C PCNTPK IF NOT ErrorLevel 2 GOTO Done MarkNet AMD \Ethernet\AMDPCNet\PCNTPK INT=0x60 GOTO Done :UninstW MapMem /Q /C PCNTPK IF ErrorLevel 2 GOTO Done RelNet AMD GOTO Done REM ===================================================== REM Real Hardware REM ===================================================== :RealHW CD \Ethernet\RealTek\ODI IF NOT %1!==! GOTO UninstR :InstR MapMem /Q /C OdiPkt IF NOT ErrorLevel 2 GOTO Done LH Lsl LH RtgEOdi Mark OdiPkt LH OdiPkt 0 0x60 GOTO Done :UninstR MapMem /Q /C OdiPkt IF ErrorLevel 2 GOTO Done Release OdiPkt RtgEOdi U LSL /U :Done PopDir PopDir I know this was a long-winded post, but hopefully somebody may get some use from the ideas and examples here. ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
