#Rexx
Since Win NT is supposed to support full OS/2 emulation, I'd be surprised if it
didn't support Rexx. Or, we'll all be able to say MS lies. Besides, even if
it isn't noticable at this point, since the WinNT kernal is essentially OS/2
(there are apparently some error messages that were not cleaned up and still
have the OS/2 tags in them, I'm told) it is almost certain that either Rexx or
hooks for it are there already. And, as users get more used to multi-tasking,
they will after a language that can create external host processes to control
and pass a variety of data among several independent applications running at
the same time.
>>You put forth a good argument on the advantages of rexx over VB but this
>>is irrelevent if VB works (ie is implemented on the host OS) and REXX
>>isn't!
Once again, what I have said has nothing to do with emotional attachments you
et al may have to Basic (don't read this with negative tone of voice as it is
not intended with such). It is a technical fact that Basic and Rexx operate at
two different levels of the machine software heirarchy and are intended to do
two entirely differnt jobs. Since you do not understand the difference, no
amount of my explanations short of a course in operating systems technology
will elucidate well enough it for you so you will understand the technical hell
your proposal will create (or at best severe limitations causing about 90% of
what Rexx does best to be tossed: that is allowing only simple Basic plug-ins
to be run from a LW button instead of having complete control of LW via an
external command host).
But don't feel bad. Most everyone who hasn't programmed extensively for a
living, earned hefty degrees in CS, or gotten equivalent experience in Hard
Knox University, doesn't grasp the distinction either.
Now, many ARexx macros in LW are essentially like plug-ins, and since the newer
revs are supposed to support plug-ins, I suspect they will suppor any language
(but probably favor C) as long as the standard interface is presented to LW
from where the pluyg-in is invoked. However, many of us watn full Rexx support
so that we can write scripts to control LW externally to to jobs that may be
more efficient if automated rather than done manually with even repeated calls
to plug-ins.
BTW, just as an added thought, consider that IBM created Rexx for the mainframe
environment where they already had access to PL-I, Cobol, Algol, Basic,
Fortran, and BAL, not to mention good ole JCL and its MVS cousins. Because all
those create applications, or simple job control batch files instead of
interprocesses communication mechanisms, they made Rexx to do specifically what
all the programming and job control languages would not. It wasn't by accident
or happanstance. Rexx was created to address a need and there still is no
other tool in a multi-tasking environment that is as readily available and as
accessible as Rexx that I know of.
wmc – via Autopilot!