RexxUtil.DLL - OS2

This is a discussion on RexxUtil.DLL - OS2 ; On Sun, 16 Dec 2007 07:43:00 UTC, spamgate@hotmai1.com (Xynix) wrote: > >> Can eCS ship with an updated, backwards compatible RexxUtil.DLL? > > > I'm pretty certain we don't have the source code, so no, probably > > not. In ...

+ Reply to Thread
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 110

Thread: RexxUtil.DLL

  1. Re: RexxUtil.DLL

    On Sun, 16 Dec 2007 07:43:00 UTC, spamgate@hotmai1.com (Xynix) wrote:

    > >> Can eCS ship with an updated, backwards compatible RexxUtil.DLL?

    >
    > > I'm pretty certain we don't have the source code, so no, probably
    > > not. In any case...

    >
    > There are multiple copies of RexxUtil.C floating arround. If those
    > are not usable, a remake should be possible.


    Of the OS/2 version? Are you sure?


    > > ...what advantage would it have over providing new functions in
    > > another DLL?

    >
    > A disadvantage of more than a minimum number of DLLs is that those
    > extra DLLs are used far less frequently, starting with RxFtp.DLL,
    > while RexxUtil.DLL already is used in the typical app: Install.CMD


    And? Who cares how often you do or don't use them? Like any
    program, in REXX scripts you load the ones you need, and don't
    care about the others.

    All of the DLLs mentioned here so far are included in the OS
    anyway, so from a user perspective it's irrelevant.


    > More than one already increases the minimum number of DLLs, but I
    > do agree that it doesn't have to be limited to 1. And it does imply
    > that eCSRxLib.DLL then has to be the number 2, because otherwise
    > the mimimum number of such a concept increased to 3 by now. The
    > order above isn't fixed, because eCSRxLib.DLL also can include yet
    > another MyCls(), but the order is the most likely one. After all,
    > using RexxUtil.DLL is hard to avoid (e.g. SysFileTree()), but other
    > DLLs don't have that advantage.


    I'm not following you here.


    > Perhaps aiming at the #2 position, does that mean that eCSRxLib.DLL
    > will become a true library of functions/libraries, as complete as
    > reasonably possible, while keeping (the usual) quality in mind so
    > it isn't flooded with useless functions?


    I don't know.


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

    Please take off hat when replying.

  2. Re: RexxUtil.DLL

    On Sun, 16 Dec 2007 07:43:00 UTC, spamgate@hotmai1.com (Xynix) wrote:

    > >> Can eCS ship with an updated, backwards compatible RexxUtil.DLL?

    >
    > > I'm pretty certain we don't have the source code, so no, probably
    > > not. In any case...

    >
    > There are multiple copies of RexxUtil.C floating arround. If those
    > are not usable, a remake should be possible.


    Of the OS/2 version? Are you sure?


    > > ...what advantage would it have over providing new functions in
    > > another DLL?

    >
    > A disadvantage of more than a minimum number of DLLs is that those
    > extra DLLs are used far less frequently, starting with RxFtp.DLL,
    > while RexxUtil.DLL already is used in the typical app: Install.CMD


    And? Who cares how often you do or don't use them? Like any
    program, in REXX scripts you load the ones you need, and don't
    care about the others.

    All of the DLLs mentioned here so far are included in the OS
    anyway, so from a user perspective it's irrelevant.


    > More than one already increases the minimum number of DLLs, but I
    > do agree that it doesn't have to be limited to 1. And it does imply
    > that eCSRxLib.DLL then has to be the number 2, because otherwise
    > the mimimum number of such a concept increased to 3 by now. The
    > order above isn't fixed, because eCSRxLib.DLL also can include yet
    > another MyCls(), but the order is the most likely one. After all,
    > using RexxUtil.DLL is hard to avoid (e.g. SysFileTree()), but other
    > DLLs don't have that advantage.


    I'm not following you here.


    > Perhaps aiming at the #2 position, does that mean that eCSRxLib.DLL
    > will become a true library of functions/libraries, as complete as
    > reasonably possible, while keeping (the usual) quality in mind so
    > it isn't flooded with useless functions?


    I don't know.


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

    Please take off hat when replying.

  3. Re: RexxUtil.DLL


    >> There are multiple copies of RexxUtil.C floating arround. If those
    >> are not usable, a remake should be possible.


    > Of the OS/2 version? Are you sure?


    My remark concerning "usable" already suggests that I don't mean a
    "the" version. Obviously there's RexxUtil.C in the toolkit, which
    isn't complete, but contains a lot of usefull pointers. And if you
    really don't understand how some magic is done, RexxUtil.*'s from
    the ooRexx-sources may provide additional clues.

    For example, SysCopyObject() isn't included in my toolkit version.
    In this case typing "HELP REXX SYSCOPYOBJECT" provides the clues,
    so adding SysCopyObject() becomes very straightforward. Using all
    available sources, adding SysCopyObject() is a no-brainer, despite
    a "the" 100% matching source is missing.

    AFAIK the only special case is RxMessageBox(), but that one isn't
    a part of RexxUtil.DLL: you don't have to RxFuncAdd() it.

    I wasn't saying where you can find "the" OS/2 sources, but AFAICT
    the puzzle has no fatal missing parts, and the available sources do
    have a rather rich content (SysFileTree() for example, which isn't
    as easy as an one-on-one interface to the WinCopyObject()-API).
    That's why I'm referring to no-brainers, even I could reveil that
    API to Rexx without any showstopper in sight.

    >> A disadvantage of more than a minimum number of DLLs is that
    >> those extra DLLs are used far less frequently, starting with
    >> RxFtp.DLL, while RexxUtil.DLL already is used in the typical
    >> app: Install.CMD


    > And? Who cares how often you do or don't use them?


    That's not the point. The point is that there is a "the" Rexx DLL,
    and it's not likely that anything outside of that scope is used as
    often as the "the" Rexx DLL, regardless of both the usefullness and
    the quality of "a" Rexx DLL. You may think of it as a big, populair
    library versus several small bookshelfs. Fill those bookshelfs with
    any book you like, but chances are it won't attract a visitor. And
    if I know your bookshelf is worth looking at, chances are I won't
    use your facility because I cannot be sure all users have the same
    books to their availability.

    > All of the DLLs mentioned here so far are included in the OS
    > anyway, so from a user perspective it's irrelevant.


    All Rexx DLLs are irrelevant for users, but I'm pretty sure users
    have a copy of RexxUtil.DLL installed. I cannot assume the same of
    any other Rexx DLL not shipped with the OS (or not well-known, but
    that already would be an exceptional situation, e.g. a VRObj.DLL).

    > I'm not following you here.


    You mentioned another Rexx DLL, which is just a "yet another DLL",
    just like the ones in e.g. REXXMATH.ZIP, RXANSI.ZIP, RXDATE20.ZIP,
    and so on. Those DLLs hardly have real users, not counting authors.

    I've written several DLLs which have real users not related to me,
    e.g. used by IBM and Mensys. I guess SysDropRexxMacro() has fewer
    users, but SysDropRexxMacro() will be far better known than any of
    my DLLs, just because it's included in RexxUtil.DLL. Please note I'm
    not advocating nor mentioning my own DLLs, but right now those too
    are just a "just another DLL". Assuming such DLLs have an use, it's
    a kind of shame to hide those, and to not include those functions
    in "the" DLL.

    Sure, some missing "yet another DLL" can be detected, and the user
    can be pointed to a download and install. "From users perspective
    it's irrelevant". So whay not add functions with a certain quality
    to "the" DLL? If not, writing a function which e.g. gives access to
    the OS API's basicly comes down to a waist of time. Actually there
    is more than one "the" DLL, but not much. All other DLLs, including
    the eCS-on you mentioned earlier, will most likely become a "yet
    another DLL", in a way ignoring added values of a larger library,
    and IRL those DLLs have a high risk of being ignored too.

    So: why not modernize RexxUtil.DLL? And why not add other usefull
    functions to it, other that obvious ones like SysFileCopy()? I did
    mention a spreadsheet-like grouping before. ooRexx covers SysPi(),
    but without caring that much about math I can think of many more
    Math*()-functions which are worth more attention that such a "yet
    another DLL" would get. When included in a "the" DLL, both authors
    and users can apply an irrelevant perspective w.r.t. requiring "yet
    another DLL", and perhaps we'll get to see more Rexx apps beyond
    typical Install.CMD's.

    If you want to expose usefull functions, to promote usage, you'll
    have to obtain a high ranking. In my book RexxUtil.DLL is #1, and
    IRL it's not possible to achieve anything higher than about #5 for
    "yet another Rexx DLL". Who notices #5, and who has installed #5
    (and many more, lower down the list of Rexx DLLs)? And after all,
    the #1 is a kind of library, so store a few good books there.



    ---

  4. Re: RexxUtil.DLL


    >> There are multiple copies of RexxUtil.C floating arround. If those
    >> are not usable, a remake should be possible.


    > Of the OS/2 version? Are you sure?


    My remark concerning "usable" already suggests that I don't mean a
    "the" version. Obviously there's RexxUtil.C in the toolkit, which
    isn't complete, but contains a lot of usefull pointers. And if you
    really don't understand how some magic is done, RexxUtil.*'s from
    the ooRexx-sources may provide additional clues.

    For example, SysCopyObject() isn't included in my toolkit version.
    In this case typing "HELP REXX SYSCOPYOBJECT" provides the clues,
    so adding SysCopyObject() becomes very straightforward. Using all
    available sources, adding SysCopyObject() is a no-brainer, despite
    a "the" 100% matching source is missing.

    AFAIK the only special case is RxMessageBox(), but that one isn't
    a part of RexxUtil.DLL: you don't have to RxFuncAdd() it.

    I wasn't saying where you can find "the" OS/2 sources, but AFAICT
    the puzzle has no fatal missing parts, and the available sources do
    have a rather rich content (SysFileTree() for example, which isn't
    as easy as an one-on-one interface to the WinCopyObject()-API).
    That's why I'm referring to no-brainers, even I could reveil that
    API to Rexx without any showstopper in sight.

    >> A disadvantage of more than a minimum number of DLLs is that
    >> those extra DLLs are used far less frequently, starting with
    >> RxFtp.DLL, while RexxUtil.DLL already is used in the typical
    >> app: Install.CMD


    > And? Who cares how often you do or don't use them?


    That's not the point. The point is that there is a "the" Rexx DLL,
    and it's not likely that anything outside of that scope is used as
    often as the "the" Rexx DLL, regardless of both the usefullness and
    the quality of "a" Rexx DLL. You may think of it as a big, populair
    library versus several small bookshelfs. Fill those bookshelfs with
    any book you like, but chances are it won't attract a visitor. And
    if I know your bookshelf is worth looking at, chances are I won't
    use your facility because I cannot be sure all users have the same
    books to their availability.

    > All of the DLLs mentioned here so far are included in the OS
    > anyway, so from a user perspective it's irrelevant.


    All Rexx DLLs are irrelevant for users, but I'm pretty sure users
    have a copy of RexxUtil.DLL installed. I cannot assume the same of
    any other Rexx DLL not shipped with the OS (or not well-known, but
    that already would be an exceptional situation, e.g. a VRObj.DLL).

    > I'm not following you here.


    You mentioned another Rexx DLL, which is just a "yet another DLL",
    just like the ones in e.g. REXXMATH.ZIP, RXANSI.ZIP, RXDATE20.ZIP,
    and so on. Those DLLs hardly have real users, not counting authors.

    I've written several DLLs which have real users not related to me,
    e.g. used by IBM and Mensys. I guess SysDropRexxMacro() has fewer
    users, but SysDropRexxMacro() will be far better known than any of
    my DLLs, just because it's included in RexxUtil.DLL. Please note I'm
    not advocating nor mentioning my own DLLs, but right now those too
    are just a "just another DLL". Assuming such DLLs have an use, it's
    a kind of shame to hide those, and to not include those functions
    in "the" DLL.

    Sure, some missing "yet another DLL" can be detected, and the user
    can be pointed to a download and install. "From users perspective
    it's irrelevant". So whay not add functions with a certain quality
    to "the" DLL? If not, writing a function which e.g. gives access to
    the OS API's basicly comes down to a waist of time. Actually there
    is more than one "the" DLL, but not much. All other DLLs, including
    the eCS-on you mentioned earlier, will most likely become a "yet
    another DLL", in a way ignoring added values of a larger library,
    and IRL those DLLs have a high risk of being ignored too.

    So: why not modernize RexxUtil.DLL? And why not add other usefull
    functions to it, other that obvious ones like SysFileCopy()? I did
    mention a spreadsheet-like grouping before. ooRexx covers SysPi(),
    but without caring that much about math I can think of many more
    Math*()-functions which are worth more attention that such a "yet
    another DLL" would get. When included in a "the" DLL, both authors
    and users can apply an irrelevant perspective w.r.t. requiring "yet
    another DLL", and perhaps we'll get to see more Rexx apps beyond
    typical Install.CMD's.

    If you want to expose usefull functions, to promote usage, you'll
    have to obtain a high ranking. In my book RexxUtil.DLL is #1, and
    IRL it's not possible to achieve anything higher than about #5 for
    "yet another Rexx DLL". Who notices #5, and who has installed #5
    (and many more, lower down the list of Rexx DLLs)? And after all,
    the #1 is a kind of library, so store a few good books there.



    ---

  5. Re: RexxUtil.DLL


    > Well, I dropped CREXX years ago


    And I'm using (the better) ORexx interpreter to interprete CRexx
    code. The group actually using O is quite small, but I do have to
    add that being able to use about the same code and new features
    (OOP, amongst others) everywhere is a plus for ooRexx.

    > so for Serenity to invest in enhancing it doesn't do anything
    > for me unless they enhance OREXX as a byproduct.


    I wouldn't mind paying for a port of ooRexx, as a byproduct too.
    It's nice to have a better and maintainable (O)Rexx interpreter,
    but there still will be more important investments than that. It
    may require an extra-ordinairy effort to obtain a newer (O)Rexx
    interpreter, and so far there's no sign of that happening.

    > but for OS/2 I want OREXX or OOREXX


    There's no need to replace the existing Rexx interpreters as such,
    and a reality check may learn that ooRexx can be ported. But it's
    not likely to happen, at least in the foreseeable future. Updating
    just RexxUtil.DLL isn't that important, but it's something that is
    possible in the foreseeable future. Provided any improvement is
    reasonably shipped with and embedded in eCS, because otherwise
    it would just be "yet another (stand-alone) Rexx DLL/interpreter"
    with a few users. Besides that, a coordinated effort prevents the
    birth of many versions of e.g. RexxUtil.DLL-replacements. Please
    also note that updating RexxUtil.DLL doesn't stop the development
    of any new or updated interpreter, so there's hardly a reason to
    wait for a new or updated interpreter. E.g. SysFileCopy() can be
    "added" to RexxUtil.DLL by tomorrow. That's progress, albeit it's
    certainly not taking care of all possible wishes people may have
    w.r.t. [[o]O]Rexx[/2]-interpreters.



    ---

  6. Re: RexxUtil.DLL


    > Well, I dropped CREXX years ago


    And I'm using (the better) ORexx interpreter to interprete CRexx
    code. The group actually using O is quite small, but I do have to
    add that being able to use about the same code and new features
    (OOP, amongst others) everywhere is a plus for ooRexx.

    > so for Serenity to invest in enhancing it doesn't do anything
    > for me unless they enhance OREXX as a byproduct.


    I wouldn't mind paying for a port of ooRexx, as a byproduct too.
    It's nice to have a better and maintainable (O)Rexx interpreter,
    but there still will be more important investments than that. It
    may require an extra-ordinairy effort to obtain a newer (O)Rexx
    interpreter, and so far there's no sign of that happening.

    > but for OS/2 I want OREXX or OOREXX


    There's no need to replace the existing Rexx interpreters as such,
    and a reality check may learn that ooRexx can be ported. But it's
    not likely to happen, at least in the foreseeable future. Updating
    just RexxUtil.DLL isn't that important, but it's something that is
    possible in the foreseeable future. Provided any improvement is
    reasonably shipped with and embedded in eCS, because otherwise
    it would just be "yet another (stand-alone) Rexx DLL/interpreter"
    with a few users. Besides that, a coordinated effort prevents the
    birth of many versions of e.g. RexxUtil.DLL-replacements. Please
    also note that updating RexxUtil.DLL doesn't stop the development
    of any new or updated interpreter, so there's hardly a reason to
    wait for a new or updated interpreter. E.g. SysFileCopy() can be
    "added" to RexxUtil.DLL by tomorrow. That's progress, albeit it's
    certainly not taking care of all possible wishes people may have
    w.r.t. [[o]O]Rexx[/2]-interpreters.



    ---

  7. Re: RexxUtil.DLL

    Hi all

    Just out of interest I have managed to get the source from Rexx la
    for some extra utils functions and should be releasing it before xmas

    function include these

    LoadWxFuncs
    DropWxFuncs
    WxGetCrc
    WxVersion
    WxFileCopy
    WxFileMove
    WxFileExist
    WxDirExist
    WxQFullName


    I have managed to compile it under watcom 1.7 and so far it seems to
    work ok, the main problems in terms of totally re- writing the rexxutils
    package is that only part of that package was included in the os/2
    toolkit, and the OORExx version has striped most of the OS/2
    stuff from the source. I will have another look at it later but it will
    take time, as for the porting of Object Rexx back to OS/2 I started a
    group up on source forge, but need some helpers pref with c and c++
    programming skills

    Hope this helped

    Regards

    Adrian Suri

  8. Re: RexxUtil.DLL

    Hi all

    Just out of interest I have managed to get the source from Rexx la
    for some extra utils functions and should be releasing it before xmas

    function include these

    LoadWxFuncs
    DropWxFuncs
    WxGetCrc
    WxVersion
    WxFileCopy
    WxFileMove
    WxFileExist
    WxDirExist
    WxQFullName


    I have managed to compile it under watcom 1.7 and so far it seems to
    work ok, the main problems in terms of totally re- writing the rexxutils
    package is that only part of that package was included in the os/2
    toolkit, and the OORExx version has striped most of the OS/2
    stuff from the source. I will have another look at it later but it will
    take time, as for the porting of Object Rexx back to OS/2 I started a
    group up on source forge, but need some helpers pref with c and c++
    programming skills

    Hope this helped

    Regards

    Adrian Suri

  9. Re: RexxUtil.DLL


    > WxFileMove


    Including allowing for WxFileMove('C:\Source.CPP','D:\Source.BAK'),
    which AFAIK CMD.EXE's "MOVE" doesn't support (not that important,
    but then it'ld be a better move than MOVE ;-))?

    > the main problems in terms of totally re- writing the rexxutils
    > package is that only part of that package was included in the
    > os/2 toolkit, and the OORExx version has striped most of the OS/2
    > stuff from the source.


    Documentation perhaps is another minor issue because "the" Rexx DLL
    is included in "the" Rexx documentation, Rexx.INF. That promotes a
    more wide-spread use of it, but OTOH real users don't require that
    status. If needed, a RexxUtil.INF could do, I'ld say.

    > I will have another look at it later but it will take time


    I may have a look at it sooner, but that could take more time and I
    may not be looking forward to "calling the shots". If so, I'm still
    thinking about (a) remake, (b) add all usefull newer RexxUtil.DLL-
    functions and (c) add more goodies to it, probably segmented (both
    w.r.t. functions names and LoadFunc'ability, dunno). While assuming
    (d), supporting CRrexx is more important than also supporting ORexx
    (but that doesn't mean ignoring ORexx, it's a priority issue).

    As far as (c) still isn't clear enough, search for "Rexx" at e.g.
    sourceforge.net. Many of the projects found seem to be Rexx DLLs,
    but I doubt "the average user" has over 10% of those (well-known)
    Rexx DLLs installed. Like I said, why's SysDropRexxMacro() a part
    of "the" Rexx DLL, while e.g. SysFileMove() isn't?

    > as for the porting of Object Rexx back to OS/2 I started a group
    > up on source forge, but need some helpers pref with c and c++
    > programming skills


    If needed, some kind of plan could help. It's a port, and there are
    newsgroups related to that. Is it likely to be an one-off effort, or
    is keeping up with ooRexx a goal? If so, will portability (to OS/2,
    obviously) be kept in mind from now on, as good as possible that is?
    Will the final result become the 3rd option of SwitchRx.CMD, or is
    it lileky that it'll become "yet another interpreter" a few people
    will use? Is there a level of active (!) RexxLA-support available?
    Is the *ux- or the Windows-version of the source? Which (specific)
    problems are expected to be encountered, and what problems showed
    during earlier attempts (e.g. the one Rony mentioned a while ago)?
    If it matters, what's why the compiler of choice w.r.t. ooRexx? Is
    it dividable in smaller parts, just like RexxUtil.DLL can be looked
    at as a separatable, kind of stand-alone part of the whole package?

    FWIW, I'm not a C & C++ programmer, so it may not be a good idea to
    combine a certain learning curve with something I rated as being not
    a no-brainer.

    > Hope this helped


    Sure! Now even empty sourceforge.net-projects are evidence of that
    being the best effort so far, not counting a few nice words w.r.t.
    non-existing OS/2-versions of ooRexx.... :-)



    ---

  10. Re: RexxUtil.DLL


    > WxFileMove


    Including allowing for WxFileMove('C:\Source.CPP','D:\Source.BAK'),
    which AFAIK CMD.EXE's "MOVE" doesn't support (not that important,
    but then it'ld be a better move than MOVE ;-))?

    > the main problems in terms of totally re- writing the rexxutils
    > package is that only part of that package was included in the
    > os/2 toolkit, and the OORExx version has striped most of the OS/2
    > stuff from the source.


    Documentation perhaps is another minor issue because "the" Rexx DLL
    is included in "the" Rexx documentation, Rexx.INF. That promotes a
    more wide-spread use of it, but OTOH real users don't require that
    status. If needed, a RexxUtil.INF could do, I'ld say.

    > I will have another look at it later but it will take time


    I may have a look at it sooner, but that could take more time and I
    may not be looking forward to "calling the shots". If so, I'm still
    thinking about (a) remake, (b) add all usefull newer RexxUtil.DLL-
    functions and (c) add more goodies to it, probably segmented (both
    w.r.t. functions names and LoadFunc'ability, dunno). While assuming
    (d), supporting CRrexx is more important than also supporting ORexx
    (but that doesn't mean ignoring ORexx, it's a priority issue).

    As far as (c) still isn't clear enough, search for "Rexx" at e.g.
    sourceforge.net. Many of the projects found seem to be Rexx DLLs,
    but I doubt "the average user" has over 10% of those (well-known)
    Rexx DLLs installed. Like I said, why's SysDropRexxMacro() a part
    of "the" Rexx DLL, while e.g. SysFileMove() isn't?

    > as for the porting of Object Rexx back to OS/2 I started a group
    > up on source forge, but need some helpers pref with c and c++
    > programming skills


    If needed, some kind of plan could help. It's a port, and there are
    newsgroups related to that. Is it likely to be an one-off effort, or
    is keeping up with ooRexx a goal? If so, will portability (to OS/2,
    obviously) be kept in mind from now on, as good as possible that is?
    Will the final result become the 3rd option of SwitchRx.CMD, or is
    it lileky that it'll become "yet another interpreter" a few people
    will use? Is there a level of active (!) RexxLA-support available?
    Is the *ux- or the Windows-version of the source? Which (specific)
    problems are expected to be encountered, and what problems showed
    during earlier attempts (e.g. the one Rony mentioned a while ago)?
    If it matters, what's why the compiler of choice w.r.t. ooRexx? Is
    it dividable in smaller parts, just like RexxUtil.DLL can be looked
    at as a separatable, kind of stand-alone part of the whole package?

    FWIW, I'm not a C & C++ programmer, so it may not be a good idea to
    combine a certain learning curve with something I rated as being not
    a no-brainer.

    > Hope this helped


    Sure! Now even empty sourceforge.net-projects are evidence of that
    being the best effort so far, not counting a few nice words w.r.t.
    non-existing OS/2-versions of ooRexx.... :-)



    ---

  11. Re: RexxUtil.DLL

    Adrian Suri wrote:
    > Hi all
    >
    > Just out of interest I have managed to get the source from Rexx la
    > for some extra utils functions and should be releasing it before xmas
    >
    > function include these
    >
    > LoadWxFuncs
    > DropWxFuncs
    > WxGetCrc
    > WxVersion
    > WxFileCopy
    > WxFileMove
    > WxFileExist
    > WxDirExist
    > WxQFullName
    >
    >
    > I have managed to compile it under watcom 1.7 and so far it seems to
    > work ok, the main problems in terms of totally re- writing the rexxutils
    > package is that only part of that package was included in the os/2
    > toolkit, and the OORExx version has striped most of the OS/2
    > stuff from the source. I will have another look at it later but it will
    > take time, as for the porting of Object Rexx back to OS/2 I started a
    > group up on source forge, but need some helpers pref with c and c++
    > programming skills
    >
    > Hope this helped
    >
    > Regards
    >
    > Adrian Suri


    Adrian,

    Sure most of the toolkit rexxutil is missing but are simple enough to
    recreate.

    Mike

  12. Re: RexxUtil.DLL

    Adrian Suri wrote:
    > Hi all
    >
    > Just out of interest I have managed to get the source from Rexx la
    > for some extra utils functions and should be releasing it before xmas
    >
    > function include these
    >
    > LoadWxFuncs
    > DropWxFuncs
    > WxGetCrc
    > WxVersion
    > WxFileCopy
    > WxFileMove
    > WxFileExist
    > WxDirExist
    > WxQFullName
    >
    >
    > I have managed to compile it under watcom 1.7 and so far it seems to
    > work ok, the main problems in terms of totally re- writing the rexxutils
    > package is that only part of that package was included in the os/2
    > toolkit, and the OORExx version has striped most of the OS/2
    > stuff from the source. I will have another look at it later but it will
    > take time, as for the porting of Object Rexx back to OS/2 I started a
    > group up on source forge, but need some helpers pref with c and c++
    > programming skills
    >
    > Hope this helped
    >
    > Regards
    >
    > Adrian Suri


    Adrian,

    Sure most of the toolkit rexxutil is missing but are simple enough to
    recreate.

    Mike

  13. Re: RexxUtil.DLL


    > Sure most of the toolkit rexxutil is missing but are simple enough
    > to recreate.


    Working on it. Below is a(n OS/2-) list of differences, according to
    the documentation. None of the functions mentioned are included in
    the toolkit example. Most missing ones are related to a single API
    function, e.g. SysAddFileHandle() equals DosSetRelMaxFH().

    Also included is a list of differences w.r.t. ooRexx's documentation.
    The provided RexxLA-documentation is outdated and not complete. Never
    functions show more issues, typically due to design or the assumption
    of Windows. I'ld avoided SysWinFileEncrypt(), used SysFileEncrypt()
    instead and with omitted 2nd(+) paramaters assume the default method
    of encryption. Portability hasn't been kept in mind at all, I guess,
    just like the Windows-documentation provides no clue about how a
    SysLinVer() could be ported fom Linux-ooRexx to Windows-ooRexx (with
    SysFork() being documented, it's not aimed at Windows) and a generic
    replacing attempt SysVersion() may have no reliably PARSE'able output
    format ("PARSE VALUE SysVersion() WITH os version" won't do). But
    nevertheless this also typically involves no-brainers, e.g. giving
    access to a C function (e.g. SysCos() -> cos(), undocumented). Names
    may be a bit messy too, e.g. SysGetFileDateTime() instead of the more
    obvious (SysFile*()-organized) SysFileGetDateTime(). Perhaps that's
    also an example of a function not adding that much to Rexx, Stream()
    and SysFileTree() already come pretty close to its result. O, well.
    This are the documented differences (typo's possible), 2 lists:


    In CRexx In ORexx
    ======================== ==========================
    SysAddFileHandle
    SysAddRexxMacro
    SysBootDrive
    SysClearRexxMacroSpace
    SysCloseEventSem
    SysCloseMutexSem
    SysCopyObject SysCopyObject
    SysCreateEventSem
    SysCreateMutexSem
    SysCreateObject SysCreateObject
    SysCreateShadow SysCreateShadow
    SysDeregisterObjectClass SysDeregisterObjectClass
    SysDestroyObject SysDestroyObject
    SysDropRexxMacro
    SysElapsedTime
    SysFileSystemType
    SysGetCollate
    SysGetKey SysGetKey
    SysLoadRexxMacroSpace
    SysMapCase
    SysMoveObject SysMoveObject
    SysNationalLanguageCompare
    SysOpenEventSem
    SysOpenMutexSem
    SysOpenObject SysOpenObject
    SysPostEventSem
    SysProcessType
    SysQueryClassList SysQueryClassList
    SysQueryEAList
    SysQueryProcessCodePage
    SysQueryRexxMacro
    SysRegisterObjectClass SysRegisterObjectClass
    SysReleaseMutexSem
    SysReorderRexxMacro
    SysRequestMutexSem
    SysResetEventSem
    SysSaveObject SysSaveObject
    SysSaveRexxMacroSpace
    SysSetFileHandle
    SysSetIcon SysSetIcon
    SysSetObjectData SysSetObjectData
    SysSetPriority
    SysSetProcessCodePage
    SysShutDownSystem
    SysWaitEventSem
    SysWaitForShell
    SysWildCard


    In ORexx In ooRexx
    ========================== ==========================
    SysAddFileHandle
    SysCopyObject
    SysCreateObject
    SysCreateShadow
    SysDeregisterObjectClass
    SysDestroyObject
    SysElapsedTime
    SysGetCollate
    SysGetEA
    SysMapCase
    SysMoveObject
    SysNationalLanguageCompare
    SysOpenObject
    SysOS2Ver
    SysProcessType
    SysPutEA
    SysQueryClassList
    SysQueryEAList
    SysQueryProcessCodePage
    SysRegisterObjectClass
    SysSaveObject
    SysSetFileHandle
    SysSetIcon
    SysSetObjectData
    SysSetProcessCodePage
    SysShutDownSystem
    SysWaitForShell
    SysWildCard
    RxWinExec
    SysCreatePipe
    SysDumpVariables
    SysFileCopy
    SysFileMove
    SysFork
    SysFromUnicode
    SysGetErrortext
    SysGetFileDateTime
    SysGetMessageX
    SysIsFile
    SysIsFileCompressed
    SysIsFileDirectory
    SysIsFileEncrypted
    SysIsFileLink
    SysIsFileNotContentIndexed
    SysIsFileOffline
    SysIsFileSparse
    SysIsFileTemporary
    SysPulseEventSem
    SysQueryProcess
    SysSetFileDateTime
    SysShutDownSystem
    SysStemCopy
    SysStemDelete
    SysStemInsert
    SysStemSort
    SysSwitchSession
    SysSystemDirectory
    SysToUnicode
    SysUtilVersion
    SysVersion
    SysWait
    SysWinDecryptFile
    SysWinEncryptFile
    SysWinGetDefaultPrinter
    SysWinGetPrinters
    SysWinSetDefaultPrinter
    SysWinVer



    ---

  14. Re: RexxUtil.DLL


    > Sure most of the toolkit rexxutil is missing but are simple enough
    > to recreate.


    Working on it. Below is a(n OS/2-) list of differences, according to
    the documentation. None of the functions mentioned are included in
    the toolkit example. Most missing ones are related to a single API
    function, e.g. SysAddFileHandle() equals DosSetRelMaxFH().

    Also included is a list of differences w.r.t. ooRexx's documentation.
    The provided RexxLA-documentation is outdated and not complete. Never
    functions show more issues, typically due to design or the assumption
    of Windows. I'ld avoided SysWinFileEncrypt(), used SysFileEncrypt()
    instead and with omitted 2nd(+) paramaters assume the default method
    of encryption. Portability hasn't been kept in mind at all, I guess,
    just like the Windows-documentation provides no clue about how a
    SysLinVer() could be ported fom Linux-ooRexx to Windows-ooRexx (with
    SysFork() being documented, it's not aimed at Windows) and a generic
    replacing attempt SysVersion() may have no reliably PARSE'able output
    format ("PARSE VALUE SysVersion() WITH os version" won't do). But
    nevertheless this also typically involves no-brainers, e.g. giving
    access to a C function (e.g. SysCos() -> cos(), undocumented). Names
    may be a bit messy too, e.g. SysGetFileDateTime() instead of the more
    obvious (SysFile*()-organized) SysFileGetDateTime(). Perhaps that's
    also an example of a function not adding that much to Rexx, Stream()
    and SysFileTree() already come pretty close to its result. O, well.
    This are the documented differences (typo's possible), 2 lists:


    In CRexx In ORexx
    ======================== ==========================
    SysAddFileHandle
    SysAddRexxMacro
    SysBootDrive
    SysClearRexxMacroSpace
    SysCloseEventSem
    SysCloseMutexSem
    SysCopyObject SysCopyObject
    SysCreateEventSem
    SysCreateMutexSem
    SysCreateObject SysCreateObject
    SysCreateShadow SysCreateShadow
    SysDeregisterObjectClass SysDeregisterObjectClass
    SysDestroyObject SysDestroyObject
    SysDropRexxMacro
    SysElapsedTime
    SysFileSystemType
    SysGetCollate
    SysGetKey SysGetKey
    SysLoadRexxMacroSpace
    SysMapCase
    SysMoveObject SysMoveObject
    SysNationalLanguageCompare
    SysOpenEventSem
    SysOpenMutexSem
    SysOpenObject SysOpenObject
    SysPostEventSem
    SysProcessType
    SysQueryClassList SysQueryClassList
    SysQueryEAList
    SysQueryProcessCodePage
    SysQueryRexxMacro
    SysRegisterObjectClass SysRegisterObjectClass
    SysReleaseMutexSem
    SysReorderRexxMacro
    SysRequestMutexSem
    SysResetEventSem
    SysSaveObject SysSaveObject
    SysSaveRexxMacroSpace
    SysSetFileHandle
    SysSetIcon SysSetIcon
    SysSetObjectData SysSetObjectData
    SysSetPriority
    SysSetProcessCodePage
    SysShutDownSystem
    SysWaitEventSem
    SysWaitForShell
    SysWildCard


    In ORexx In ooRexx
    ========================== ==========================
    SysAddFileHandle
    SysCopyObject
    SysCreateObject
    SysCreateShadow
    SysDeregisterObjectClass
    SysDestroyObject
    SysElapsedTime
    SysGetCollate
    SysGetEA
    SysMapCase
    SysMoveObject
    SysNationalLanguageCompare
    SysOpenObject
    SysOS2Ver
    SysProcessType
    SysPutEA
    SysQueryClassList
    SysQueryEAList
    SysQueryProcessCodePage
    SysRegisterObjectClass
    SysSaveObject
    SysSetFileHandle
    SysSetIcon
    SysSetObjectData
    SysSetProcessCodePage
    SysShutDownSystem
    SysWaitForShell
    SysWildCard
    RxWinExec
    SysCreatePipe
    SysDumpVariables
    SysFileCopy
    SysFileMove
    SysFork
    SysFromUnicode
    SysGetErrortext
    SysGetFileDateTime
    SysGetMessageX
    SysIsFile
    SysIsFileCompressed
    SysIsFileDirectory
    SysIsFileEncrypted
    SysIsFileLink
    SysIsFileNotContentIndexed
    SysIsFileOffline
    SysIsFileSparse
    SysIsFileTemporary
    SysPulseEventSem
    SysQueryProcess
    SysSetFileDateTime
    SysShutDownSystem
    SysStemCopy
    SysStemDelete
    SysStemInsert
    SysStemSort
    SysSwitchSession
    SysSystemDirectory
    SysToUnicode
    SysUtilVersion
    SysVersion
    SysWait
    SysWinDecryptFile
    SysWinEncryptFile
    SysWinGetDefaultPrinter
    SysWinGetPrinters
    SysWinSetDefaultPrinter
    SysWinVer



    ---

  15. Re: RexxUtil.DLL


    > Never functions show more issues


    Please read "Those (ooRexx-)" instead of "Never".



    ---

  16. Re: RexxUtil.DLL


    > Never functions show more issues


    Please read "Those (ooRexx-)" instead of "Never".



    ---

  17. Re: RexxUtil.DLL


    > Below is a(n OS/2-) list of differences


    Another minor issue, when using the toolkit source code as-is as a
    starting point for a remake: the Y2K-related RexxUtil.DLL changes



    ---

  18. Re: RexxUtil.DLL


    > Below is a(n OS/2-) list of differences


    Another minor issue, when using the toolkit source code as-is as a
    starting point for a remake: the Y2K-related RexxUtil.DLL changes



    ---

  19. Re: RexxUtil.DLL

    ML wrote:
    > > Sure most of the toolkit rexxutil is missing but are simple enough
    > > to recreate.

    >
    > Working on it. Below is a(n OS/2-) list of differences, according to
    > the documentation. None of the functions mentioned are included in
    > the toolkit example. Most missing ones are related to a single API
    > function, e.g. SysAddFileHandle() equals DosSetRelMaxFH().


    --snip

    Ok, I play with this a little for fun. I just cleaned up what I have:

    static char *RxFncTable[ ] = {
    RXLIBNAME,
    "SysDropFuncs",
    "SysLoadFuncs",
    "SysCls",
    "SysCurPos",
    "SysCurState",
    "SysSleep",
    "SysOS2Ver",
    "SysVersion",
    "SysUtilVersion",
    "SysFileDelete",
    "SysMkDir",
    "SysRmDir",
    "SysTempFileName",
    "SysTextScreenSize",
    "SysTextScreenRead",
    "SysBootDrive",
    "SysDriveInfo",
    "SysDriveMap",
    "SysGetMessage",
    "SysGetEA",
    "SysPutEA"
    };

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

    Mike

  20. Re: RexxUtil.DLL

    ML wrote:
    > > Sure most of the toolkit rexxutil is missing but are simple enough
    > > to recreate.

    >
    > Working on it. Below is a(n OS/2-) list of differences, according to
    > the documentation. None of the functions mentioned are included in
    > the toolkit example. Most missing ones are related to a single API
    > function, e.g. SysAddFileHandle() equals DosSetRelMaxFH().


    --snip

    Ok, I play with this a little for fun. I just cleaned up what I have:

    static char *RxFncTable[ ] = {
    RXLIBNAME,
    "SysDropFuncs",
    "SysLoadFuncs",
    "SysCls",
    "SysCurPos",
    "SysCurState",
    "SysSleep",
    "SysOS2Ver",
    "SysVersion",
    "SysUtilVersion",
    "SysFileDelete",
    "SysMkDir",
    "SysRmDir",
    "SysTempFileName",
    "SysTextScreenSize",
    "SysTextScreenRead",
    "SysBootDrive",
    "SysDriveInfo",
    "SysDriveMap",
    "SysGetMessage",
    "SysGetEA",
    "SysPutEA"
    };

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

    Mike

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