Hi, On Wed, Mar 25, 2015 at 3:54 PM, Eric Auer <[email protected]> wrote: > >>> I went through the ISO file,but I couldn't find the files needed >>> for the format /s command, > > The kernel and command.com are probably on the > (compressed) boot floppy image on the ISO, so > you do not see them unless you boot from that > CD.
I don't remember. Ask Bernd. > Maybe we should also put the files on the > ISO directly, for those who want to use them > without having to boot from the CD or having > to take extra steps to reach the files... Maybe. I mean it's not the worst idea. But (for now) end users can always just grab them manually via network: 1). http://sourceforge.net/projects/freedos/files/ 2). http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ > Rugxulo has some boot floppy images as well > as the files from them and the sources online: > >> https://sites.google.com/site/rugxulo/ Too old, too obscure, too buggy. It was just too hard to keep them perennially up-to-date (not to mention the hassle of always chasing licenses) and test and release and .... > If you "just want to SYS your C: drive", it > can be easier to use those, in particular if > you know what you are doing and you know that > you can not boot from CD or DVD drive... :-) Assuming he has a physical floppy drive, which he probably doesn't (as most don't anymore, early XP machines still allegedly needed them to add drivers [SATA?]). Sure, you can probably? still buy a USB floppy drive, but most people don't want 'em. > As far as I remember, FORMAT /S is identical > to formatting, then running SYS to copy those > files and make the boot sector. Copying them > without running SYS is not enough, as format > itself probably only puts a boot sector which > shows some "this does not boot" message... I don't remember. "/s" is probably for convenience, but it's not much help. I always just do it manually, copying the files and running SYS separately. I don't do dozens of installs daily, and I don't think most of us do either. >> In other words, it's not just raw files that can be copied (due to >> drive geometry differences), so there still needs to be some proper >> installation "work". > > Exactly. In particular, "mkdosfs" (of Linux > dosfstools) or some Windows FORMAT tool will > NOT put a boot sector which loads the kernel > of FreeDOS. Eric, I know you don't use Windows, but even I only use it because it's there, not because I prefer it. My obvious (limited, end user) experience is with that, e.g. XP or Vista or 7. Unlike Vista, with XP you could still boot off of FAT. It also had a "mostly" working NTVDM. It also didn't have any 64-bit version (except Pro from 2005, which wasn't very popular). It still used BOOT.INI in the "old" boot manager (which was replaced / expanded in Vista). I remember old guides tell us to save the DOS boot sector to file to use with BOOT.INI. It didn't even let you resize your NTFS, so you had to use (third-party, Linux) GParted liveCD and then "shrink + defrag" (or whatever) just to make enough room. (Clearly NT/XP wasn't mean to co-exist with DOS anymore.) Like I said before, with Vista at least you could resize the NTFS from within Windows. You can still create a FAT, but you just can't boot Windows off of it. The "new" boot manager is arcane, so you probably need (third-party) EasyBCD just to manage it. (Unless you want to use a different boot manager, and good luck, you'll need it!) You can still create an MS-DOS system floppy image from Explorer, but it's extremely bare bones. I think RUFUS nowadays prefers FreeDOS, esp. for keyboard locales. Even though RUFUS (AFAIK) runs atop "Windows only" for now. But at least UNetBootIn has Linux-hosted versions. Though that doesn't save persistent changes, which is "probably" bad for most people (unless you want that, who knows). Of course, even that assumes you still have a BIOS. I don't know how long before UEFI totally takes over the world. I've heard that Win7 still needed CSM (compatibility module) for UEFI, but Win8 doesn't need that anymore. I think even Win8 allegedly can mount .VHD files (not sure if "read only" or extract or boot from them). Like I said, emulators exist, but there are all kinds of restrictions and bugs and limitations. Honestly, modern computing is just a mess. Too many competing technologies. Maybe it's our fault for clinging so tightly to legacy. Sure, I agree with Jim Hall that "app compatibility is important", but nobody else does. It's just almost ridiculous to have raw binaries at all. And it's also ridiculous to need to recompile for every single freakin' Linux distro! But what are we going to do, use interpreters? Way too slow, and dynamic typing leaves too many bugs. But even portability (with standards and test suites) is very difficult. And people can't be bothered with minimal standard hardware or the portable subset of languages or restrictive standards or reasonable licensing anyways. (It's always something.) >> USB jump drive is probably your best bet. Although you can >> "probably" use Eric's sys-freedos-linux (Perl?) script, if >> direly desired. > > The tool is a Perl script which calls nasm to Which Perl?? Ugh, I hate the idea of ten bazillion unsupported, incompatible Perl versions. > compile a boot sector and sets a few specific > values in the boot sector depending on various > partition and filesystem properties. You would > need PERL and NASM to run it. Also, you would > have to specify some of the values manually if > the script does not find them in simple ways. It's good to have, just maybe?? brittle. But sadly I can't test everything myself. > In short, it is easier to use SYS after booting > DOS from anything that can boot DOS, such as an > USB stick or CD. Note that booting from USB or > CD can have an effect on drive letter "numbers" > so make sure that you use SYS on the drive that > you actually want to use... Well, if the file system already exists, and it's FAT, then it's likely not for Linux or Windows use (anymore). Linux hasn't supported FAT host (UMSDOS) since 2.4, which is long obsolete. And Windows hasn't directly cared about DOS since WinME (if even barely then). >>> As for a VM, I don't like emulated things. > > In that case, I recommend that you use Windows > or Linux tools to make your existing partitions > (e.g. Windows NTFS or Linux) smaller: This is > often possible "on the fly" without formatting > but of course you want to make backups before! It's not 100% precise to size, for whatever reason, but Windows (Vista on up) can do it. I don't know if I trust GParted as much, but I guess if you're desperate (and backed up all important files first and had installation CDs/DVDs on-hand), then it's better than nothing. Honestly, it's probably better to use a scratch computer (or virtual machine) instead. Or plan ahead of time (before manually installing any OS) what OSes you want to run full-time. (I don't even remember the order in which I installed on this triple-boot machine, but I know it took a few tries.) > After making space as described, you can again > use Linux or Windows to create for example some > FAT32 partition of a few gigabytes for DOS. As > last step, boot from a DOS boot disk for SYS :-) The ultra minimal ("Win98 EBD"?) MS-DOS "system disk" doesn't have SYS (go figure, probably to avoid accidental destruction and the ensuing support calls). Like I said, I haven't specifically tried it, but FD SYS "may" support that variant as well. > Of course, if your computer is big and fast, you > can easily run DOS in a VM while keeping the rest > of your computer busy with other things. "Fast" is subjective, even with Ghz. Emulators are usually *way* too slow and *way* too buggy ... unless you have VT-X, but even then things aren't perfect. It's just too hard (I suppose??) to emulate all the peripherals and quirks associated with so many cpu modes, even with explicit hardware virtualization support. > When you boot DOS on the raw hardware, you can obviously > do only DOS things until you boot your Windows or > Linux again ;-) https://www.freebsd.org/doc/handbook/nutshell.html Basically, they brag about many things. And FreeDOS is almost the exact opposite (on purpose!) in most ways. As even you have said, Eric, there are different needs and use cases, and DOS users don't need to make DOS into the "next Linux" (or whatever). E.g. Multitasking is slower, thus bad for benchmarking (but see DOSEMU). Memory protection is optional (e.g. DPMI) and somewhat more difficult to program for. Networking can be nice (e.g. packet drivers), but it's also the biggest avenue for security breaches. So DOS is faster, simpler, and more secure. :-) (Obviously I'm half-joking here, but you can probably pretend that "some" of it is a virtue, even if not done for those sole purposes.) > PS: Rugxulo, your Grub2 comment mentions a MEMDISK > based workflow, so it does NOT answer whether or not > Grub2 has any problems with booting DOS directly... I vaguely recall reading the original announcement of GRUB 2, and I had thought it said it supported FreeDOS. All I know is that I haven't tried, and I have no (major) interest in tinkering just to find out. > https://wiki.archlinux.org/index.php/Flashing_BIOS_from_Linux#FreeDOS > > http://www.syslinux.org/wiki/index.php/MEMDISK says > max CHS geometry is 1024x256x64 for 8 GB but that > it is limited by int 15 memory (maybe max 3-4 GB?). Dunno. Tell them to implement PAE. :-) (j/k, nobody cares, sigh) :-P ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
