CLI v. GUI

[spotracite]

I've been working on an operating system for my custom computer called PlanB, a complete m68k computer inspired by the workstations of the late 80s and early 90s such as the Macintosh, Amiga, Atari, and the like. That being said, it's obviously graphically oriented since that's what I find more interesting. My question is, what are you guys doing for yours? Are you going for a DOS or UNIX like command interpreter, a completely graphical system, or something in between?

Most of the systems that I found more interesting were the "in-between" ones. Things like the Xerox Alto, which booted into an executive shell with graphical capabilities such as a mouse cursor and hyperlinks, or A/UX which frankensteined the Macintosh interface onto a Unix workstation using some *ahem* inspired methods.

Of course, I think it's also interesting to have something like Unix that boots into a CLI but can start a GUI later via X11, Wayland, NeWS, or whatever windowing system you prefer. It makes a lot of sense for a machine that's meant to be efficient and powerful.

It's also obviously easier to implement a basic shell than it is to implement a basic windowing system, but I think once you get into writing a really powerful shell like Zsh or Fish then you get comparable to a basic windowing system (at least from what I have found).

[FranchuFranchu]

I'm not really interested in the graphical aspect of developing an OS. I find IPC, drivers, and system call API design much more engaging. I assume that sooner or later I would have to implement some sort of CLI program, but if I were to do that I wouldn't use a Unix shell like sh or bash, because I think those were intended as shell programs and then people started using them as scripting programming languages, a function which I think they aren't well-suited for. On the question of how GUI-ish the terminal should be; not very. I think just printing color and characters, and getting keyboard input is everything a terminal should do. Trying to mix in GUI into it with mouse support or embedded images and 3d models is an interesting and fun idea, but it seems very dirty and takes away the simplicity of a text terminal.

[bloodline]

I've been working on an operating system for my custom computer called PlanB, a complete m68k computer inspired by the workstations of the late 80s and early 90s such as the Macintosh, Amiga, Atari, and the like. That being said, it's obviously graphically oriented since that's what I find more interesting. My question is, what are you guys doing for yours? Are you going for a DOS or UNIX like command interpreter, a completely graphical system, or something in between?

You’ll appreciate my approach then, a CLI in a GUI a la AmigaOS1.3... because, why not? Overlapping windows is a headache to implement, and requires a fairly complex event system... I don’t recommend it.

Do you have any more details of your PlanB system?

[Solar]

This really isn't an "X or Y" question. A good environment offers both approaches, and integrates them with each other.

Windows came from the GUI side of things, and only lately acknowleged the usefullness of a full CLI environment (and, predictably, made a nice hash of that as well). *nix came from a CLI perspective, with GUI added later on and the disconnect between the two still felt today, with several applications coming as CLI-only with a separate GUI frontends for different desktop environments provided by a completely different projects (with the predictable issues of compatibility and abandonment).

I strongly second @bloodline here with pointing to AmigaOS for inspiration. Calling the AmigaOS GUI file selector to allow the user to select a file or drawer, or make a choice of "OK, Abort" could easily be done from a script. Likewise, these requesters could easily be navigated by keyboard. Most applications could be started from the GUI (double-click on the icon, get the GUI) or from the CLI (call with parameters on what to do). Most applications also made use of "ARexx Ports", a scripting callback interface that allowed applications to "talk" with each other, or be "remote controlled" by scripts.

What is the purpose of having a command line FTP client (for scripting), and a GUI FTP client (for interactive use), and having to configure your address book for each separately? It should be the same application.

One of my favorite use cases for the integration of CLI and GUI on AmigaOS was starting a script telling the GUI photo manager to take a selection of pictures, pipe them through the GUI graphics application to generate high-quality thumbnails of the desired size, have the script generate the appropriate HTML files to create an online photo album (with the descriptions from the photo manager added, thumbnails on the index site leading to full-view subpages), and then call the GUI FTP client to upload it all to my website. At the click of one button.

The trick here is to understand GUI and CLI, not as competing ends of a spectrum you have to chose from, but two absolutely valid usecases that a system should both embrace, and make it easy for application programmers to support both at the same time.

And while I understand that neither is really the job of an OS kernel, my opinion on the matter is that both should be provided by the OS environment. Leaving either to third-party competition inevitably leads to fractioning, reinvention of the wheel, wastefulness, and ugliness. Point in case, KDE vs. Gnome 2 vs. Gnome 3 vs. Xfce vs. ..., and bash vs. ksh vs. csh vs. ... -- Unix was very early, and with the help of Linux, is very large today. It can afford some reinvention and wastefulness. An all new OS, IMHO, cannot.

[PeterX]

1.) There are already 2 OS projects named "Plan B":

A distributed Plan 9 derivate:
http://www.lsub.org/ls/planb.html

Huawei's attempt of an own smartphone OS:
https://www.businessinsider.in/huawei-d ... 419888.cms

2.) In Windows95 the Explorer (the graphical file manager) and the shell are one and the same program. I guess that's still the same in Windows 10, but I don't know that.

3.) You can implement a shell ontop of a GUI (you probably know XTerm). That way you have both.

Greetings
Peter

[nexos]

2.) In Windows95 the Explorer (the graphical file manager) and the shell are one and the same program. I guess that's still the same in Windows 10, but I don't know that.

Yes, it still it. (start rant) Windows shell startup is a long drawn out process for me. On my W10 laptop, it took 5 minutes for the desktop! Now it takes 10 minutes for the User Profile Service to log my account in (end rant )

I'm not really interested in the graphical aspect of developing an OS. I find IPC, drivers, and system call API design much more engaging.

Me too. On my microkernel right now, it prints out stuff about events being broadcast and signals being raised, which are completely invisible to the user.

That being said, it's obviously graphically oriented since that's what I find more interesting. My question is, what are you guys doing for yours? Are you going for a DOS or UNIX like command interpreter, a completely graphical system, or something in between?

For me, I am going to make system mostly graphical in the long term. My overall OS (NexOS) aims to be a distributed system, distributed meaning that one computer can have many monitors, keyboards, and mice hooked up to it and make it be many computers. I know Windows Server can do this, but hey, why not I try it? Anyway, with that being said, I guess a GUI would be a good thing to have in a system like this. But a complex kernel with NUMA and ACPI, a driver interface with modern features, a full USB stack with xHCI, and etc interests me more then making the world's most beautiful OS.

[spotracite]

Do you have any more details of your PlanB system?

Well, it's not terribly fruitful yet as an operating system but as a machine it's very exciting. It's a hardware emulator that uses a monochrome display (running via IMGUI) with a 68k CPU. The hardware itself is based off of what you'd find in a Mac Plus, so there's a 512x342 pixel screen, a ROM, a couple megabytes of RAM, and some stuff that I haven't fully implemented yet like a hardware BitBlit system. The ROM contains most of my OSdev work so far, all it does is draw 16 "colors" to the screen which I've implemented through hardware level dithering. The ROM will eventually contain a full microkernel that doesn't multitask, multitasking is going to be implemented through a secondary system that's loaded off of storage. The emulator also has two VT100 terminals that are used for error logging and printing text (I picked VT100 cause it's cool and easy to write )

A major design inspiration was QuickDraw and the Xerox Alto, I looked through a lot of source code for both of those so that I could write my graphical routines quickly and efficiently. Similar to QuickDraw, the ROM will render everything in a separate memory location and only print it to the screen once it's fully done, and it implements clipping at the lowest possible level. Similar to the Alto, it uses BitBlit for practically everything it does graphics-wise so that it doesn't need to calculate anything (only read data to the screen). It also makes use of a software scanline system so that if it detects lag it will render it directly instead of waiting till it's done, which causes screen tearing but will run faster.

For me, I am going to make system mostly graphical in the long term. My overall OS (NexOS) aims to be a distributed system, distributed meaning that one computer can have many monitors, keyboards, and mice hooked up to it and make it be many computers. I know Windows Server can do this, but hey, why not I try it? Anyway, with that being said, I guess a GUI would be a good thing to have in a system like this.

That sounds like it'd be pretty cool! We don't have enough OSes nowadays that actually try to be modern from the ground up. My main goal isn't necessarily to be as modern as possible but more to take full advantage of the hardware provided, continuing in the spirit of the programming Gurus of old. That being said, it's a lot harder to take full advantage of modern hardware since there's just so dang much of it! I don't see any actual reason why I genuinely need more than four gigabytes of RAM in a home computer, and even that is more than enough for word processing and web browsing.

But a complex kernel with NUMA and ACPI, a driver interface with modern features, a full USB stack with xHCI, and etc interests me more then making the world's most beautiful OS.

Haha, I doubt my OS will be beautiful at all. Considering it'll have a monochrome display with less than 640x480 pixels, less than a gigabyte of RAM, and barely more ROM than the original Macintosh, it'll probably be a very hacked together system. But, that's what's fun about it! I'm doing this as my foray into genuine programming (I was taught Python and Java for the two years of Computer Science I took, but nothing about C), so it'll likely be butt-ugly until I figure out what I'm doing.

Edit: Ack! I'm too new to this forum, I can't figure out how to quote apparently

[PeterX]

Do you have any more details of your PlanB system?

Well, it's not terribly fruitful yet as an operating system but as a machine it's very exciting. It's a hardware emulator that uses a monochrome display (running via IMGUI) with a 68k CPU. The hardware itself is based off of what you'd find in a Mac Plus, so there's a 512x342 pixel screen, a ROM, a couple megabytes of RAM, and some stuff that I haven't fully implemented yet like a hardware BitBlit system.

If there would be a real hardware computer like that, I'd probably buy it

But what is immediate mode? I looked it up in the forum and the wiki, but didn't find anything. And I don't understand the two wikipedia articles (IMGUI and immediate mode). I also looked at the following page and still don't understand it:
https://docs.microsoft.com/en-us/window ... diate-mode

Geetings
Peter

[nexos]

But what is immediate mode?

My guess from reading the MS Docs article is that the graphics library doesn't remember anything about previous drawings. It sends it all directly to the GPU.

Well, it's not terribly fruitful yet as an operating system but as a machine it's very exciting. It's a hardware emulator that uses a monochrome display (running via IMGUI) with a 68k CPU. The hardware itself is based off of what you'd find in a Mac Plus, so there's a 512x342 pixel screen, a ROM, a couple megabytes of RAM, and some stuff that I haven't fully implemented yet like a hardware BitBlit system. The ROM contains most of my OSdev work so far, all it does is draw 16 "colors" to the screen which I've implemented through hardware level dithering. The ROM will eventually contain a full microkernel that doesn't multitask, multitasking is going to be implemented through a secondary system that's loaded off of storage. The emulator also has two VT100 terminals that are used for error logging and printing text (I picked VT100 cause it's cool and easy to write )

Sound nice! Is it open source?

[reapersms]

But what is immediate mode? I looked it up in the forum and the wiki, but didn't find anything. And I don't understand the two wikipedia articles (IMGUI and immediate mode). I also looked at the following page and still don't understand it:
https://docs.microsoft.com/en-us/window ... diate-mode

This is probably heading off topic, but...

As nexos mentioned, it generally means there is not a lot of retained state. For IMGUI, it borrowed the idea and term from ancient D3D. Around D3D/DX3, the API offered the low level Immediate mode, where you fed it data for raw triangles, every frame, along with any render state changes needed as they came along. This is more or less how OpenGL worked at the time, but D3D did it in a much more painful way. D3D used an Execute Buffer concept, where you fed it what was essentially a carefully constructed bytecode stream with inline data to render. Those buffers, in usual MS style, of course had to be reserved, allocated, locked, filled, unlocked, submitted, and collected. You were expected to either just know the appropriate size, or do a bunch of queries to determine it, and naturally the optimal size would vary depending on the workload, driver, and hardware. OpenGL just had you make a (admittedly large) number of function calls, and dealt with the buffering under the hood. The driver/hardware didn't do any fancy reordering or anything, it did everything in the order presented, and at one point or another, tended to do it more or less immediately while you were feeding it, aside from maybe requiring some sort of Flush call if you wanted to spin on some results.

To make dealing with D3D a bit more humane for mortals, MS also offered a Retained Mode that sat on top. Instead of dealing with raw triangles, you fed it actual meshes, and had them arranged into a persistent scene hierarchy, providing methods to mutate the hierarchy as needed. They would have associated textures and render states, and the API would figure out the ordering and nested transforms on its own. These days that sort of thing would be dealt with more in a framework or engine, but this was 1996, and the only engines that really counted were iD's and BUILD, and neither one did hardware rendering yet. Later on, the sort of stuff Retained Mode covered got resurrected as the XNA framework.

GUI frameworks and APIs traditionally work more like Retained Mode graphics. You create a bunch of widgets, feed them into the hierarchy, and the general updates are handled under the hood. Rendering tends to revolve around dirty rectangle updates, or something similar (like the Win32 Invalidate/Paint cycle), and everything tends towards a very event driven setup.

IMGUI applies something more like the Immediate Mode graphics API style to things. It doesn't keep track of anything from frame to frame, you tell it what things it should display that frame, and track it yourself. It very much derives from the traditional game loop where you're redrawing the entire thing each time anyways. Any and all state needed for rendering is grabbed on the spot, and there's no lifetimes or marshalling needed for things like a status display or such. It's original use case was lightweight, simple GUIs for editors, testbeds, and demos -- things like a model or animation viewer.

Which works better for a particular use case varies. If you are creating something that works very much like the things one of the frameworks provides, it might be better to stick with one of them -- though modern threading and such can make that a real pain, and all of the frameworks involve a significant amount of boilerplate code everyone just copy-pastes from stackoverflow. On the other hand, if you have some custom controls you'd want to provide, or are particular about how you keep the data around, immediate mode may make that a lot easier to deal with. It tends to mean you have to do a bunch of the framework level stuff (layout, input processing, etc) yourself, but generally allows it to be tailored for your specific circumstances.

[PeterX]

Thanks for the informations!

I think I understand it now.
- Immediate mode means telling what to draw. Like "draw a rectangle from 0/0 to 100/20; draw a point at 70/70".
- Retained mode means building widget or 3D structs/lists and activate them with a command. Like "Define Window1 -> button1 and button2; show()"

Greetings
Peter

[reapersms]

That is pretty much it. IMGUI-like things usually provide some helpers for drawing windows/buttons/etc, but the host application is expected to loop over something to call those.

[spotracite]

I should clarify that it's the emulator that's using IMGUI, not the operating system. The emulator spawns one window in whatever the host system is and uses IMGUI to draw a monitor window, a debugging window, and two teletype windows all of which are inside of the host system window. That way it's easy to make the emulator cross compatible and it's also good practice for other IMGUI applications.

Also, it's not open source because I plan on eventually submitting it as an extra credit assignment for school. However, it will likely become open source when it gets farther along!

[eekee]

I'm pretty sure read about the PlanB project some time ago. I thought it was pretty cool.

I've been thinking of going non-PC myself. I could design my own hardware, but I'm not really hardcore enough. I'm thinking of fairly powerful microcontrollers; not designed to be "complex enough" *cough cough* for an OS. Just tonight, reading threads about BIOS troubles and a new wiki page on UEFI, I've pretty-much decided on it. Graphics will likely be another microcontroller dynamically generating the video signal.

The other day, I tried to work out if I could get 1080x1920 with only 16KB video memory. I might be slightly insane, but I think if the video memory is RLE-compressed, it might just work. I think text will compress pretty well with the vertical scanlines. But I should be sensible, making the pixels longer and duplicating the scanlines. Or there's 512KB SRAM chips these days...

If there would be a real hardware computer like that, I'd probably buy it

There are some. I remember an FPGA-based device which simulates a variety of 80s/90s machines. It loads ROM images from SD cards, but it's otherwise a lot closer than an emulator because it sets up its FPGA to act like the original hardware. Another machine is compatible with the Atari ST, but more powerful. There's a lot of love for old hardware right now. I'd supply links but I've lost my notes on it. They're hard to find because search results are swamped by actual old hardware, new games for old hardware, and diy projects. It all comes under "retrocomputing". New accessories for old hardware might be a jumping-off point; I remember finding new versions of the weird plugs 8-bit Ataris had at the same time I learned about those computers. But speaking of DIY, if you know someone who likes soldering more than he likes programming...

[rdos]

I'm pretty sure read about the PlanB project some time ago. I thought it was pretty cool.

I've been thinking of going non-PC myself. I could design my own hardware, but I'm not really hardcore enough. I'm thinking of fairly powerful microcontrollers; not designed to be "complex enough" *cough cough* for an OS. Just tonight, reading threads about BIOS troubles and a new wiki page on UEFI, I've pretty-much decided on it. Graphics will likely be another microcontroller dynamically generating the video signal.

The other day, I tried to work out if I could get 1080x1920 with only 16KB video memory. I might be slightly insane, but I think if the video memory is RLE-compressed, it might just work. I think text will compress pretty well with the vertical scanlines. But I should be sensible, making the pixels longer and duplicating the scanlines. Or there's 512KB SRAM chips these days...

If there would be a real hardware computer like that, I'd probably buy it

There are some. I remember an FPGA-based device which simulates a variety of 80s/90s machines. It loads ROM images from SD cards, but it's otherwise a lot closer than an emulator because it sets up its FPGA to act like the original hardware. Another machine is compatible with the Atari ST, but more powerful. There's a lot of love for old hardware right now. I'd supply links but I've lost my notes on it. They're hard to find because search results are swamped by actual old hardware, new games for old hardware, and diy projects. It all comes under "retrocomputing". New accessories for old hardware might be a jumping-off point; I remember finding new versions of the weird plugs 8-bit Ataris had at the same time I learned about those computers. But speaking of DIY, if you know someone who likes soldering more than he likes programming...

I have a pretty advanced FPGA device that has Ethernet, Fibre interface, HDMI video interface, high speed ADC/DAC interface, USB, Micro SD-card interface, and an 8 lane PCI express interface. It's a pretty complex device on its own, but you need to program it with Verilog, and maybe a Verilog based OS is not such a good idea?

OTOH, you could also use it as a general peripheral and then implement the OS with whatever hardware you like as long as it has 8x PCI express. That has the advantage of learning both how to create complex hardware devices and OSes.