jaclaz

What do you mean? What is the problem with that? jaclaz

I was saying something slightly different, the Volume serial is a form of hash of actual date/time, i.e. the same serial can be generated on different date/times. If we use some fantasy it is not difficult to increase dramatically probabilties of a collision. Let's say that an employee in a Swiss watchmakers company was told to format a floppy and save to it his morning work just before lunch (or let's assume that a batch including a format command was scheduled to run every day at EXACTLY 12:30 ). Notwithstanding the high level of precision of the guy (or of the scheduler) while the actual job is started exactly at 12:30,00, the actual format command is executed with a delay variable between 0 and 99 hundreths of second. Another employee of the same company is tasked every month to store the images of the floppies, and, in order to identify them uniquely, uses the volume serial. What will happen on August 1st, 1992? (with data of July 1992) The probabilities field is a highly slippery one , but my guess is that probabilities of a collision in this scenario are very, very high, actually you have a very high probability of having at least one collision. See the attached spreadsheet..... Happy F9ing .... jaclaz Volchances.zip

Yes , that is expected (collisions when cloning in some situations), I was talking of actual "by chance" collisions, more curiosity than anything else, the ID is 4 bytes, thus min 00000000 and max FFFFFFFF, i.e. 4,294,967,296 available values, but 4,294,967,296 to 1 against though pretty rare is not "nearly impossible", and since the ID/Volume serial is not "random" but is calculated, as seen on the little "reversing" spreadsheet I made: chances are much bigger that that. jaclaz

An E90000 is not? Yep, for the moment I am still in the FAT12/16 only realm. Yes, hopefully you have only one of these mounted at a time, but generating a "random" ID is not a problem and "safer". BTW and OT, ever heard of a "collision"? Let's make it 0x29 then, though I still wonder WHAT used 0x28.... Yep, I was trying to avoid the need to dig up a Win9x to test, but I will do it like this, I wll make the non-bootable floppy sector based on the data we have till now, and then people may be able to test an image with it on a few systems . thanks for the insights. jaclaz

That's why I said it was NOT an answer to your question. (actually it is, but not the answer you wanted) No other kid wants to play with me with the XPCLI stuff . That is the traditional way, but why adding it in the first time, if you later remove it? Sure it is. You should be able to get a largely functional XP below 300 Mb But of course as always it depends what you *need* and how you rate "largely functional". Here is a step-by-step for one at around 400 Mb: http://www.i64x.com/eeexp.php Ever heard of the Wayback Machine? http://www.archive.org/ Well, LiveXP is NOT an XP, it is a PE 1 .x. And if you are gong the PE way, there are much smaller builds than that. (and again it depends on the functionalities you want/need), a couple oldish examples: http://www.911cd.net/forums//index.php?showtopic=12067 http://www.911cd.net/forums//index.php?showtopic=16543 http://www.brian-hoover.com/Navigation/Code%20Repository/Other/BartPE%20AIO.php but also the various Winbuilder "barebone" projects are much smaller than that. jaclaz

You didn't sound like it. As you were just told, "El-Torito" does nothing, one of the THREE available modes do, instead AND you do not have to know/choose anything about it, as it is "hard coded" in the builder. But you are an expert at it and at El-Torito settings? Sure it is possible, only with different, misterious ways. I have seen better advice in my experience, carpenter's comparison: You use nail to join planks because screws have that unesthetical slot or cross. Your problem is (finally): I have a .iso (or a CD/DVD) created with Bart's PEbuilder. How can I recreate it EXACTLY as it is, only changing three files? And there are two answers to it, one, ( the wrong one IMHO) is "use a .iso editor", and the (right IMHO) one is "rebuild the .iso", since what Bart's PEbuilder uses to make the iso is mkisofs.exe that has the nice feature of writing on the .iso HOW exactly it was used at build time. See here: http://reboot.pro/12406/ bextract 0.04 should do: http://reboot.pro/12406/page__st__31 Please note the highly specialized technical term I used : Running it on a "random" BartPE I have it gave me the mkisofs command used allright, but I have seen parsing errors on some builds, so until I find what is the parsing error issue and update the batch you can open the .iso file in *any* hex editor and search for text "mkisofs" to get the command line used, then open the .iso in 7-zip to get the no-emulation bootsector. jaclaz

I guess we are not targeting DOS 1.x, though, so I would say that we do need a BPB anyway. Naaah, I don't think there is any conspiracy , just "normal" stupidity/crazyness of non-standards or undisclosed/undocumented properly ones....... Back to business, A non-bootable bootsector needs to: start with E9 (or EB0090) <- to comply with the MS DOS 7.x (and hopefully earlier) and XP (and hopefully later) OS have anyway the Magic Bytes 55AA <- to comply with FreeDOS "quirk" since the OEM name is only checked during booting there is no need for it valid BPB data (from 0xB to 0x24) let's go on with the eBPB: Field Offset Length ----- ------ ------ Physical Drive Number 36 1 Current Head 37 1 Signature 38 1 ID 39 4 Volume Label 43 11 System ID 54 8 Physical Drive Number is seemingly only meaningful for bootable devices (so it can stay 00 for the non-bootable one) Current Head is OK left as 00 in any case, though we may add to the description it's use as "dirty flag" Signature (NT Signature) any reason to prefer 0x28 over 0x29 or viceversa? (I remember seeing only 0x29 in "real life" bootsectors) <- needed for compatibility with NT (and hopefully later) ID is this "needed" or a 00000000 would do as well? Volume Label, even if it is not used anymore it could be set to something more meaningful than the "NO NAME"? System ID: Definitely "FAT12 " or "FAT16 " Comments, ideas? @rloew Can you detail any findings you may have handy about IOS.VXD and/or VFAT.VXD behaviour? jaclaz

Just for the record (and to keep things as together as possible): jaclaz

Maybe because there is no need whatsoever to completely wipe the disk (and this will take some time). Wiping the first 100 sectors is more than enough (and much faster) should something prevent a normal install, but I personally also doubt that even this smaller set of sectors actually *need* to be wiped at all, in this case just wiping the MBR (1 sector) would do. JFYI, if you need to completely wipe a disk, CMRR Secure Erase is faster, as it uses the internal ATA commands: http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml @submix8c Grub does whatever is told to do in menu.lst. @cdoublejj If you could make a post actually describing the issue you are having, which is NOT clear to me at all, it may help. IF you boot from floppy *some* DOS and FDISK (NO switches) does work? 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