byte-to-pixel data display program?

ONE: the ONLY drive was the SCSI; i had booted with the Parted Magic CD and that gets ejected after program is loaded. TWO: i know nothing about that Linux gibberish, all i know is what the disk erase options say. THREE: "Expecting dd to work if the OS isn't following through"....are you trying to tell me that Linux is unreliable? FOUR: what id straps? I just looked carefully, and the BRAND NEW drive has some pins available, presumably for testing purpose, and the drive arrived with those unused. FIVE: What HBA diagnostics? Where? SIX: When i have seen a directory of the drive, i have added files and deleted others. Really nice after a "diskwipe" ...

Looks like "C" to me. Forget it (1) no compiler, (2) that "example" most likely will not even compile as-is, (3) "C" and i plain do not get along together, wasted a month trying to get simple assed programs like "hello world" to work; followed the tutor book to the letter. Someone else then wrote a simple counting program which did work. I found that it was impossible to find the code, that the same program written in BASIC and compiled, was extremely easy to find, took a tenth of the space and ran ten times faster. Furthermore, the compiled code was available in ASM format and no improvement could be done on the code - already optimized.

Did you notice a killer word in the description? "file". Does that not mean some kind of readable directory?

They make it sooo complicated, when there is NO need...

Thanks. got the 0.5 and the 0.6beta. Now all i have to do is try to remember how the heck to get into admin mode, and what a CMD prompt looks like in admin mode.

BTW,that would be dd if=/dev/zero of=\\?\Device\Harddisk0\Partition0 since i would operate in my standard mode and have only the one HD (nobody can say data etc is coming from somewhere else).

I think the problem is that you are just too thick to understand either how to use the program you claim has failed to erase the disk properly or how to diagnose the problem and very probably both.

I have a feeling that Windows these days blocks direct physical access to the disk layout for all user mode programs. You are best off trying to read the physical disk from a Unix shell of some sort.

--
Regards, 
Martin Brown

So it would be more like:

with open("/dev/sda","rb") as raw_drive: try: raw_drive.seek(offset, start_pos) data = bytearray(raw_drive.read(num_bytes)) except IOError: //error handling

The "with...as" statement block should ensure that regardless of success/failure the pipe to the device is cleaned up/closed out appropriately

Thanks. Seems you are the only one that approaches this simply, and not talk about TerrorByte drives (which i clearly DID NOT indicate), not talk about exotic things that Parted Magic does not do, does not talk about reading umpteen gigabytes (which i clearly DID NOT indicate), does not talk about exotic graphics (which i clearly DID NOT indicate), does not read what i said, etc.

Above is KISS. As a cat might say, PURRfect.

Let me see if I can explain this without using "big woids and frazes"...

A file is an ordered collection of zero or more bytes. (i.e., 1 2 3 4 is a different collection than 2 3 1 4)

It optionally can have one or more names. (i.e., it can have MULTIPLE names!)

Names are largely chosen by conventions.

Names need not be "stored" ON the medium containing the named objects (!) (e.g., where is the name "C:\" stored??)

A medium (e.g., disk) is an ordered collection of zero or more bytes.

A medium can contain files -- by imposing a structure on the bytes that it contains ("Hmmm... we'll call these bytes a 'partition table' and those bytes a 'directory' and these others can be a 'file' *in* that 'directory'...)

Now, here comes the hard part. Concentrate...

There is nothing to stop a program that can display an "ordered collection of bytes" from displaying a MEDIUM FULL of bytes! Nor does the collection need to exist in some physical form; /dev/timeofday is an ordered collection of bytes that happens to yield 11:04:27 when read. A second read of the same "file" yields 11:04:32! OhMiGosh!!

Anything ordered collection of bytes that can be NAMED in a manner that can be parsed by a "reader program" can thus be examined

*by* that reader program.

E.g., if that program were to attempt to read /dev/timeofday, it would yield the result 11:04:54. If it was told to read /dev/wholedisk, then it would display the ordered sequence of bytes on the "wholedisk" (whatever THAT may be).

In, for example, NetBSD, /dev/rwd0 is the "name" (filename!!!!!!!!) of the "raw" Winchester Disk #0.

[A "raw" device is seen as a byte/character stream, not as a set of 512/2048/4096/etc byte "blocks"]

The designation /dev/rwd0d refers to the entire contents of the medium (as if you positioned the "read head" at the very beginning of the medium and watched every byte fly past, in sequence). In a PC, this is the MBR and a set of "partitions" - which typically encompass most/all of the medium.

So, any access (read *or* write) of the (file!) named "/dev/rwd0d" will be interpreted with respect to the boundaries of the physical disk medium. If I want to inspect (or alter!) the MBR (on a disk that I *know* to have an MBR -- the VTOC from one medium to the next can vary based on the needs of the OS that supports it!), then I would access this /dev/rwd0d "file" (remembering that a file is just a collection of bytes, not a "file" in the colloquial sense)

The MBR can contain 4 MBR_PARTITIONS (deliberately referenced in this way to sidestep the confusion to follow!).

A NetBSD system refers to these as SLICES. So, the third MBR_PARTITION may define a slice that contains a NetBSD file system.

The designation /dev/rwd0c refers to the contents of the NetBSD slice on that drive (you may be SHARING the "whole disk" with something else). So, if I access the /dev/rwd0c "file", I will only see those things that pertain to the NetBSD system; the MBR (which is part of /dev/rwd0d) won't be visible.

Likewise, if I scribble on /dev/rwd0c with utter abandon, I can be assured (by the operating system) that I will NOT interfere with anything that "doesn't belong to NetBSD". E.g., I can have Windows on the same physical disk and never worry about corrupting any part of that Windows system!

So, /dev/rwd0c can be regarded as the NetBSD "disk" -- within the physical /dev/rwd0d disk.

The designation /dev/rwd0a refers to the contents of the first BSD_PARTITION (note the difference indesignation between MBR_PARTITION and "slice") *in* the NetBSD part of the drive. And, /dev/rwd0e is the second part (rwd0b is, by convention, the "swap" (i.e., "PAGEFILE") partition of the drive.

Because we are now operating entirely *within* the NetBSD MBR_PARTITION (slice), we are no longer bound by the rules that apply to the MBR. Namely, we can have many more than 4 "partitions" on a NetBSD disk (i.e., in a NetBSD *slice*). Each have names in the "file hierarchy", though none of those names appear on the media, per se.

In my case (for a single physical disk system): wd0a root wd0b swap wd0c NetBSD portion wd0d whole disk wd0e /var wd0f /usr wd0g /usr/pkg wd0h /home wd0i /Sources wd0j /Playpen wd0k /Archive

So, I can examine the part of the NetBSD disk that I mount as the home directory directory (/home) by examining /dev/rwd0h. If I poke around in there, I'll eventually find the contents of all of "my" files -- in their "raw" forms (without the benefit of the directory structure imposed by the filesystem).

Likewise, if something is *munged* in there, I can directly edit those bytes on the media by referencing them:

- somewhere within /dev/rwd0h (i.e., /home)

- somewhere within /dev/rwd0c (i.e., the NetBSD slice that contains /home!)

- somewhere within /dev/rdw0d (i.e., the whole disk that contains the NetBSD slice that contains the /home partition!)

And, in each case, I am dealing with a "file". And, the same tool that you might choose to use to examine/alter the contents of ReadMe.txt

A "safe minimum" for disk maintenance is two disks.

One for your Windows C: (i.e. where the OS lives, where ntfs.sys is located). You need a stable platform somewhere, for code to run from. Erasing the OS while the command was running, probably wouldn't work very well :-)

+-----+-----------------------------+ | MBR | C: Windows (running OS) | Harddisk0 +-----+-----------------------------+

+-----+-----------------------------+ | second drive in need of erasure | Harddisk1

+-----+-----------------------------+

dd if=/dev/zero of=\\?\Device\Harddisk1\Partition0

Or let's make up a more dangerous example. It is possible to erase a partition on the same drive. But, just a partition, not the whole drive. The notation is "Partition0" is a whole drive. "Partition1" is the first partition. "Partition2" is the second partition.

+-----+-----------------------------+-----------------------------+ | MBR | C: Windows (running OS) | D: Data partition to erase | +-----+-----------------------------+-----------------------------+

dd if=/dev/zero of=\\?\Device\Harddisk0\Partition2

Note that this application has a mind of its own. It will arbitrarily decide you don't have permission (even as administrator) to erase a partition. You will see a leading indicator when using

dd.exe --list

as any partition which lacks size information, there's a good chance you cannot erase it. I haven't seen enough of a pattern to this behavior, to give a recipe as to what's up.

*******

The Linux version is "without compromise", but I still like the chrysocome.net effort anyway. It allows me to do the things I need to do. This would erase the "D: Data partition to erase" in the last example.

dd if=/dev/zero of=/dev/sdb2

The disks don't magically take the right position. It's up to *you* to positively identify the target. Check, check and re-check your command, before issuing. Have full backups, if you're a klutz with the command line :-)

*******

In the more modern Windows Oses with "diskpart" application, you can select a drive and do "clean all". Which is equivalent to an attack with dd.exe , but there isn't as much feedback.

To monitor progress, normally you can open Task Manager, edit the column configuration, add "Read Data" and "Write Data" columns, and they show the cumulative I/O done by the program. If you're erasing a 1TB drive, you expect to see a big fat number in the write column. And by glancing at that once in a while, you can see how much longer it will take.

You can also run perfmon.msc and add some counters to the display, to show instantaneous I/O. And that's another way to get feedback about how efficient a "dd.exe" command you've just issued.

*Be careful*

*You can easily erase the wrong drive*

Be absolutely sure of your syntax before each invocation.

*******

Potentially, you could boot your Windows 7 installer DVD, select the option to run a Command Prompt there, and run simple programs (ones without a GUI). I haven't experimented with this, because between running dd.exe from Windows, or running a Linux LiveCD and using "dd" on there, I've always been able to get the job done. I'll leave the more esoteric attacks for others :-)

Paul

photorec does not need a directory on the source media.

--
This email has not been checked by half-arsed antivirus software

Sounds to me like you want to "visualize" the bytes on a harddisk ? (storage device)

Correct ?

And also why ? :)

Bye, Skybuck.