Playing with THEOS Corona
I finally got around to it. Only took around 25 years. I fired off an email to find out how much it cost to get a license to THEOS Corona, and then went through with a purchase.
THEOS Corona is different. It came about in the late 1970s where someone had the great idea of creating a multi-user operating system for microcomputers to give them the capabilities of a mini. It's the ideal system for what I affectionalely call boring business software. I can't really say specifically what its conceptual lineage is. It's easy, and familiar, yet different. It's like that kid from school that was from the rural part of another state that's just a bit weird but also a genius.
I'm filing this under PROJ rather than TECH, as I'm actively working on projects using THEOS, and TECH is more for pretending to be a snarky jerk tech pundit that's wrong about everything.
The general idea
For most deployments, a THEOS system isn't being used as a general purpose operating system. Rather, it's usually running one single, typically business-oriented, application. For when those users have to drop to the command line, commands aren't overly complicated, and there's a decent HELP command. Normal users shouldn't be bothered with more than they need to. Avoid foot guns.
File paths
ACCOUNT\dirname/subdir1/subdir2/subdir3/file.name:b
So that's different. It makes sense, though, when you realize that originally THEOS didn't have hierarchical directories as we think of them today. Rather, you kept files in libraries, which used a filename.type format as expected, but the files in the library were one dot lower, like libname.stuff.file. If you've dealt with partitioned datasets on z/OS or libraries in OS/400, you will mostly get the gist.
Oh, and the colon-b part? That's the drive letter. It's tacked on at the end because normally you don't have to think about it. You have a drive search list that sort of combines everything into one logical view. Same goes with the account name... you don't normally need to specify that unless you are referencing the files of a different account.
Command line arguments
Let's say you wanted to copy files from a library to a directory, you could do something like this:
copy ledger.src.* /projects/leder/src/=.basic:n ( noq type
Any wildcards in the specification get mapped to equal signs on the second argument. This is a wonderful way to do this, but the one quirk is that you must specify the target pattern. Well, it will run without it, but it will not behave as expected. Fortunately, it will generally Do The Right Thing to avoid any unexpected footguns. This is the sort of thing you want in a system that handles boring business software, like your company's general ledger or payroll system.
Most commands in THEOS do not take an unlimited number of arguments like your typical unix command. Rather, they tend to be more restrained. You'll often be able to specify just one file as an argument. Any optional arguments will be listed after an opening parenthesis. When you start writing your own software you will definitely be confused when you find out that the command string interpreter will drop any closing or subsequent opening parenthesis. For options that take an argument they are separated by spaces.
File types
I have no idea how the underlying file system is actually implemented, but from the user-facing side of things, there are several types of files. We're familiar with the sequential file, which is what you see in the DOS, Windows, and UNIX world. However, directories and libraries are their own special file type, which is also a thing on those other systems to some degree, but in THEOS we have to pre-allocate them. Directories are easy, in that they inherit the file system defaults. Libraries, on the other hand, need you to define the number of entries that could be in the library. There are also several types of data files... direct (relative), keyed, indexed, and large ISAM (LISAM). Oh, and programs are also their own special file type above and beyond just the file extension.
Data files are preallocated, though they can be extended automatically. However, once created you cannot change the key length or record length. Fortunately, though, you can copy the records between the old and new files, even between the keyed file types. Note that the indexed file types have just one index. If you need to create alternate indexes, well, you have to create it yourself. Note that there is also the "THEOS Database" system which brings a sql relational dbms with transaction capability (and is a separately licensed product that isn't on the standard price list).
As for what to use and when... looks like LISAM is usually the right choice if you need an indexed-type file, unless you need to interoperate with an older system. If you will almost always be performing a sequential scan on a file, then keyed is a suitable choice. Direct has its various use cases. One of which is when you are using an indexed file where its records are a location in the direct file.
If all of this seems like it's a big headache, it's not that bad, and these days I think they call this a NoSQL database. BASIC is a better query language than javascript.
Licensing
THEOS was, and still is, mostly sold through VARs that develop their own integrated application and sell it with an OS license. The end user gets a full solution to whatever it is that they need. Most would never talk to THEOS Software Corporation, as that's the reseller's job. As a comparison, THEOS isn't that much different from fully licensing a Windows terminal services deployment, but not nearly as expensive.
The base OS is licensed by PowerSteps, which is almost the same as concurrent user licensing, but it's a little more subtle than that. It's effectively the number of devices that can host a login session. If the device supports it, you can actually get up to eight sessions per device. Confusingly, they typically refer to PowerSteps as users, but rest assured, you can have eight sessions running on the console. There's a quirk with all this where it's even possible to license a PowerStep 0 system, which apparently allows just a single session on the console. I think it's the same as what used to be called a "THEOS Lite" system. Probably used for something like a point of sale terminal that would only have just a single application running that would be talking to the main system. That sort of operation isn't really a thing right now due to hardware support. More on that later. The PowerStep 1 level is not that expensive, but the price triples for a PowerStep 2. Fortunately, if you're licensing more than just the base OS, they will be more than happy to give you a deal on that.
If you want to use the system as a web server, you'll need the Server Suite, which in cludes that, an FTP server, a search server, various utility services, a print server, and some network login facilities. Those facilities are separate from THEOS Work Station, which is a specialized terminal emulator for THEOS. TWS comes in network and serial (as in RS232) varities. The network edition also gives you telnet service. Additional connections from the same source IP will be counted as an additional session. Exceeding that will need an additional TWS license. Note that the server suite is licensed by the system.
In addition to the Server Suite, there are several PlusPaks and compilers available that are also licensed on a per-system basis. The three PlusPaks aren't all that interesting these days — THEOS+Fax, CDWriter, and a Digi intelligent multiport serial driver. This leaves the two compilers... BASIC and THEOS C. The BASIC compiler costs a bit less than the C compiler. However, the price did not not factor into my choice of BASIC over C. Rather, I don't trust myself to write C.
Hardware Support
THEOS is a 32-bit operating system. It needs a BIOS. Your motherboard's UEFI CSM may not be good enough. Hardware support for recent hardware is not good. They recommend the use of VMware Workstation Pro. From my own experience, the latest release of VMware Workstation Pro, which is now free for non-commercial use, will work better than ESXi 8.0, at least with regards to networking. For whatever reason, ESXi's emulated E1000 card is very different than that in Workstation Pro 17.
I have managed to get it to boot and install on a few different industrial boards that are on the trailing edge to various success. I also have a newish legacy-free desktop that can somehow boot the operating system, but does not have compatible storage hardware.
Yeah, but why though?
In this world of everything done via the internet... where everything embeds a web browser to the point that your web browser is a bloated javascript implementation of a web browser running on top of a core web browser underneath... where creating a simple Hello, World program requires dozens of gigabytes of things to be downloaded and spending six months mastering seventeen different frameworks... where it's difficult to disconnect from everything... I just sort of want a system where you go, "Nah, let's not do any of that."
Mostly, I'm enjoying using a pretty reasonable implementation of BASIC, that's more or less what one would expect from Business BASIC, though I don't think it's fully compliant with the ANSI standard. Developing quick little tools that work with a data file is straight forward. I'm porting over my time tracker tools, which end up talking to an Addmaster IJ7200 bank teller receipt printer. I've also made a quick and dirty filelist utility that gives a more compact listing. I'm also working on the Havardgram system again.