World: r4wp

>> exists? %temp.dll
== true
>> lib: load/library %temp.dll
>>

No need to become dirty with WinDbg :-)

Try now:

foo: make routine! [a [integer!] return: [integer!]] lib "foo"
foo 123

>> foo: make routine! [a [integer!] return: [integer!]] lib "foo"
>> foo 123
== 124

Good! :-)

Yes :-)

So what was the difference? Rellocation support?

It seems some systems are forcing relocation on loading DLLs (even 
when no conflict) while others not.

So we have finally improved DLL support for R2, right? :-)

I mean - now we can make wrapper libs, coding almost in REBOL (syntax), 
no need to become dirty with C, and hence get more libraries to work 
with R2, via a wrapper libraries written in Red/System?

It might also be caused by real conflicts from DLLs loaded by REBOL...only 
WinDbg could tell us by looking at the base address of all loaded 
DLLs.

Pekr: yep. :-)

I can confirm, that it works now

Great!

Well, if someone would create a plug-in wrapper, we could use the 
aproach for R3 too ...

Doc, can you statically link other C libs and use the functions from 
Red?

Not yet Robert, but that's on the roadmap.

Ok, that would be very cool.

Easly creating self-contained DLLs with a R2 / R3 interface would 
be a major time-saver.

can you statically link other C libs...

 you mean link static libraries with Red/System executable, right?

yes, to get one binary.

Because for statically linking to dynamic libraries, that's already 
possible.

For static libs linking, if someone could contribute by providing 
a .lib and .a file reader/parser, that would help get that feature 
implemented sooner.

(.lib and .a reader coded in R2)

So, next steps (next week), add PIC support to backends and implement 
shared lib support in Mach-o and ELF emitters.

that's not a microcontroller, right? :-)

OK, position independent code, got it via Wikipedia ...

No, it's Position Independent Code: http://en.wikipedia.org/wiki/Position-independent_code

PIC is mandatory in UNIX shared libs.

so so far only Windows DLLs are supported, right?

Right.

But that enables already to build a lot of things, like bridges with 
other languages or VMs.

yes, generally we are now able to write low level binding using rebol 
like syntax, generate libraries for environments like Delphi, etc., 
which e.g. my friend still uses :-)

My personal favorite is Blender, I'd very much like to add Red/System 
support to it (and kick out Python later when Red will be there). 
;-)

But bridging with Android and iOS is high priority, so Blender will 
wait.

BTW, best option for bridging with Java can be discussed here (on 
the ML). I'm not sure anymore that the JNI way is the best one...

What I still think is, that we need strong parse. It is very cool 
technology. Yes, I dare to call it a technology. We need r3 level 
parse. Then we can create dialects, and show other guys, that dialecting 
is a cool concept. Pity we were not able to capitalise on it more, 
mainly due to closed nature of R2 possibilities to bind to other 
environments .... you imo :-)

*(or on the ML)

you = just

some kind of brige is required, if we want to get into an Android 
API. Ditto for .NET?

Yes

Same issue.

I have added a sample program for those who want to play with DLL 
generation:


https://github.com/dockimbel/Red/blob/dyn-lib-emitter/red-system/tests/shared-lib.reds

I've looked at the Blender interface, but it's rather big and complex

Petr, I think we need Topaz level PARSE :-)

you used -dlib option, does it replace -t one? Not skilled here, 
but - can I generate e.g. ARM executable/library from Windows Red/System? 
Or is target environment needed?

Topaz has even better parse than R3?

I don't know if it's complete, but it goes beyond REBOL

Doc, this page can be updated because of the support of DLL generation. 
http://www.red-lang.org/p/roadmap.html

Also, 4.8 in the documentation: