1. Virtual Address Space
I ran across something peculiar when working with multiple
threads, i was wondering if anyone had any ideas on this:
for example:
In the following two programs, program1 allocates a single
byte in memory, fills the byte with the number 2, and then
calls a second program passing the address of the byte. It
then waits for user to type a key before freeing the original
byte allocated.
The called program, program2, attempts to read the original byte
using the address passed from the first program. The address is
printed out byte by byte in both programs in order to verify that
the address was passed successfully.
program1.exe contains bindw code:
include get.e
atom addr,i
sequence AddrString
addr=allocate(1) --one byte
poke(addr,2) --poke the number 2 at addr
?peek(addr) --prints a "2" as expected
AddrString=sprintf("%f",addr) --convert addr to string to pass
?int_to_bytes(addr)--print out addr as 4 bytes
system("program2.exe "&AddrString,0) --call program2.exe (below)
--passing AddrString
i=wait_key()
free(addr)
program2.exe contains bindw code:
include GetCommLineParams.e --just function to return param strings
atom i,addr
sequence AddrString
AddrString=GetCommLineParams(1)--gets string param #3 (passed address)
AddrString=value(AddrString)
if AddrString[1]=GET_SUCCESS then
addr=AddrString[2] --now contains original addr
end if
?int_to_bytes(addr)--prints out addr as 4 bytes for verification
--this always prints out exactly as in program1.exe
--so i assume it was passed successfully.
?peek(addr) --this never prints out the original byte poked, but
--also does not generate an access exception
i=wait_key()
The peculiar thing here is that although the byte cant be read
successfully in the second program, it doesnt generate an exception
or any error of any kind. Just quietly returns the wrong value
every single time.
Any other thoughts or comments on this?
Thanks,
Al
2. Re: Virtual Address Space
On 10 Nov 2000, at 13:29, Al Getz wrote:
> I ran across something peculiar when working with multiple
> threads, i was wondering if anyone had any ideas on this:
>
> for example:
>
> In the following two programs, program1 allocates a single
> byte in memory, fills the byte with the number 2, and then
> calls a second program passing the address of the byte. It
> then waits for user to type a key before freeing the original
> byte allocated.
> The called program, program2, attempts to read the original byte
> using the address passed from the first program. The address is
> printed out byte by byte in both programs in order to verify that
> the address was passed successfully.
<snip>
> The peculiar thing here is that although the byte cant be read
> successfully in the second program, it doesnt generate an exception
> or any error of any kind. Just quietly returns the wrong value
> every single time.
>
> Any other thoughts or comments on this?
Are you trying that multithreading idea i mentioned a month or more ago? One of
the things i mentioned, that are required, is that the memory be locked, so that
the
OS can't page the programs/data around. I don't mean allocated, i mean truely
locked down by the OS. It's "lock_memory" in dos32, i don't know what it is in
win32lib. If you can grab the memory, i recommend memory windoze doesn't use,
like maybe a small section of dos/driver/card memory between 640K and 1meg. In
the olden days, some of us used a few bytes of non-displaying screen memory. 
Alternatively, you might be surprised by how fast you can write a short file to
disk
and have the 2nd program read it, i have written loops before that read the file
back
out and deleted it before the OS's disk cache ever actually put it on the disk.
It
stayed in memory the whole time, and speed at the time was not a problem.
YMMV. I had suggested a small ini file to hold those memory addys you
mentioned, so you can pass them back and forth between multiple threads, handy
when the size of the reserved memory must be changed, or when you want to map
a variable *into* another, as opposed to *on top of*.
Or you can use DDE, in windoze, if you can figure out how, i can't. I use it in
mirc a
lot (it's a built-in function), it saves on error msgs too, and the state of the
handles
is query-able, etc..
And as usual, socks is attractive, especially in threading, even with the
overhead,
cause you can then thread on separate puters on a LAN, on different OSs even, if
you have threads that last any significant amount of time.
Lemme know if you want me to be quiet..
Kat
3. Re: Virtual Address Space
On Fri, 10 Nov 2000 13:29:57 -0500, Al Getz <xaxo at AOL.COM> wrote:
>I ran across something peculiar when working with multiple
>threads, i was wondering if anyone had any ideas on this:
>
Al:
There is no guaranty that the contents in a memory
address will be preserved, unless there is someway to
tell the OS to protect that region of memory.
The operating system can swap out memory at any time,
relocate a DLL in memory at any time, etc.
This simplest solution is to reserve a portion of
the clipboard to pass the data back and forth between
programs because the clipboard contents is protected.
Bernie
4. Re: Virtual Address Space
On 10 Nov 2000, at 14:34, Bernie wrote:
> On Fri, 10 Nov 2000 13:29:57 -0500, Al Getz <xaxo at AOL.COM> wrote:
>
> >I ran across something peculiar when working with multiple
> >threads, i was wondering if anyone had any ideas on this:
> >
> Al:
> There is no guaranty that the contents in a memory
> address will be preserved, unless there is someway to
> tell the OS to protect that region of memory.
> The operating system can swap out memory at any time,
> relocate a DLL in memory at any time, etc.
>
> This simplest solution is to reserve a portion of
> the clipboard to pass the data back and forth between
> programs because the clipboard contents is protected.
But can't the clipbd be overwritten?
Kat
5. Re: Virtual Address Space
Al Getz writes:
> system("program2.exe "&AddrString,0) --call program2.exe (below)
>
--passing AddrString
program2.exe is a separate program.
Separate programs do not share memory with each other.
Each has its own address space.
Address 1000 in program1 has nothing
to do with address 1000 in program2.
These are *virtual* addresses. The O/S and the hardware
map these to different *physical* addresses.
You can't pass data that way between programs (processes).
This is a wonderful thing as it prevents one program
from messing around with memory being
used by another program.
Within a *single program*, Windows allows for
something called multiple *threads*. Threads run in
parallel and each has its own call stack. The threads
of one program share the global variables and memory
of a single program. Euphoria does not support threads,
but might in the future.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Virtual Address Space
This may be helpful:
http://www.experts-
This is real interesting too, it's a short circuited and faster version of what
i
did when i used ini files (this may be for winNT only, there was one for
winCE and win2K exclusively too):
For win95:
Something else you could do is write a device driver that does nothing but
store info and pass it back to whoever is calling for it, sorta like a ramdrive.
Assuming you don't want to use the existing ramdrives. I liked ramdrives
so much, around 1993 i wrote a tsr in turbo pascal to do ramdrive functions
that wasn't in the device driver chain so i could delete it at will.
Kat
7. Re: Virtual Address Space
Kat and Bernie,
Thanks for the input...
Kat:
dont be quiet, please! Your input is appreciated.
As far as mem management goes, Windows managages
memory on a per process basis, i.e. the following
functions work with the current process only:
GlobalAlloc, LocalAlloc, HeapAlloc, VirtualAlloc
and, shared memory is implemented by file mapping
in the Win32 API.
Also, i need more memory then that in low dos mem, typically
3 megs up to, say, 10 megs but i hate to put a limit on that
size.
The strange thing is, peek(addr) doesnt generate an error
even though another program had allocated that 'space',
yet returns whatever the heck its getting from who
knows where
Bernie:
I actually did just that, but i did it on a temporary basis
as i would like to free up the clipboard for normal use, and
achieve this without having to maintain a copy of the clipboard
data (and reload it after use) as the amount of data that
can be found on the clipboard can easily exceed 10 megs
and therefor would require too much overhead time to manage
time sharing the clipboard.
I was hoping someone had another way to share memory, but it
looks like file mapping is the only real way to go.
Thanks again for all your generous input. Any more thoughts
please dont hesitate to voice them here...
--Al
8. Re: Virtual Address Space
Thanks to everyone: Rob, Kat, Bernie who responded to this thread.
I guess ill try the Win32 API function:
ReadProcessMemory()
next.
Rob:
I still have to wonder why peek(addr) attemps to return a value though
Thanks again.
--Al
9. Re: Virtual Address Space
On Fri, 10 Nov 2000 17:45:40 -0500, Al Getz <xaxo at AOL.COM> wrote:
> I actually did just that, but i did it on a temporary basis
> as i would like to free up the clipboard for normal use, and
> achieve this without having to maintain a copy of the clipboard
> data (and reload it after use) as the amount of data that
> can be found on the clipboard can easily exceed 10 megs
> and therefor would require too much overhead time to manage
> time sharing the clipboard.
>
> I was hoping someone had another way to share memory, but it
> looks like file mapping is the only real way to go.
Al:
Other things you can do is to get the DTA ( disk transfer area )
using int21 2fh. and use that area.
Use the unused interrupt vectors.
Use any unused bytes system area at 40:0 ( 400h )
Create a VIRTUAL disk.
Bernie
10. Re: Virtual Address Space
- Posted by Robert Craig <r..craig at SYMPATICO.CA>
Nov 10, 2000
-
Last edited Nov 11, 2000
Al Getz writes:
> The strange thing is, peek(addr) doesnt generate an error
> even though another program had allocated that 'space',
No. Another program did not allocate that space.
The other program allocated space in *its own*
virtual address space. peek(addr) refers to a different
*physical* memory location in every program that's running,
so it's not surprising that a different value will be returned
in each case. system() starts up a new program.
Two active programs can both be using
virtual memory location 1000 (say) at the same time,
but it's a *different* physical location. This is the magic
of virtual memory.
In modern operating systems (WIN32, Linux etc.)
programs deal with virtual addresses. The O/S with help
from the hardware maps these virtual addresses into
the physical addresses that access the memory chips.
> Rob:
> I still have to wonder why peek(addr) attemps to return a value
though
I guess addr was a legitimate (virtual) address for that program.
Some other address might give you a segmentation violation.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
