Mijzelf

Unicorns a myth?

I remember a virus (looong ago) which hijacked the exe registration. Instead of "%1" %* it did \full\path\to\virus.exe "%1" %*. This way the virus was activated as soon a you started an executable. Then the virusscanner removed the virus, but did not correct the registry key. Result: you could no longer start an executable, not even regedit. Solution: Boot the box to dos (F8 while booting? Long ago), rename regedit.exe to regedit.com. Boot to Windows, execute regedit.com and fix the entry.

It's not dropping support, it's 'not adding' support. For those new chipsets new drivers were needed. Most new chipsets are shipped in new computers, most new computers are shipped with a new OS. So I guess Intel didn't think it is profitable to write XP drivers for the few people who put a new mobo in an old computer, or who install an old OS on a new computer.

Windows XP is the first MS OS which needs to be activated. If MS just switches off the activation server, no new XP installations are possible, unless you somehow pull the check, which is against the law. If you have an XP license, which shows no expiration date, and if MS switches off the activation server, does that mean you have the right to do whatever needed to keep it running?

Why are you now switching from a position based key to a function based key? It seems more likely to me that the chipset has support for 7 slots, and only 6 are actually physically installed.

Uhm, why shouldn't they just use a state-of-the-art motherboard, running a much less vulnerable OS, like OpenBSD, from which they can easily check if evil Western imperialists didn't put any backdoors in it, and for which currently is no malware around at all?

I disagree. I have inserted under WinXP into an SDHC card reader a 1GB SD card with 2 partitions, which I had left over from my experiments with SDHC cards <snip> MBRWizard 4.0 appears to display correctly the partition info of a partitioned SD card, so the partition info by MBRWizard about the caleb diskette (also removable/ejectable media in a USB device) may be correct.I agree that MBRWizard might be capable to correctly show the partition table of a caleb diskette, but the output of both fdisk and MBRWizard in this case is plain bogus. The partitions overlap, and are bigger than the disk itself. So the MBR doesn't contain a valid partition table.

In that case I misunderstood your intention. The first link is (in my eyes) a blog about the search to a small port of dd, without huge dependencies. Conclusions: Doesn't seem the author thought he had succeeded. Curious indeed. The device is needed to zero out any output file of dd. But the simple fact that it's needed to include it makes the executable more complex, and also shows the shortcoming. How about /dev/random? Yes, NT supports piping, and a Windows port of dd likely also. But the ecosystem mainly doesn't. So where can I pipe from/to? A mayor strength of dd (and most commandline tools) in *nix is that it can be piped with many other tools, adding amazingly much functionality. Want to fill a disk with 0xFF?cat /dev/zero | tr "\000" "\377" | dd of=/dev/sdaIt's all just available.

The device just doesn't have a partition table.

I think anyone who wants a 'simple' Windows version of dd, is doomed, just because it can't be done. On *nix, dd is a quite simple and small (54kB on my box) utility, and that can be done because dd only needs to know 1 single trick: Copy one or more blocks of data from one file to another. On *nix everything is a file, a disk can be treated as a file, and so can a partition, or a regular file (duh!), and something like /dev/zero is just a file, which will return zero's on each read, no matter how big the blocksize or from which start position. Oh, and stdin and stdout are pipes, and so also files, so you can also read from, or write to a pipedevice. Storing and restoring a parition to a zipfile: dd if=/dev/sda1 | gzip >sda1.zip gzip -d sda1.zip | dd of=/dev/sdb1 But in windows all these kinds of devices have different ways of open, read and write, so dd has to recognize each device you offer him, and know the way how to access them, creating a big and complex executable, or it has to lean on a complex compatibility layer, like Cygwin.

dd in Linux.dd if=/dev/zero of=/dev/sdb bs=1M count=16will copy 16 blocks of 1MiB from /dev/zero (an infinite source of zero's) to /dev/sdb (second harddisk)

Maybe you'd kill the partition table before creating the filesystem: dd if=/dev/zero of=/dev/sdb bs=1M count=1This will zero out the first 1MB of the disk. I did some tests with mkudffs. First, create a 1M file filled with zeros, and one filled with 0xFF: dd if=/dev/zero of=1M00 bs=1M count=1 tr "\000" "\377" < /dev/zero | dd of=1MFF bs=1M count=1 Put an udf filesystem on them, using Multibooter's parameters: $ mkudffs --media-type=hd --blocksize=512 --udfrev=0x0102 1M00 start=0, blocks=64, type=RESERVED start=64, blocks=12, type=VRS start=76, blocks=180, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=16, type=PVDS start=273, blocks=1, type=LVID start=274, blocks=1517, type=PSPACE start=1791, blocks=1, type=ANCHOR start=1792, blocks=239, type=USPACE start=2031, blocks=16, type=RVDS start=2047, blocks=1, type=ANCHOR $ mkudffs --media-type=hd --blocksize=512 --udfrev=0x0102 1MFF start=0, blocks=64, type=RESERVED start=64, blocks=12, type=VRS start=76, blocks=180, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=16, type=PVDS start=273, blocks=1, type=LVID start=274, blocks=1517, type=PSPACE start=1791, blocks=1, type=ANCHOR start=1792, blocks=239, type=USPACE start=2031, blocks=16, type=RVDS start=2047, blocks=1, type=ANCHOR Look at the actual contents: $ hexdump 1M00 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0008000 4200 4145 3130 0001 0000 0000 0000 0000 0008010 0000 0000 0000 0000 0000 0000 0000 0000 * 0008800 4e00 5253 3230 0001 0000 0000 0000 0000 0008810 0000 0000 0000 0000 0000 0000 0000 0000 * 0009000 5400 4145 3130 0001 0000 0000 0000 0000 0009010 0000 0000 0000 0000 0000 0000 0000 0000 * 0020000 0002 0002 00c3 0001 af1d 01f0 0100 0000 <snip> $ hexdump 1MFF 0000000 ffff ffff ffff ffff ffff ffff ffff ffff * 0008000 4200 4145 3130 0001 0000 0000 0000 0000 0008010 0000 0000 0000 0000 0000 0000 0000 0000 * 0008800 4e00 5253 3230 0001 0000 0000 0000 0000 0008810 0000 0000 0000 0000 0000 0000 0000 0000 * 0009000 5400 4145 3130 0001 0000 0000 0000 0000 0009010 0000 0000 0000 0000 0000 0000 0000 0000 * 0009800 ffff ffff ffff ffff ffff ffff ffff ffff * 0010e00 0002 0002 0090 0001 26ed 01f0 0087 0000 0010e10 2000 0000 0101 0000 2000 0000 0177 0000 0010e20 0000 0000 0000 0000 0000 0000 0000 0000 * 0011000 ffff ffff ffff ffff ffff ffff ffff ffff * 0020000 0002 0002 000a 0001 26ed 01f0 0100 0000 <snip> Conclusion: The first 32k is not written at all, and further only a few bytes are witten at the start of each section mentioned by mkudffs. I repeated this with a 64MB file: $ mkudffs --media-type=hd --blocksize=512 --udfrev=0x0102 64M00 start=0, blocks=64, type=RESERVED start=64, blocks=12, type=VRS start=76, blocks=180, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=16, type=PVDS start=273, blocks=1, type=LVID start=274, blocks=130541, type=PSPACE start=130815, blocks=1, type=ANCHOR start=130816, blocks=239, type=USPACE start=131055, blocks=16, type=RVDS start=131071, blocks=1, type=ANCHORThe same blocks (and also the same blocks as on Multibooters 2TB disk), only the size is different. Also the amount of written data is equal: $ hexdump 64M00 | wc -l 272 $ hexdump 1M00 | wc -l 272The number of 'not zero' lines is the same. So an UDF formatted 2TB disk can easily contain a (almost) undamaged FAT filesystem. But I couldn't find the 'fake' partition table. This is not made by mkudffs, but maybe it is by one of the Windows tools. It seems UDF doesn't care about the contents of the disk, outside the 10 small blocks of data it writes This might be a point of care. The sectornumber swapped to negative. This might be only cosmetical, but maybe mkudffs actually can't handle disks with more than 2^31 blocks, which is a bit bigger than 1TB (at a blocksize of 512)

Hey, it's a terminal. You can just copy&paste the text.Anyway, this proves it. sdb1 starts on sector 0, just like sdb1p1. The partition contains the partition table. Or, looking in another way, sdb1 doesn't really exist, just the disk sdb starting with a fake partition table. (Recursing backwards).I wonder if this is just a trick to get Windows happy. Windows regularly doesn't like a disk to have no partition table.

This is great! Apparently the UDF filesystem starts with a partition table, which is conscientiously read by fdisk, and it shows the nested partition /dev/sdb1p1 (the notation ..pn is used for partitions on devices which normally don't have partition tables, like mc cards and loop devices. And apparently also partitions. The size in blocks of /dev/sdb1 and /dev/sdb1p1 is equal, so it seems the partition /dev/sdb1p1 also contains the partition table itself! (Maybe this causes your WinXP hang? This is fully recursive, so it could be running forever trying to find the most inner partition table) Can you repeat this with 'fdisk -lu'? This will show the start and endpoint of the partition(s) in sectors, instead of cylinders. About your FAT-UDF hybrid: Did you change the filesystem ID in the partitiontable from FAT32 to HPFS/NTFS? AFAIK Win9x just reads the filesystem ID, and tries to mount using the dictated filesystem. So in case of FAT32 it reads the MBR, finds the size of the FATS and the startsector of the rootdirectory, which all might be just there, if UDF didn't overwrite it. 2 filesystems can coexist on one blockdevice as long as they don't overwrite each others vital structures. (All 'unformat' utilities are based on this).

What exactly does 'fdisk -l' show? Your output is impossible. 'fdisk -l' only shows the contents of a partition table, including the filesystem ID, which happens to be HPFS/NTFS for your sdb1. But fdisk cannot show a filesystem ID for sdb, because a disk cannot have this kind of metadata.