introducing minimOS

[GARTHWILSON]

Point-and-click doesn't require GUI though. A purely text interface, especially using the ANSI [Edit: that should say IBM437] character set that allows drawing the frames and scroll bars and so on, works very well, allowing you to re-size windows, drag and drop, minimize and maximize, choose menu items, have hypertext help, scroll, etc., all with the mouse. My DOS-based MultiEdit professional programmer's text editor is outstanding in this area and takes advantage of the hi-res monitor, and is way better than any GUI-based text editor I've ever seen. I've had up to about 34 files open on it at once. My DOS-based (E)EPROM programmer software is mouse-powered also. My DOS-based PCB CAD is of course a graphics program and mouse-powered, but does not use a GUI OS.

[enso]

Good point, Garth. I am all about elective features. The mouse in your system augments the application, but you are not required to use (or install) one.

BTW, that is what I meant about elective OSs. It's there, but you don't have to use it, if you choose to take over the machine.

The modern PC is doing way too many things for this to be possible these days, but personally, I would rather have a bunch of real or virtual DOS-like sessions that you can switch between, perhaps with some way to share data (clipboard?). You could have multiprocessing or virtualization or some OS creating the illusion of that...

[BigDumbDinosaur]

I avoid using a mouse as much as possible. Most of the time the d**ned things get in the way of real work.

[GARTHWILSON]

Quote:

Good point, Garth. I am all about elective features. The mouse in your system augments the application, but you are not required to use (or install) one.

Very little if anything in the software I mentioned actually requires the mouse, and many things are quicker with the F keys and <CTRL> and <ALT> key keyboard shortcuts once you learn them (which you will if you use the software a lot). Using the keys for these functions does not involve spelling out commands-- although I do think it's good to leave that option open, and it probably leaves the greatest flexibility. I type well though so it doesn't bother me.

[White Flame]

While I enjoy my CLIs, I do recognize some specific objective benefits of GUIs:

• A pointing device is faster when you're looking at a giant pile of heterogeneous stuff and want to say "I pick _that_ one", than having to cursor over to it, or if it has no sensible name to type. That, and placing the cursor in a particular visible place in a large document is faster with a mouse.
• Scrolling & traversing large amounts of data is generally better in GUIs. In exploring a filesystem that you're not familiar with, using cd & ls is usually slower and less contextual than a graphical explorer. Also, consider console hypertext programs vs a graphical web browser, with both of these points. The scroll wheel is also a fantastic invention.
• A GUI presents you with what you can do with a program. An empty CLI prompt does not.

But of course, keyboard shortcuts and typed commands are far faster when you know exactly what you want to do, console support is far easier to create and expand from a programmer's perspective, and scriptability is hugely important for a tool-oriented (vs application-oriented) system and allows combining features of a single program easier.

[GARTHWILSON]

White Flame wrote:

While I enjoy my CLIs, I do recognize some specific objective benefits of GUIs:

• A pointing device is faster when you're looking at a giant pile of heterogeneous stuff and want to say "I pick _that_ one", than having to cursor over to it, or if it has no sensible name to type. That, and placing the cursor in a particular visible place in a large document is faster with a mouse.
• Scrolling & traversing large amounts of data is generally better in GUIs. In exploring a filesystem that you're not familiar with, using cd & ls is usually slower and less contextual than a graphical explorer. Also, consider console hypertext programs vs a graphical web browser, with both of these points. The scroll wheel is also a fantastic invention.
• A GUI presents you with what you can do with a program. An empty CLI prompt does not.

But again, these don't need a GUI to do them. You can point at words, boxes, diagrams, scroll bars, arrows, etc. formed with the DOS/ANSI [Edit: that should say IBM437] character set instead of poinitng at pictures. (I usually keep the icons in my Linux GUI turned off anyway because they're more cryptic than words are. I mostly just leave the words turned on.)

I had 15 files loaded, 9 of them minimized (showing at the bottom), 2 on top, and 3 behind them, then I used the mouse to pull down the "file" menu, clicked on "load new file," then clicked on the down arrow for history. I could move the menu windows around with the mouse too. Just in the menu boxes, I see 33 things to click on. (There would be more if one box were not partly hiding the one behind it.) No graphics.

The only graphics in my PCB CAD are the ones you draw. Its interface is mouse-powered but menu items are shown in text. You can point and click, although I usually use the shortcut keys and skip the menus.

EPCPROscreen.jpg (86.84 KiB) Viewed 2282 times

Some here will recognize this as my 4Mx8 SRAM board. I clicked on a hot point at the top of the screen to pull down one of five menus.

Besides point-and-click selection, the (E)EPROM programmer software also uses the special characters to form a picture showing how to put the EPROM in the socket:

I've seen where someone in the CAM department of a PCB manufacturer many years ago used batch files (back in the DOS days) to set up a menu system in DOS itself. It did not use the mouse but rather cursor keys to get to the desired item before selecting it with the <Enter> key. He didn't have to type for much of anything. I would like to experiment with DrDOS or FreeDOS which is multitasking, but have not been able to get questions answered even by the people who supposedly supply it.

[whartung]

GARTHWILSON wrote:

But again, these don't need a GUI to do them.

He's not talking about a GUI built of pixels, he's talking about a WIMP interface, however it's manifested.

The key component of WIMP/GUI interface beyond the "pick THIS" capability, is discoverability. Through menus and other interface elements, people can "discover" the capabilities of the system more readily than with a CLI.

In Unix we have (reasonably) ubiquitous man pages, but the man pages are only helpful if you happen to know the command. Once you know the command you can ideally use "man <cmd>" to learn about what it does, it's options, etc., or if it follows other common conventions, you may be able to get by with "<cmd> -help". "man -k" can sometimes help as it can search the man pages, but it still helps a lot to know what you're looking for.

Menu systems, including icons with float over text, lay the command structure out in the open. It's a simple procedure to stare at a Microsoft command ribbon and mouse over all of the little pictures to see what the command might do. If the command has other options, a dialog box typically appears presenting those options, with the more rare and obscure options hidden behind an "advanced" button. This helps present a large subset of the overall command set, in english, vs the arcana that is "ls /usr/bin".

Keyboard navigation in large spaces has been in place for years and years, combined through key binds from simple next-char, to next-word, next-sentence, next-paragraph, next-page, next-chapter. To incremental searching and "leaping", case sensitive and insensitive. Auto-complete is a powerful short cut and search tool.

But keyboard navigation is less discoverable. If you don't know the vocabulary of the system, it's difficult to ask the right questions. System that work with implied structure, such as Ctrl-F moves forward a character, Meta-F moves forward a word, Ctrl-Meta-F moves forward a sentence. Most people do not connect the pattern of the Ctrl->Meta->Ctrl-Meta escalation. You could tell them "Ctrl-F moves forward a character", and they will have NO idea how to move forward a sentence. Most command sets are completely arcane and arbitrary that trying to find patterns and make sense of them is not in the domain of most users. Rather they simply need to know what to do, not why it's key that it is, or the taxonomy of the command structure.

Most people do not understand why Ctrl-X, C, V are Cut, Copy, Paste. They may use it every day, but do not understand why it is the way it is. And why isn't it Ctrl-K or Ctrl-P.

Wordstar had an excellent interface back in the day, especially it's auto expanding windows when the meta-command key was pressed and not immediately followed by an actual command. These were on machines that had little more than Ctrl, Shift, Backspace, and Return.

Modern GUIs have lost site of discoverability, hiding things behind right clicks, shift clicks, float over expansion, menus that change with shift keys. The new touch interfaces are ever worse, assuming someone "just knows" to swipe from some edge that's not indicated in anyway as to do anything. This isn't discoverability, it's stumble upon interfaces, if you're lucky.

[BigDumbDinosaur]

whartung wrote:

In Unix we have (reasonably) ubiquitous man pages, but the man pages are only helpful if you happen to know the command.

apropos followed by a word or phrase will help when you don't know which command(s) might do what you want. In this sense, apropos is the software analog of the hard-copy UNIX manual's permuted index.

[BigEd]

Indeed - and the same functionality is there with

Code: Select all

man -k

(k for keyword)

I'll often grep the output of that to narrow it down a bit more:

Code: Select all

man -k keyword1 | grep -i keyword2

Cheers
Ed

[zuiko21]

Wow! It's been a long time since my last post... all these summer chores leave little spare time, and I admit not having written a single line of code Anyway, the wheels inside my head keep turning, and digesting all your interesting contributions.

Certainly, I was meaning a WIMP interface -- the use of characters or a bitmapped display is irrelevant to me. Discoverability is the key (sometimes sadly forgotten in today's GUIs) but I agree about scriptability being very useful. The concept of separating the actual (CLI) application from the GUI/WIMP interface component sounds a bit scary to me, but if properly done should be the most versatile way. While no actual code for this (or any of the WIMP interface) exists in minimOS so far, it has been already considered, and in due time will be implemented.

Elective features should also be another key of my system... about the mouse, I miss very much the mouse-emulation keys of the Atari ST. Thus, if in a mixed (CLI/WIMP) environment some app "needs" a mouse but the actual device is not available, the user could still get the work done, if not in the most convenient way. Of course, the classic keyboard shortcuts make things quite faster and don't get in the way in any case. I however prefer the use of something like Ctrl+Alt (or some 'meta' key, if available) in order not to disturb control characters.

My apologies if I sounded too "radical" against CLIs... while WIMP is a desireable feature to me, it shouldn't be mandatory -- but neither the other way. And CLI makes things much simpler (or even possible) when on limited resources. But even if no 'screen layout' is needed (think about running thru some kind of serial link) a rudimentary "windowing" system could be very interesting for implementing interactive multitasking apps (instead of a single interactive task plus several background daemons).

In order to keep compatibility between simple CLI apps and WIMP/GUI environments, any interactive app should ask my OS for a port number to be used in subsequent I/O calls, and "release" that port upon exit. That's actually what would become the window_open function, this time called with a NIL set of parameters -- no window size, no position. A WIMP system should then open a default sized "terminal" window for user interaction. On the other hand, systems without an "addressable" screen would only accept those NIL-sized calls, rejecting calls with specified size/position from more graphical apps (although the smarter ones might switch into a "terminal mode" by means of a second call with the NIL parameters)

Although the simplest implementations may return as port number a reference to the physical device (e.g. serial link, say in the 128...255 range), several window numbers could be served sequentially to requesting apps. The idea is to have a FIFO (probably less than 2 Kb would do) for each "window". A global variable keeps track of the active window; if an I/O operation is performed on such window, direct access to the default physical device is granted; otherwise, the output character is stored in that window's FIFO (or no character is received, if an input operation). Upon a specified "window switch event" (some key combo or escape sequence) a "title" (probably a PID or other process reference) is printed and then the corresponding FIFO is flushed. Might work

Anyway, all this is elective as well: I don't think my system would prevent any app writing to a certain "physical" port under its sole responsability -- even to a foreign-owned window! BTW, I don't think a rugged OS is necessarily a good thing... what we need is bug-free apps: if during development, a diminutive error crashes the whole system, that developer may become particularly careful in the future, possibly improving the quality of the developed apps...

Thanks again for reading and commenting!

[whartung]

The biggest problem with most any kind of WIMP interface on a small machine, especially compared against a CLI, is simply memory. Most (although not necessarily all) need RAM to back the windows, and much of that RAM is used exclusively for display purposes.

Multiple TTY windows, even without scrollback, are notorious consumers. An 80x24 screen of simple characters is 2K, and the TTY system would need to ghost all of the open windows with a RAM store.

Something more complicate, such as a dialog box with text fields or simple controls, would minimally need the display list of controls to show, their coordinates, plus their individual states. This can include the text of the label, the text of the field, things like that. Small dialogs would consume less than something like a TTY, but it's still memory for mostly cosmetic purposes rather than actual working data.

CLIs have none of that, they rely on the memory of the display terminal (minimally 1 page of lines/columns) for those purposes. If the display terminal is separated from the machine, then that memory is free. On a self hosted video system (like Atari or C64), then that memory is part of the machine itself and may not necessarily be usable for application state.

[BigDumbDinosaur]

whartung wrote:

The biggest problem with most any kind of WIMP interface on a small machine, especially compared against a CLI, is simply memory. Most (although not necessarily all) need RAM to back the windows, and much of that RAM is used exclusively for display purposes.

I suppose it could be done on a 65C816 equipped with the full complement of RAM, but there are the usual cross-bank access penalties to be paid. Performance would be somewhat questionable with anything more than a relatively low-res display.

Quote:

Multiple TTY windows, even without scrollback, are notorious consumers. An 80x24 screen of simple characters is 2K, and the TTY system would need to ghost all of the open windows with a RAM store.

The Thoroughbred Business BASIC environment supports character-based windowing in a small RAM footprint, and maintains attributes per character cell, as well as the actual character. A "windows" stack is used to maintain enough state information to restore the area under a window when it is closed, without having to make multiple copies of the full screen. BTW, I was able to successfully run that environment on an 80386 box on top of SCO UNIX (3.2 kernel) 25 years ago with only 2 megs of RAM (of which part had to be consumed by the operating system, of course), a maximum of 8 users configured and up to 10 windows possible per BASIC session (80 possible windows en toto). It can be done, but it isn't simple.

I see a text-based windowing function to be practical for a 65C02/65C816 system running at a high clock speed, but have to question the viability of a full WIMP package.

Quote:

Something more complicate, such as a dialog box with text fields or simple controls, would minimally need the display list of controls to show, their coordinates, plus their individual states. This can include the text of the label, the text of the field, things like that. Small dialogs would consume less than something like a TTY, but it's still memory for mostly cosmetic purposes rather than actual working data.

This is where knowledgeable use of display capabilities can save the day. One of the reasons the WYSE 60 was such a huge success was that it was very intelligent for a "dumb terminal." The host machine didn't have to literally draw it a picture to produce a nice looking presentation with text boxes, different character attributes, etc. Developers who understood the terminal's mechanics in detail could get a lot of capability with relatively small code. The display device connected to my POC unit is a Boundless ADDS "replacement" terminal that uses a standard VGA monitor and either a PC-compatible or ANSI keyboard. I have this unit running in WYSE 325 emulation, which is WYSE 60 combined with an ANSI-style 16 color mode. Very little RAM is used in POC to track the display.

Boundless WYSE 325 Emulation Display

[whartung]

BigDumbDinosaur wrote:

The Thoroughbred Business BASIC environment supports character-based windowing in a small RAM footprint, and maintains attributes per character cell, as well as the actual character. A "windows" stack is used to maintain enough state information to restore the area under a window when it is closed, without having to make multiple copies of the full screen. BTW, I was able to successfully run that environment on an 80386 box on top of SCO UNIX (3.2 kernel) 25 years ago with only 2 megs of RAM (of which part had to be consumed by the operating system, of course), a maximum of 8 users configured and up to 10 windows possible per BASIC session (80 possible windows en toto). It can be done, but it isn't simple.

When I talk about a small machine, I mean a 8-Bit with 64K minus whatever ROM and I/O. 2K out of 64K is 3% of the RAM. Once you break through the 8-Bit wall, whether through going 24/32 bit or even bank switching on an 8-Bit, the problem rapidly vanishes. A 2K screen on a 2MB machine is hardly worth mentioning.

Quote:

This is where knowledgeable use of display capabilities can save the day. One of the reasons the WYSE 60 was such a huge success was that it was very intelligent for a "dumb terminal." The host machine didn't have to literally draw it a picture to produce a nice looking presentation with text boxes, different character attributes, etc. Developers who understood the terminal's mechanics in detail could get a lot of capability with relatively small code. The display device connected to my POC unit is a Boundless ADDS "replacement" terminal that uses a standard VGA monitor and either a PC-compatible or ANSI keyboard. I have this unit running in WYSE 325 emulation, which is WYSE 60 combined with an ANSI-style 16 color mode. Very little RAM is used in POC to track the display.

The smart terminals of the day were quite capable and had all sorts of fascinating features that most folks, notably in the PC, and even UNIX world, don't work with very often.

Several terminals had multiple pages that they could use, upon which the computer could paint forms. Then the computer could readily, and instantly, switch from form to form. Also these forms used the concept of "protected fields" that the terminal would know how to navigate. This kept basic editing and navigation a completely local process until the user hits a "send" button that sends the entire form, all at once, to the host. Obviously, this really lowered the interactive load on a host computer, but at the same time it offered a "less friendly" user experience (things like dynamic field validation beyond simple contents, field lookup, dynamic pickers, etc.).

As I/O processing became cheaper and faster, the call for local processing went down. Now every character is sent to the host to be echoed or acted upon.

[Arlet]

whartung wrote:

Several terminals had multiple pages that they could use, upon which the computer could paint forms. Then the computer could readily, and instantly, switch from form to form. Also these forms used the concept of "protected fields" that the terminal would know how to navigate. This kept basic editing and navigation a completely local process until the user hits a "send" button that sends the entire form, all at once, to the host. Obviously, this really lowered the interactive load on a host computer, but at the same time it offered a "less friendly" user experience (things like dynamic field validation beyond simple contents, field lookup, dynamic pickers, etc.).

And it quickly becomes a nightmare if each manufacturer comes up with their own incompatible features, and your software needs to work with all of them.

[BigDumbDinosaur]

whartung wrote:

When I talk about a small machine, I mean a 8-Bit with 64K minus whatever ROM and I/O. 2K out of 64K is 3% of the RAM. Once you break through the 8-Bit wall, whether through going 24/32 bit or even bank switching on an 8-Bit, the problem rapidly vanishes. A 2K screen on a 2MB machine is hardly worth mentioning.

I was referring to a 2MB machine supporting eight concurrent users. A base screen image required 4K of RAM (specifically, 3840 bytes to map the character and attribute cells)...per user. Don't forget that this was 2MB on Intel 386 hardware, which wasn't really a contiguous 2MB. The UNIX kernel loaded above the 384K UMB, so the effective RAM was much less that it appeared to be.

Quote:

The smart terminals of the day were quite capable and had all sorts of fascinating features that most folks, notably in the PC, and even UNIX world, don't work with very often.

Several terminals had multiple pages that they could use, upon which the computer could paint forms. Then the computer could readily, and instantly, switch from form to form. Also these forms used the concept of "protected fields" that the terminal would know how to navigate. This kept basic editing and navigation a completely local process until the user hits a "send" button that sends the entire form, all at once, to the host. Obviously, this really lowered the interactive load on a host computer, but at the same time it offered a "less friendly" user experience (things like dynamic field validation beyond simple contents, field lookup, dynamic pickers, etc.).

As I/O processing became cheaper and faster, the call for local processing went down. Now every character is sent to the host to be echoed or acted upon.

Preaching to the choir. I was working with that stuff 30 years ago (BTW, the WYSE 60 was released c. 1987 and was an overnight success). The use of block mode in terminals (the operating mode you describe) was pretty much obsolete by the end of the 1980s. The last time I recall writing anything that used a terminal's block mode was in 1985—by then virtually everything was operating in conversational mode. Block mode persisted for a while in cases where terminals were being driven through long-haul modems, but that was essentially history once 14.4 Kbps error-correcting modems became available (c. 1990).