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

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 t

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 f

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,

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)

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.