I asked this question before, but maybe I'll phrase it better this time. If I want to use pointers well, then I must be able to know my memory. That is, where RAM is versus ROM, and especially where the screen graphics memory is, and what values I can put in them to make some kind of display. And then, where the sound values in RAM are, and what numbers I can use to work with sound. So what must I do to get access to a table, probably huge, which shows me what goes where and what does what in memory. This sounds like more for Assembly, But Assembly is pretty complicated, and I want to do simple things. And would this source have a list of appropriate opcodes also?

Quote:Original post by conejo5991
That is, where RAM is versus ROM,

There isn't really ROM in a modern PC as far as an application is concerned. You can think of all of your pointers as pointing somewhere in the system's main RAM... Really though, RAM is virtualised these days, meaning only the OS really knows where your pointers are pointing.
You could have a pointer to some data in RAM, but the OS is actually storing the data on your hard-drive and pretending it's in RAM...

Quote:and especially where the screen graphics memory is,
and what values I can put in them to make some kind of display.

You can't write directly to graphics memory like that on a modern PC. You'll have to use an API, like DirectX or OpenGL.

Quote:And then, where the sound values in RAM are,
and what numbers I can use to work with sound.

You can't write directly to sound memory like that on a modern PC. You'll have to use an API, like DirectX or OpenAL.

Quote:
So what must I do to get access to a table,
probably huge, which shows me what goes where
and what does what in memory.

Such a thing doesn't exist anymore on a modern PC, at least not in user mode. Since memory became virtualized, pointers don't mean anything special anymore. You ask the OS for memory or some resource, and it returns you a pointer into your processes virtual address space. You manipulate the memory or resource through that pointer, and eventually release it when you're done. That's about it. The actual value of the pointer is completely irrelevant.

As Hodgman said, hardware IO is not exposed through memory mapped regions anymore if you're in user space. You have to use the appropriate APIs instead.

Here is some more info about the subject.

Would I have to learn something like Assembly then to actually do anything with
the memory within the Operating System? One thing I rmember, and even used a little bit before I stopped programming in 1984, was that there was a DOS command called DEBUG where you could actually look directly at and even manipulate the machine language, which was arranged in columns and rows, and was all addressed and presented in hexadecimal. But as far as I know, it was not possible to write programs in that mode. All you could do was change values in pre-existing programs. But to be honest with you, what I want to do ultimately is very simple, and I promise it is not hacking. It has to do with
my own ideas about AI theory, of which I have for quite a while.
But I had quit programming, and spent years thnking about the theory part, although I didn't forget the programming I learned, while I was getting the ideas together, computers advanced exponentially, and then when I came back to learn modern programming methods, Ouialah! They had developed OOP in the mean time, which I have just about gotten down, except for understanding the relationship, in a simple conceptual way, between objects and member functions, in which area I am making fairly rapid progress. But the truth is that how I would like to do it could pretty much be accomplished in an algorithmic setting because that's how I was dealing with it in the past.
However, to understand OOP, would probably greatly enhance it's scope and power.
But thruth is that if assembly were a heck of alot simpler,
then it could easily be done that way.
So I end up bouncing around conceptually between BASIC, C++, and Assembly.
I havde even posted several months ago if there was such a language, to which I have not yet been exposed, which simply would integrate all of the concepts of the three, and the response to that was that I should learn PYTHON, which does seem nice as far as I've gone with that.
But the book on it is very thick, and I would like to obtain either a simple video tutorial, or even a small but powerful textbook, which would quickly
and effectively cross reference what I have had the good fortune to learn recently about C++ and OOP, because I learned C++ by taking the concepts I remembered from BASIC and simply converting them over a semester,
although I had a little technophobia because I hadn't had hands-on
in quite a while. Also, if you are reading this maybe you could even
recommend a book which goes into the conceptual theory behind
Virtual Reality, but I seem to do very well when I try to understand things from layman's terms because too many technical terms throws me off
the track of cenceptual understanding. That's why I'm having difficulty
making my questions clear because I am trying to get a picture in my mind
so it will be easier to develop so-to-speak blueprints for the use of OOP.
But I don't think I'm too far off at this point, and I keep trying
so I'll probably be at that point fairly quickly.
I hope my verbosity doesn't get in the way of a clear-cut understanding
of my goal to comprehend fully OOP. Thank you.

In general operating systems (at least decent ones) do not allow a program to alter memory outside of the pool of which is dedicated to itself. I believe the executable is even loaded into a different memory page which is also off limits for alteration by the executable itself.

All of this is done with limiting the damage of viruses in mind. Of course people writing viruses keep finding ways around these types of measures. That said, I do not think you actually need to alter operating system memory in order to do any kind of AI.

Are you basically looking to write something that can adapt its logic and learn hence needing to write it's own executable? If so you can go a couple different routes that do not require anything that requires direct physical memory writing (that is what drivers and operating systems are for.)

For instance you could use an executable that loads up scripts. Or you can use an extensible programming language (like Python which was recommended to you already it seems).

In both situations the actual executable basically consist of a state machine which loads and processes a command buffer. This buffer contains operations in which different arguments may be available for. Basically a software implementation of the cpu where the operations tend to be a bit higher level than the cpu's assembly language, but allowing you to load up your instructions at your leisure and in some cases change them and reinterpret/compile them at run time. The nice part being that it is all happening within your applications own memory alottment so the operating system does not mind at all.

You do not usually need to know assembly to do any of these, although the interpreters are commonly mimicing assembly so it may help you understand them.

If your goal of all of this is to simply understand OOP you may be going a bit overkill. OOP is just a way to structure and expand code. Different languages implement it in different ways, and although some implementations are pointer heavy a deep understanding of pointers is usually more a requirement of a particular language and not that of OOP. Some languages even hide pointers from the end user to prevent them from having to even do anything remotely "low level" like managing memory.

you can't simply use the memory addresses of other processes, os shouldn't let you do this.

each process has its own virtual address space, for example it might be addresses between 0-1000. but process does not actually know the real address of these space, it might even be mapping into different locations like virtual 0-500 is mapped to real 2000-2500 and 500-1000 to 1000-1500.

Altought I am not sure how memory editors work, as far as I know they shouldnt =)

That was exttremely insightful. But I must say a good deal of the things you were trying to tell me were beyond the things to which I have been exposed, although a serious study of them would certainly prove helpful and enlightneing.
With regard to OOP, my feeling is that all the things I've had to study in the past seem to follow this pattern: You study what is higher, and then that which is lower almost alsways becomes much clearer.
And with regards to pointers, I didn't originally set out to know exactly what is going on in every RAM address at all times. That would be ridiculous on my part. But my reason for wanting to know what is in the field of RAM is that what I would like to do in at least two ways would require some direct usage of RAM, and my fundamental reason for wanting to know what is going on in the guts of the machine is primarily for the purpose of trying to eliminate, probably an impossible word, or at least to greatly minimize any possible error in generated code.
And along with that concept lies the idea that I knew from long ago that if you input certain values into certain areas of RAM, that it could lead to the point of permanently messing up the RAM to where you would have to at least reboot and start from scratch, which of course would be very frustrating, or even to the point that I would have to do a complete PC Recovery. Both items would make my attempts mext to impossible.
Therefore, I seem to be compelled, or even forced, to know what is going on in RAM so that I can at least attempt to avert fatal software implementations. Moreover, the times before when I considered this, and I did quite often, it led me to the conclusion that my intuitions would necessitate a sort of perpetual motion machine with respect to the necessitation of the perfection of a complete avoidance of any kind of errors generated which couldescalate into a programmers nightmare and a complete failure of the project.
Therefore I cannot help but try to keep these "islands of memory" untouched by the chaos of possible RAM values accessed. So it seems a natural thing that I would have to be obsessed with a fair understanding of RAM values and their respective opcodes, in reiteration, for the sake of avoidance of fatal errors.

I just wanted to add humorously that my last statement could be termed

a programming paranoia, so I should take some medication and go to

programming therapy. However, I have never until this moment even concieved

of such an animal. And I seriously doubt that it would be feasible to begin

looking for a programming therapist. But you never know. ha ha.

Quote:Original post by conejo5991
And along with that concept lies the idea that I knew from long ago that if you input certain values into certain areas of RAM, that it could lead to the point of permanently messing up the RAM to where you would have to at least reboot and start from scratch, which of course would be very frustrating, or even to the point that I would have to do a complete PC Recovery. Both items would make my attempts mext to impossible.

This is not possible with modern operating systems. Wikipedia has a good article on virtual memory that should help to make things a bit clearer for you. I suggest you read that whole article, which provides a good overview as well as a history of how it all developed.

As stated above, your application should be able to (try and) do anything to RAM that it wants -- your OS will "protect" your PC by killing your application.

The things you're talking about -- inspecting the contents of RAM, writing into random areas of RAM -- doesn't really make sense these days.

You don't even have access to RAM any more! Your application is given a virtual view of RAM, which is mediated by the OS.

When you read or write to your own private, virtualised view of RAM, the OS validates what you're trying to do, and then writes to/reads from the real physical RAM.

If you just pick a random location within RAM, and try to read that value, the OS will likely throw an exception and kill your program (because it doesn't make sense!).

You should only read from or write to areas of RAM that you have allocated yourself!