Why build another CLI editor? What motivated us to build Edit was the need for a default CLI text editor in 64-bit versions of Windows. 32-bit versions of Windows ship with the MS-DOS editor, but 64-bit versions do not have a CLI editor installed inbox. From there, we narrowed down our options… Many of you are probably familiar with the “How do I exit vim?” meme. While it is relatively simple to learn the magic exit incantation, it’s certainly not a coincidence that this often turns up as a stumbling block for new and old programmers. Because we wanted to avoid this for a built-in default editor, we decided that we wanted a modeless editor for Windows (versus a modal editor where new users would have to remember different modes of operation and how to switch between them).
This unfortunately limited our choices to a list of editors that either had no first-party support for Windows or were too big to bundle them with every version of the OS. As a result, Edit was born.
TL;DR: We tried nothing and were all out of options.
The name was voted by the community. There were a lot of very good names that unfortunately were already being used by other projects. I'm not a fan of the final choice either.
Only ever interacted with 6.0 beta. It was a great microkernel system. Even its GUI, Photon, was of a microkernel design, each module operating as a separate process. And it looked so good.
Technically yes. But it can't support many hard real-time use cases. For that you need a true RTOS, thought from the ground up for that purpose. Something like VxWorks, QNX, some flavors of L4.
Yup. If it isn't a friendly neighborhood jumping spider, I'm bringing a cup and a piece of paper and it's out with the spider. Not risking the life of my tiny dog.
Why didn't they write this instead of the BS above?