jaclaz

There are NO settings for the .iso creation! Bart's PEbuilder provides itself the right parameters to mkisofs.exe. You can only choose: the name of the .iso build the .iso or not additionally burn the .iso to CD or not http://www.nu2.nu/pebuilder/help/english/main.htm http://www.lazesoft.com/how-to-create-bartpe-bootable-cd-reset-administrator-password.html Usage of F5: http://www.911cd.net/forums//index.php?showtopic=21027&st=6 jaclaz

NO, you actually were WRONG, as you babbled about Word 2.0 doc files, (whilst the issue was with Word 6.0 doc files). The good news is that the OP also is wrong as he FAILED to do what he was told (preferring the shortcut of cwordpad) The KB glen9999 posted is part of the story, you have to additionally add the "AllowConvversion" key on updated systems. BUT, if you do so, you will be prompted to go here : http://support.microsoft.com/kb/923561 and told about how dangerous is to open that file with Wordpad: http://technet.microsoft.com/en-us/security/bulletin/ms09-010 It's seemingly a no-win/no-win situation (if you want to use wordpad you have to ckick OK each time (unless there is something else in the Registry that disables the prompt) jaclaz

Wait a further 35 minutes, then unpower the thingy, test if by any chance it is now unbricked, if not re-do from start. jaclaz

Just so you know, the IF EXIST in winnt.sif may choke on some card controllers See here: jaclaz

NOT what you asked . But maybe you could be interested to the "other way round", real Nano build, then add ONLY what you need: http://reboot.pro/3717/ Warning: much troublesome, highly experimental, YMMV, etc., etc. On another side, an old exeperiment with Windows 2000: http://reboot.pro/5679/ UPXing is a double-edged sword, it will make smaller disk occupation, but will use more RAM, if the buid is really "nano" you won't have that much improvement as most windows "core" files cannot be compressed. jaclaz

No, I thought that DOS 7.1 would have done for the moment. And what about this? http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/volume-boot-block-oem-name-field.html Where does the actual BPB end? Theoretically at 0x24 It seems like we have to consider the existence of a "real" BPB AND of an eBPB (extended Boot Parameter Block) http://support.microsoft.com/kb/140418/en-us (and consequently "divide" the set in BPB and eBPB) Yep , but as seen we need to have at least EB0090 or E90000 even on a "no code" bootsector (just as you posted ) for the tested MS OS's, while this is happily ignored by FreeDOS. Yep , but as seen we need to have at them for FreeDOS anyway, while the tested MS OS's happily ignore them. Last two items seems to me like a nice contradiction (and no-end loop kind of situation). On the other hand it provides a nice way to have volumes that are accessible/mountable only on FreeDOS (AND NOT on MS OS's)..... and another kind of volume that can be accessed only on MS OS's (AND NOT on FreeDOS) .... pretty much unuseful, if you ask me, but still some interesting news. (and also a way to have a volume accessible from XP - and possibly later - MS OS 's, BUT NOT from DOS 7.x - and possibly earlier) jaclaz

Since when? The result of running BartPE is a bootable .iso, you simply "burn" the .iso to CD/DVD. And BTW it uses (just like Windows install) No-Emulation mode, possible settings for a bootable iso are normally called: El-torito Floppy Emulation mode No emulation mode El-Torito hard disk emulation mode but this is already managed by the mkisofs when you build the .iso which is nothing but a sector-by sector image of the CD/DVD. And for a simple plugin there is also the F5 option in Bart's PEBuilder, which will recreate the .iso from the original BartPE folder (modified with the new plugin). jaclaz

Only part of the effort in distinguishing among cloning, imaging (sector based or forensic sound vs. file-based), and backing up. @tal ormanda A longish list of more or less suitable apps, each with it's "peculiarities" can be found here: Probably this would suit your needs: http://www.partition-saving.com/ jaclaz

The KB Glenn9999 posted is a correct answer: http://support.microsoft.com/?kbid=883090 but if you have Word installed, it may "interfere" with wordpad settings. In other words, I suspect that the issue is not "only" XP in itself, BUT XP with Word installed to it. In case of need: http://www.cetussoft.com/cwordpad.htm AND check this. http://www.wincert.net/tips/1786-word-cannot-start-the-converter-mswrd632wpc-error.html jaclaz

You make it sound a little bit too obvious and B/W for my tastes. There is a whole lot of shades of grey. http://reboot.pro/15878/ Experiments: make a "normal" floppy disk image with *any* bootsector starting with EB3C90 and ending with 55AA, write to it a simple .txt file. remove from it any boot code (optional). Replace 55AA with 00. Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed). Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy. [*]Replace EB3C90 with EB3C00. Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed). When in the VM, it fails with "General failure reading drive M" with DOS7.1, AND it cannnot be accessed properly by FREEdos [*]Replace EB3C00 with EB5800. Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed). When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy [*]Replace EB5800 with EB0000. Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed). When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy [*]Replace EB0000 with 000000. Image CANNOT be mounted by IMDISK. When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy [*]Replace EB0000 000000 with EB0090. Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed). Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy [*]Replace EB0090 with EB0190. Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed). Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy [*]Replace EB0190 with 000000 AND re-add the Magic Bytes 55AA. Image CANNOT be mounted by IMDISK. When in the VM, it fails with "General failure reading drive M" with DOS7.1, BUT it can be accessed allright by FREEdos [*]Replace 000000 with E90000. Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed). Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos [*]Leave the three bytes E90000 but remove the Magicbytes. Image can be mounted by IMDISK (and it's filesystem is recognized and it's contents are listed). Same can be done in a Qemu VM booting a DOS 7.1 floppy and putting the image as second floppy, AND it can be accessed allright by FREEdos, BUT ONLY if before you access another floppy I am attaching a set of such 1440K floppy images. Preliminary conclusions . under both DOS and XP the Magic Bytes are ignored and have NO influence whatsoever with reading/accessing the BPB, so they are part of the CODE (and not of the BPB) . XP only checks if first byte is EB OR that first byte is E9 (the three one jump bytes are is part of the BPB) DOS 7.1 checks that first byte is EB and third is 90 (the three two jump bytes are part of the BPB) OR that first byte is E9 (the three one jump bytes are is part of the BPB) FREEdos ignores the three jump bytes and only checks for Magic Bytes (so , Magic Bytes is part of the BPB and NOT of the CODE, and the three jump bytes are part of the CODE and NOT of the BPB ) and it also has some kind of "sticky attitude" if it accesses another properly setup floppy, somehow the Magic Bytes are "ported over". jaclaz EBE955AA.zip

Do you really think we know all the internet and can guess WHERE you read that ? And yes, we can . http://www.911cd.net/forums//index.php?showtopic=7233 but that is 2004, there are much easier ways by now (typically using a DOS floppy or superfloppy image mapped with grub4dos). If you state what your GOAL is (as opposed to the way you think you should reach it) there may be even further ways. Please take note of these too: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/problem-report-standard-litany.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html jaclaz

And which OS would you boot to use it with restore in the case the original machine is botched? jaclaz

Hey, kids, noone wanting to play with me anymore? I am almost finished with the spreadsheet , but I just got a doubt. The three bytes jump code is actually part of the CODE and NOT of the BPB, right? I mean, if I want to make a non-bootable bootsector those three bytes should be 00 00 00, and ONLY when I decide to apply the bootsector CODE, then they will get (examples): EB 3C 90 (MS) EB 3C 90 (FREEdos) EB 58 90 (some other bootsectors) etc. Or do you think that by default (if NO code is chosen) I should put a non-bootable bootsector code? Same question goes for the "Magic Bytes" 55 AA: http://linuxgazette.net/issue84/dashti.html are they used only if the bootsector is bootable (thus CODE) or they define the sector as a bootsector (and thus they should also be 00 00 by default)? Suggestions for a Public Domain or however freely redistributable bootsector code that can print a message (or display an image) welcome. JFYI, I have also started working on a few batches, and then stopped and then started again....., and again, and again.... ....I will do such things, .... ....What they are, yet I know not: but they shall be The terrors of the bootsectors jaclaz

Maybe, or maybe NOT. Just try doing some experiments, there is no way you can learn more than from direct experience. You can use IMDISK: http://www.ltr-data.se/opencode.html/ and since the experiments are about volumes and not "full disks" a straight sparse file generator, like mksparse: http://reboot.pro/3191/page__st__42 via Wayback Machine: http://wayback.archive.org/web/*/http://www.acc.umu.se/~bosse/mksparse.zip will be more than enough: mksparse 8gbvolume.ima 8gb Mount it in IMDISK. Format it with "default allocation size" as NTFS. You will have 8Kb 4 Kb clusters and $MFT @cluster #786432 Re-format with 512 byte cluster and you will get $MFT @ cluster #6291456 Re-format with 1024 byte cluster and you will get $MFT @ cluster #3145728 Re-format with 2048 byte cluster and you will get $MFT @ cluster #1572864 Re-format with 4096 byte cluster and you will get $MFT @ cluster ...... <find it yourself, then try to make some sense of the results.... (you can use a hex editor with a bootsector viewer to make sure) Tiny Hexer is recommended: http://reboot.pro/8734/page__st__17 Exactly, that's why it is important that you carry them experiments. -------------------------------- Yes, there is a lot of confusion, and you still have missed the point I was trying to make. The issue is the following, you have now a correct "mental map" where an Extended Partition is a container for (one or more) volume(s). Let's take the simplest possible Extended Partition, one that has inside a single big volume, and let's us assume that it is formatted with a FAT filesystem. You will have this container with: beginning of Extended Partition the EPBR and a few hidden sectors (the EPBR contains the start address of the volume and the end of Extended Partition) beginning of volume (first sector of the volume is the bootsector or VBR, it contains the start address of the volume and the end of the volume) end of volume end of Extended Partition (end of volume is the SAME as end of Extended partition) Now, compare with a whole disk (again the simplest possible setup, one single primary partition occupying all the space), and consider it as a container also: the MBR and a few hidden sectors (the MBR contains the start and end addresses of the Primary partition) beginning of Primary Partition (first sector of the Partition is the bootsector or VBR or PBR, it contains the start address of the volume and the end of the volume) beginning of volume (first sector of the volume is the bootsector or VBR or PBR, it contains the start address of the volume and the end of the volume) end of volume end of Extended Partition (BOTH beginning and end of volume are the SAME as beginning and end of Extended partition) And in both cases above the volume contains a filesystem (and the filesystem beginning and end are the SAME as those of the "container" volume). We can say that in this case the container (partition) is exactly the same of the contents (volume) and that the container (volume) is exactly the same of the contents (filesystem). Now, when you format with NTFS you are in this situation (the way the Starman represents it): Extended: beginning of Extended Partition the EPBR and a few hidden sectors (the EPBR contains the start address of the volume and the end of Extended Partition) beginning of volume (first sector of the volume is the bootsector or VBR, it contains the start address of the volume and the end of the volume) end of volume one sector holding a copy of the VBR end of Extended Partition Disk/Primary: the MBR and a few hidden sectors (the MBR contains the start and end addresses of the Primary partition) beginning of Primary Partition (first sector of the Partition is the bootsector or VBR or PBR, it contains the start address of the volume and the end of the volume) beginning of volume (first sector of the volume is the bootsector or VBR or PBR, it contains the start address of the volume and the end of the volume) end of volume one sector holding a copy of the VBR end of Extended Partition And the way I like to represent it: Extended: beginning of Extended Partition the EPBR and a few hidden sectors (the EPBR contains the start address of the volume and the end of Extended Partition) beginning of volume (first sector of the volume is the bootsector or VBR, it contains the start address of the volume and the end of the volume, but, IF the filesystem is NTFS the value is end of volume minus one sector) one sector holding a copy of the VBR end of volume end of Extended Partition Disk/Primary the MBR and a few hidden sectors (the MBR contains the start and end addresses of the Primary partition) beginning of Primary Partition (first sector of the Partition is the bootsector or VBR or PBR, it contains the start address of the volume and the end of the volume) beginning of volume (first sector of the volume is the bootsector or VBR or PBR, it contains the start address of the volume and the end of the volume, but, IF the filesystem is NTFS the value is end of volume minus one sector) one sector holding a copy of the VBR end of volume end of Extended Partition As you can see both representation may be valid, the issue is only when you go and backup such a thing, in my view, when I say that I backup a volume I actually backup from the beginning VBR to the End of the allocated space for the volume, including, in the case of NTFS the "extra sector". If you prefer, in my mental map the volume extends over the addresses stored in it's VBR, but in the case of a NTFS formatted filesystem, I know that the end address must be increased by one, or that the addresses in the VBR represent the filesystem and not the volume. And that while with FAT filesystem and volume begin and end at the same address, with NTFS the filesystem is one sector less than the volume. So i say that the volume contains the filesystem and in the case of NTFS it contains the filesystem + a backup bootsector. Just for the record, early versions of NTFS had the backup bootsector in the MIDDLE of the volume http://support.microsoft.com/kb/153973/en-us which, while making slightly more difficult to find the backup bootsector and making it prone to be deleted by some "deviating" software, did not create the above confusion between the addresses stored in the VBR and actual extents on disk. jaclaz

peewee you are seemingly missing the main point If the manufacturer utility says that the drive has failed, it has failed. Now you can try to "revive" it by using a few programs, but unless they are trivial (fixable) errors, that disk drive is deemed ultimately to the dustbin. The effect of the format command is DIFFERENT in XP and in Vista (and later) OS: You may want to try it with a "third party utility" such as Victoria for Windows, and/or invest a few bucks in HDD regenerator, but that's in practice everything you can make. The way DOS marked bad sectors as bad is still effective, but generally speaking never has a chance to "kick in" as the drive firmware will prolly re-map the defective sector in a way that is transparent to the OS and filesystem utilities before they can detect it. If there is one (or a few) biggish chunk(s) of bad sectors, simply partition the drive in such a way that the bunch is outside the partitioned/accessible space, but there is NO guarantee whatsoever that the "bad zone" won't "expand" over time. Always think that a 250 Gb drive has more or less 25 times the capacity of a (largish) DOS era drive in the same physical space, this basically calls for a 25x precision in *everything* , no actual surprise that it has more chances of developing a defect. jaclaz

Sure, define "best", please. Some of the possible parameters that contribute to "best": faster in imaging faster in restoring tighter (smaller) image "forensic sound" or "filesystem sound" or just "file based" disk based or partition based capability to restore to a different disk capability to make fractioned images (to be stored on several CD/DVD's, as an example and to restore from them running from which OS/LiveCD/etc. price range (IF Commercial/NOT Freeware) GUI vs. command line image format compatible with other utilities (name them) add here any other feature I might have missed jaclaz

Quick instructions: create a "dummy" (i.e. NOT containing ANY personal/meaningful data) .doc with wordpad under 9x. verify XP worpad "chokes" on it compress the file to a .zip archive and attach it to your next post or upload somewhere and provide a link to it Someone may be able to replicate the issue and hopefully find a solution (or at least a workaround). Call me hairy reasoner as you like , but since a typical Win98 system originally shipped (LATEST ones, year 1999 or 2000) with 64 Mb of RAM and a P-III at 700 Mhz or 1GHz processor or the like, a Windows 98 in a VM machine (even Qemu) will be on average modern hardware at least as fast as the original system you were used to, so, if you don't want to dual boot (to gain speed at the expense of "fixing" the 98 install to new hardware) a VM is a good enough solution, as I see it. On the other hand, if you like to play the game , you need to approach each single issue at a time, one by one, and know that a solution may exist or may not. jaclaz P.S. Small (needed IMHO) correction: Just for the record "people who know what they're doing" usually know also how to disable SFC/WFP.

Just to keep things as together as possible: http://www.911cd.net/forums//index.php?showtopic=24719&hl= http://reboot.pro/16164/ jaclaz

Ranish Partition Manager lets you have a backup (and more) at a place of your choice. Drawback is that it's user interface is not intuitive at all, not to say user unfriendly. And as we saw, support for bigger disks is dodgy. Sure, and you can also use dd or any other direct disk access software, to make a copy of a sector and store it on another sector, including DEBUG on DOS/Win9x to make a copy of it. I'll rephrase : Landing or parking zone is - as clearly stated on the given link - a "no-data" zone, it has nothing to do with where data is stored. Additionally a number of disks have a "head parking zone" OUTSIDE the disk platter on a ramp, so called UNLOADING: http://en.wikipedia.org/wiki/Hard_disk_drive#Landing_zones jaclaz

You do understand that you are asking about Installing Windows from USB in the Multi-Boot CD/DVDs forum? Your question should possibly go here: http://www.msfn.org/board/forum/157-install-windows-from-usb/ However, your report is "strange". Windows 7 install from USB cannot normally work like that (from .iso) and you will have the same missing CD/DVD error, most probably the fact that you have (why?) duplicated sources like the "install.swms" may be, creates a sort of hybrid install. You should read this one: http://reboot.pro/9076/ and check among the proposed solutions: http://www.rmprepusb.com/tutorials/how-to-create-a-usb-drive-that-will-install-vista-win7-and-server-2008 http://www.rmprepusb.com/tutorials/winiso http://www.rmprepusb.com/tutorials/firawiniso jaclaz

No . Yes . The basic notion that the $MFT is actually a file. It begins at it's begin and ends some bytes "later" or "on the right". A cluster size is "defined" as part of the filesystem "earlier" than the $MFT, or, if you prefer, you know how much a foot is, but you first need to establish a length (say 1 yard equals 3 feet) and only after you can say that something is 10 yards from you. In the bootsector you first write how big in sectors a cluster is, and only later you can use that unit of measure to actually find the address where to start writing the $MFT. The equation is: y=ax where: $MFT Start Address (in sectors)=y Cluster size (in sectors)=a (Constant) $MFT Start Address (in clusters)=x you cannot find y if you don't know (besides x) the value of the multiplier a (and you can only count sectors until you devine cluster size) You are wrong , see above. You still have some confusion between MBR (which is ALWAYS on LBA sector 0) and bootsector (or PBR or VBR) whiich is first sector of the volume (see below for definitions). On a disk there is only one MBR and as many bootsectors as there are volumes, WHICH of the n bootsectors would you think should be written to sector LBA 1? grub4dos does normally (and IF installed to the MBR+hidden sectors AND IF properly installed) store a copy of the MBR on LBA 1, though. I know of no other software that does the same, let alone MS OS's. NTFS has this feature, when you format a partition (or volume) with NTFS the volume size will be 1 sector less than the actual space in the MBR (or EPBR) partition table, this extra sector, inside the partition or volume but outside of the actual filesystem, holds a copy of the first sector of the NTFS formatted partition/volume, see: http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm#BSback (and you also have another example on how confusing the terms partition, volume and filesystem can be, I use them in a slightly different way from there) To me: filesystem=volume for FAT1x/32/64 (but we can say that filesystem is INSIDE the volume, , actually being EXACTLY the volume, or if you prefer the filesystem and volume start and end at the SAME address) filesystem is INSIDE volume for NTFS, as filesystem and volume start at the SAME address BUT filesystem ends 1 sector before volume if the partition is primary, partition=volume (but we can say that volume is INSIDE partition, actually being EXACTLY the partition, or if you prefer partition and volume start and end at the SAME address) if the partition volume is a logical volume inside extended partition, volume=volume and it is of course inside the (extended) partition, but it starts at a given address that is NEVER the same address as the (extended) partition and ends at an address that may (or may not) be the same as the (extended) partition Yep. Never happened to actually fill a NTFS volume "up to the brim" (or at least I don't remember having studied the "filling area progression"). Logically the MFT area should be eroded "from the right", as to leave as much "reserved" area as possible at each file written, most probably this is done in "chunks", but really cannot say. That's why I said: I'm more like a hex/command line only kind of guy, but you could have a look at ultradefrag: http://ultradefrag.sourceforge.net/ jaclaz

No way to know, if it a modified OEM source it may be not your fault (though honestly and with all due respect, it could also be just you). Let's see if another couple questions (actually your answers to them) provide some more useful info: Do you have a physical CD disc? If yes, what is written on it? jaclaz

It makes sense BUT does NOT answer the "original" (pardon me the pun ) question: There are several versions of "original": original XP ("full") <-the "where" is Microsoft, directly or through a dealer original XP ("generic OEM") <-the "where" is Microsoft, directly or through a dealer, and it came together with your hardware original XP ("OEM" AND modified by the OEM, i.e. HP, DELL, etc.) <-the "where" is the OEM, directly or through a dealer, and it came together with your hardware #3 may have been (even deeply) modified by the OEM. jaclaz

I had this deja-vu feeling jaclaz

As often happens, I beg to differ. Command line is very functional in any NT/2K/XP OS, and it's command line interpreter CMD.EXE actually has a rather extended command set/functionalities. Besides the referenced SS64 site, Rob van der Woude's one is an excellent source: http://www.robvanderwoude.com/ The issues are most probably not at all related to cmd.exe, but rather to the HAL layer (or if you prefer the NTVDM ) combined with the common use in "real DOS" days of undocumented functions/direct access to hardware and what not). If the OP, instead of a general ranting would provide an EXACT, DETAILed list of the issues, maybe someone could try and help him in mitigating them. jaclaz