rosenman@godot.radonc.unc.edu (Julian Rosenman) (11/10/89)
I am both a new IIGS owner and a new user of comp.sys.apple so I'm probably going to ask some dumb questions, but here goes... 1) If you boot up GS/OS and click on BASIC.SYSTEM you then go into the AppleSoft environment. How do you get back to the OS without rebooting the system? (I've tried "brunning" all the system files with no luck. The documentation is silent on this issue). 2) Why can't GS/OS read DOS 3.3 files and just display them like ProDos files? Is there a utility that does this, or do I have to convert them all to ProDos 16 to view them on the desk top? 3) What programming language is recommended for the IIGS? AppleSoft is clearly inadequate as it does not support the sound chip, super hires screen, tool box, extended memory etc. Do any of the commercial BASIC's support these things? Which would you recommend? 4) Can the perimeter of the color monitor be altered (other than background color)?
delaneyg@wnre.aecl.CDN ("H. Grant Delaney") (11/10/89)
>Organization: Radiation Oncology NCMH/UNC, Chapel Hill, NC
I am both a new IIGS owner and a new user of comp.sys.apple so I'm
probably going to ask some dumb questions, but here goes...
1) If you boot up GS/OS and click on BASIC.SYSTEM you then go into
the AppleSoft environment. How do you get back to the OS without
rebooting the system? (I've tried "brunning" all the system files with
no luck. The documentation is silent on this issue).
Easier yet type BYE at the ]
2) Why can't GS/OS read DOS 3.3 files and just display them like
ProDos files? Is there a utility that does this, or do I have to
convert them all to ProDos 16 to view them on the desk top?
It can but you have to boot DOS 3.3 or convert them to ProDOS the disk
format is quite different.
3) What programming language is recommended for the IIGS? AppleSoft is
clearly inadequate as it does not support the sound chip, super hires
screen, tool box, extended memory etc. Do any of the commercial
BASIC's support these things? Which would you recommend?
There are 3 GS Basics TML Basic (somewhat outdated update due in next year)
MICOL ADVANCED BASIC Very good
AC BASIC like Microsoft Basic good as well but not as popular
TML PASCAL II Just released supports all the new things
APW BASIC Apples owm
ORCA PASCAL Nice environment My Favorite Pascal though TML close second
ORCA C New Release due next month several serious bugs in first release
APW C Apples C
4) Can the perimeter of the color monitor be altered (other than
background color)?
With the right Public domain Utilities Virtully anything I have a picture
for a background and clock in the menus bar etc etc etc.
grant
.dlyons@Apple.COM (David Lyons) (11/10/89)
In article <1134@godot.radonc.unc.edu> rosenman@godot.UUCP (Julian Rosenman) writes: >[...] >1) If you boot up GS/OS and click on BASIC.SYSTEM you then go into >the AppleSoft environment. How do you get back to the OS without >rebooting the system? (I've tried "brunning" all the system files with >no luck. The documentation is silent on this issue). Type BYE (and hit return). This is sort of documented, but it's in the book about BASIC.SYSTEM (_BASIC Programming with ProDOS_, I think). >2) Why can't GS/OS read DOS 3.3 files and just display them like >ProDos files? Is there a utility that does this, or do I have to >convert them all to ProDos 16 to view them on the desk top? GS/OS is designed to allow capabilities like working with DOS 3.3 disks to be added. If there were a DOS 3.3 File System Translator for you to put in your System:FSTs folder, it could. Currently, you have to convert your DOS 3.3 files to ProDOS files to work with them from GS/OS programs. The System Utilities program on Apple II System Disk 3.1 is one that will do the job. [I'll let other people answer the languages question--I'm not taking sides.] >4) Can the perimeter of the color monitor be altered (other than >background color)? No, although there are some programs that (just for a keen effect) change the border color at carefully timed intervals to get strange and generally "stripey" effects in the border. But you can't draw there, and it's limited to one of 16 colors. -- --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
farrier@Apple.COM (Cary Farrier) (11/10/89)
In article <1134@godot.radonc.unc.edu> rosenman@godot.UUCP (Julian Rosenman) writes: >I am both a new IIGS owner and a new user of comp.sys.apple so I'm >probably going to ask some dumb questions, but here goes... The only dumb questions are the ones never asked. >1) If you boot up GS/OS and click on BASIC.SYSTEM you then go into >the AppleSoft environment. How do you get back to the OS without >rebooting the system? (I've tried "brunning" all the system files with >no luck. The documentation is silent on this issue). The command to exit from basic is called "bye". Just type it in at the prompt, and you will be dropped back to the application you were in when you ran basic, which is probably the Finder. >2) Why can't GS/OS read DOS 3.3 files and just display them like >ProDos files? Is there a utility that does this, or do I have to >convert them all to ProDos 16 to view them on the desk top? GS/OS can't read DOS 3.3 files because there is not a file system translator (FST) which reads DOS 3.3 volumes. The way data is arranged on a disk can be different between different file systems (such as ProDOS and DOS 3.3), and the system has to be told how to read in the data. So far GS/OS only knows how to read in disks which were created under the ProDOS, High Sierra, or ISO 9660 file systems. The system also knows how to read AppleShare volumes, but these volumes are encountered only on networks. >3) What programming language is recommended for the IIGS? AppleSoft is >clearly inadequate as it does not support the sound chip, super hires >screen, tool box, extended memory etc. Do any of the commercial >BASIC's support these things? Which would you recommend? The programming language I would recommend would vary depending on what type of program you wanted to write. If you are writing something that requires alot of speed, then you should probably use assembly. If you are writing something that needs to be ported to other machines, then a higher level language (such as C or Pascal) might be better suited. >4) Can the perimeter of the color monitor be altered (other than >background color)? I'm not exactly sure what you mean. If are asking whether you can draw into the border, it is possible with some tricky interrupt handling, but not easy for the beginner. Cary Farrier -- +--------------+-------------------------+ | Cary Farrier | farrier@apple.com | +--------------+-------------------------+
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/11/89)
In article <1134@godot.radonc.unc.edu> rosenman@godot.UUCP (Julian Rosenman) writes: >1) If you boot up GS/OS and click on BASIC.SYSTEM you then go into >the AppleSoft environment. How do you get back to the OS without >rebooting the system? Type the standard BASIC command "BYE". >2) Why can't GS/OS read DOS 3.3 files and just display them like >ProDos files? Is there a utility that does this, or do I have to >convert them all to ProDos 16 to view them on the desk top? There is currently no File System Translator for DOS 3.3, which has been deemed "obsolete" by Apple for many years now. You have to convert them to ProDOS. Many copy utilities such as Copy II+ will do this conveniently. >3) What programming language is recommended for the IIGS? AppleSoft is >clearly inadequate as it does not support the sound chip, super hires >screen, tool box, extended memory etc. Do any of the commercial >BASIC's support these things? Which would you recommend? AppleSoft BASIC can be beefed up to access ToolBox routines etc. but for serious programming I would recommend using a serious programming language and support environment. The official support environment is the Apple IIGS Programmer's Workshop (APW), which comes with an assembler; you can obtain it from the Apple Programmers and Developers Association (APDA), whose address I don't have at hand at the moment. APDA also sells an APW C compiler and some third-party development products. ByteWorks sells an enhanced APW environment that includes a "DeskTop" with source-level debugger, mouse editor, etc. under the name ORCA/M for its macro assembler. ByteWorks also sells ORCA/Pascal and ORCA/C for this environment and/or APW. There is another company, TML, that sells a IIGS Pascal compiler, but I'm not sure it's fully APW compatible. >4) Can the perimeter of the color monitor be altered (other than >background color)? Sure; you can set it from the Control Panel.
huang@husc4.HARVARD.EDU (Howard Huang) (11/11/89)
In article <1134@godot.radonc.unc.edu> rosenman@godot.UUCP (Julian Rosenman) writes: >1) If you boot up GS/OS and click on BASIC.SYSTEM you then go into >the AppleSoft environment. How do you get back to the OS without >rebooting the system? Executing the "PRODOS" system file should get you back into GS/OS. Type "-PRODOS" from within Basic. >2) Why can't GS/OS read DOS 3.3 files and just display them like >ProDos files? Is there a utility that does this, or do I have to >convert them all to ProDos 16 to view them on the desk top? I guess GS/OS can't do it because DOS 3.3 is "outdated" and not supported. I don't know if there's a GS/OS utility that will display DOS 3.3 files, but there are several programs that let you convert 3.3 files to ProDOS, like Copy II Plus. I'm sure Prosel does this too. >3) What programming language is recommended for the IIGS? AppleSoft is >clearly inadequate as it does not support the sound chip, super hires >screen, tool box, extended memory etc. Do any of the commercial >BASIC's support these things? Which would you recommend? There are a lot of new BASICs for the IIgs. Micol Advanced BASIC is actually a compiler, but it supports the IIgs. I haven't ever used it; I'm looking at a write-up of it in the May 1989 Nibble magazine. Assembly language is pretty widely used, but Pascal is becoming popular too. All of the newer programming packages (TML Pascal, APW assembler and C, and ORCA assembler and C) support the IIgs. There isn't really a recommended language; use whatever you're most comfortable with. Hope this helps... Howard C. Huang huang@husc4.harvard.edu huang@husc4.BITNET huang@husc4.UUCP
dtroup@carroll1.UUCP (David C. Troup - Skunk Works : 2600hz) (11/11/89)
In article <5124@internal.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: > > GS/OS can't read DOS 3.3 files because there is not > a file system translator (FST) which reads DOS 3.3 volumes. Anyone out there have ANY file system translator for the GS? Currently, I have been using the system utilities to read from a DOS disk and move it to a Prodos volume. It would be a GREAT sharware hack. -- "We got computers, we're tapping phone lines, knowin' that ain't allowed"__ _______ _______________ |David C. Troup / Surf Rat _______)(______ | |dtroup@carroll1.cc.edu : mail ________________________________|414-524-6809______________________________
UD041948@VM1.NODAK.EDU (Joe Carlin) (11/12/89)
Better yet, does anyone know where to get information on _HOW_ to write an FST? Or printer driver for that matter? Or is this just stuff Apple likes to keep to itself? It seems rather anti-productive to me. Or a CDEV? Joe
lhaider@pro-sol.cts.com (Lawrence Haider) (11/12/89)
In-Reply-To: message from UD041948@vm1.nodak.edu >Better yet, does anyone know where to get information on _HOW_ to write >an FST? Or printer driver for that matter? Or is this just stuff Apple >likes to keep to itself? It seems rather anti-productive to me. Or >a CDEV? >Joe This was hashed out a few weeks ago. The response from Apple was basically "NO!". It has to do with making changes to GS/OS to implement changes with FSTs. A lot of very experienced Apple developers seem to be irked by the situation, but that's the way it is. : ( Laer lhaider@pro-sol.cts.com
mattd@Apple.COM (Matt Deatherage) (11/12/89)
In article <8911111239.aa09869@SMOKE.BRL.MIL> UD041948@VM1.NODAK.EDU (Joe Carlin) writes: >Better yet, does anyone know where to get information on _HOW_ to write >an FST? Or printer driver for that matter? Or is this just stuff Apple >likes to keep to itself? It seems rather anti-productive to me. Or >a CDEV? > >Joe FSTs, Apple keeps for itself. The internals of GS/OS allow easy addition of extra drivers, but adding a file system is so complex that, at least so far, changes have been required to GS/OS itself for suitable compatibility. Besides, can you imagine 20 people with DOS 3.3 FSTs, each of which interpreted (or stored) the expanded GS/OS parameters in a different way? Or dealt with non- 5.25" disks in a different way? Calamity! You think you have headaches NOW... Printer Drivers (and Port Drivers, which send printer information through given hardware) have been documented for the past 18 months in Apple IIgs Technical Notes #35 and #36. To my knowledge, no one has written printer drivers yet. (Claris' driver was based on Apple code which was, but is no longer, licensable; I haven't seen Bill Heineman's drivers Joe referred to but would encourage him to release them somehow.) The information has been there for a long time, but no one seems to want it. CDEV specifications are in the File Type Note for CDevs ($C7) released this September. The Technical Notes and File Type Notes are available for anonymous FTP from Apple's FTP site. -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
mattd@Apple.COM (Matt Deatherage) (11/13/89)
lhaider@pro-sol.cts.com (Lawrence Haider) writes: >In-Reply-To: message from UD041948@vm1.nodak.edu > >>Better yet, does anyone know where to get information on _HOW_ to write >>an FST? Or printer driver for that matter? Or is this just stuff Apple >>likes to keep to itself? It seems rather anti-productive to me. Or >>a CDEV? > >>Joe > >This was hashed out a few weeks ago. The response from Apple was basically >"NO!". It has to do with making changes to GS/OS to implement changes with >FSTs. A lot of very experienced Apple developers seem to be irked by the >situation, but that's the way it is. : ( > > Laer >lhaider@pro-sol.cts.com Actually, as I said yesterday (which may be tomorrow for some of you :) we said "no" to *FSTs* for very good reason. The rest is already documented in Apple II Technical Notes; the Printer Drivers have been documented there for 18 months. Please don't answer multi-part questions with "yes" or "no". :) -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
mdavis@pro-sol.cts.com (Morgan Davis) (11/13/89)
In-Reply-To: message from mattd@apple.com I can definitely see Apple's argument of revealing the details of FST construction as a big "no no" when you're talking about existing file system formats (i.e. DOS 3.3). What about 3rd parties who want to design new file systems (i.e. UNIX)? My vote is definitely NO for those who want to forge ahead and beat Apple at producing FST's for existing filesystems (DOS 3.3, Apple Pascal, etc.). But a definite YES vote for those companies wishing to explore new filesystem designs which (hopefully) can enhance IIGS computing. UUCP: crash!pnet01!pro-sol!mdavis ProLine: mdavis@pro-sol ARPA: crash!pnet01!pro-sol!mdavis@nosc.mil MCI Mail: 137-6036 INET: mdavis@pro-sol.cts.com America Online, BIX: mdavis
mattd@Apple.COM (Matt Deatherage) (11/13/89)
In article <13519.apple.net@pro-sol> mdavis@pro-sol.cts.com (Morgan Davis) writes: > >I can definitely see Apple's argument of revealing the details of FST >construction as a big "no no" when you're talking about existing file system >formats (i.e. DOS 3.3). What about 3rd parties who want to design new file >systems (i.e. UNIX)? > File systems not listed in the GS/OS Reference are even more likely than others to need things added to the OS for them, since the designers did not have them or their features in mind at the time. >My vote is definitely NO for those who want to forge ahead and beat Apple at >producing FST's for existing filesystems (DOS 3.3, Apple Pascal, etc.). But a >definite YES vote for those companies wishing to explore new filesystem >designs which (hopefully) can enhance IIGS computing. > Not to sound more sarcastic than I do as an accident of birth, Morgan, but how do you propose to sufficiently document things so that people could write FSTs for some file systems but not others (ignoring changes most likely needed to GS/OS for them)? >UUCP: crash!pnet01!pro-sol!mdavis ProLine: mdavis@pro-sol >ARPA: crash!pnet01!pro-sol!mdavis@nosc.mil MCI Mail: 137-6036 >INET: mdavis@pro-sol.cts.com America Online, BIX: mdavis -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
farrier@Apple.COM (Cary Farrier) (11/14/89)
In article <11584@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <1134@godot.radonc.unc.edu> rosenman@godot.UUCP (Julian Rosenman) writes: > >>4) Can the perimeter of the color monitor be altered (other than >>background color)? > >Sure; you can set it from the Control Panel. No, you can't. Cary -- +--------------+-------------------------+ | Cary Farrier | farrier@apple.com | +--------------+-------------------------+
mrharrison@orchid.waterloo.edu (Mike Harrison) (11/14/89)
In article <5169@internal.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >In article <11584@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>In article <1134@godot.radonc.unc.edu> rosenman@godot.UUCP (Julian Rosenman) writes: >> >>>4) Can the perimeter of the color monitor be altered (other than >>>background color)? >> >>Sure; you can set it from the Control Panel. > > No, you can't. Well, I hate to gainsay someone from Apple, but at least on my GS, yes, you can set the border color from within the Control Panel. The "display" menu selection allows changing the screen,border,and text colors. Mike mrharrison@orchid.waterloo.edu
farrier@Apple.COM (Cary Farrier) (11/15/89)
In article <678@orchid.waterloo.edu> mrharrison@orchid.waterloo.edu (Mike Harrison) writes: >In article <5169@internal.Apple.COM> farrier@Apple.COM (Cary Farrier) writes: >>In article <11584@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>>In article <1134@godot.radonc.unc.edu> rosenman@godot.UUCP (Julian Rosenman) writes: >>> >>>>4) Can the perimeter of the color monitor be altered (other than >>>>background color)? >>> >>>Sure; you can set it from the Control Panel. >> >> No, you can't. > >Well, I hate to gainsay someone from Apple, but at least on my GS, yes, you >can set the border color from within the Control Panel. The "display" menu >selection allows changing the screen,border,and text colors. Don't worry 'bout it, because you didn't :-). Julian asked if the perimeter of the monitor could be altered, and it can't. Julian didn't ask if the border color could be altered. > >Mike >mrharrison@orchid.waterloo.edu Cary Farrier -- +--------------+-------------------------+ | Cary Farrier | farrier@apple.com | +--------------+-------------------------+
yk4@cunixb.cc.columbia.edu (Yong Su Kim) (11/15/89)
Although the border cannot be changed such that you can get graphics, the border can have more than one colour. I have seen horizontal stripes being displayed by a slide show program which made the screen look like a french flag turned on its side. I have also seen text with more than one colour but only in horizontal bands. Interesting how creative people can get with the GS. _____________________________________________________________________________ |Internet: yk4@cunixb.cc.columbia.edu |||||||The Korean from Hong Kong.|||||| |Bitnet : yk4@cunixc ||||||||||||||||||||||||||||||||||||||| |UUCP : rutgers!columbia!cunixc!yk4 ||||||||||...Apple IIGS user...|||||||| |_______________________________________|||||||||||||||||||||||||||||||||||||||
dkl@pro-houston.cts.com (David Karl Leikam) (11/15/89)
In-Reply-To: message from mdavis@pro-sol.cts.com In CS-ID: #2634.cortland/info-apple@pro-houston, mdavis@pro-sol.cts.com (Morgan Davis) writes In-Reply-To: message from mattd@apple.com >I can definitely see Apple's argument of revealing the details of FST >construction as a big "no no" when you're talking about existing file system >formats (i.e. DOS 3.3). What about 3rd parties who want to design new file >systems (i.e. UNIX)? And I guess that again, I have a problem with consistency. (My little mind's favorite hobgoblin, I suppose...) But look: in the search for alternative devices and operating systems, you cannot hold things back - they're going to happen. Let Apple publish the current FST guidelines, be they ever so strict, and see what can be done out in the wide world. I grant you Apple Computer is a repository of much of the rational thought about personal computers in the western world, but surely it's not the only one? Let us see what, say, a Roger Wagner, or even (shudder) a jabernathy, can do within those guidelines? And if it's the case that they must be SO strictly drawn that little or no development of that kind is possible, then I must ask, "Why have FST's, or the capability for them, at all? If they can't be implemented, why waste the disk space and time to store/access 'em as separate files, rather than embedding the code into the rest of the O/S???" If you can't use 'em, what good are they? If you _can_, let us see what use can be made! n'cest pas? UUCP: crash!pro-houston!dkl ARPA: crash!pro-houston!dkl@nosc.mil INET: dkl@pro-houston.cts.com
farrier@Apple.COM (Cary Farrier) (11/16/89)
In article <2634.cortland.info-apple@pro-houston> dkl@pro-houston.cts.com (David Karl Leikam) writes: > And if it's the case that they must be SO strictly drawn that little or no >development of that kind is possible, then I must ask, "Why have FST's, or the >capability for them, at all? If they can't be implemented, why waste the disk >space and time to store/access 'em as separate files, rather than embedding >the code into the rest of the O/S???" If you can't use 'em, what good are >they? If you _can_, let us see what use can be made! *Using* an FST is _not_ the same as *writing* an FST! One of the intracacies of creating an FST involves how closely it interacts with the rest of the OS. Sometimes these details change in an OS revision. When this happens, we can update the FSTs, but we can't update a 3d party FST. Do you not drive a car because you can't manufacture it yourself? Do you not buy software because the the author doesn't publish the source code? Just because every individual can't be involved in the creation process doesn't mean that the end product is not useful. Cary Farrier -- +---------------------------------------+---------------------------------+ | Cary Farrier | Internet : farrier@apple.com | | Apple II Systems Software Engineering | UUCP : apple!farrier | | Apple Computer, Inc. | Fax : (408) 974-1704 | | 20525 Mariani Ave. | AppleLink : FARRIER | | Cupertino, CA 95014 | -or- : applelink.apple.com | +---------------------------------------+---------------------------------+ | I don't speak for Apple Computer, our products do that just fine. | +-------------------------------------------------------------------------+
mattd@Apple.COM (Matt Deatherage) (11/16/89)
In article <2634.cortland.info-apple@pro-houston> dkl@pro-houston.cts.com (David Karl Leikam) writes: > And if it's the case that they must be SO strictly drawn that little or no >development of that kind is possible, then I must ask, "Why have FST's, or the >capability for them, at all? If they can't be implemented, why waste the disk >space and time to store/access 'em as separate files, rather than embedding >the code into the rest of the O/S???" If you can't use 'em, what good are >they? If you _can_, let us see what use can be made! > > n'cest pas? >UUCP: crash!pro-houston!dkl >ARPA: crash!pro-houston!dkl@nosc.mil >INET: dkl@pro-houston.cts.com Not to spend too much time on this, but storing FSTs as separate files is good for much of the same reasons storing drivers in files is good: 1) If Apple does release more, you can add them easily. 2) If you don't want to use all that are available, you can remove the files (or even inactivate them from the Finder). Who without a CD-ROM wants to take memory or boot time on a High Sierra FST? Who wants AppleShare who doesn't have a network? If they were built-into the system, you might be stuck with them. 3) They've traditionally not done these things with files on the Macintosh (most of these things are resources in the System file), and lots of people don't like it. I'd like to say I could go on, but that's probably the extent of it. :) -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/16/89)
In article <2634.cortland.info-apple@pro-houston> dkl@pro-houston.cts.com (David Karl Leikam) writes: > And if it's the case that they must be SO strictly drawn that little or no >development of that kind is possible, then I must ask, "Why have FST's, or the >capability for them, at all? If they can't be implemented, why waste the disk >space and time to store/access 'em as separate files, rather than embedding >the code into the rest of the O/S???" The answers to that should be obvious to any software engineer. The only question I have is, why the ballyhoo about FSTs and not about the system call switchout table, or whatever other nifty technology might be embedded within GS/OS's design? If the idea was to let us know that more FSTs could be expected, then why not let us know definitely which ones and when we can expect them? It would help our own long-range planning.