Re: [Tutor] Windows Memory Basics

[Steven D'Aprano]

On Mon, Oct 16, 2017 at 01:04:40PM -0700, Michael C wrote:
> Hi all:
> 
> 
> I don't understand this part about the memory:
> 
> if I used VirtualQueryEx to find out if a region of memory is ok to scan,
> and it
> says it's ok, are the values in the region arranged like this:
> 
> short,int,double,long,char, double, short in
> 
> as in, random?


I am not a Windows expert, but I doubt it. Memory is always an array of 
bytes. How you interpret that memory depends on what you are doing with 
it, and there's no way to tell from outside how it should be 
interpreted. (Some very clever, perhaps too clever, can even give the 
same chunk of memory two or more *valid* interpretations at the same 
time.)

This implies that unless you know that this chunk of memory has some 
special meaning to Windows, the choice of how to interpret the chunk of 
memory is up to you. If you have a block of memory in hexadecimal that 
looks like this:

1f78a924b6c00be4f7546cda298860951a6c30d75640e62f82c8f5c0f1cb0bfc

then it is entirely up to you whether you interpret it as:

(1) 64 one-byte values:

1f 78 a9 24 ...

(2) 32 two-byte values:

1f78 a924 b6c0 ...

(3) 16 four-byte values:

1f78a924 b6c00be4 ...

or something else. You could interpret them as ASCII bytes, Unicode code 
points, signed integers, unsigned integers, single- or double-precision 
floating point numbers, strings, or anything you like.



-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Windows Memory Basics

[Alan Gauld via Tutor]

On 16/10/17 21:04, Michael C wrote:

> I don't understand this part about the memory:

And I'm not sure I understand your question but...

> if I used VirtualQueryEx to find out if a region of memory is ok to scan,
> and it
> says it's ok, are the values in the region arranged like this:
> 
> short,int,double,long,char, double, short in
> 
> as in, random?

They won't be random, they'll be in the order that the
program that wrote the memory chose them to be in. For
example the memory might contain some program variables
and those variables may be of different types (assuming
a compiled language like C++, say). Or it may be holding
a complex data structure, like a class, that has fields
of different types.

What those types are will not be obvious and unless you
know what you are reading will be impossible to guess
in most cases since it is just a sequence of bytes and
one set of 8 bits looks a lot like any other.

> I am asking this because, if it's random, then I'd have to run
> ReadProcessMemory
>  by increasing  the value of of my loop by ONE (1) at a time, like this

That doesn't really help, you need to know what each
chunk of data represents and then increment the index
by the size of each corresponding data type.

For example if you have a string of 8 UTF8 characters
that will probably be 8 bytes long(some UTF characters
are more than 8 bits). But those 8 bytes could equally
be a floating point number or a long integer or a
struct containing 2 32 bit ints. You have absolutely
no way to tell.

And if you increment your index by one you will then
look at the first 7 bytes plus one other. What is
the 8th byte? It could be the start of another float,
another UTF8 character or something else entirely.

Things are then further complicated by the tendency
to store data on word boundaries, so either 4 or
8 byte chunks, but even that can't be guaranteed
since it could be a compressed memory scheme in
action or a piece of assembler code taking the
'law' into its own hands.

And of course it may not represent anything since
many programs set aside memory spaqce for later use
and either fill it with zeros or some other arbitrary
pattern, or just leave it with whatever bits happened
to already be there.

> for i in range(start_of_region, end_of_region, 1):
>   ReadProcessMemory(Process, i, ctypes.byref(buffer),
> ctypes.sizeof(buffer), ctypes.byref(nread))
> 
> Is that correct?

Probably not. If you know what data you are reading you
can do what you want, but if it's just a random block
of memory you are scanning then its almost impossible
to determine for certain what the raw data represents.

If you have access to a *nix system (or cygwin
on windows) it may help you to see the nature
of the problem by running od -x on a text file
You can find out what is in it by looking at it
in a text editor but the hex listing will be
meaningless. If that's what simple text looks
like imagine what a binary file containing
mixed data is like.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Windows Memory Basics

[Michael C]

Hi all:


I don't understand this part about the memory:

if I used VirtualQueryEx to find out if a region of memory is ok to scan,
and it
says it's ok, are the values in the region arranged like this:

short,int,double,long,char, double, short in

as in, random?


I am asking this because, if it's random, then I'd have to run
ReadProcessMemory
 by increasing  the value of of my loop by ONE (1) at a time, like this

for i in range(start_of_region, end_of_region, 1):
  ReadProcessMemory(Process, i, ctypes.byref(buffer),
ctypes.sizeof(buffer), ctypes.byref(nread))


Is that correct?
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] How to test for the existence of a table in a sqlite3 db?

[Neil Cerutti]

On 2017-10-15, boB Stepp  wrote:
> Some things I am still pondering:
>
> 1)  If I adopt the incremental approach to creating and
> initializing the working db, then it seems that the list,
> "sql_scripts", should not be hard-coded into the program.  It
> seems to me it should be off somewhere by itself with perhaps
> other things that might evolve/change over time in its own file
> where it (and its brethren) are easy to locate and update.

An incremental approach is not recommended if you are using the
sqlite3 module. In sqlite modifying table definitions is limited
to the simple addition of a new row of data. Any other change
requires you to create a new table, copy the old data into it,
and then drop the old table.

> 3)  I am supposed to be delving into writing classes on this
> project. Should the code so far stay as a function or get
> incorporated into a class?  My original intent was to do a
> class for the BloodPressureReadings table, but I am not at the
> point of going there yet.

I don't recommend cobbling together your own ORM, if that's what
you are asking. ;)

> 4)  I wish there was a PEP 8 for SQL!  I have several SQL books
> I have consulted, but I have gotten conflicting suggestions for
> SQL code style.  I have tried to adopt something that seems to
> me to be both consistent and reasonable, but is it good enough?

As long as you can imagine yourself reading it two years from
now, and being able to understand it and make changes, it's
probably an OK style. The two big hurdles for me were acquiescing
to uppercase all the SQL keywords, and learning the quoting
rules. My impression is that SQL is very old, and so lots of
different styles are valid and just fine to use. Your main goal,
at first, should be to stick with standard SQL as much as you
possibly can, to make it easier to switch database engines should
you ever wish to do so.

-- 
Neil Cerutti

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor