Jump to content

Mijzelf

Member
  • Posts

    464
  • Joined

  • Last visited

  • Donations

    $0.00 

Posts posted by Mijzelf

  1. 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.

  2. Really, what was their claim for dropping support all of sudden, did they say something on that? I mean what was the idea behind it? 1/3 of computers still use XP, and the OS is one year away from being unsupported by microsoft, what's the point of dropping support this year and not next, it doesn't make sense.

    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.

  3. 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?

  4. I would surmise that it is reserved for a specific device that either you don't have, or for something disabled. For example 40F000 might be for USB 1.0 or some other variant of another device ( existing or not ).
    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.
  5. I would speculate that some government agencies in non-Western countries are purchasing these Win98 motherboards, to be less vulnerable to Western malware attacks. If this is true, one could speculate further that eventually new malware for the Win9x platform will be developed by Western agencies.

    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?

  6. The device just doesn't have a partition table.
    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.

  7. 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:

    Will any of you create a compiled dd.exe that:

    • needs NO external .dll's
    • has NO "convert" options
    • an access Physical devices both read and write
    • has an internal /dev/zero
    • it is smaller than the mentioned ones (ideally below the 40 Kb mark)

    Doesn't seem the author thought he had succeeded.
    curiously a version that includes a /dev/zero device
    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?
    and of course piping is perfectly posible on NT systems.
    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/sda

    It's all just available.

  8. But since Multibooter is already on the "dd bandwagon", he (and you ;) ) might find this thread interesting:

    http://reboot.pro/15207/

    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.

  9. Maybe you'd kill the partition table before creating the filesystem:

    dd if=/dev/zero of=/dev/sdb bs=1M count=1

    This 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=ANCHOR

    The 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
    272

    The 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

    start=-387938385
    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)
  10. I am attaching a screenshot of  the 2TB HDD under Ubuntu, freshly formatted under WinXP with WriteUDF to UDF 1.02. If you need the screen shot in the future, please save it since I am running out of upload space and will delete it soon.
    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.
  11. <br/>

    I am attaching a screen shot. The file of this screen shot is actually the added file on the LinuxUDF HDD, which is visible under Ubuntu, invisible under Win98SE and which causes problems for WinXP.

    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).

  12. When I enter sudo fdisk -l Ubuntu displays /dev/sdb and /dev/sdb1, both with System HPFS/NTFS and 2000.4GB. A UDF drive with a partition?

    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.

  13. so I am told by the 2 (two) people that still run it daily
    Really? I cannot remember I ever told you of my problems.

    Anyway, I am running W95 OSR2, on a 25MHz 486SX, and 16MB memory. Actually it's in use as a ethernet to parallel port converter, also called printserver. The only extra software installed is vnc-server, and a small program I wrote myself, which pings a number of IP addresses, and shuts down Windows when nothing is answering anymore. (When no computer is up, no-one will print, right?)

    msdos.sys is reconfigured not to start the GUI, and autoexec.bat contains:

    win
    music.exe

    When Windows is down, it will return to DOS, and start the dos program music, which will make some noise through the on-board speaker, so I know Windows is down and the computer can be switched off. (There is no monitor, mouse or keyboard attached).

  14. Trolling? That is not my intention, so I apologize when it looks like that.

    About 32 bits, from Wikipedia

    For each pixel, generally one byte is used for each channel while the fourth byte (if present) is being used either as an alpha channel data or simply ignored.
    I know in some image formats (tiff,png) a fourth channel can be used for alpha.

    But think about it, what should alpha information do in video memory (except for making you able to see the Bacterians in time)? I am convinced that it's value is simply ignored, and the only purpose for the byte is memory alignment.

  15. @ScrewUpgrading: 16 bits color can be a lot slower than 24 or 32 bits. Internally windows uses 24 bits, so a lot of bit shuffling has to be done to fit the 24 bits 8-8-8 pixels in 16 bits 5-5-5 or 5-6-5 pixels. Each time a pixel has been written to the video memory.

    On the other hand, less memory have to be written when using 16 bits, so when you've got a slow bus (ISA?), 16 bits might be faster.

    When bandwidth and video memory is no bottleneck, 32 bits can be even faster than 24 bits. 32 bits is actually 24 bits and a padding byte, to make each pixel address a multiple of 4. Due to architecture oddities this makes accessing pixels faster.



×
×
  • Create New...