World: r4wp

Nice! I've missed that. It will make parts of my OpenGL binding look 
much nicer

Fine, I will try it and it could be even more elegant solution. Anyway, 
when you say it would break REBOL's synactic rules, does not your 
hexa format breaks it as well? Personaly I found very annoying to 
change many values like 0x00FF (usually in C's defines) into 00FFh. 
But I can live with that as I can always use some  converting script.

I see no reason why Red/System could not support typically used 0xx00FF 
format ... IIRC, when designing R3, we were also thinking to extend 
the syntax to support more formats, but nothing concrete appeared 
...

0x00FF format would kill pair! syntax, remember that Red/System is 
a dialect of Red and that Red will have pair!.

Hexa format: you're right and I hope to fix that once we rewrite 
Red/System in Red (then we'll have our own lexer instead of been 
limited by LOAD).

BTW, we can also decide that C-like hex format is more important 
than pair! syntax and find another literal form for pairs, but that 
would push us further away from REBOL (and clones) compatibility.

Pekr: from my little experience with lexers, I found it surprizingly 
difficult to design a set of consistent rules for a simple and readable 
syntax. If I had to design a new language syntax from scratch, this 
would probably be the hardest part.  Carl did a fantastic job when 
designing REBOL syntactic rules (even if it's not 100% perfect, R3 
did fix a lot of those issues).

Ok then ... I think we have more iportant things to solve/design 
:-)

How do I generate DLL? I added #export but it stills create .EXE 
file. Should I just rename it, or is there some compiler switch?

You need to use the WinDLL target: -t WinDLL

Thanks.

Note that currently your exported function will have cdecl calling 
convention forced on them. I'll change the #export syntax  today 
to allow optional convention to be specified (default will still 
be cdecl).

So I build my first Red/System DLL, but R2 refuses to load it with: 
** Access Error: Cannot open builds/temp.dll as library.

It is probably not related, but you might try with secure none, but 
I does not seem to be problem of REBOL's security or licence missing 
...

secure none doesn't help.

Let me test if there's no regression in last commits...

Works fine here. I'm testing with:

Red/System [ ]

i: 56
foo: func [a [integer!] return: [integer!]][a + 1]

#export [foo i]

You're sure that you're in `dyn-lib-emitter` branch?

(just in case)

If you still can't make it work, send me a copy of your DLL, I'll 
see what's wrong with it.

Yes, I'm in dyn-lib-emitter branch, otherwise compiler throws #export 
directive not found (or something like that)

My DLL is almost same as your example ('i is missing and function 
is called 'f1 instead of 'foo but otherwise it exactly same :)

RED/System[
	Title: "RED/System inline compilator test"
]

f1: func [a [integer!] return: [integer!]] [a + 1]
#export [f1]

(FYI: I'm trying to implement your make-native example)

Your code works fine here (REBOL 2.7.6): 

>> lib: load/library %builds/test.dll
>> f1: make routine! [a [integer!] return: [integer!]] lib "f1"
>> f1 123
== 124

Hm, I'll try with 2.7.6, I'm using 2.7.8 this may be the problem.

Works here from 2.7.8 too. Try from a freshly cloned repo.

Or just send me a copy of your DLL at [nr-:-red-lang-:-org], I should be 
able to quickly see what's wrong.

The DLL is here: http://box.lebeda.ws/~rebolek/temp.dll
source is here: http://box.lebeda.ws/~rebolek/temp.reds
But I guess it's just some stupid mistake on my side.

Let see that...

Works fine here: 

>> lib: load/library %builds/temp.dll
>> f1: make routine! [a [integer!] return: [integer!]] lib "f1"
>> f1 123
== 124

Are you running it under Windows XP?

(I wonder if it's not an OS compatibility issue)

No, W7. I will try this under virtual XP

I'm running it under W7 too, should be ok.

Mystery deepens...:-)

Are you preloading other DLL in your REBOL session before loading 
temp.dll?

Same under WXP (virtual) with both 2.7.6 and 2.7.8 . It's probably 
some bad day :)

>> lib: load/library %temp.dll
** Access Error: Cannot open temp.dll as library
** Near: lib: load/library %temp.dll

No, clear session

hmm...

Try with following C executable:  http://static.red-lang.org/tmp/loadlib.exe
(or .zip if you have issue downloading the exe).


Put it in the same folder as temp.dll and run it from DOS shell, 
you should have something like: 

C:\Dev\Red\red-system\builds>loadlib
error: 0
hModule: 268435456				;-- library handler
error: 0
&f1: 10001a85				;-- f1 function address
124						;-- f1(123)
error: 0

If it works, the DLL should be ok and the issue would be with your 
REBOL instances.

This is the source code for loadlib.exe: https://gist.github.com/3435800

Also, if someone else could test loading Rebolek's temp.dll lib, 
that would help.

Guess what. That works:

c:\code\Red\red-system\builds>loadlib.exe temp.dll
error: 0
hModule: 268435456
error: 0
&f1: 10001a85
124
error: 0

So it's probably really a bad day here for coding/testing :)

:-)

The only cause I can think of is because the DLL produced by Red/System 
are not (yet) relocatable, they can be conflicting with other loaded 
DLLs (but shouldn't happen with a fresh REBOL session), or are triggering 
something in anti-virus or Windows security sub-systems.

One thing - between some versions, there was change in syntax of 
"renturn". One version used the colon, the other did not. Just an 
idea ...

but if the same code works for Doc, problem is elsewhere ...

Petr, can you please try loading the DLL I provided, so we're sure 
it's just som eproblem with my setup?