World: r4wp

Anyway, it should load even on XP, so I really suspect a relocation 
need for boxes with older msvcrt.

I have changed 'on-load definition in last commit:


You can now _optionally_ defined 4 callbacks when producing a DLL:

 on-load:        func [hModule [integer!][...]
 on-unload:      func [hModule [integer!][...]
 on-new-thread:  func [hModule [integer!][...]
 on-exit-thread: func [hModule [integer!][...]

 hModule is a handler on the DLL instance.

They don't need to be added to #export block.

I tried to put a msvcrt.dll > 7600 into the same path as temp.dll, 
into system32 or into the rebol home path. still no success

Doc - the SW you suggest for Git is extremly nice, almost like working 
with tablet, but otherwise not much usefull to me. It does not add 
context menu to the shell, so no right click upon the directory. 
I also did not figured out, how should I add red in there? There 
is no place to paste the https://github.com/dockimbel/Red.gitURL 
... I will install back some other git client ...

I try to keep with the console Git to practice it properly, but it 
may not be easy under Windows. I don't know.

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.