MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically.

Community Reputation

About Mijzelf

Recent Profile Visitors

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?

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.

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.

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.