RexxUtil.DLL - OS2

This is a discussion on RexxUtil.DLL - OS2 ; On Sun, 23 Dec 2007 12:07:32 UTC, spamgate@hotmai1.com (ML) wrote: > In CRexx In ORexx > ======================== ========================== Are you talking about the library, or the documentation? FWIW, all of the functions in both columns are available to classic REXX ...

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 110

Thread: RexxUtil.DLL

  1. Re: RexxUtil.DLL

    On Sun, 23 Dec 2007 12:07:32 UTC, spamgate@hotmai1.com (ML) wrote:

    > In CRexx In ORexx
    > ======================== ==========================


    Are you talking about the library, or the documentation?

    FWIW, all of the functions in both columns are available
    to classic REXX under OS/2. The older cREXX documentation
    just was never updated with them.

    Have you seen my updated REXXUTIL.INF document?
    http://www.cs-club.org/~alex/os2/too...til/index.html


    Just for the record, I mislike the very idea of adding all
    sorts of new functions to REXXUTIL on our own initiative.
    If it's coordinated through RexxLAA and kept more or less
    synchronized across all platforms, then sure. But I think
    any further work on OS/2 REXX should try to move _towards_
    cross-platform functionality, rather than diverging.

    --
    Alex Taylor
    http://www.cs-club.org/~alex

    Please take off hat when replying.

  2. Re: RexxUtil.DLL

    On Sun, 23 Dec 2007 12:07:32 UTC, spamgate@hotmai1.com (ML) wrote:

    > In CRexx In ORexx
    > ======================== ==========================


    Are you talking about the library, or the documentation?

    FWIW, all of the functions in both columns are available
    to classic REXX under OS/2. The older cREXX documentation
    just was never updated with them.

    Have you seen my updated REXXUTIL.INF document?
    http://www.cs-club.org/~alex/os2/too...til/index.html


    Just for the record, I mislike the very idea of adding all
    sorts of new functions to REXXUTIL on our own initiative.
    If it's coordinated through RexxLAA and kept more or less
    synchronized across all platforms, then sure. But I think
    any further work on OS/2 REXX should try to move _towards_
    cross-platform functionality, rather than diverging.

    --
    Alex Taylor
    http://www.cs-club.org/~alex

    Please take off hat when replying.

  3. Re: RexxUtil.DLL


    >> In CRexx In ORexx


    > Are you talking about the library, or the documentation?


    Documentation: no source available, and they complement eachother. A
    first copy of a finished product could be CRexx+ORexx+(some )ooRexx.

    > The older cREXX documentation just was never updated with them.


    The same may apply to the ooRexx-documentation.

    > Have you seen my updated REXXUTIL.INF document?
    > http://www.cs-club.org/~alex/os2/too...til/index.html


    Out of sight, unless its existence is made known explicitly (I a way
    the same would apply to My.DLL ;-)).

    > Just for the record, I mislike the very idea of adding all sorts
    > of new functions to REXXUTIL on our own initiative.


    There's no other initiative w.r.t. OS/2. Basicly the other initiative
    is aimed at Windows and a few power-users, not keeping anything else
    in mind. Plenty examples of that, e.g. what result would you expect
    with "SysIsFileCompressed('MyBackup.WPI')"? FWIW, I've never seen an
    initiative aimed at porting just RexxUtil.DLL to OS/2.

    Personally I may even care more about portability than that. It's not
    the best example thinkable, but why not add SysWinVer(), letting it
    return a bogus result like "0.00"? Why use SysUtilVersion() as-is,
    and not:

    - called without argument: return the version
    - called with argument: return 0, or 1 when it meets or exceeds the
    argument

    If SysPi() returns the number pi with an accuracy of NUMERIC DIGITS,
    why not add SysPi(digs) too, with "digs" digits? And so on. There's
    no standard nor any RexxLA-effort, so why not choose a descent one
    ourselves? Innovative: without neglecting other interests completely

    > But I think any further work on OS/2 REXX should try to move
    > _towards_ cross-platform functionality, rather than diverging.


    I think I've already more cross-platform functionality in mind than
    the RexxLA-project has ever shown so far, and I sure wouldn't want
    to inherit anything that project produced as-is.

    A part of the solution could be more than one function name for the
    same function, e.g. encryption isn't a Windows-only functionality. I
    think that allows for both SysWinFileEncrypt() and SysFileEncrypt(),
    albeit then we're stuck with such a SysWinFileEncrypt() forever.

    When it comes to adding functions, keeping sense and quality in our
    minds, it's possible for any other platform to look at our version.
    Basic clipboard-related functions could be an example. I don't think
    we should call those functions Sys_OS2_Clip*(), isn't it?

    Besides that, I'm not advocating adding anything one can think of.
    For starters there aren't zillions of "classic" functions out here,
    and a risk is that adding too much functions will result in a lot of
    "macro's". And too much books in a poorly organized library isn't a
    good idea. Hence me mentioning e.g. MathCos() instead of SysCos(),
    preferring the best Rexx math library source available (ooRexx, or
    RexxMath, whatever).

    Anyway, it may be a good moment to start glueing? I'm thinking about
    setting up a simple web page, divided in sections: the RexxUtil.DLL
    in the OS/2 toolkit, CRexx, ORexx, ooRexx usable, ooRexx improved
    (e.g. w.r.t. cross-platform issues), add-on proposals. It could show
    who picked up what so far with some details (e.g. compiler used for
    a part), with (links to) sources and "decisions". Such a decision is
    perhaps that the toolkit version includes string2long(), which may
    be preferred above C's atol() in order to remain consistent. IMhO
    it reached a finished stage with anything upto and including ooRexx
    usable as-is without naming convention problems (e.g. SysFileCopy()
    fits in the already existing, shared SysFile*()-group, so I cannot
    think of any possible issues related to that one).

    Disadvantage: a web page cannot be fully shared. Advantage: novice
    programmers can have a go at even a single function without having
    to bother about CVS, subscriptions, and so on.

    If anybody has a better idea, feel frea to submit it! Now there's no
    other initiative, other than people (at least Adrian and Michael,
    apart from me) already having a go at some (existing) functions.



    ---

  4. Re: RexxUtil.DLL


    >> In CRexx In ORexx


    > Are you talking about the library, or the documentation?


    Documentation: no source available, and they complement eachother. A
    first copy of a finished product could be CRexx+ORexx+(some )ooRexx.

    > The older cREXX documentation just was never updated with them.


    The same may apply to the ooRexx-documentation.

    > Have you seen my updated REXXUTIL.INF document?
    > http://www.cs-club.org/~alex/os2/too...til/index.html


    Out of sight, unless its existence is made known explicitly (I a way
    the same would apply to My.DLL ;-)).

    > Just for the record, I mislike the very idea of adding all sorts
    > of new functions to REXXUTIL on our own initiative.


    There's no other initiative w.r.t. OS/2. Basicly the other initiative
    is aimed at Windows and a few power-users, not keeping anything else
    in mind. Plenty examples of that, e.g. what result would you expect
    with "SysIsFileCompressed('MyBackup.WPI')"? FWIW, I've never seen an
    initiative aimed at porting just RexxUtil.DLL to OS/2.

    Personally I may even care more about portability than that. It's not
    the best example thinkable, but why not add SysWinVer(), letting it
    return a bogus result like "0.00"? Why use SysUtilVersion() as-is,
    and not:

    - called without argument: return the version
    - called with argument: return 0, or 1 when it meets or exceeds the
    argument

    If SysPi() returns the number pi with an accuracy of NUMERIC DIGITS,
    why not add SysPi(digs) too, with "digs" digits? And so on. There's
    no standard nor any RexxLA-effort, so why not choose a descent one
    ourselves? Innovative: without neglecting other interests completely

    > But I think any further work on OS/2 REXX should try to move
    > _towards_ cross-platform functionality, rather than diverging.


    I think I've already more cross-platform functionality in mind than
    the RexxLA-project has ever shown so far, and I sure wouldn't want
    to inherit anything that project produced as-is.

    A part of the solution could be more than one function name for the
    same function, e.g. encryption isn't a Windows-only functionality. I
    think that allows for both SysWinFileEncrypt() and SysFileEncrypt(),
    albeit then we're stuck with such a SysWinFileEncrypt() forever.

    When it comes to adding functions, keeping sense and quality in our
    minds, it's possible for any other platform to look at our version.
    Basic clipboard-related functions could be an example. I don't think
    we should call those functions Sys_OS2_Clip*(), isn't it?

    Besides that, I'm not advocating adding anything one can think of.
    For starters there aren't zillions of "classic" functions out here,
    and a risk is that adding too much functions will result in a lot of
    "macro's". And too much books in a poorly organized library isn't a
    good idea. Hence me mentioning e.g. MathCos() instead of SysCos(),
    preferring the best Rexx math library source available (ooRexx, or
    RexxMath, whatever).

    Anyway, it may be a good moment to start glueing? I'm thinking about
    setting up a simple web page, divided in sections: the RexxUtil.DLL
    in the OS/2 toolkit, CRexx, ORexx, ooRexx usable, ooRexx improved
    (e.g. w.r.t. cross-platform issues), add-on proposals. It could show
    who picked up what so far with some details (e.g. compiler used for
    a part), with (links to) sources and "decisions". Such a decision is
    perhaps that the toolkit version includes string2long(), which may
    be preferred above C's atol() in order to remain consistent. IMhO
    it reached a finished stage with anything upto and including ooRexx
    usable as-is without naming convention problems (e.g. SysFileCopy()
    fits in the already existing, shared SysFile*()-group, so I cannot
    think of any possible issues related to that one).

    Disadvantage: a web page cannot be fully shared. Advantage: novice
    programmers can have a go at even a single function without having
    to bother about CVS, subscriptions, and so on.

    If anybody has a better idea, feel frea to submit it! Now there's no
    other initiative, other than people (at least Adrian and Michael,
    apart from me) already having a go at some (existing) functions.



    ---

  5. Re: RexxUtil.DLL


    > I use Open Watcom and I broke the source to separate files.


    Sounds fine to me, using VAC! AFAIK your compiler doesn't introduce
    additional requirements related to C. For old-timers maybe the only
    thing to watch for is to try to use generic toolkit functions like
    string2long() instead of the ones included in (the old) VXTECH01.ZIP
    (http://hobbes.nmsu.edu/pub/os2/dev/r...h/vxtech01.zip) or the
    use of C's atol(). That may avoid a few (nearly) identical support
    functions. Or instead use support functions from ooRexx RexxUtil.C,
    which very well may achieve the same goal.



    ---

  6. Re: RexxUtil.DLL


    > I use Open Watcom and I broke the source to separate files.


    Sounds fine to me, using VAC! AFAIK your compiler doesn't introduce
    additional requirements related to C. For old-timers maybe the only
    thing to watch for is to try to use generic toolkit functions like
    string2long() instead of the ones included in (the old) VXTECH01.ZIP
    (http://hobbes.nmsu.edu/pub/os2/dev/r...h/vxtech01.zip) or the
    use of C's atol(). That may avoid a few (nearly) identical support
    functions. Or instead use support functions from ooRexx RexxUtil.C,
    which very well may achieve the same goal.



    ---

  7. Re: RexxUtil.DLL


    string2long() has a maximum length of 9, but a long can have a length
    of 11. string2ulong() has a maximum length of 10, but 9012345678 isn't
    a proper u(nsigned )long. The fixed number of MAX_DIGITS is 9, but a
    NUMERIC DIGITS-related error can be kept hidden. MAX_DIGITS isn't
    what "SAY Digits()" prints, which e.g. could be "7".

    I think it's safe to adjust both string2(u)long()-support functions.
    If Rexx, due to a default number of 9 digits, has a problem with a
    file handle of 'DEADFACE'x, the interpreter should complain about
    that, instead of showing a REX40-error message. And reversed a
    rounded file handle of "4E9" should result in an unknown file handle-
    related error message. After all, what's wrong with RexxUtil.DLL?

    Anybody predicting a problem with "improving" string2(u)long()'s? A
    long can be longer than 9 digits, and 9 isn't guaranteed to be the
    default setting of numeric digits anyway. It often is 9 by default
    anyway, but will allowing for real (u)long's break anything?



    ---

  8. Re: RexxUtil.DLL


    string2long() has a maximum length of 9, but a long can have a length
    of 11. string2ulong() has a maximum length of 10, but 9012345678 isn't
    a proper u(nsigned )long. The fixed number of MAX_DIGITS is 9, but a
    NUMERIC DIGITS-related error can be kept hidden. MAX_DIGITS isn't
    what "SAY Digits()" prints, which e.g. could be "7".

    I think it's safe to adjust both string2(u)long()-support functions.
    If Rexx, due to a default number of 9 digits, has a problem with a
    file handle of 'DEADFACE'x, the interpreter should complain about
    that, instead of showing a REX40-error message. And reversed a
    rounded file handle of "4E9" should result in an unknown file handle-
    related error message. After all, what's wrong with RexxUtil.DLL?

    Anybody predicting a problem with "improving" string2(u)long()'s? A
    long can be longer than 9 digits, and 9 isn't guaranteed to be the
    default setting of numeric digits anyway. It often is 9 by default
    anyway, but will allowing for real (u)long's break anything?



    ---

  9. Re: RexxUtil.DLL

    ML wrote:
    > string2long() has a maximum length of 9, but a long can have a length
    > of 11. string2ulong() has a maximum length of 10, but 9012345678 isn't
    > a proper u(nsigned )long. The fixed number of MAX_DIGITS is 9, but a
    > NUMERIC DIGITS-related error can be kept hidden. MAX_DIGITS isn't
    > what "SAY Digits()" prints, which e.g. could be "7".
    >
    > I think it's safe to adjust both string2(u)long()-support functions.
    > If Rexx, due to a default number of 9 digits, has a problem with a
    > file handle of 'DEADFACE'x, the interpreter should complain about
    > that, instead of showing a REX40-error message. And reversed a
    > rounded file handle of "4E9" should result in an unknown file handle-
    > related error message. After all, what's wrong with RexxUtil.DLL?
    >
    > Anybody predicting a problem with "improving" string2(u)long()'s? A
    > long can be longer than 9 digits, and 9 isn't guaranteed to be the
    > default setting of numeric digits anyway. It often is 9 by default
    > anyway, but will allowing for real (u)long's break anything?
    >


    Not sure. How many odf the function do you have recreated? As of today I
    have the following working and part of the demo script:

    EXPORT SysCls
    EXPORT SysCurPos
    EXPORT SysCurState
    EXPORT SysDriveInfo
    EXPORT SysDriveMap
    EXPORT SysDropFuncs
    EXPORT SysFileDelete
    EXPORT SysFileSearch
    EXPORT SysFileTree
    EXPORT SysGetKey
    EXPORT SysGetMessage
    EXPORT SysIni
    EXPORT SysLoadFuncs
    EXPORT SysMkDir
    EXPORT SysOS2Ver
    EXPORT SysRmDir
    EXPORT SysSearchPath
    EXPORT SysSleep
    EXPORT SysTempFileName
    EXPORT SysTextScreenRead
    EXPORT SysTextScreenSize
    EXPORT SysGetEA
    EXPORT SysPutEA
    EXPORT SysWaitNamedPipe
    EXPORT SysBootDrive
    EXPORT SysFileSystemType
    EXPORT SysAddFileHandle
    EXPORT SysSetFileHandle
    EXPORT SysAddRexxMacro
    EXPORT SysDropRexxMacro
    EXPORT SysReorderRexxMacro
    EXPORT SysQueryRexxMacro
    EXPORT SysClearRexxMacroSpace
    EXPORT SysLoadRexxMacroSpace
    EXPORT SysSaveRexxMacroSpace
    EXPORT SysWaitForShell
    #EXPORT SysStemSort Needs work
    EXPORT SysStemDelete
    EXPORT SysStemInsert
    EXPORT SysStemCopy
    EXPORT SysVersion
    EXPORT SysUtilVersion

    SysStemSort will need work because of this:

    /* the sorting is done in the interpreter */
    if (!RexxStemSort(stemName, sortOrder, sortType, first, last, firstCol,
    lastCol)) {
    sprintf(retstr->strptr, "-1");
    retstr->strlength = 2;
    return INVALID_ROUTINE;
    }

    I have tried to import the ordinal from the OS/2 OREXX.DLL but it
    doesn't seem to be there.

    Mike

  10. Re: RexxUtil.DLL

    ML wrote:
    > string2long() has a maximum length of 9, but a long can have a length
    > of 11. string2ulong() has a maximum length of 10, but 9012345678 isn't
    > a proper u(nsigned )long. The fixed number of MAX_DIGITS is 9, but a
    > NUMERIC DIGITS-related error can be kept hidden. MAX_DIGITS isn't
    > what "SAY Digits()" prints, which e.g. could be "7".
    >
    > I think it's safe to adjust both string2(u)long()-support functions.
    > If Rexx, due to a default number of 9 digits, has a problem with a
    > file handle of 'DEADFACE'x, the interpreter should complain about
    > that, instead of showing a REX40-error message. And reversed a
    > rounded file handle of "4E9" should result in an unknown file handle-
    > related error message. After all, what's wrong with RexxUtil.DLL?
    >
    > Anybody predicting a problem with "improving" string2(u)long()'s? A
    > long can be longer than 9 digits, and 9 isn't guaranteed to be the
    > default setting of numeric digits anyway. It often is 9 by default
    > anyway, but will allowing for real (u)long's break anything?
    >


    Not sure. How many odf the function do you have recreated? As of today I
    have the following working and part of the demo script:

    EXPORT SysCls
    EXPORT SysCurPos
    EXPORT SysCurState
    EXPORT SysDriveInfo
    EXPORT SysDriveMap
    EXPORT SysDropFuncs
    EXPORT SysFileDelete
    EXPORT SysFileSearch
    EXPORT SysFileTree
    EXPORT SysGetKey
    EXPORT SysGetMessage
    EXPORT SysIni
    EXPORT SysLoadFuncs
    EXPORT SysMkDir
    EXPORT SysOS2Ver
    EXPORT SysRmDir
    EXPORT SysSearchPath
    EXPORT SysSleep
    EXPORT SysTempFileName
    EXPORT SysTextScreenRead
    EXPORT SysTextScreenSize
    EXPORT SysGetEA
    EXPORT SysPutEA
    EXPORT SysWaitNamedPipe
    EXPORT SysBootDrive
    EXPORT SysFileSystemType
    EXPORT SysAddFileHandle
    EXPORT SysSetFileHandle
    EXPORT SysAddRexxMacro
    EXPORT SysDropRexxMacro
    EXPORT SysReorderRexxMacro
    EXPORT SysQueryRexxMacro
    EXPORT SysClearRexxMacroSpace
    EXPORT SysLoadRexxMacroSpace
    EXPORT SysSaveRexxMacroSpace
    EXPORT SysWaitForShell
    #EXPORT SysStemSort Needs work
    EXPORT SysStemDelete
    EXPORT SysStemInsert
    EXPORT SysStemCopy
    EXPORT SysVersion
    EXPORT SysUtilVersion

    SysStemSort will need work because of this:

    /* the sorting is done in the interpreter */
    if (!RexxStemSort(stemName, sortOrder, sortType, first, last, firstCol,
    lastCol)) {
    sprintf(retstr->strptr, "-1");
    retstr->strlength = 2;
    return INVALID_ROUTINE;
    }

    I have tried to import the ordinal from the OS/2 OREXX.DLL but it
    doesn't seem to be there.

    Mike

  11. Re: RexxUtil.DLL


    > Not sure.


    Later maybe I'll have a look at using a dynamic Digits() instead of
    a fixed number of MAX_DIGITS. AFAICT MAX_DIGITS is set to a default
    number of Digits(), but that may be changed to e.g. 7, and is REX40
    appropiate with a perfectly valid argument of (LONG)1,000,000,000.

    > How many odf the function do you have recreated?


    Additional to yours, that is:

    SysCloseEventSem
    SysMapCase
    SysProcessType
    SysSetProcessCodePage
    SysWildCard (requires Warp 4 and beyond)

    Testing learned one of those returned unexpected results (existing
    version), and I also spent some time looking at some possibilities.
    Please don't think too much of that: I may even have wondered why
    "if (numargs)" returns INVALID_ROUTINE instead of just ignoring the
    unneeded args... :-)

    Anyway, next ones up at my end: OS/2's Sys*Object*()-functions. I
    don't really care if someone else already covered those, comparing
    sources is probably easier than testing different binaries, but
    nevertheless I skip already announced remaked functions, e.g. the
    ones Adrian mentioned in his article.

    > SysFileTree


    Did you think of the Y2K-related changes to that one, documented
    in the Warp 4, FP9 releasenotes? And perhaps the case-sensitivity
    option added because "the" a user requested that?

    > SysStemSort will need work because of this:
    > /* the sorting is done in the interpreter */


    That may be related to memory usage and/or execution speed. If
    needed, remake the output instead of the way it works under the
    interpreter-hood (for one because there's no ooRexx/s (yet))?

    > I have tried to import the ordinal from the OS/2 OREXX.DLL but it
    > doesn't seem to be there.


    The functions are newer than that one, IIRC. ooRexx-related source
    files with "SysStem" occuring in 'em, an "undocumented API", FWIW:

    kernel\rexx.def
    kernel\platform\unix\VariablePool.cpp
    kernel\platform\windows\VariablePool.cpp
    kernel\platform\wrexx.def
    kernel\runtime\RexxNativeActivation.cpp
    kernel\runtime\RexxNativeAPI.h
    rexutils\unix\rexxutil.cpp
    rexutils\windows\rexxutil.c
    rexutils\windows\rexxutil.def

    And please be carefull adding the new ooRexx-functions. Many are
    candidates for some kind of debate. And obvious ones are missing,
    e.g. SysIsInternetConnectionUpAndRunningLikeACharm(). ;-)



    ---

  12. Re: RexxUtil.DLL


    > Not sure.


    Later maybe I'll have a look at using a dynamic Digits() instead of
    a fixed number of MAX_DIGITS. AFAICT MAX_DIGITS is set to a default
    number of Digits(), but that may be changed to e.g. 7, and is REX40
    appropiate with a perfectly valid argument of (LONG)1,000,000,000.

    > How many odf the function do you have recreated?


    Additional to yours, that is:

    SysCloseEventSem
    SysMapCase
    SysProcessType
    SysSetProcessCodePage
    SysWildCard (requires Warp 4 and beyond)

    Testing learned one of those returned unexpected results (existing
    version), and I also spent some time looking at some possibilities.
    Please don't think too much of that: I may even have wondered why
    "if (numargs)" returns INVALID_ROUTINE instead of just ignoring the
    unneeded args... :-)

    Anyway, next ones up at my end: OS/2's Sys*Object*()-functions. I
    don't really care if someone else already covered those, comparing
    sources is probably easier than testing different binaries, but
    nevertheless I skip already announced remaked functions, e.g. the
    ones Adrian mentioned in his article.

    > SysFileTree


    Did you think of the Y2K-related changes to that one, documented
    in the Warp 4, FP9 releasenotes? And perhaps the case-sensitivity
    option added because "the" a user requested that?

    > SysStemSort will need work because of this:
    > /* the sorting is done in the interpreter */


    That may be related to memory usage and/or execution speed. If
    needed, remake the output instead of the way it works under the
    interpreter-hood (for one because there's no ooRexx/s (yet))?

    > I have tried to import the ordinal from the OS/2 OREXX.DLL but it
    > doesn't seem to be there.


    The functions are newer than that one, IIRC. ooRexx-related source
    files with "SysStem" occuring in 'em, an "undocumented API", FWIW:

    kernel\rexx.def
    kernel\platform\unix\VariablePool.cpp
    kernel\platform\windows\VariablePool.cpp
    kernel\platform\wrexx.def
    kernel\runtime\RexxNativeActivation.cpp
    kernel\runtime\RexxNativeAPI.h
    rexutils\unix\rexxutil.cpp
    rexutils\windows\rexxutil.c
    rexutils\windows\rexxutil.def

    And please be carefull adding the new ooRexx-functions. Many are
    candidates for some kind of debate. And obvious ones are missing,
    e.g. SysIsInternetConnectionUpAndRunningLikeACharm(). ;-)



    ---

  13. Re: RexxUtil.DLL


    >> How many odf the function do you have recreated?


    > Additional to yours, that is:


    > SysCloseEventSem


    Whithout thinking about closing open handles on exit/termination:


    ULONG SysCloseEventSem(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    HEV hev;

    if (numargs!=1)
    return INVALID_ROUTINE;

    if (!string2ulong(args[0].strptr,&hev))
    return INVALID_ROUTINE;

    sprintf(retstr->strptr,"%d",DosCloseEventSem(hev));
    retstr->strlength=strlen(retstr->strptr);
    return VALID_ROUTINE;
    }


    > SysMapCase


    Empty result possible, not checked yet if that's the OS/2 API or a
    VALID_ROUTINE.


    ULONG SysMapCase(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    COUNTRYCODE Country={0};

    if (numargs<1||numargs>3)
    return INVALID_ROUTINE;

    if (!strlen(args[0].strptr))
    return INVALID_ROUTINE;

    Country.country=COUNTRY_CODE;
    Country.codepage=NLS_CODEPAGE;

    if (numargs>1)
    {
    if (strlen(args[1].strptr))
    if (!string2ulong(args[1].strptr,&Country.country))
    return INVALID_ROUTINE;
    if (numargs==3)
    {
    if (strlen(args[2].strptr))
    if (!string2ulong(args[2].strptr,&Country.codepage))
    return INVALID_ROUTINE;
    }
    }

    if (DosMapCase(sizeof(args[0].strptr),&Country,args[0].strptr))
    return INVALID_ROUTINE;

    sprintf(retstr->strptr,"%s",args[0].strptr);
    retstr->strlength=strlen(retstr->strptr);
    return VALID_ROUTINE;
    }


    > SysProcessType



    ULONG SysProcessType(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    PPIB ppib=NULL;
    PTIB ptib=NULL;

    if (numargs)
    return INVALID_ROUTINE;

    DosGetInfoBlocks(&ptib,&ppib);

    sprintf(retstr->strptr,"%d",ppib->pib_ultype);
    retstr->strlength=1;
    return VALID_ROUTINE;
    }


    > SysSetProcessCodePage



    ULONG SysSetProcessCodePage(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    ULONG cp;

    if (numargs!=1)
    return INVALID_ROUTINE;

    if (!string2ulong(args[0].strptr,&cp))
    return INVALID_ROUTINE;

    sprintf(retstr->strptr,"%d",DosSetProcessCp(cp));
    retstr->strlength=strlen(retstr->strptr);
    return VALID_ROUTINE;
    }


    > SysWildCard (requires Warp 4 and beyond)


    Not tested yet.


    ULONG SysWildCard(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    UCHAR achTarget[MAX]="";

    if (numargs!=2)
    return INVALID_ROUTINE;

    if (!strlen(args[0].strptr))
    return INVALID_ROUTINE;

    if (DosEditName(1,args[0].strptr,args[1].strptr,achTarget,MAX))
    return INVALID_ROUTINE;

    sprintf(retstr->strptr,"%s",achTarget);
    retstr->strlength=strlen(retstr->strptr);
    return VALID_ROUTINE;
    }



    ---

  14. Re: RexxUtil.DLL


    >> How many odf the function do you have recreated?


    > Additional to yours, that is:


    > SysCloseEventSem


    Whithout thinking about closing open handles on exit/termination:


    ULONG SysCloseEventSem(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    HEV hev;

    if (numargs!=1)
    return INVALID_ROUTINE;

    if (!string2ulong(args[0].strptr,&hev))
    return INVALID_ROUTINE;

    sprintf(retstr->strptr,"%d",DosCloseEventSem(hev));
    retstr->strlength=strlen(retstr->strptr);
    return VALID_ROUTINE;
    }


    > SysMapCase


    Empty result possible, not checked yet if that's the OS/2 API or a
    VALID_ROUTINE.


    ULONG SysMapCase(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    COUNTRYCODE Country={0};

    if (numargs<1||numargs>3)
    return INVALID_ROUTINE;

    if (!strlen(args[0].strptr))
    return INVALID_ROUTINE;

    Country.country=COUNTRY_CODE;
    Country.codepage=NLS_CODEPAGE;

    if (numargs>1)
    {
    if (strlen(args[1].strptr))
    if (!string2ulong(args[1].strptr,&Country.country))
    return INVALID_ROUTINE;
    if (numargs==3)
    {
    if (strlen(args[2].strptr))
    if (!string2ulong(args[2].strptr,&Country.codepage))
    return INVALID_ROUTINE;
    }
    }

    if (DosMapCase(sizeof(args[0].strptr),&Country,args[0].strptr))
    return INVALID_ROUTINE;

    sprintf(retstr->strptr,"%s",args[0].strptr);
    retstr->strlength=strlen(retstr->strptr);
    return VALID_ROUTINE;
    }


    > SysProcessType



    ULONG SysProcessType(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    PPIB ppib=NULL;
    PTIB ptib=NULL;

    if (numargs)
    return INVALID_ROUTINE;

    DosGetInfoBlocks(&ptib,&ppib);

    sprintf(retstr->strptr,"%d",ppib->pib_ultype);
    retstr->strlength=1;
    return VALID_ROUTINE;
    }


    > SysSetProcessCodePage



    ULONG SysSetProcessCodePage(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    ULONG cp;

    if (numargs!=1)
    return INVALID_ROUTINE;

    if (!string2ulong(args[0].strptr,&cp))
    return INVALID_ROUTINE;

    sprintf(retstr->strptr,"%d",DosSetProcessCp(cp));
    retstr->strlength=strlen(retstr->strptr);
    return VALID_ROUTINE;
    }


    > SysWildCard (requires Warp 4 and beyond)


    Not tested yet.


    ULONG SysWildCard(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    UCHAR achTarget[MAX]="";

    if (numargs!=2)
    return INVALID_ROUTINE;

    if (!strlen(args[0].strptr))
    return INVALID_ROUTINE;

    if (DosEditName(1,args[0].strptr,args[1].strptr,achTarget,MAX))
    return INVALID_ROUTINE;

    sprintf(retstr->strptr,"%s",achTarget);
    retstr->strlength=strlen(retstr->strptr);
    return VALID_ROUTINE;
    }



    ---

  15. Re: RexxUtil.DLL

    On Tue, 01 Jan 2008 12:44:48 +0100, ML wrote:

    > sprintf(retstr->strptr,"%d",DosCloseEventSem(hev));


    > sprintf(retstr->strptr,"%d",ppib->pib_ultype);


    > sprintf(retstr->strptr,"%d",DosSetProcessCp(cp));


    I always wonder why people persistetly use %d with unsigned variables...
    Have you never heard of %u or what?

  16. Re: RexxUtil.DLL


    > Anyway, next ones up at my end: OS/2's Sys*Object*()-functions.


    That whole group of functions, that is, including Sys*Shadow*().
    Here's yet another Q&D one of those, SysCopyObject():


    ULONG SysCopyObject(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    HOBJECT hDest,hObject;

    if (numargs!=2)
    return INVALID_ROUTINE;

    retstr->strlength=1;

    hObject=WinQueryObject(args[0].strptr);
    if (hObject!=NULLHANDLE)
    {
    hDest=WinQueryObject(args[1].strptr);
    if (hDest!=NULLHANDLE)
    {
    if (WinCopyObject(hObject,hDest,CO_FAILIFEXISTS)!=NUL LHANDLE)
    {
    sprintf(retstr->strptr,"1");
    return VALID_ROUTINE;
    }
    }
    }

    sprintf(retstr->strptr,"0");
    return VALID_ROUTINE;
    }



    ---

  17. Re: RexxUtil.DLL


    > Anyway, next ones up at my end: OS/2's Sys*Object*()-functions.


    That whole group of functions, that is, including Sys*Shadow*().
    Here's yet another Q&D one of those, SysCopyObject():


    ULONG SysCopyObject(CHAR *name,ULONG numargs,RXSTRING args[],
    CHAR *queuename,RXSTRING *retstr)
    {
    HOBJECT hDest,hObject;

    if (numargs!=2)
    return INVALID_ROUTINE;

    retstr->strlength=1;

    hObject=WinQueryObject(args[0].strptr);
    if (hObject!=NULLHANDLE)
    {
    hDest=WinQueryObject(args[1].strptr);
    if (hDest!=NULLHANDLE)
    {
    if (WinCopyObject(hObject,hDest,CO_FAILIFEXISTS)!=NUL LHANDLE)
    {
    sprintf(retstr->strptr,"1");
    return VALID_ROUTINE;
    }
    }
    }

    sprintf(retstr->strptr,"0");
    return VALID_ROUTINE;
    }



    ---

  18. Re: RexxUtil.DLL


    >> SysStemSort will need work because of this:
    >> /* the sorting is done in the interpreter */


    > That may be related to memory usage


    Having to copy a huge stem to the DLLs memory.

    > and/or execution speed.


    ISTR using VariablePool() is limited to a certain number of elements
    per go (14xx?), and one clearly notices it's rather slow. Perhaps
    even slower than the possibly time-consuming sorting itself.



    ---

  19. Re: RexxUtil.DLL


    >> SysStemSort will need work because of this:
    >> /* the sorting is done in the interpreter */


    > That may be related to memory usage


    Having to copy a huge stem to the DLLs memory.

    > and/or execution speed.


    ISTR using VariablePool() is limited to a certain number of elements
    per go (14xx?), and one clearly notices it's rather slow. Perhaps
    even slower than the possibly time-consuming sorting itself.



    ---

  20. Re: RexxUtil.DLL

    On Tue, 1 Jan 2008 12:06:10 UTC, Paul Ratcliffe
    wrote:

    > On Tue, 01 Jan 2008 12:44:48 +0100, ML wrote:
    >
    > > sprintf(retstr->strptr,"%d",DosCloseEventSem(hev));

    >
    > > sprintf(retstr->strptr,"%d",ppib->pib_ultype);

    >
    > > sprintf(retstr->strptr,"%d",DosSetProcessCp(cp));

    >
    > I always wonder why people persistetly use %d with unsigned variables...
    > Have you never heard of %u or what?


    Not to mention the rather over-the-top:

    > sprintf(retstr->strptr,"1");


    Hasn't heard of strcpy either?

+ Reply to Thread
Page 3 of 6 FirstFirst 1 2 3 4 5 ... LastLast