World: r3wp

so it should work correctly, expecting zero terminator in C level?

maybe it would be better to see your wrapper

hum... I think I understand something... because the call, is not 
returning a string!, but filling up a buffer, REBOL has no means 
to know that it should fix the string! and resize it to the zero 
terminator, right?

don't  you define in your wrapper call what the function returns?

You don't pass a string as a bit of memory to be filled ...

yes it returns success, but fills up the buffer I send it... it does 
not return the buffer itself...

well many C calls expect a buffer as an argument... what's the prefered 
method then?

it would be good to see original C function spec. Because - e.g. 
when I was wrapping one function (trying to investigate red-icons 
problem IIRC), the function was clearly expecting chars (certain 
amount), but it did not work, untill Ladislav came in and changed 
it to struct for that part of function.

I just hope, that for R3, more automatic wrapping will be possible.

yeah... like .h file loading ;-)  we can always dream  ;-)

my routine spec:

		username: make routine! [
			"Get the current logon name of thread which launched REBOL"
			buffer [char*]
			count [string!]
			return: [integer!]
		] libinfo "GetUserNameA"

C spec:

BOOL GetUserName(
  LPTSTR lpBuffer,
  LPDWORD lpnSize
);

about [<] - I think I have reported the problem like 5 years ago. 
In my scripts I use to lit-word! "<".

is double word correctly specified as a string? (count). Should not 
it be an integer?

Five years ago? OK, why do I care:)))

pekr:  its actually a word pointer  and  MS example look like so:
GetUserName( infoBuf, &bufCharCount )

which is why I supplied a string, so that the get user name would 
receive a pointer instead of a number.

pointer is a number

&bufCharCount  asks to get the pointer to the word, not the value 
of the word... no?

what about trying putting struct instead of buffer [char] in there? 
:-), with first element being a string? Struct itself will be represented 
as a pointer

well, maybe better wait for someone like Ladislav or Anton or Gabriele 
or anyone else more experience than me. I always work by guess, try, 
change aproach, till it works (or it does not :-))

just one question, how many bytes is a double word (in MS) supposed 
to have 4 or 8?

16?

sorry, mixed bytes and bits :-)

bit, byte=8bit, nibble=4bit, word=32bit=4bytes, double=64bit=8bytes?

k thanks, just wanted to confirm.. I've just not been thinking in 
those terms for soo long.

my friend suggests me, that it can't be said - it depends upon platform. 
Typically it is good to use sizeo(word) to get the idea ...

sizeof

I think that is more a problem with the use of int and long.

try wikipedia - some good entries there ...

but... anyhow... thanks... by chatting with you I realized why my 
string was staying at 0 length, while its actually filled with the 
data.

yesss... I do more and more... computer sciences are very well explained 
on it.

so what actuall you realized?

string! have an internal size and an external size.  using a string 
within rebol, will always update the size, so that it returns the 
current amount of the string! which has been "filled"

which is why 
>>  make string 100
== {}

internally, its 100 bytes long, but externally, it hasn't been filled 
so its still length? 0

now the external call dumps chars directly in the string and add 
a null termination.

but obviously, since REBOL didn't fill it... it still thinks it length? 
0  ... but its internal buffer really does contain data!

so prefilling the string to 100 chars of anything, will at least 
allow you to acces the whole buffer afterwards...

there are two cases - when external function returns string and expects 
your struct for it, and second, when external function allocates 
its own buffer and provides you with a pointer

that is strange a bit then .... feels like close to cause a crash 
:-)

yep, but in a case where rebol returns the value, its smart enough 
to look it up and find the null terminator for you  :-)

and adjust the external size counter.

in this case, rebol never really manipulates the string...

well, that's true - doing make string! 100 does not mean length? 
should return 100 .... maybe we should have size-of?

all I need to do is :
value: copy/part  buf  find  buf  #"^@"

good idea!

wouldn't it be enought to just value: copy buff?

hum... nope, tried it, it copies the whole string past the terminator... 
and it actually should, otherwise we could not parse binary data...

Max: to-logic "false" how about using something like to-logic "1 
+ 3 < 2" then?