[Coco] CoCo TALK #18 an introduction to OS9

[Bill Nobel]

I definetly agree Bill, The system calls themselves are carved in stone.  Developers/Programmers need to use those calls more than just forking out a shell to do the same thing.  for example to do a tmode change one would use the SS.Opt cmd to I$Getstt on either of the standard paths change whatever you want then and do a I$SetStt, and away you go.

Bill Nobel
b_nobel at hotmail.com<mailto:b_nobel at hotmail.com>



On Jul 25, 2017, at 1:33 PM, Bill Pierce via Coco <coco at maltedmedia.com<mailto:coco at maltedmedia.com>> wrote:

I agree whole heartedly with Dave. Anyone can download or write their own custom cmds (there's plenty on RTSI), which then becomes a game changer, but the system calls are not going to change anytime soon. the way the call is handled may change, but the call itself is pretty much carved in stone now. Using a system call for something like tmode takes about the same space (or less) than the setup to call an external cmd. I've even thought of adding tmode, PWD & PXD to the OS9 C library (clib.l) as they are small and compact cmds.
In writing MShell, I wrote my own utilities and used system calls as much as possible. There are a few (and very few at that) exceptions, but for the most part, the MShell system will run on just about any NitrOS9 system out there with no additional cmds.
For the most part, the cmds in NitrOS9 that have changed ARE external to the system (and therefore can't be considered "part of the system", they are just cmds, see above). The system itself runs as OS9 did in 1987, just faster and better. There are even a couple of new system calls but all previous calls are preserved and function as the did in vanilla OS9.
Most of the changed cmds were derived from alt cmds from Delphi & CIS. I had the new tmode & dir many years before I ever ran NitrOS9 as I never had a 6309 and didn't run NitrOS9 until it was backported to the 6809.
I ran into the problems Wayne described even with old vanilla (or KD patched) OS9. I just had dual copies of each, the old & the new cmds, with extensions "*.old" & "*.new", which I would copy over the current cmd whenever I needed the alternate cmd. And this was in 1990, long befroe I ran NitrOS9. The first program I remember having problems with was Ultimuse3 which used the old tmode. I actually patched it to use the new one back then. Now, I've added an internal tmode (& pwd/pxd) to Ultimuse3 so that problem doesn't exist in Ultimuse3. It no longer relies on any external cmds.





Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page

E-Mail: ooogalapasooo at aol.com





-----Original Message-----
From: Allen Huffman <alsplace at pobox.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Tue, Jul 25, 2017 2:04 pm
Subject: Re: [Coco] CoCo TALK #18 an introduction to OS9

On Jul 25, 2017, at 12:47 PM, Dave Philipsen <dave at davebiz.com> wrote:> > Actually, in my opinion if you write a program that requires an external program (OS9 command) then you should probably be prepared for the fact that that external program could change in which case it would behoove you to include the external program with your distribution. And, if you find that you really do have a problem with such a program that calls an external program (like tmode and dir) then just use the older version of the program which behaves correctly with your program.Microware's official recommendation was to use external commands just this way, because internal OS structures could change with a future OS revision, but the command line options could be preserved. (This was true even in the OS-9/68K, 9000 days.)Thus, I used "tmode" in MiniBanners09. And it won't work as intended under NitrOS-9 because of the command change. -- A-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco

--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco