REXX DLL problems solved (was Re: Problems getting C subcommand to work) 
Author Message
 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



Sat, 17 Apr 1999 03:00:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Problems getting C subcommand REXX DLL to work

2. I am unavle to solve a problem

3. VX-REXX Secondary Window Problem Solved

4. SysSleep function in OS/2 Rexx (problem solved)

5. 32bit problem - one problem solved & another found

6. VRML EAI problems: Java3d solves many portabilty problems of VRML

7. Problems solving a problem with lists

8. Stack overflow problem but increasing stack size does not solve the problem

9. Difficult problem to solve: Tcl 7.3 to Tcl 8.0p2 Array of Array Problem

10. problem solved for C and Tcl7.5 compilation problems

11. problem getting pbmake and rcs to work

12. REXX and 4OS2 problem: lower-case text gets converted to upper-case

 

 
Powered by phpBB® Forum Software