REXX DLL problems solved (was Re: Problems getting C subcommand to work)
I posted last week about a REXX DLL that didn't work although it appeared
to me that everything was fine. This was basically true. Everything I was
looking at *was* just fine. The culprit, as anyone who has followed the thread
this far likely knows by now, is that OS/2 requires DLL names to follow the
DOS 8.3 naming convention (= max 8 chars + '.' + max 3 chars). I had been lulled
into a false sense of security by HPFS. I haven't been able to find any
reference to this in the VAC++ documentation or in any of the OS/2 online
documentation. I wondered if this was OS/2 wide.
Quote:
>Warp 3 and later require DLL names to be 8.3, max.
(Knowing this, I really wonder why RxFuncAdd() returns success given a DLL
it couldn't possibly load).
Warp 3 and later? It's not legacy?!
get genius points -- or get to assign me idiot points -- for the 8.3 info).
-----
Almost every time I'm in this group, there seems to be someone having
troubles with REXX DLLs so I felt I should take this opportunity to
summarize some of the other comments I received -- sort of a
why-doesn't-my-dll-work FAQ.
Quote:
>> ULONG RFLoadFormatFuncs(CHAR* name, ULONG numargs, RXSTRING args[],
>> CHAR* queuename, RXSTRING* retstr)
>Shouldn't that be ULONG APIENTRY RFLoad... ?
>I had some major problems with my Rexx DLL's and Rexx support in my app
>until I added the APIENTRY.
>Which compiler are you using?
For the time being, it shouldn't really matter given that RexxFunctionHandler
is typedefed (in rexxsaa.h) as
typedef ULONG APIENTRY RexxFunctionHandler(PUCHAR,
ULONG,
PRXSTRING,
PSZ,
PRXSTRING);
and that APIENTRY is typedefed (in os2def.h) as:
typedef int ( APIENTRY _PFN) ();
However, he (Phil) had troubles on his system, the code is a bit more
self documenting with it (IMHO) and it will be safeguarded against any
changes to the typedefs in future versions so it's in my code now (and
it still works :-) ).
(BTW, I/m using IBM VisualAge C/C++ v3).
Other suggestions that actually didn't apply to me but may apply to others
out there are:
Make sure the directory the DLL is in, is in your LIBPATH. Unlike the PATH
environment variable, the current directory is not searched by default when
looking for DLLs so put "." in your LIBPATH (or BeginLIBPATH or EndLIBPATH)
if necessary. (All but the first sentence may be specific to OS/2).
If files have been moving around, check that a previous version of the DLL
isn't found before the one you think you're using is found (ie. it exists in
2 or more directories in your LIBPATH).
Thank you to everybody that took the time to answer.
Todd Fox
