World: r4wp

My msvcrt.dll version is 7.0.2600.5512 (on XP/Pro Turkish). and it 
works.

The 2600 version was on virtual XP, on W7 I've got 7.0.7601.17744

I just tested on a XP/Pro on VirtualBox, msvcrt.dll version is 7.0.2600.2180, 
it works.

Works on W7/64/Pro, but not on XP/Pro

Petr - for a git GUI you might want to try SmartGit - free for non 
commercial use and, IMO, the best GUI. Also, it's available for all 
platforms. I use this, tortoise and the command-line, depending on 
the context

Pekr: it's easier than you think: just open https://github.com/dockimbel/Red
and click on the "Clone in Windows" button ;)

Well, I am ok with tortoise, I just somehow can't easily swith the 
branches, it can't see them ... one option can see dyn-lib, other 
is still seeing a float branch, etc ...

Will try that. I though I will have to do something on the github 
page. I thought it is "watch" which is needed, but it was not it. 
Clone in windows - what a name ;-)

ToirtoiseGit context menu->Switch/Checkout, then choose your branch 
(can be local branch or remote/origin/* or remote/dockimbel/* not 
sure) or add new ones with "..." button on the right side->click 
on remotes->click on origin->select your branch.

So it's not a msvcrt issue it seems.

With the latest series of fixes, I've finally been able to move the 
SQLite binding into a CONTEXT

This has led to a huge shift in the naming of words. If you had written 
anything on this binding, you need to update your programs

Also, because it needs the latest non-released Red/System, I have 
put the binding changes in a separate developing branch:

http://red.esperconsultancy.nl/Red-SQLite

Pekr and Rebolek: could you try to use ProcessMonitor (PM) to see 
if we can get a clue about what is blocking the DLL loading from 
R2?


1) Download it from: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
2) Run it

3) Open a REBOL console and CD to the folder where the DLL is located

4) In PM, drag'n drop the "target" icon to the REBOL console window
5) Type in console: lib: load/library %temp.dll

6) Scroll down in the PM window to look for rebol.exe process entries, 
look for failure reports in Result and Detail columns...

I know sysinternals tools for quite some time. Just checked, no failure 
reports ....

Pekr & Rebolek: can you give it a new try with latest commit (it 
adds relocation support to DLLs).

If it still doesn't work, we'll have to get your hands dirty by diving 
in Windows guts using WinDbg. ;-)

ok, going to test it ....

what is now latest temp.reds source? I got:

Compiling tests/temp.reds ...
Script: "Red/System IA-32 code emitter" (none)
*** Compilation Error: missing argument
*** in file: %runtime/win32.reds
*** in function: ***-dll-entry-point
*** at line: 204
*** near: [hinstDLL]

hmm...let me see...

Red/System []

on-load: func [a [integer!]][
	print-line "on-load executed"
]

on-unload: func [a [integer!]][
	print-line "on-unload executed"
]

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

#export [foo i]

>> 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