World: r4wp

So far, I suppose that the issue is caused by either:
- lack of relocation ability from the DLL (my #1 suspect)

- compatibility issue(s) with some system DLL (msvcrt.dll most probably)
- another unknown reason

I'll try to add relocation data to the DLL tonight.

When I ran my successful test, I ran as a user not admin.

same problem here

>> read %temp.dll

== {MZ€^@^A^@^@^@^D^@^P^@ÿÿ^@^@@^A^@^@^@^@^@^@@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@€^@^@^@^N
^_º^N...
>> lib:  load/library %temp.dll
** Access Error: Cannot open temp.dll as library
** Near: lib:  load/library %temp.dll
	
but
>> load/library %shell32.dll
>>

What if you explicitly point to the current directory? Is that %.\temp.dll 
on Windows?

Or try the full path to the DLL

i tried with full path too. same result

OK, it fixes some cases with R3 extension loading

it is imo not definitely a path problem. Just check with exists? 
%temp.dll, and it returns true. Still library is not loading ...

I suspect about the different msvcrt.dll versions.

AdrianS: "did REBOL core only have library support if you had a licensed 
sdk?" - yes licensed Core (Core/Pro) support library.

I just tried on Win7 64bit, it works.

msvcrt.dll - version 7.0.2600.5701

I tried also on my W7 x64 instance on laptop, it works.

msvcrt.dll - v7.0.7600.16930
kernel32.dll - v6.1.7600.16850

mine is: 7.0.6002.18551 (vistasp2_gdr.111214-0301)

kernel32: 6.0.6001.18000 (longhorn_rtm.080118-1840)

msvcrt.dll - 7.0.7601.21878
kernel32.dll - 6.1.7601.17651

Win 7 x64
msvcrt.dll 7.0.7601.17744
kernel32.dll 6.1.7601.17651

So for ppl where it loads, we have msvcrt rev >= 7600, for ppl where 
it doesn't load, we have rev 2600 and 6002 (Vista). 

Rebolek, are you running on a pre-RTM version of W7?

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! :-)