World: r3wp

Would you mind mailing me your resulting .dll?

And what compiler did you use? GCC or MSVC?

gcc (GCC) 3.4.5 (mingw-vista special r3)

Would you mind trying the following:
http://bolka.at/2010/rebol3/tmp/sample.dll

works

Ok, so works on XP, fails on Linux and Wine. Will try Win7 later 
on.

I've tested extensively, and no matter what I do, it segfaults right 
away on init when there are more than 14 commands in the init block. 
That's indeed on Linux

Hm, a trivial extension exporting 20 commands seems to work fine 
for me:
https://gist.github.com/e9192ae7083a2fbf5d78

Both for A110 Linux and A110 Win32+Wine.

Interesting, but that's a very empty example. Can you try with command 
parameters?

I'm exporting them wrapped in a context. That may make a difference

When I split the cURL binding in two contexts, it works, so it seems 
to be some object limit

Very peculiar.

When I export a context wrapping the above 20 cmds, it still works.

export cmds: context [cmd01: command [] cmd02: ...]

Then please give them some more work to do

It also bombs out for me when the fifteenth context slot is such 
an empty command

Makes no difference even if I add 3 parameters to each of them.

Let me try with 10 parameters each.

It sure is a strange thing :-)

Most peculiar, yes.

Nope, 20 cmds with 10 params each works as well.

Maybe something to do with the length of the init block?

OK, let me upload the cURL binding source for you

I tried shortening the init block, but it didn't help

An error return code is defined for extensions, but it's not used 
anywhere in the host kit or documentation, so we don't know how to 
use it

There's also a SET_EXT_ERROR macro, but also undocumented, and it 
only allows setting an unknown number

I'm experimenting with image! as a command agrument and found this 
strange behaviour:
I have:
	img-echo: command [img [image!] ]
In RX_Call I use just:   return RXR_VALUE;

And then when I call the img-echo I get image, but with index at 
the tail so it looks like:
>> i: img-echo img
== make image! [50x20 #{
}]
>> index? i
== 1001

Is this normal? How I can set the index on the C side?

I've found solution for my answer related to warning: ../R3A110/src/include/reb-config.h:107: 
warning: ignoring #pragma warning  

To remove this warning, use this compiler option:  -Wno-unknown-pragmas

Image index at tail sounds like a bug

This should set it at the head:

RXA_INDEX(arguments, 1) = 0;

But it should already be at that value

I've located where is the problem.. it's returning the image at the 
tail if the command is used in exported context!

Correction... it returns image index at tail when there is any exported 
context.. the command can be out of the context.

http://issue.cc/r3/1809

btw... I was trying to use: RXA_INDEX(frm, 1) = 0;  but in my complex 
extension I was even able to crash REBOL. But I'm not able to simplify 
it. The sample.c included with the bug report must be enough, it 
clearly shows that there is something wrong.

It's also strange that it returns correct index before I eval the 
exported context.

I added that last sentence to the ticket, as it might help diagnose 
the problem.

The callbacks documentation is incomplete, and refers to the host-ext-test.c 
file for examples, but this isn't in the current host kit

RL_Protect_GC protects unreferenced series from disappearing, but 
does it also protect them from being moved?

If not, how can an extension be sure that a pointer to a series is 
still valid?

I don't think the REBOL GC is copying or compacting. Series are only 
moved when they are expanded (a reallocation) so if you don't want 
it to move, preallocate the length you want.

OK, I gathered that it must work like that if it is to be stable 
now. But I wonder if it won't get complicated by tasking

I saw a warning somewhere in the documentation that series can be 
moved, but maybe that is indeed limited to their own isolated memory 
management

It would explain some of REBOL's high memory usage, because it it 
doesn't do compacting, there can be a lot of unusable, fragmented 
memory

if it

I don't understand, though, how the RL_SET_CHAR and RL_SET_VALUE 
functions could extend a series when necessary without ever moving 
it

There must be a guarantee that the description data that is pointed 
to will stay immobile, while the actual data does get moved

REBOL must have a global series descriptors registry, much like the 
words registry