I don't want to put an interface library between Parrot and a kernel32.dll
library -- I'd like to call it directly.
* Is there a generic way to get an generic memory area in PASM that can be
used as the target of a function. In C I'd do:
thingy *foo;
foo=malloc(sizeof(thingy));
func(&foo);
or even
foo=func();
* Once I've got one of these things, how would I destroy it?
* And, somwhat importantly, how can I walk about inside of it to find the
bits I need?
For now, I'm doing okay with what I've got. There's stuff I'd *love* to
call but haven't figured out how without a C library in between...
> I've been playing with NCI -- what a blast. I've got Parrot BASIC
> calling Win32 functions natively. Mua-hahahaha.
>
> I don't want to put an interface library between Parrot and a
> kernel32.dll library -- I'd like to call it directly.
>
> * Is there a generic way to get an generic memory area in PASM that
> * can be used as the target of a function. In C I'd do:
>
> thingy *foo;
> foo=malloc(sizeof(thingy));
> func(&foo);
>
> or even
>
> foo=func();
>
> * Once I've got one of these things, how would I destroy it?
> * And, somwhat importantly, how can I walk about inside of it to find
> * the bits I need?
Can you implement a 'scratch buffer' PMC? One method of which would be
'address', possibly with other methods for walking about in the
buffer. Then just rely on GC to clean up for you.
--
Piers
And presumably muddle about in dlfunc's implementation to add another
function signature type (pointer to generic buffer
to be modified by the called routine)?
I suppose I could. Gak. I really didn't want to have to learn PMC's for
the sake of GetConsoleScreenBufferInfo() ... :)
That's what unmanagedstruct (the PMC type) was intended for. Gotta
run out for a bit, so sorry about being short on details--I'll get
back to you in a while. (Given how far behind i am in e-mail, I
figure any not-information-free response is better than none...)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
So the unmanaged struct PMC is there, but assumes that something external's
gonna malloc up some memory and give a pointer to it -- which isn't the
case here. It seems the bare minimum I'd need a PMC to do (and you can
expand on this Dan, Piers) is:
* Allocate N number of bytes for its "buffer"
* Resize the buffer by re-allocating space, moving pointers, etc...
* Be able to PEEK into the buffer to get a specific byte
* Be able to POKE a byte into the buffer at specific points
What kind of interface though?
new P5, .Unmanaged
set P5, 512 # Get a 512 byte buffer
set P5, 1024 # Resize it to 1024 bytes
set P5, 256 # Another resize (presumably keeping the
first 256 bytes...)
# Bytes, meaning 8-bits worth and nothing
fancy...
Peek and poke? Somehow treat it like an array?
set P5[67], 0xff # Poke
set I0, P5[66] # Peek