World: r4wp

You might need to uninstall the 64-bit version first.

they can't coexist? Btw - so 64 bit version is no go ATM?

I'm not sure they can coexit as Java is setting some environment 
variables that are unique.

Upgraded my JDK to 1.7.0_21, recompiled JNIdemo on Win7, everything 
is working fine.

Looks like -d32 option is working on OSX only, so a 32-bit JVM is 
required on other platforms.

(My .class files where generated on a 64-bit machine, but that does 
not matter.)

Anyway, Android is using a 32-bit JVM.

So we shouldn't have a problem there.

What does the bridge do?

There's only the low-level part of the bridge currently. It binds 
to the JVM through JNI and allows to create Java objects, call their 
methods, define callbacks to Red/System code, etc...

It's a remote control for the JVM from Red/System, you can do most 
of what a Java program can do.

similar aim to the SL4A then

except without restriction

I'm not sure how SL4A binds to the JVM, but you can't get closer 
than JNI.

Wow, SL4A seems to use JSON messages over TCP...talk about an overhead. 
:-)

JNI native code is running in the same thread as the JVM.

as the JVM
 => "as the Java program"

but SL4A allows remote control of an android device :)

FYI, I'm re-arranging the Red compiler code output in order to allow 
the Red runtime library initialization on DLL loading. Once that 
done, we'll be able to produce Red shared libs (the exporting interface 
remains at Red/System level though).

Excellent Doc. That sounds great.

Very cool Doc.

I've compiled and run my first Red shared library. Use #call directive 
to call back Red functions from Red/System.

Declare your Red/System exported function in a #system-global block.

Untested, but should work:

Red [ ]

#system-global [
	launch: does [#call [main]]	
	#export [launch]
]

main: does [
	print "Hello Red World!"
]

BTW, I could make the #system-global block implicit there using a 
Red level directive to abtract such code.

Hmm, would work only if no arguments are passed from the caller and 
no value returned to it. Red/System is still needed to marshall the 
values between outer world and Red datatypes.

congrats, great work! :-)

btw - when ELF will be finished, so that we can have JNI example 
without the crash when exiting app? Or was it unrelated?

I've fixed the crashes on JNI demo a couple of days ago.

The exiting crash is related to running it in a 64-bit JVM, which 
is not supported.

Go Doc Go!

How about having the compilers recognise a "Type: library" field 
in the Red [] and Red/System [] headers, so you don't have to add 
the -dlib parameter to the command line?

I thought about it already as one of the ways to produce a shared 
lib, in some of my recent scripts there's already a `Type: 'dll` 
header field, but `library` is probably nicer. I will implement support 
for it when I'll find time as it's a minor feature.

Thanks

Hi Doc, I was messing around with the PE.

Added section: [.rsrc  [-   #{00000000000000000004000000000000}]] 
in compiler (this should be just empty .rsrc, and trying to build 
it in PE.r using:

oh/rsrc-addr:			section-addr? job '.rsrc
oh/rsrc-size:			length? job/sections/.rsrc/2


but the address is pointing into wrong position (512B less). You 
probably don't know without some deeper examination, what may be 
the reason, do you?

Btw. there should be:
    .rsrc				#{40000040}	;-- [read initialized]

at this line: https://github.com/dockimbel/Red/blob/master/red-system/formats/PE.r#L119
(the section name starts with a dot).

Oldes: adding .rsrc support is not trivial. I have a stashed prototype 
somewhere, I could push it in a new branch for you to look at and 
improve it.

PE format does not require specific section names, so Red uses its 
own ones.

be able to add just the empty .rsrc section would be a good start.

Let me see...

Pushed it in new rsrc-support branch: https://github.com/dockimbel/Red/tree/rsrc-support

See the commit diff: https://github.com/dockimbel/Red/commit/160cf3dfa3629c63b4dc2e9465fb5337a43754b8

That base should be enough for a start, the hard part now is to generate 
the resources tree with all the right entries ...far from easy.

Oh, it seems I've stopped in the middle of the coding session at 
ligne 381 in PE.r.

Hm.. I'm not sure this will help me. I have the rsrc data (parsed 
from valid file), just the section's adress is not correct.

rsrc entries contain file offsets and memory addresses, if you plan 
to just insert a blob of data, it won't work.

So I must call some commands in the middle, instead of just data 
and setting pointer to it, right?

Ok.. I will play with it even more for a while before going sleep.

For empty rsrc should be enough to provide: table/id-entries:    
 0 instead of 1 on line 377 of your commit and not adding the entry 
(at least that's what I see with exe containing empty rsrc). But 
line 369 of this commit is strange.

Is the plan to use .res files? i.e., to have a resource compiler 
that the linker can include?

*Many* years ago, I wrote a resource compiler in VB. Too long ago 
to have any of it left in my brain, but something might come back 
is .res is the target.