jaclaz

From the boot image file you posted, it seems to me: 1) it's a boot CD image of some kind (the text CDBOOT is present a number of times) 2) the size is a multiple of 2048 (size of the CD sector) I would try to make a bootable .iso with it and test the result in Qemu (or other VM) - I would try several ones as they tend to be "picky" when it comes to .iso booting I would use mkisofs.exe with something like: mkisofs -v -iso-level 3 -l -D -d -J -joliet-long -R -sysid "Win32" -b boot.img -no-emul-boot -boot-load-seg 0x1000 -allow-multidot -hide boot.img -hide boot.catalog -o .mytest.iso SMINST or mkisofs -v -iso-level 3 -l -D -d -J -joliet-long -R -sysid "Win32" -b boot.img -no-emul-boot -boot-load-size 47 -boot-info-table -allow-multidot -hide boot.img -hide boot.catalog -o .mytest.iso SMINST (just ideas, mind you ) jaclaz

Any recent (meaning several years) motherboard have BIOS chips with a "recovery" part (which is not "flashed" by updates or normal BIOS tools) that's the part that should make the beeps and allow re-flashing from floppy even if all the rest has gone beserk. It is nearly impossible (if possible at all) to "ruin" this part, and anyway VERY unlikely that this happens on three machines. If you have access to some other boards, not necessarily identical, the only necessary thing is that they use the same kind of BIOS chip and same BIOS manufacturer (AMI, AWARD, Phoenix, etc.) from a motherboard grossly similar, like same socket, same "main" chips, you can try using the "other" BIOS chip on one on the failing boards, after having checked thoroughfully that there is not some electrical problem of any kind to the actual BIOS chip socket. The "exchanged" chip won't get harmed in any way, and even if the "recovery block" is not exactly the same, it should be enough to beep or however to change the behaviour of the motherboard when booting. If you see changes you may risk the money to buy the new chips, otherwise it would be wasted money. jaclaz

The date of the bootpart.exe version update that I downloaded is 01/08/2005. As you say the program is rather poorly explained. Now I understand much better what I've done: I've only replaced the part of the bootsector that calls the Operating System, which in fact was damaged. Thank you very much for your documented post, jaclaz! Yep that's the latest, version 2.6 : http://www.winimage.com/bootpart.htm You are welcome. 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