jaclaz

Hmmm, lots of questions. Dual booting: simply two lines in BOOT.INI: "light OS" is a extremely nlited version (and something else removed), no network, no nothing except disk drive access + a number of utilities, 200 Mb roughly. (the "old" version I used, based on 2K was around 100 Mb) FAT16 for the first partition is just because I also have on the same drive MS-DOS 6.22. the little less than 2 Gb is a "need" to have not a too big cluster size. (the "old" version I used was "little less than 1 Gb", and had half the cluster size, extending it to 2 Gb is somewhat "stretching it") Besides, FAT16 is the oldest and most compatible with everything filesystem, I can (if needed) hexedit/modify/fix it directly, it has just one bootsector. FAT32 is allright, and better (as it is MORE efficient) as long as you don't use anything "older" than Win9x/DOS 7.x. Since you have a presumably smallish separate partition for the pagefile.sys (typically fixed size, in my case, 1024 Mb) and of course you do not need any of the advanced features of NTFS, FAT32 is (slightly) faster: http://www.ntfs.com/ntfs_vs_fat.htm On the other hand, for all the other partitions, much bigger, NTFS has several advantages: 1) it is inherently more efficient (no problems of "slack space" due to fixed big sized clusters) 2) allows restricting access on a per-user basis 3) tends to fragment far less than any FAT 4) it is much more secure in case of filesystem corruption 5) allows for "sparse" files, mount points and hard links 6) allows for files bigger than 4 Gb (important for the "Data" partition) 7) it is faster on big sized partitions About partitioning, I use NONE of the two. In my opinion and experience, ALL this kinds of programs have a basic "dangerous" design. Basic assumption: Kids should not play with matches. This kind of apps make any newbie feel like he is a "master" in managing drives, creating partitions, resizing them, converting from Logical Volume to Primary, changing filesystems at will, etc. Since Murphy's Laws ALWAYS apply and expecially to this delicate matter, if you fiddle long enough with these apps something is going to happen, and often the result of this is an unbootable/hard to recover system. By allowing to easily do whatever one fancies this kind of utilities remove any need for the most important part: preventive, accurate, exhaustive thinking about planning of the partitioning scheme A bit of (personal) history: Partition Magic up to version 3 (limited to 8 Gb, so not much useful nowadays) worked like a charm. I passed on 4 and 5. Version 6 was a disaster. Version 7 was slightly better (hearsay only). Version 8 should be again reliable, but still I see a number of posts around of people crying about the damage it did on their drives, it is very possible that they are actually cases of PBCAK : http://acronyms.thefreedictionary.com/PBCAK but you never know. After the "professional" PC technician in the firm I used to work for wiped flat a couple of hard disks with version 6, after having recovered the data (and sent the guy to a forced perennial vacation ) I "banned" PM, and got Acronis, if I remember right version 7 or 8. While being in my opinion more dependable, the versions I tried still did in some cases "strange" things to drives, like using a non-standard MBR, writing some data in the hidden sectors, etc. My advice is: 1) PLAN before 2) use standard tools (Disk Manager works perfectly, unless you need to resize partitions) 3) if really, really needed, be very, very, very careful when using this kind of tools, and in any case, backup before 4) use gparted, part of many Linux distro's partedmagic: http://partedmagic.com/ http://downloads.partedmagic.com/ is a live CD/USB stick that I have used with success (right now the actual site has been hacked, it should get back soon for docs and the forum) 5) whatever tool you use think BEFORE doing anything, don't be fooled by the apparent easyness with which very complex operations can be carried on. In other words: if you have to perform common, simple operations, use standard, common, simple tools. if you have to perform advanced, complex operations, the tool you use is anyway a tool, what is important (and that can may make the difference between a success and a failure) is your brain and your knowledge whatever you are doing, assume that something may go wrong and be prepared for it (backup, save MBR's and bootsectors, etc.) Finally, on the same "better be safe than sorry" trend: unless it is a portable (with an efficient battery) don't even think of resizing partitions, changing filesystems, etc. with the PC not connected to a working UPS. jaclaz

Isn't this the good ol' self deleting batch? http://www.msfn.org/board/force-directory-...3.html&st=3 http://catch22.net/tuts/selfdel It should work on 9x too. jaclaz

Just for the record, bootpart is REALLY old, something like 15 years, but it has been updated, though the documentation is a bit scarce. Valid "System ID's" in current version are (see here): http://forum.winimage.com/viewtopic.php?t=276 You should not use a "different" parameter from what your OS actually is, there are slight differences between the bootsectors of different OS, and although using WINNT instead of WINXP may work at booting, it is not recommended "mixing" different bootsectors/OSes. jaclaz

@zomos Did you write the MkMigrateInf.exe? Why? I mean, doesn't the MkMigrateInf.cmd: http://www.911cd.net/forums//index.php?showtopic=19663 or the MkMigrateInf2.cmd version part of the USB multiboot_10 : http://www.msfn.org/board/install-XP-USB-t111406.html work allright? jaclaz

I don't get it. fixboot/fixmbr are Recovery Console commands. You need to boot to Recovery Console, and the smallest I could get (fully functional) was about 7 Mb if I recall correctly. There is an ogoing experimental project at boot-land, WINROOT: http://www.boot-land.net/forums/index.php?...ic=3537&hl= that tops at 2.88 Mb (WARNING not functional yet - just something to play with) so maybe one day it will be possible to use one of those 2.88 Mb floppies (if they will still exist) But what about booting good ol' DOS and use DOS programs to replicate the behaviour of fixboot/fixmbr? For the MBR there are several DOS programs available, for the bootsector TESTDISK should do. jaclaz

A very small number of - generally badly programmed - apps do have hardcoded paths for install, but a great part of them will however prompt you for confirmation of the proposed path during install, so the problem may arise for just a handful of programs, most of which are worthless anyway, which leaves you with very few, small apps to deal with. What I usually do is to have a single primary partition, usually FAT16, a little less than 2Gb, on which there is just the "base booting" files: NTLDR NTDETECT.COM BOOT.INI (NTBOOTDD.SYS) needed in some setups with SCSI disks (BOOTFONT.BIN) needed in some not EN-US national versions The "System" is in a Logical Volume inside Extended partition. Another volume is for "Program Files". Another volume (actually more than one) is for "Data" On a single drive system I do use yet another separate volume (FAT32 formatted) for the pagefile. I then use some 600 Mbytes of the Primary for a second ("light") version of the OS, for emergency/recovery/offline checks, etc. This leaves about 1.3 Gbytes available for the very few programs that "like" C:\ as their "home" (which most of the time get anyway deleted after testing ). jaclaz

Sorry I had taken for given that you actually mounted the boot.img, instead you "peered" in it with a hex editor or a plain edirtor? .img is a conventional extension given to disk images (typically .ima is for floppy disks and .img for hard disk images - but it's not "compulsory") How big is the "boot.img"? (in Bytes) Have you tried accessing it with Winimage or mounting it with VDK? Winimage: http://www.winimage.com/ VDK: http://chitchat.at.infoseek.co.jp/vmware/vdk.html Pseudo-GUI for VDK: http://home.graffiti.net/jaclaz:graffiti.n...ts/VDM/vdm.html jaclaz

AFAIK the MBR used in those machines has "special" code that allows the use of F11. From the menu you posted it seems to me like this "special" MBR is option "4", while the "normal" one is option "A". Since you already have a backup of first 63 sectors (partially working) and the means to restore them, you could try using option "4". @Tripredacus Actually you "vanished" from the original thread: http://www.msfn.org/board/Create-Recovery-....html&st=26 leaving an open question. Did you try using the SELM parameter? And how? jaclaz

In the really old times there were "self-standing" apps made by Roxio or Ahead to allow accessing "packet written" CD/CDRW, if I am not mistaken, DLA is somewhat different, it is a sort of UDF filesystem implementation on CD/DVD for both writing and reading, some details are here: http://www.argentuma.com/backup/software/dla.html The old apps you have in mind should be : UDF READER and EASYREADER: http://www.velocityreviews.com/forums/t195...-my-system.html jaclaz

What about a floppy chainloading the CD? Either a grub4dos floppy or a BCDL one will do. jaclaz

People will also appreciate a less aggressive way to address other members, and expecially when addressing developers that share their knowledge and programs and also spend their time helping members with the problems they may have. For the record, ilko's joke is quite common, and derives from my "standard reply #32": http://www.boot-land.net/forums/?showtopic=2587 jaclaz

I wasn't referring specifically to Freedos: however you may want to tell this to the Freedos Authors: http://www.freedos.org/ If an operating system is software, calling Freedos "freeware" does not seem inaccurate to me. If you meant that it is both "free" (thus "freeware") and "Open Source", you are correct. jaclaz

For the record, it does not "significantly" slow down the system as a whole. With modern systems with lots of RAM, the pagefile is rarely used, so even if it would "significantly" slow down operation, it will do so in very rare occasions. It makes actually no sense defragging the pagefile - unless, for any reason, you can NEVER reboot -: it is much easier, as I see it, boot to another instance of the OS - or to another OS capable of accessing the drive - and simply delete the pagefile file, it will be recreated, in pristine state, at next boot. There are a lot of controversial opinions on how big a pagefile should be, and there are even people suggesting that it is not even needed at all, while others think that Windows is good enough to manage it internally. Definitely avoiding the flip-flop to dinamycally resize is an advantage, so a fixed size is recommended. (at least by me ) I think that each user has it's own way to use the PC so there is not a "one-size-fits-all" solution, a good approach is actually check how the pagefile is used during your normal activity: http://articles.techrepublic.com.com/5100-...11-5073570.html and size it accordingly. jaclaz

Just for the record: http://synergy2.sourceforge.net/ jaclaz

And, again, WHICH ones? jaclaz

@darksimon Well, no. I mean let's try not to re-invent the wheel. \I386 is the path hardcoded in SETUPLDR.BIN when run on removable media (like a CD or superfloppy, with NO MBR) - common between SETUP and PE booting \minint is the path hardcoded in SETUPLDR.BIN when run on "fixed" media (like a HD, with MBR) - only for PE booting \$winnt.~bt$ is the path hardcoded in SETUPLDR.BIN when run on "fixed" media (like a HD, with MBR) - only for SETUP booting If you want to re-start from the beginning, you will need to go through all the "historical thread": http://www.msfn.org/board/index.php?showtopic=61384 where you will find all the steps that led us to the current working solution, and possibly find where to "deviate" from the taken path and introduce the variations. Just in case, read these seemingly unrelated threads: http://www.911cd.net/forums//index.php?showtopic=17504 http://www.msfn.org/board/Solution-multibo...-Wi-t58410.html jaclaz

Well, you can memorize a "one line" batch, but still I am not sure if you want to check if folders are empty or not. I mean this, directly entered on command line: FOR /F "delims=" %A IN ('dir /b /s /A:D') DO ECHO "%A" will list only folders "below" current path, something like this: FOR /F "delims=" %A IN ('dir /b /s /A:D') DO RD "%A" 2>nul will only delete EMPTY folders (without prompting) But you will have to re-run it for each "level". Using this: FOR /F "delims=" %A IN ('dir /b /s /A:D') DO RD "%A" /S 2>nul will prompt you, but if you say yes to deleting a higher level folder, you will be prompted for all folders in the lower levels (that do not exist anymore) jaclaz

Hmmm : http://www.msfn.org/board/Hiren-Boot-CD-t38784.html jaclaz

Just in case, alternate drivers to try are Maximus Decim's: http://www.msfn.org/board/Maximum-Decim-Na...USB-t43605.html Generic one: http://www.msfn.org/board/Generic-98-USB-d...-me-t99220.html jaclaz

No, but, just for the record, it is possible to run Windows 3.x on freedos kernel: http://www.911cd.net/forums//index.php?sho...16754&st=43 http://wiki.fdos.org/Main/Windows http://www.fdos.org/kernel/test/ So it should be possible to also make it work with WIN9x, but what would be the scope? I mean, while it is possible that one holds a valid license for Win 3.x, but not for MS-DOS, if you have a licence for WIN9x/ME you also have a licence to use the underlying DOS 7.x/8.0. I don't think that the freedos kernel files provide any advantage over MS-DOS 7.x/8.0. jaclaz

What about a small batch file? If I get it right you want to delete files one by one, and then remove folders one by one, being prompted each time? jaclaz

Actually we would call that a "mess" , however, WHICH " MS-DOS programs in the Win98SE setup"? And Why? jaclaz

Yep, that was exactly the idea: During a Repair may work Botsect.exe WON'T. jaclaz

Just for the record: in some cases it is possible to do a Repair install http://www.michaelstevenstech.com/XPrepairinstall.htm http://www.michaelstevenstech.com/moving_xp.html the procedure is tricky, so it is not recommended unless there is a reason. Usually the BSOD flashes and then the computer restarts because of a badly configured (MS setting by default ) Registry key. By default XP is set that in case of Error it should re-boot. This setting can be changed through the GUI on a fully booted XP, in a case like yours the fix is changing a key in the Registry: http://www.pctools.com/guides/registry/detail/229/ You will need a PE of some kind to boot from and change the Registry key value in order to see the BSOD and know which is the specuific STOP ERROR it gives, most probably the 0x0000007b connected to a missing/wrong mass storage device driver as Tripredacus hinted. jaclaz

Yep, may ask you WHY do you want to argue over something for which you already know the (hopefully correct) answer? jaclaz