jaclaz

Well, you have to take a decision, then we will work on the details and possibilities. As said, personally I have all my multiboot systems[1] with a defined drive letter that never changes no matter which of the OS is installed, as I find it easier this way to know at once which OS is currently running and avoid the risk of copying/overwriting the "wrong" file (in the sense of the "right" file on the "wrong" partition), but it is only a matter of preferences You want grub4dos (which is not GRUB, i.e the thing that can be either GRUB legacy or GRUB2), https://github.com/chenall/grub4dos/releases It has a number of additional features (some, many, of which you won't need), but essentially it has capabilities to directly chainload the various MS system loaders and/or bootmanagers AND it can be called/invoked by DOS AND there is not any real *need* to install it (which is a huge advantage). If you use it, you can even have not *any* of the later system bootloaders/bootmanagers in the first primary partition, and have the booted system always have (say) the C:\ drive letter[2] (though I personally do not advise this, as the hiding/unhiding of partitions at each boot is anyway a complication, in case it would be better - on the systems that allow it (the NT ones) - to avoid the mounting of the volumes in the OS). With a trick or two, logical volumes inside extended can be directly bootable. 8 GB is more than enough for DOS/WIn9x, and you would have 4 Kb cluster size that is just the "right" size (but on SSD you won't notice any practical advantage), but 16 GB would be fine as well, going over it , up to 32 Kb cluster size, i.e. 32 GB, it is bigger than that that becomes the (not "real", only "common sense") limit: https://support.microsoft.com/en-us/help/140365/default-cluster-size-for-ntfs-fat-and-exfat jaclaz [1] only for the record, the one I have that also has Win9x installed has it as well in a volume inside extended (but DOS remains in the primary, active partition, as it was made at the time with "traditional" methods) [2] this may be a little bit trickier at install time and it may depend on the number of disks installed, because of DOS and NT automatic letter assignment, particularly for 2K and XP but is doable.

No. (but thanks anyway for sharing your opinion ) There are not that much differences between 7/8.1 and 10, your personal line is way above the one I described. Since the number of machines around with 16 GB Ram AND NVMe (which are obviously faster and "better") are only a minimal fraction of the installed Windows 10 (again we are talking of ordinary, low power, office machines) you are telling me that - say - 95% of the offices in the world cannot do what actually is done (or cannot do it swiftly enough). jaclaz

Very likely . 32767 in hex is 0x7FFF. So it is a limit for a (signed) integer in 2 bytes. The actual limit for the number of files in FAT32 is anyway 65535 (or 0xFFFF), i.e. 2 bytes unsigned integer; https://stackoverflow.com/questions/466521/how-many-files-can-i-put-in-a-directory The reference document (by Microsoft) as often happens says this (and the contrary of it) explicitly: http://download.microsoft.com/download/0/8/4/084c452b-b772-4fe5-89bb-a0cbf082286a/fatgen103.doc (at the very end, pages 33/34) BUT see also: http://reboot.pro/topic/19643-winsxs-hardlinked-files/ https://stackoverflow.com/questions/37135262/fat32-number-of-files-per-directory-limit there is the added complication of file name length (it shouldn't affect specifically your case since they are 8.3 "normal" file names) Anyway, I wouldn't be surprised if in MS-DOS 7.1 the DIR used a signed integer instead of an unsigned one. jaclaz

@JFX Please can you make available (as a separate download) last version supporting 32 bit? jaclaz

Personally I wouldn't install 9x+2K+XP on a same partition. too many risks of conflicts. Partitions are free, and you can have up to 4 primary ones or 3 primaries+1 Extended containing as much volumes as you want and - besides the whoie NT family of OS's has been originally designed to be installed to a volume inside extended. Besides, creation of FAT32 volumes larger than 32 GB is not allowed by XP and later, and - strange as it might be - this artificial limitation has its reasons, as a too large cluster size, particularly on OS sytem volumes with thousands small files is not "efficient". Yes, you should align partitions BUT additionally since you are planning to use FAT32 you should align the volumes, see: https://msfn.org/board/topic/151798-does-fat32-align-its-clusters/ Then you should decide how do you want drive letters to appear, there are two school of thoughts: https://msfn.org/board/topic/181501-installing-vista-from-scratch/?tab=comments#comment-1186267 And finally you should decide which bootmanager you want to manage the multibooting (I am partial to grub4dos, but there are less powerful/flexible alternatives that may be good enough). jaclaz

Generally speaking a capacitor is essentially a power storage device capable of releasing the power it stores when needed, and they are usually employed to "level" the power passing in the circuit. So - since during booting there is a peak request of power by the motherboard (and other devices) - if capacitors on it have lost some of their capacity, a more beefy power supply is more likely to provide enough instant current to be able to boot the machine whilst a less powerful one simply cannot. In multi-disk systems (like RAID storage) it was common to set them for staggered spin-up: https://en.wikipedia.org/wiki/Spin-up to avoid the initial peaks. jaclaz

The MBR doesn't know that, the PBR does. ALL the MBR code does (a "normal", "standard" MBR) is: 1) check if in the partition table a primary partition table is defined AND it is marked active 2) chainload the first sector of that partition (the PBR or bootsector[1]) Then the PBR code invokes (chainloads) the OS file (like io.sys for DOS) or the bootmanager/bootloader (like NTLDR or BOOTMGR) which filename is embedded in it. In Vista (and later) there is a program, bootsect.exe that with the options /NT52 or /NT60 changes the bootsector code to invoke either NTLDR or BOOTMGR, the booting mechanism remains exactly the same. Within limits (same length), you can even hexedit the string with the name of the file in the bootsector, as an example it is possible (though NOT advised) to change "NTLDR" to "GRLDR" to have the /NT52 boosector invoke the grub4dos grldr file. If you prefer, the normal boot sequence (BIOS) is: BIOS->MBR->PBR of primary, active partition->*whatever* the PBR invokes jaclaz [1] even if technically in NTFS the bootsector is actually 16 sectors long (or in FAT32 usually 3 sectors long) or - more properly - the boot code is multi-sector - the MBR only chainloads the first sector and the code in it loads the "rest of itself".

Not that much old, only like a week old. The question came out because quite a few friends with this continued lockdown are getting short of devices (typical dad AND mom working from home AND one or two children doing remote schooling with - again typically - one "current" pc or laptop, an old (or older) one, one el-cheapo tablet, and one - quite capable BTW - smartphone but with a too tiny screen). Family fights to get a decently large screen assured. jaclaz

I think you really need the additional RAM, XP runs just fine with 1 GB, but nowadays browsers (please read a stupidly bloated websites) think it is one of those "all you can eat" places, and 2 GB is probably the bare minimum to have a "normal" experience with a few tabs/sites open in the browser at the same time. As a side note, the more you can access with QTweb (and with javascript disabled), the better. jaclaz

Which is good, but completely unrelated, since my note (and method) is NOT AT ALL about the "embedded" menu.lst in grub4dos, it is about embedding booting commands in the target .iso (or .vhd, or .img, etc.). I think you are still missing the point (which is about compatibility), sure we should use the right commands, but by having a non-existing command produce a warning (and/or a non-blocking error) the non-existing command can remain where it is. jaclaz

Sure, as if copy/paste was not a thing. Besides, one could use n .lst files and have in menu.lst each entry ponting to a specific "other" .lst. Example (BIOS /menu.lst): title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst configfile /CD/linuxmint-19.3-cinnamon-64bit.lst Example (UEFI EFI/grub/menu.lst): title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst configfile /CD/linuxmint-19.3-cinnamon-64bit.lst linuxmint-19.3-cinnamon-64bit.lst title linuxmint-19.3-cinnamon-64bit.iso set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso map (hd1,4)%iso_path% (0xff) map --hook root (0xff) kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash -- initrd /casper/initrd.lz And of course this would be useful for my personal approach (COSMIAS, which noone else uses BTW) with "embedded" batch and self-mounting (JFYI): http://reboot.pro/topic/17807-release-cosmias-a-new-approach-to-g4d-images/ Yep. jaclaz

What you should try is to add to the menu.lst entry a: map --hook Two possible results: 1) the entry fails because the "unknown" command creates a blocking error 2) the unknown command creates a warning and the entry works nonetheless If this latter, you can use (minus the iftitle ) the same entry on both normal grub4dos and on UEFI grub4dos. jaclaz

USB sticks can be seen EITHER as "fixed" (very few) or "removable" (most), at least on XP/Vista/7. Windows won't put a MBR on "removable" sticks, or if you prefer, "removable" USB sticks are NOT partitioned, they are normally "super-floppies", i.e. their first sector is a PBR and not a MBR. There are several different approaches to have the MBR on a removable stick, mainly: 1) write manually a MBR and partition table to it[1] 2) add a driver to the running Windows install that can make the stick be seen a "fixed" 3) use the stick "Manufacturer's tools" to "flip" the removable bit 4) make an image of the stick, mount it in a virtual drive, partition/format it, then dd it back to the stick Then there may be some issues with the BIOS of the specific machine, some *need* a second (minimal, hidden) partition to see the stick as "fixed" at boot time. Then the booting sequence remains the same: BIOS->MBR->PBR of active partition->bootloader or system file (i.e. IO.SYS or NTLDR or BOOTMGR)->OS Of course either BOOT.INI or /boot/BCD need to have correct settings. Choose among 1-4 above and I will point you to the details/tools needed, though the easiest would still remain uing one of the several partitioning/formatting tools that we have now available, namely I would recommend you RMPREPUSB. jaclaz [1] once there is a pre-written MBR and partition table on the stick, Disk Manager will allow formatting of the partition/volume in it BUT (if there are more than a single volume on a "removable" stick, only one will be mounted and assigned a drive letter)

Naah, JFYI: but - to be fair - with the Service Packs it is not that bad (and as I see it Windows 7 is actually a Vista service Pack 3+) jaclaz

Sure , but you started it . BTW, and JFYI deleting posts is usually frowned upon, if you wrote something that you later find to be incorrect, it is better to format the text by striking it, so that people can understand what happened. This is an example of something that is striken. jaclaz

Sure, that is a so-called "cheat-code" or kernel parameters, it has nothing to do with the booting method (BIOS vs. UEFI), it simply tells the kernel where to look for the rest of the system. Those settings could also be put inside the initrd, but of course you would have to rebuild a custom one. Anyway, generally speaking, linux .iso's cannot normally be booted by chainloading the bootsector, which is normally bypassed by the explicit kernel and initrd commands and the cheat-codes, this is not "news" and it is not "peculiar" to the UEFI. Sticky since 2009: http://reboot.pro/topic/8944-boot-any-iso-image-or-boot-all-iso-images/ jaclaz

Oh, no, I did not misunderstand you, rest assured . You wrote what you wrote: and I doubted it, to which you provided proof by posting a couple senseless (and not-funny) jokes coming from a Quora answer (without providing a link to it, i.e. additionally completely out of context) : https://www.quora.com/How-good-is-12-GB-of-RAM? Nothing more, nothing less. jaclaz

Ah well, that (the origin, and the fact that you call - BTW not funny - jokes "proof) says it all, you convinced me, all the machines around running just fine with 3, 5, 6, 12 GB of RAM aren't. jaclaz

Sure. the whole point is that the FAT32 is an artificial limitation that has no technical grounds whatoever AND that if a NTFS driver can be written that runs in EFI/UEFI, then *anything* can be written in it AND that the Secure Boot mechanism is a stupid provision, because: 1) it can be worked around nonetheless as you are well aware (see https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot ) 2) the signature mechanism is mis-managed by MS (and by the sheepish manufacturers that follow them) AND that - to be a standard - it is pretty much a failure as everyone makes changes to it: https://wiki.archlinux.org/index.php/GRUB/EFI_examples (possibly even in good faith as the specifications are more than 2,000 (two thousand) page long) jaclaz

map to WHAT? jaclaz

Hmmmm. jaclaz

Still, in a perfect world, it is in theory possible to emulate BIOS in UEFI, not entirely unlike what CSM does on most "dual" UEFI/BIOS firmwares, at least for the basic functions that DOS requires. A sort of "reversed" Clover. The whole point that the Intel (and associates) guys used to sell us[1] the stupid EFI/UEFI crap[2] was that it was essentially an operating system on chip and that *everything* was possible in this environment. Now, more than 10 (ten) years have passed (actually almost 15), and we evolved from a very limited boot environment that could only execute a bunch of assembler, consisting ONLY of MBR code, PBR code and bootloader/bootmanagers to a powerful environment that can run *anything* BUT for which essentially only bootloaders/bootmanagers exist (and was it not for our friend PBatard - Author of Rufus among other things - we would also be limited to FAT32 ): https://github.com/pbatard/uefi-ntfs In a nutshell, the possibilities are out there, and hopefully - before or later - someone will take the challenge. jaclaz [1] please read a "force down our throats" [2] not only crap in itself, crap worsened by arbitrary overlays of uneeded complications and limitations, the perfect example of "committee design" worsened by the de facto monopolistic power of some of the components of the committee

Well, you can "not-integrate" it and use a F6 floppy, the files here: https://www.helpjet.net/Fs-18881100-17836036-56797337-extract.html seem to have the txtsetup.oem just fine. You can use a "virtual" grub4dos floppy image: https://msfn.org/board/topic/179566-getting-sata-mode-to-work-during-and-after-xp-install/ https://msfn.org/board/topic/154071-f6-without-a-floppy-drive/ or a Syslinux/Memdisk one: http://wp.xin.at/archives/2702 jaclaz

I am (quite a bit) outside of the hardware loop and my experience with Windows 10 is extremely limited (I only happen to do quick fixes to the PC's of friends from time to time). Lately (think of COVID-19 lockdown/smart working) I have seen a lot of movement about refurbishing old (but not that much old) "business" PC's (think of Lenovo, HP and DELL small form factor desktops) by essentially: 1) upgrading RAM to 4 or 8 GB 2) replacing built-in SATA hard disks (originally 250/320/500 GB) with 120/128 or 240/256 SSD's 3) using (or abusing?) Microsoft upgrade policy to update OS from 7 (or 8/8.1) to 10 The processors in these machines are usually Intel i3, i5 or i7. Now the question, in the past the rule of thumb was to quadruple MS OS minimum requirements for RAM and double or triple the processor speed to have a "normally behaving" machine, as an example past "lines" for me were: a. Windows 2000 512 MB Ram 1 GHz processor (VIA C3/C7 were border line) b. Windows XP 2GB Ram 2 GHz possibly dual core (Atoms and similar were border-line) c. Windows 7 (32 bit) 4 GB RAM 2.8/3 Ghz, dual or quadruple core Video cards (for "normal" office use, and web browsing, NOT for gaming or graphic applications) have never been an issue and integrated cards always worked fine for me. Now (thanks mainly to the stupid web and current browsers bloat) I believe that 4 GB are out of question for 64 bit OS and 8 GB is needed. The hard disk vs. SSD is a no-brainer, a small SSD (+ a USB 3 rotating hard disk if needed) runs circles around internal rotating hard disks only, and 120/128 GB is more than enough for "normal" use. So, what remains is the processor and its speed/clock. Suggestions, ideas, experience? [1] jaclaz [1] Please understand how the questions revolve around el-cheapo, ordinary, low-power office machines that are readily available used in quantities, NOT about custom-built PC's with high-end processors, KW power supplies and stupidly fast double or quadruple fan video cards with a zillion GB of dedicated RAM.

Or 2 years - by Law - for non-business customers in EU. jaclaz