On Thu, 15 Apr 2021 at 01:16, Adam Nielsen via Freedos-user <[email protected]> wrote: > > Have you written down your tips and tricks for this anywhere? I find > these sorts of things interesting to read, mostly for nostalgia > reasons - as in finally learning about things that mystified me when I > was younger.
For DOS memory optimisation? No... I have considered it, but it's quite a complex process and some of it depends a bit on other knowledge (e.g. dependencies among DOS drivers, or the few drivers that can be loaded either from CONFIG.SYS _or_ from AUTOEXEC.BAT). I tried writing up just the DOS disk drive letter assignment algorithm, but even that is quite complex! Axioms: • DOS only understands FAT12, FAT16 and in later versions FAT32. HPFS, NTFS and all *nix filesystems will be skipped. • We are only considering MBR partitioning So: • Hard disks support 2 partition types: primary and logical. Logical drives must go inside an extended partition. • MBR supports a legal max of 4 primaries per drive. • Only 1 primary partition on the 1st drive can be marked "active" and the BIOS will boot that one _unless_ you have a *nix bootloader installed. • You can only have 1 extended partition per drive. It counts as a primary partition. • To be "legal" and to support early versions of NT and OS/2, only 1 DOS-readable primary partition per drive is allowed. All other partitions should go inside an extended partition. • MS-DOS, PC DOS and NT will only boot from a primary partition. Those are our "givens". Now, after all that, how does DOS (inc Win9x) assign drive letters? 1. It starts with drive letter C 2. It enumerates all available hard drives visible to the BIOS 3. The first *primary* partition on each drive is assigned a letter. 4. Then it goes back to the start and starts going through all the physical hard disks a 2nd time. 5. Now it enumerates all *logical* partitions on each drive and assigns them letters. 6. So, all the logicals on the 1st drive get sequential letters 7. Then all the logicals on the next drive 8. And so on through all logicals on all hard disks. 9. Then drivers in CONFIG.SYS are processed and if they create drives (e.g. DRIVER.SYS) those letters are assigned next. 10. Then drivers in AUTOEXEC.BAT are processed and if _they_ create drives (e.g. MSCDEX) those are assigned next. So you see... it's quite complicated. :-) Assigning upper memory blocks is _more_ complicated. NT changes this and I am not 100% sure of the details. From observation: NT 3 did the same, but with the addition of HPFS and NTFS (NT 3.1 & 3.5) and NTFS (3.51) drives. NT 4 does not recognise HPFS at all but the 3.51 driver can be retrofitted. NT 3, 4 & 5 (Win2K) *require* that partitions are in sequential order. Numbers may be missing but you can't have, say: [part № 1] [part № 2] [part № 4] [part № 3] They will blue-screen on boot if you have this. Linux doesn't care. Riders/: [1] The NT booloader must be on the first primary partition on the first drive. [1b] A 3rd party boot-loader can override this and, for instance, multi-boot several different installations on different drives [2] The rest of the OS can be anywhere, including a logical drive. NT 6 (Vista) & later can handle it, but this is because MS rewrote the drive-letter allocation algorithm. (At least I _think_ this is why but I do not know for sure; it could be a coincidence.) Conditions: the NT 6+ bootloader must be in the same drive as the rest of the OS. The bootloader must be on a primary partition. Therefore, NT 6+ must be in a primary partition, a new restriction. NT 6+ must be installed on an NTFS volume, therefore, it can no longer dual-boot with DOS on its own & a 3rd party bootloader is needed. NT 6+ just does this: [1] The drive where the NT bootloader is becomes C: [2] Then it allocates all readable partitions on drive 1, then all those on drive 2, then all those on drive 3, etc. So just listing the rules is quite complicated. Turning into a step-by-step how-to guide is significantly longer and more complex. As an example, the much simpler process of cleaning up Windows 7/8.x/10 if preparing to dual-boot took me several thousand words, and I skipped some entire considerations to keep it that "short". https://liam-on-linux.livejournal.com/68495.html > Given the upswing in retro-gaming (as you can see by the increase in > eBay prices for DOS-compatible hardware over the last few years), it > seems more and more people who grew up with DOS games are now reaching > the age where they have the time and financial means to go build the DOS > PC they always wanted. Knowing how to set it up better than you ever > could back in the day would be something quite valuable. I've lost > count of the number of new discoveries about old hardware I wish I > could've gone back and told myself about 20 years ago! Fair point! > Personally I have a collection of hardware from the 1990s that I picked > up cheap over the years (often for free as people were throwing it out > as obsolete) and my goal is to one day set up a small computer lab with > it all. That's the point where getting network drivers loaded while > still having enough free memory to run the games themselves would be > very useful! With MS-DOS 6.22, or PC DOS 7/7.1, you can just run MEMMAKER or RAMBOOST and it will do a fairly good job for you. But you've given me food for thought. I may have another go at this. > As to the original question, while I only use DOS for nostalgia > reasons, I think it makes an excellent teaching tool for learning how > modern computers work. It's especially useful for people who wish to > run Windows, as many conventions that started with DOS (such as drive > letters) are still used today. Ha! Drive letters most definitely did _not_ start with DOS. Remember that in effect MS-DOS was an unlicensed copy of Digital Research's CP/M and particularly CP/M-86. When the IBM PC was launched, IBM offered a choice of 3 OSes: PC DOS, CP/M-86 and the UCDS p-System (a bytecoded Pascal IDE and run-time environment.) CP/M and CP/M-86 used drive letters in exactly the same way, with limitations -- the drive it booted from was A, then it enumerated all other drives. It didn't support hard disk partitions at first because it didn't support hard disks at first; when it did, I think it only supported a small number of simple flat partitions, no primary/logical stuff. So if you did have a hard disk, when you booted from the hard disk, it was drive A: — but if you booted from floppy, the floppy was drive A: and the hard disk became B: or C:. Confusing! > But DOS exposes everything at a much > lower level so it makes it easier for a beginner to get a feeling for > how the machine is affected by what they do. Even modern Windows is > having a bit of a resurgence when it comes to the command line, so all > the skills DOS users learned with command line programs are even more > relevant today in the world of Windows than they ever have been before. Well, somewhat, yes. > It is, after all, my "obsolete" DOS skills that have allowed me, in an > office setting, to show people how to do things like get a list of > files in a directory into a text file, manipulate them with an Excel > formula, produce a set of rename commands, and then run them in a > command prompt to do a bulk rename of a few hundred files. :-) > Tasks like this are things you cannot do entirely via the default GUI > and the first thing people do (who aren't familiar with DOS) is jump on > Google and look for a program that can do it for them. These often > cost money and/or are filled with ads (or worse) and are usually > massive downloads because of all the awful graphics they come with to > bulk out the program, to disguise the fact that it doesn't actually do > much at all. True. Balena Etcher is one of my favourite examples. It burns ISO images to Flash drives, and nothing else. This is a job you can do in 500 kB of code if you're very lazy and inefficient. But Etcher is an Electron app: it's written in JavaScript (a *wildly* bad choice for such a task) and so it embeds an entire copy of the Chromium web-rendering engine just to display a line of text and ask which file and which drive. Result: it's an 85MB compressed download, and that's after they have managed to make it smaller in recent releases. It is on the order of _one thousand times_ bigger than it needs to be to perform its task. That implies that it has in the region of a thousand times more potential bugs, vulnerabilities etc. Just to write a file to a device, something I'd normally do with the command: dd if=linux.iso of=/dev/sdb (27 characters and contains 90% of the functionality of Etcher.) > But a few simple commands unchanged since early versions of DOS can do > it in no time, with no additional software installs required. So being > familiar with DOS can still to this day give you skills that are useful > with even the latest computers and operating systems. Well, this is why, in part, I am sorry that OS/2 failed and Windows took the evolution of the DOS platform in another, very different direction. Back in the 1980s I used and supported Digital Research's Concurrent DOS/386. This was a DOS-like DOS, derived from CP/M-86, which was a multitasking multiuser protect-mode OS that could multitask DOS apps as well as its own native apps. I had demo PCs in the office running CDOS, with a fractal generator running in the background all day rendering high-res images, but they sat there with a DOS prompt blinking and you could use them as normal and never know the CPU was working flat-out in the background. :-) CDOS was not a simple or trivial OS but it was about 1% of the size of Windows 95 and it did the core stuff for the time: multitasking, using the 386 chip and all its memory... No GUI, no windowing, but DR had other products that did that stuff. DR originally did a multitasking CDOS for 286 computers, which could use 16MB of RAM and multitask DOS apps, but Intel removed the CPU feature the OS used before the 80286 shipped. Without it, it couldn't multitask DOS apps. Later Intel put it back, but it was too late, DR got wounded _again_ and it was too late. So DR re-targeted the OS as a realtime OS called FlexOS and sold it for things like cash registers. Remember the lightweight GEM desktop? FlexOS had a multitasking GEM GUI called X-GEM on top. A form of it still is sold today -- IBM owned it for years and called it the IBM 4680 and 4690 OS. (Catchy, huh?) Later it sold it to Toshiba who still support it. Partly because OS/2 failed, and MS cheated DR out of its fair share of the market, we never got the multitasking relatives of DOS we could have had in the 1980s. Instead, we got a very heavyweight inefficient series of ones in the 1990s... and we still run their descendants today. And in its efforts to keep up, Linux has grown just as bloated. I used a distro in the mid-1990s that ran in 3MB of disk space (2 floppies) — http://www.toms.net/rb/ — and another that installed onto a DOS hard disk in a subdirectory and took about 10MB — http://www.ipt.ntnu.no/~knutb/linux486/download/pygmy/pygmy09help.html -- Liam Proven – Profile: https://about.me/liamproven Email: [email protected] – gMail/gTalk/gHangouts: [email protected] Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
