World: r3wp

So, you want to make a modular OS that has all dynamic libraries 
be R3 extensions natively - LOAD-EXTENSION won't load arbitrary libraries, 
just extensions - and you want the library filename suffix to be 
something other than .rx. OK.

LOAD-EXTENSION doesn't do lookup beyond the current directory, so 
if you want to have it use some library path you have to add that 
in the host code, or %rebol.r. Either way you can add extensions 
and modules programmatically to the R3 runtime before the script 
you're running starts. If you want your scripts to be cross-platform 
then you probably shouldn't use a platform-specific file extension 
for the files, but if they are loaded or delayed in the host code 
or %rebol.r then it wouldn't matter.

What's the problem? Even in R2 I was using code like:
	lib_ImageMagickWand: load/library either system/version/4 = 3 [
		%/c/utils/ImageMagick/CORE_RL_wand_.dll
	][	%/usr/lib/libMagickWand.so ]

I prefere to have this under control. The location may differ on 
different platforms.

For that matter, code like that can go in %rebol.r and then scripts 
won't have to even know that an extension isn't a regular module, 
as long as the API matches what they expect.

Oldes, R3 has decided to let the OS find an extension as a native 
library. I really don't want to override that and write my own loader 
in every script

Are you saying that on Linux and/or Syllable LOAD-EXTENSION looks 
up the extensions in the system library path? Weird.

Not weird, nice :-)

You may want to review my documentation for the cURL binding

Too late at night for me to read documentation :(

It's the logical effect of using the system's loader

https://github.com/Oldes/R3A110/blob/master/extensions/zlib/zlib.r3

I'm going to sleep, too

That sounds really dangerous with security turned off. Be careful.

Don't worry, I am the master of my systems

I don't get it Oldes. Why is it called %zlib-rxt.dll, when it could 
just as easily be called %zlib.rx and not have the platform-specific 
code?

Yes

But either way, that works.

I'm a newbie.. I expect that when I build DLL against windows version 
of the lib, it will not work on Linux.. or maybe I'm wrong.

That's true, but it's not tied to the name, Brian tells us

True. You would use a different file for Linux, though it could also 
be called %zlib.rx :)

I admit I confuse people by violating this truth and running the 
Linux binary on Syllable :-)

But than I need zlib.dll and zlib.so in the folder.. and what if 
I don't have zlib.so yet?

Since they don't work on both OSes, you wouldn't install them both. 
You install the matching one under the same name

Then don't have zlib.rx in that directory either :)

What is content of zlib.rx?

The R3 extension wrapper for ZLib.

that's the zlib.r3 for me.

Or the R3 extension that statically links ZLib if you like.

I don't get it.. I will wait for real life example..I'm fine how 
I have it now.

In your case you could just rename zlib-rxt.dll to zlib.rx and it 
would work.

And it will work on Linux?

You would then import %zlib.rx instead of %zlib.r3. It would work 
on Linux if you made a Linux build of zlib as a R3 extension and 
also called it zlib.rx.

But I want to make clear that the file is DLL, not SO.

maybe I will need my extension on linux later so I will make the 
SO, and I want both in the same directory, not just one, which I 
use at this moment. I want to have my files structure platform independent.

Why? Don't you put other platforms' extensions in different directories? 
There are multiple platforms that use .dll and .so, remember.

no... I use same structure.

And when you install it you don't need to install other platforms, 
just the platform you're on. So you only install the zlib.rx for 
your platform.

I do not install... I just copy folders. the true is, that now it 
can be more complicated as I have also the C sources in the same 
dir.

never mind... this is just a minor detail. Form me is important I 
can decompress zlib data as I could with R2. That's all.

If I had more time, it would be good to try some zlib/gz scheme.. 
but that's not important for me at this moment.

What is more important - can we UNLOAD the extension?

I thought that was included in R3 now?

You can't unload extensions.

Zlib in R3 doesn't work.

http://issue.cc/r3/1667

Kaj, here's an example %rebol.r for your scenario:

REBOL []
use [sys-path] [
sys-path:  %/some/safe/directory/full/of/extensions/
sys/load-module/delay map-each x read sys-path [sys-path/:x]
]

I have no time to wai for built in zlibt. But for me is every small 
extension a good C exercise

Then you make sure that your extensions can survive being delayed 
:-/

How much time and memory do delayed modules take? In any case, it 
will be too much on for example CGI scripts

BrianH: isn't having just one name going to be a problem for us? 
I like the .rx extension very much. But think about distros. You 
can't have one storage of extensions for various platforms. Dunno 
if such use case would exist. Something like big directory of extensions 
somewhere on the fileshare. In the same path. If the suffixes would 
be different, then those files could co-exist. Hmm, maybe not, because 
.so works for Linux, other Unixes, and those might require different 
extension binary anyway? How would you solve such a case? Subdirs 
per system? e.g. /amiga, /win32, /win64, /linux, /syllable?