how low (level) can you go?

[peterworth]

i want to read directly from an address in memory (ie regardless of whether it is part of the assigned program memory).

can i do this in a C program?...

this:

char* pointer = (char*)0;
fwrite(pointer,4,1,file);

causes a debug assertion error. can i just turn these assertions off or something?

 

[cpjust]

This is a C++ forum, not a C forum.

No, you can't write to (or even read from) memory that doesn't belong to you. That would defeat the whole point of the protected memory system. ;-)

 

[xwb]

Depends on what type of OS you're using. If you are using DOS or Win 9x, that is possible. For true 32 bit OS with protection, you're just looking at virtual memory. Everything has a 2Gb virtual space (4Gb if you really know how to get to it). I don't know about Windows CE or any of the PDAs.

On 8086/186/286/386/486 in real mode, you don't want to write to location 0. 0-1023 contains the interrupt vectors which are used for all sorts. Messing with them can really screw up your system.

In protected mode, they are protected locations. If you have a hardware device at a specific location, you probably need to write a device driver for it. Have a look for DDK on the MS website. It is a free download.

 

[cpjust]

On 8086/186/286/386/486 in real mode, you don't want to write to location 0. 0-1023 contains the interrupt vectors

What about Pentiums...?

 

[xwb]

No idea about pentiums or 686s - I've never done any low level stuff on them. Investigated the debug registers and read about the different modes but that is about it.

Wonder when the OS which uses the Pentium in segmented addressing mode will come out. We can then have 64 terabytes of virtual memory. Maybe it will never happen like the 286 in 16Mb mode (only 1 OS used that feature)

 

[peterworth]

what about some kind of core dump?

by the way, i don't want to write i just want to read.

 

[xwb]

You get coredumps in Unix but I've never seen one in Windows. The nearest I've seen is in the event viewer where they give you a stack trace and possibly some data but that is only in C#. I've never seen it in C/C++.

abort() on Unix is supposed to give you a core dump but on Windows it just exits.

On DOS & Windows 9X you can read from physical locations. For instance if you want to know the reset address in real mode:

char* reset = 0xFFFF0;
for (int i = 0; i < 16; ++i)
   printf ("%02x ", reset[i]);
printf ("\n");

 

[peterworth]

ok, thanks for the info everyone.

what about reading directly from addresses on the hard drive? just being able to read it like an array, including garbage, across different files etc.

 

[xwb]

Do you mean read sector by sector in order or according to the skew factor? There is also the track and the platter/head. It really depends on what type of disk drive you have. Some will not tell you the skew factor and it is quite an art just to work it out. Also you need to know whether your OS formats them in order of head, track, sector or track, head, sector. On IDE drives there are virtual heads (255) so ther eis no way of telling how many physical heads there really are except by looking at the documentation of the disk.

 

[peterworth]

what's the skew factor?

i suppose it doesnt matter if it's a virtual head or not, as long as i can find out exactly what is stored sequentially on the drive.

 

[lionelhill]

... but files aren't stored sequentially on hard drives...

 

[cpjust]

If you tell us what you're trying to accomplish, we might be able to give you a better or easier solution.

 

[peterworth]

... but files aren't stored sequentially on hard drives..."

doesn't matter! in fact it's even better.

"If you tell us what you're trying to accomplish, we might be able to give you a better or easier solution."

it's just for the sake of a piece of art which involves visualizing and/or audiolizing data stored on my pc (either in memory or on the hard drive) sequentially, in the order it is stored, and regardless of whether parts of it are garbage etc

 

[lionelhill]

Ah! Creativity! In that case, rather than just picking random bits of memory, why not open a (random?) file? You can list the files in your favourite directory, pick one of them randomly, open it as a binary file, load lumps of it to memory that does belong to you (hence no segmentation faults or complaints of any kind) and interpret the data in any way you want.

Of course the other thing you can do is allocate yourself a chunk of memory and merely look at it without initialising it, but if you're unlucky it might just be a load of zeroes.

If used data for an artwork in any way in which the data might be recognised (e.g. ascii dumps etc.) you must make sure that you aren't putting on public display information that might upset someone; you might, for instance, accidentally come across passwords, fragments of e-mails, e-mail addresses etc.; [for any voyeurs reading this, you probably won't find anything interesting at all. Murphy's law predicts that if you are, you won't, and if you aren't, you will.]

If you're audiolising you could just tape a dial-up modem dialling... Incidentally there is a long history of this. The first ever computerised payroll was that of the Lyons corner tea-shops, and I believe their (valve-and-mercury-tank) machine also contributed noises to the BBC, I think it was a program involved in weather forecasting, but might be wrong.

I'd avoid any file that's been compressed. Compression (by definition) makes the data look more random, and most of us know what random noise looks like and sounds like.

 

[peterworth]

thanks for the reply. i like the idea of allocating memory and not initializing it best i think.

good point about the compression. i think the other way round - interpreting uncompressed data as compressed, could be interesting though... if every other bit of rgba data in a bitmap is taken to be the run length of the colour before it etc. i also like the idea of bytes moving out of phase, i.e. reading some 16 bit data as 12 bit or something.

 

[mingis]

> what about reading directly from addresses on the hard drive

> Do you mean read sector by sector in order or according to
> the skew factor? There is also the track and the
> platter/head. It really depends on what type of disk drive
> you have.

It is possible in DOS only (Win98 DOS mode as well).
DOS interrupt 0x25 allows to read/write sequential sectors of the disk, independent of its track/head structure. There was also a restriction to first 2GB border - some LBA related stuff.

 

[mingis]

Idea about bit art awaked my memory about ancient home computer times, when files were loaded from cassette recorders. Video memory of that exemplar I worked with was simply a part of conventional RAM. So big files sometimes overlapped video memory and it could be seen how do my files look like "internally". But I don't think, that such colored white noise would be very productive. Further, these motley pictures lead me to an idea about testing of random generator algorithms. If randomly painted dots make unordered noise on the screen - algorithm works good. If there some ornaments could be recognized - bad. Probably these "bad" random generators of dots in the painting could lead to more sensible results in point of view of creativity...

 

[cpjust]

Wouldn't using random data in sound/pictures just look and sound like static? Maybe it's like one of those new 'abstract' kinds of art, but I've always gone by the rule of "if it looks like crap or sounds like crap, it is crap". ;-)

 

[mingis]

I have said "bad" random - it means producing some regular sequences, which can after some further investigation come to more difficult structures like fractals or something.

On the other hand - a bit of flame - a criterion of artisticity of a creative product is following: does it generate some thoughts, moods, does it explain or illustrate some Feature of The World or not. Some pieces of crap does it, some don't - it depends - on composition, associations, etc.

 

[peterworth]

this is the piece which sparked my interest:

http://turbulence.org/Works/arcangel/

the stuff i'm working on is different but it would be useful to indiscriminantly read memory like Arcangel has here.