I'm working on a project to convert ORexx, Regina, Arexx & Reginald
rexx etc. scripts to different platforms but do have some problem with
Regina...

The RexxRegisterSubcomDll() function /* I believe that's the function
to def */

This function is used to set up a routine that is located in a module
in a dynamic link library, as a subcommand handler. Some operating
systems don't have dynamic linking, and thus cannot make use of this
facility. The prototype of this function is:

APIRET APIENTRY RexxRegisterSubcomDll(
PSZ EnvName,
PSZ ModuleName,
PFN EntryPoint,
PUCHAR UserArea,
ULONG DropAuth

How do I funcdef a list of all functions from a external library in
regina ones and all in one or do I have to do this manually, every
used function one and all...

and is it posible to funcdef external library functions at all in
regina and how please...

sorry as a new commer to regina...

Kåre Johansson

This function is not yet supported by Regina.

ptjm

% This function is used to set up a routine that is located in a module
% in a dynamic link library, as a subcommand handler. Some operating
% systems don't have dynamic linking, and thus cannot make use of this
% facility. The prototype of this function is:
%
% APIRET APIENTRY RexxRegisterSubcomDll(
% PSZ EnvName,
% PSZ ModuleName,
% PFN EntryPoint,
% PUCHAR UserArea,
% ULONG DropAuth
%
% How do I funcdef a list of all functions from a external library in
% regina ones and all in one or do I have to do this manually, every
% used function one and all...

This seems like a non-sequitor. If you have a list of functions, you
can call RexxRegisterFunctionDll() for each of them. If the platform
you're working on has no dynamic linking, then you obviously can't have
a function defined in an external library, can you?

% and is it posible to funcdef external library functions at all in
% regina and how please...

% This function is not yet supported by Regina.

This appeared below your name, and I'm not sure what was meant by it, but
if it's supposed to be an error message emitted by Regina, I can't find
it in the sources. What platform are you working on?

In any case, whatever your problem is, you don't have to use the
Register*Dll functions just because your functions are in a DLL.
So long as the function names are resolved at the time you call
the register functions, you can use RexxRegisterFunctionExe and
pass a function pointer. I always do this in LoadFuncs-type functions,
because it allows shared libraries to be renamed without changing
the source code and recompiling.

--

Patrick TJ McPhee
East York Canada
ptjm@interlog.com

jeff glatt

Kare,

I'm sort of confused over what you're doing. Are you writing some software in
C? Because RexxRegisterSubcomDll() would normally be called only by a C program
(ie, not a REXX script).

Most of the REXX interpreters for personal computers have some APIs that are


not only runs REXX scripts -- it also provides a way for software written in
_other_ languages to launch REXX scripts, add new functions (written in a
language such as C) that are callable by that REXX script, and in general
interact (ie, exchange data) with that REXX script.

RexxRegisterSubcomDll() is one such API. RexxRegisterFunctionDll() is another
such API. Interpreters such as Reginald, Regina, and Object REXX have these
C/fortran/assembly/etc callable functions.

The purpose of RexxRegisterFunctionDll is to allow a program written in C, for
example, to add new functions designed for a REXX script to call. These
functions would normally be written in C. And by using RexxRegisterFunctionDll,
the C program makes these callable by your REXX script without your script
needing to use the REXX built-in function RXFUNCADD. (Think of RXFUNCADD as the
REXX script's version of the C callable RexxRegisterFunctionDll).

For example, you know that RexxEd makes special functions available to your
script to call such as EditGetDoc(), EditGetText(), etc. RexxEd is written in
C. EditGetDoc, EditGetText, etc, are C functions inside of my exe. I called
Reginald's RexxRegisterFunctionDll to make them available to any script that
RexxEd runs. Your script doesn't need to call RXFUNCADD to define EditGetDoc,
EditGetText, etc, because my C program does that for you using
RexxRegisterFunctionDll.

Contrast this with REXX Dialog. Because REXX Dialog does not call
RexxRegisterFunctionDll, your script needs to call RXFUNCADD to add the REXX
Dialog functions such as RXMSG, RXCREATE, etc. (Ok, actually you have to
RXFUNCADD only one REXX Dialog function, RXDLGLOADFUNCS, and call it once.
RXDLGLOADFUNCS actually does call RexxRegisterFunctionDll to register each and
every one of the _other_ REXX Dialog functions. Otherwise, you would need to
call RXFUNCADD for every one of them. And yes, Reginald's auto-load feature
eliminates the need to even RXFUNCADD and call RXDLGLOADFUNCS, because that's
what the auto-load feature essentially does).

What I think you're really asking about is "How does a REXX script register
functions in a DLL?". The answer to that is, if the DLL is written to support
REXX, such as REXX Dialog, MIDI Rexx, some DLLs that Patrick or Florian make,
etc, then you need to use RXFUNCADD to register each and every function you
intend to call. (But like REXX Dialog, typically these DLLs give you one
function to RXFUNCADD, and when you call this, it registers all of the other
functions on your behalf. In REXX Dialog, this is called RXDLGLOADFUNCS, but
other DLLs will have their own name for it. For example, MIDI Rexx has
MIDILOADFUNCS. One of Patrick's DLLs has a SYSLOADFUNCS).

But, if you want to register functions in a DLL that is not specifically
designed to support REXX, such as a Windows operating system DLL like
USER32.DLL, then you need to use some proprietary method (and hope the
interpreter supports that). For example, Reginald offers FUNCDEF, which allows
you to register these "non-REXX" DLLs, and offers a relatively straightforward
way of defining and calling them. Regina has an add-on DLL called GCI which has
its own method for defining and calling a non-REXX DLL's functions. (GCI should
also work with Reginald, although it's a bit more involved than using
Reginald's FUNCDEF. I'm not sure if it works with Object REXX. If not, then you
really have to take a long way around to call a non-REXX DLL from Object REXX.
You may have to create an ActiveX component in some other language).

In conclusion, for DLLs that directly support REXX, your script uses the
built-in function RXFUNCADD to register functions in that DLL. You then call
them just like you would any other built-in function. For DLLs that don't
directly support REXX, your script uses a proprietary method to register that
DLL's functions, such as Reginald's FUNCDEF or Florian's GCI add-on. And the
way you call the function may be different than a "normal" function. Reginald's
FUNCDEF tries to keep it very similiar to a normal call. GCI uses stem
variables more. (It's more like the way you set up the VAL variables for REXX
Dialog before you call RXCREATE).

shmuel (seymour j.) metz

In <bpk4n0$h2p$3@news.eusc.inter.net>, on 11/21/2003
at 05:35 AM, ptjm@interlog.com (Patrick TJ McPhee) said:


What do you mean by "dynamic" linking? It isn't synonymous with DLL.
Certainly in CMS and MVS a REXX program can dynamically call a routine
that is not in a DLL. A REXX program can also call routines in a
function package that is not in a DLL.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action. I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me. Do
not reply to spamtrap@library.lspace.org

ptjm

% at 05:35 AM, ptjm@interlog.com (Patrick TJ McPhee) said: %
% >This seems like a non-sequitor. If you have a list of functions, you
% >can call RexxRegisterFunctionDll() for each of them. If the platform
% >you're working on has no dynamic linking, then you obviously can't
% >have a function defined in an external library, can you?
%
% What do you mean by "dynamic" linking? It isn't synonymous with DLL.

The ability to load executable text from a file external to the module
from which the process was created, based on program logic. DLL is an
acronym for a kind of file which contains executable text and indices
into the text -- it is certainly not synonymous with dynamic linking,
but is synonymous with `shared object' or `shared library', the names
that come up most often on Unix systems.

% Certainly in CMS and MVS a REXX program can dynamically call a routine
% that is not in a DLL.

Why would you say it's not in a DLL? Because it's not called a DLL, or
because there's some conceptual difference between the way these
routines are called and the way routines are called from DLLs?

% A REXX program can also call routines in a
% function package that is not in a DLL.

Meaning what? That it's a collection of Rexx-language functions, or
that it's a collection of executable text in a library that doesn't
happen to be called DLL on that platform?

But RexxRegisterFunctionDll() is not something you can call from a Rexx
program. It's part of the SAA API and the discussion centres around
functions written in compiled languages, notable C and its derivatives.
There is an equivalent function which can be called from Rexx programs
directly, and which is usually supported on platforms which provide
the SAA API, but I'm not sure if the OP is interested in that.

--

Patrick TJ McPhee
East York Canada
ptjm@interlog.com

shmuel (seymour j.) metz

In <bplqen$4bu$6@news.eusc.inter.net>, on 11/21/2003
at 08:52 PM, ptjm@interlog.com (Patrick TJ McPhee) said:

No it is not. A DLL is a particular type of shared library.

Because it isn't. A DLL is a type of object with a particular type of
interface, and it is not the only type of object that can store
external routines.


Both the way that they are called and the way that they are packaged.
In both CMS and MVS I can call an external routine from REXX without
first registering it. I can't do that with a routine in a DLL.

Meaning that a REXX program can also call routines in a function
package that is not in a DLL. It does not need to first register the
routine, as it would for a routine in a DLL.

different in that it is specific to REXX and uses REXX calling
sequences rather than the normal calling sequences of its host.

It's not something that you need to call in order to call an external
function. It's not relevant to external functions that are not in a DLL.


Il va sans dire. I've written such functions, and have not needed to
put them in a DLL to call them, although I have sometimes found it
convenient to package them in REXX function packages.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action. I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me. Do
not reply to spamtrap@library.lspace.org

ptjm

% Both the way that they are called and the way that they are packaged.
% In both CMS and MVS I can call an external routine from REXX without
% first registering it. I can't do that with a routine in a DLL.

That's certainly not true. In practice, there are mechanisms for calling
routines from DLLs without registering them first, and in theory,
there's absolutely no reason for registration functions like
RexxRegisterFunctionDll to exist. In practice, some Rexx implementations
use them, but that's just because someone decided to do it that way.
% >But RexxRegisterFunctionDll() is not something you can call from a
% >Rexx program
%
% It's not something that you need to call in order to call an external
% function. It's not relevant to external functions that are not in a
% DLL.

It's not clear to me what your point is, but it doesn't seem like you're
making a distinction between `functions in DLLs' and `external
functions', but rather between Rexx implementations which require
functions in DLLs to be registered, and Rexx implementations which
don't. You may feel free to provide some details if I'm wrong, but I
presume your `external functions' sit in a file which is some sort of
library, and that the Rexx implementation searches this file, or some
set of files which it's programmed to recognise, for external functions.
Implementations which support the SAA API could do exactly the same
thing, although to my knowledge none of them do. This has nothing to do
with the nature of the libraries, but with the way the Rexx
implementations themselves work. It doesn't seem like there's a useful
distinction between DLLs and other kinds of libraries of compiled
functions, for a start.
--

Patrick TJ McPhee
East York Canada
ptjm@interlog.com

imc

Shmuel (Seymour J.) Metz entertained comp.lang.rexx with the following
story:


It's not an a priori necessity that routines stored in a DLL must be
registered - that's just a current widely-used convention.
--
---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including REXX section):
------ http://users.comlab.ox.ac.uk/ian.collier/imc.shtml

New to this group? Answers to frequently-asked questions can be had from
http://rexx.hursley.ibm.com/rexx/ .

florian_große-coosmann

kjactive@adslhome.dk schrieb:

is missing and returns an error like the exit stuff. Yes that's right
and will be fixed in 3.3 final which will be released around chrismas
hopefully.

RexxRegisterExitDll() doesn't work, too. Another error needs to be fixed.
RexxDeregisterFunction doesn't unload a loaded DLL allocated by
RxFuncAdd or RxFuncDefine or RexxRegisterFunctionDll.

---

Others have shown their opinion at different places of the thread. Mine
is that RexxRegister???Dll is the only clean way to be sure that the
interpreter won't crash. Loading a library and using RexxRegister???Exe
isn't safe if another script or function or hook tries to unload the
library.

Final note: Even ORexx doesn't follow the SAA do***entation. The
various error cases are handled in another way as do***ented.

You have to do it on your own. The best solution is to create a
loader function that is called by your script as the first function
which registers all other exported functions.


RexxRegisterFunctionDll should work for a long time already. Registering
hooks can be made doing a local lookup for the entries and then doing
a RexxRegister???Exe as already stated.

You only have to apologise if you don't come to Regina ;-)

Cheers, Florian

shmuel (seymour j.) metz

In <26781-Williamsburg.imc@comlab.ox.ac.uk>, on 11/24/2003
at 12:49 PM, imc@comlab.ox.ac.uk (Ian Collier) said:


Understood, but that's a secondary issue. The primary issue is that a
DLL is only one type of library, and that I can and have dynamically
called REXX aware subroutines from other types of libraries.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action. I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me. Do
not reply to spamtrap@library.lspace.org