[HN Gopher] VTM: A Text-Based Desktop Environment
___________________________________________________________________
VTM: A Text-Based Desktop Environment
Author : mssdvd
Score : 413 points
Date : 2020-08-22 11:53 UTC (11 hours ago)
(HTM) web link (vtm.netxs.online)
(TXT) w3m dump (vtm.netxs.online)
| 29athrowaway wrote:
| The source code is just a file named "not ready yet". How is this
| open source?
| Shared404 wrote:
| Pretty sure that MIT doesn't mean that they have to put the
| code in a repo. Have you tried emailing them?
|
| Edit: Presumably they plan to put the code in a repo, but it's
| not ready yet.
| mysterydip wrote:
| Glad to see someone made this to save me the time! I've wondered
| if a TUI could replace some desktops for low end or embedded
| systems, or something to use on remoting into a datacenter etc.
| z3t4 wrote:
| Drawing text is the most expensive in a GUI.
| stjohnswarts wrote:
| I suggest running this on a server vs xfce/lxde/some other
| low overhead windows environment and get back with us on the
| overall load on the machine vs graphics. Holistically this is
| going to be a much smaller footprint.
| qayxc wrote:
| That's only true for TrueType Fonts in graphical mode.
|
| In text-mode, characters are "drawn" by simply writing their
| ASCII code point into VRAM and writing another byte (two
| 4-bit values really) in an additional "attribute" buffer to
| set the foreground and background colour.
|
| Programmers can swap out the default character set to provide
| their own typeface and graphical characters for use as window
| borders, shadows, etc.
|
| (S)VGA text-mode is as cheap as it gets in terms of
| computational complexity.
| ezoe wrote:
| Come on. We had long past the ASCII only era.
| FlyMoreRockets wrote:
| ASCII is eternal
| dividedbyzero wrote:
| Tell that to the French, Germans, Russians, Chinese,
| Japanese, Koreans, Spanish, Norwegians, etc. pp.
| naikrovek wrote:
| For people downvoting this guy, he's saying we're long
| past the ASCII era, and he is NOT saying we're long past
| the TEXT era.
|
| It's the America-centric ASCII stuff that we're past, not
| plain text itself.
|
| UTF-8 forever!
| iforgotpassword wrote:
| Depends. If you render it yourself in a frame buffer with
| anti aliasing and whatnot sure, but real text mode or using
| bitmap fonts is dirt cheap.
| Phil-bitplex wrote:
| True in the general case - but a fixed size font drawn in a
| grid over the screen? There's a lot you can to do make it
| very cheap
| rudolfwinestock wrote:
| Related: The MGR Window System https://hack.org/mc/mgr/
|
| "MGR provides each client window with: curses-like terminal
| control functions, graphics primitives such as line and circle
| drawing; facilities for manipulating bitmaps, fonts, icons, and
| pop-up menus; commands to reshape and position windows; and a
| message passing facility enabling client programs to rendezvous
| and exchange messages."
|
| Essentially, each window was a souped up ASCII terminal with
| extra escape sequences which implemented primitive graphics. It
| competed with X-Windows on low-end workstations during the 1980s.
|
| Discussion: https://news.ycombinator.com/item?id=18742611
| ilaksh wrote:
| Love it! I have a strange desire to try to make that work in
| WASM over HTTP/2 and hack in MGR server hyperlinks.
| 7thaccount wrote:
| Is this running on top of Windows and just replaces the GUI?
| ktpsns wrote:
| Nope, I guess this is a Linux or at least platform-independent
| command line interface program.
|
| You are probably confused by the powershell which seems to be
| available for multiple platforms nowadays, see
| https://aka.ms/pscore6
| moron4hire wrote:
| There's also a window claiming to be Windows' CMD. As I can't
| figure out how to enter text in any of these windows (I'm
| assuming it's disabled, otherwise CHAOS) I can't tell if it's
| just a vestigial window of if it's a true output.
|
| The topics on the Github repo list both Linux and Windows.
| The Readme calls itself "aka Monotty Desktop". That makes me
| think they may have written the code for the Mono runtime, so
| I'm expecting it's C#.
|
| I had played around with a similar idea in C# some months
| back, though I was targeting only Windows because it took
| P-Invoking into some Win32 APIs to get most of the
| functionality.
| cstross wrote:
| Powershell. But Microsoft ported Powershell to run on
| UNIX/Linux, so ...
| moron4hire wrote:
| I know the difference between PowerShell and CMD. And I
| know Microsoft ported PowerShell to Linux. You're not
| paying attention. Command Prompt is _also_ on display:
| https://dice.netxs.online/cloud/vtm/mde_banner.png
| 7thaccount wrote:
| Yep, I'm in the same boat as you. Part of it just looked
| like Linux running Powershell, but CMD threw me off.
| moron4hire wrote:
| When PowerShell runs on Linux, it doesn't show a "C:/"
| prompt. This is clearly running on Windows with WSL or
| Cygwin for the Unix tools.
| Abishek_Muthian wrote:
| I've been thinking about such text-based DE for custom Raspberry
| Pi nano based smartphone. Reason being, common mobile apps are
| not going to arrive for Linux and Nano is not powerful enough to
| run web browsers anyways; So why not a text-based DE or even just
| a console which enables basic communication features and Lynx for
| browsing?
|
| It would be great if we could get some GPU juice from Pi for text
| rendering in such environment like how iTerm2 does on macOS.
| ajford wrote:
| Are you talking about a Pi Zero? That can totally run a desktop
| environment and browser. Especially something light like XFCE
| or Enlightenment.
| submeta wrote:
| I came here expecting an article about my beloved Emacs ;)
| ravar wrote:
| serious question about exwm, how do you deal with a broken
| .emacs, and what about when you hang emacs?
| stjohnswarts wrote:
| I would suggest keeping around some versions :) I use git for
| this very reason locally when I'm futzing with settings, it's
| immeasurably handy for experimenters and config file junkies.
| ajarmst wrote:
| Same as any other WM (although I don't actually use exwm).
| Enable ssh for troubleshooting or use boot flags to boot to
| console.
| maxpro wrote:
| same here. didn't know there are other DEs besides Emacs
| mr_spothawk wrote:
| this is the maximalism that i come to hackernews to find.
| jdormit wrote:
| Might as well dive all the way in:
| https://github.com/ch11ng/exwm
| ajarmst wrote:
| Stumpwm would probably be attractive as well, because Lisp.
| http://stumpwm.github.io/
| ChrisMarshallNY wrote:
| Reminds me of the first edition of MS Windows.
|
| A lot of firmware systems still do their "windowing" like this.
| jefurii wrote:
| I love the lines connecting all the windows to a single point.
| Helps with the spatial relationships.
| cientifico wrote:
| Tip: If you want to escape from any ssh session you can press
| this sequence:
|
| 1. <Enter> Press Enter.
|
| 2. ~ Press Tilde.
|
| 3. . Press dot.
|
| This disconnects from the remote host.
|
| If you want more: `man ssh` and look for "ESCAPE CHARACTERS"
| rusk wrote:
| You can do ? instead of . and it will tell you what else it can
| do. Client side escape sequences. Handy to know!
| afranchuk wrote:
| I think the sequence is "<Enter>~.". I use it often.
| cientifico wrote:
| Thanks. Corrected.
| 411111111111111 wrote:
| why not use the logout shortcurt ^d ? this abort sequence is
| so much move involved vs just ^c ^d -ing
| rusk wrote:
| C^D instructs the server to disconnect you. With these
| tilde commands you are issuing client side instructions.
| EE84M3i wrote:
| This shortcut works even if the remote side isn't
| responding to ^c and/or ^d. It's handled by the local
| client. The two primary use cases I've found it useful are
| when I accidentally wedge the remote box by using up all of
| some resource or when some other event causes my network
| connection to hang and I don't want to wait for a timeout.
| 411111111111111 wrote:
| yeah, i was specifically confused about him having to use
| it often. it is sometimes useful, like when you're
| connected to the demo site and cba to figure out how to
| disconnect.
|
| but such situation are so rare that i was confused about
| the remark how often he uses it.
| EE84M3i wrote:
| I use it pretty often because I have SSH sessions that
| get messed up from (dis)connecting my VPN and I'm
| impatient.
| Ignacy-s wrote:
| If you do the first connection with mosh instead of ssh,
| it will survive vpn/wifi/4g roaming and even system
| hibernation. Assuming that first hop is a vps in the
| cloud with a stable connection, you can literally wake
| your pc from hibernation and once you get any Internet
| access, mosh will happily restore your "ssh" session for
| you.
|
| mosh.org: >Mosh will log the user in via SSH, then start
| a connection on a UDP port between 60000 and 61000.
|
| Needs at least a couple of ports in that range open,
| because old sessions tend to block ports until they are
| cleaned.
| EE84M3i wrote:
| I use mosh for personal stuff. My work does not allow
| mosh.
| dec0dedab0de wrote:
| I love things like this. Is it not released yet? A glance at the
| repo from my phone looks like there is no code yet.
|
| Does anyone remember Tandy Deskmate?
| city41 wrote:
| Here is a nice quick tour of Deskmate:
| https://www.youtube.com/watch?v=mYHtojsaRkY&t=9m47s
| Yuioup wrote:
| Tried to connect with Juice SSH on mobile and it looked quite ...
| abstract.
| sfgweilr4f wrote:
| Same with PuTTY on Windows. Its certainly colorful.
| mpweiher wrote:
| Also with Terminal.app from macOS...very..er..."colorful".
|
| https://www.dropbox.com/s/q52w26jsyv086hn/Screen%20Shot%2020...
| reaperducer wrote:
| Looks fun like that on iOS Prompt, too.
|
| Must be looking for ANSI instead of VT100.
|
| Mismatched emulator modes reminds me of BBS days.
| agumonkey wrote:
| I like that, a lot. For the low bandwidth only.
| exikyut wrote:
| > _" total sent: 56 878 123 bytes"_
|
| :/
| agumonkey wrote:
| aka one gif video on imgur
| ashton314 wrote:
| I once built something like this. There's a Perl library[1] that
| lets you control windows, dialogues, etc. My grasp on concepts
| like asynchronous programming, callbacks, process IO, etc. was
| nascent at best, so naturally this UI that I built was pretty
| terrible. I learned a ton though!
|
| [1]: https://metacpan.org/pod/Curses::UI
| beojan wrote:
| Not just Perl. Curses is what most TUIs on *nix are built in.
| It's a C library with a few different implementations.
| cycomanic wrote:
| This looks quite cool, but I don't think it's open source? I
| can't find any source code in the repository, there's just a
| single file called not_ready_yet.
| lokl wrote:
| The source might not be there, yet, but the MIT License is in
| the repo.
| trenchgun wrote:
| It is probably not ready yet.
| _emacsomancer_ wrote:
| I was at least hoping to see information about the language(s)
| used.
| [deleted]
| colordrops wrote:
| What's the point of overlapping windows in text? Seems that tmux
| already fits the bill for this use case.
| Skunkleton wrote:
| Its good to see experiments like this. Maybe this project won't
| be the next big thing, but maybe it will give someone an idea
| of what the next big thing should be.
| ajarmst wrote:
| The width of the display used in the screenshot appears to be
| less than 150 characters. Why would you add the clutter and
| distraction of _transparent_ windows with frame decorations in
| such a limited environment? 30% of the real estate is consumed by
| elements that don 't present any information to the user.
|
| On a modern display, this could far more productively be replaced
| with (1) any number of tiling WMs with console terminals in the
| panes (I use stumpwm for this), or---and you don't even need a
| GUI/WM for these---tmux or screen, or even emacs -nw, which give
| you a much more configurable and robust text-only environment. My
| normal working environment is a pretty heavily customized tmux
| (including powerline and full 256-color/unicode support) running
| on a machine that doesn't even have a GUI installed. (I do cheat
| a bit by using kmscon---or fbcon in the past---to get colour and
| font support on linux vttys.).
| egypturnash wrote:
| The demo video
| (https://www.youtube.com/watch?v=fLumnSctakY&feature=youtu.be)
| reveals that this is not just a traditional window manager for
| a static screen, it's got a much larger virtual canvas that the
| display can scroll around in. So there's a LOT more space to
| make an aesthetic decision for big, character-wide window
| frames.
|
| Seriously go watch the video, this thing feels like it's got a
| foot in the realm of UI roads not taken like Raskin's zoomable
| UI, text-mode is maybe more just a way to keep their focus on
| thinking about the interactions without having to worry about
| drawing a bunch of pretty widgets.
| ajarmst wrote:
| Yeah, I see it. I just don't get it. There's an awful lot of
| UX work being done to preserve an illusion that you have a
| bunch of fixed-size consoles that are arbitrarily arranged in
| a 2d space. Which, I guess, is the defining metaphor of GUI
| interfaces, but if that's what is desired, why create a
| console-only (if only in appearance) GUI? Text buffers in
| emacs or panes in screen or tmux can be made to have
| arbitrary size and dimension if you want to turn off wrapping
| and keep a longish scrollback. You can have as many buffers
| as you want, as many as your screen can accomodate visible at
| once and easily navigate them as you like. All you have to
| give up is the conceit that windows have independent physical
| size and location and embrace one that holds that you can
| have an arbitrary number of text buffers available to
| arrange, swap, hide, show, etc. Not trying to be nasty, but
| this feels like a bit of a cargo cult: someone stuck in the
| windows GUI metaphor trying to create a version of CLI
| metaphor they don't fully grasp. Of course, the fact that
| those of us who prefer the CLI metaphor are rapidly dying off
| is relevant here---but seizing all of the disadvantages of an
| all-text environment without any of the advantages seems ill-
| advised. That said, no one needs my approval. If this works
| for you (and I'll readily admit it's kind of cool), what do
| you care that I don't get it.
| z3t4 wrote:
| Typing text into a terminal/buffer is easy. But remembering
| all the shortcuts or cammands to resize and move windows in
| termux et.al is hard. Resizing and dragging with a mouse is
| easier (or fingers on a touch screen/interface)
| irq-1 wrote:
| Wow. The organizational lines and brightly colored windows
| make it look like a flower.
| subbz wrote:
| 80x24 is the default terminal height. I mostly use this size on
| all of my projects. It has many favors: compatibility
| everywhere, tiny bandwidth, etc.
| stjohnswarts wrote:
| Yeah, why did we ever stop using it as default for
| everything. I grow weary of graphics and options with said
| graphics.
| ajarmst wrote:
| And, of course, ed is the default editor. :-) I exert geek
| dominance over introduction to C students by demoing using ed
| to modify a source file. After which I amuse myself for the
| remainder of the term: "Source Control? Syntax highlighting?
| Luxury! When I was young we had to hand-magnetize knitting
| needles and edit files one bit at a time directly on a
| Winchester drive!"
|
| More seriously, I think the 80 column width is just too
| constraining with more modern languages that aren't remotely
| as terse as C-not to mention a limit that aggressively
| militates against in-line commenting. We also have monitors
| and fonts with resolutions that permit easily reading much
| denser use of the visual display. I mostly go with 120 chars
| now (in practice, that means that lines still won't wrap when
| I print source code files) and however many lines fit into
| the display pane.
| chrisseaton wrote:
| Things like borders may be empty of content but that doesn't
| mean they don't help you see and understand other content more
| easily.
| ajarmst wrote:
| Agreed. But using an entire character-width for that purpose
| is extravagant in this example (use of background colour
| would be better. Right now, some of those windows are !0%
| border). In a larger area, you can use unicode or even the
| drawing characters in MS 8-bit ASCII for a single-pixel
| hairline plus padding for both windows' text). I guess my
| take is that this is sacrificing an awful lot of real-estate
| to simulate overlapping windows, which is a feature of
| dubious utility in a pure text environment. "Users expect
| them" is probably the most common and egregious excuse for
| bad UX design, but I do understand why.
| throwawayForMe2 wrote:
| Along with DESQView and IBM's TopView as already mentioned, this
| reminded me of the first version of PC Smalltalk put out by
| Digitalk that was called "Smalltalk Methods". It was a character
| based windowed Smalltalk.
|
| This was quickly followed with the full bit mapped windowed
| Smalltalk/V. I believe all of this was when MS Windows still only
| had tiled windows without overlap.
| deltron3030 wrote:
| Isn't it similar to the rio windowing system from Plan 9?.
| forgotpwd16 wrote:
| rio is a graphical interface so not really. It is more like
| acme itself but with floating windows and translucency.
| lehi wrote:
| Emulating stacked translucency in a terminal is pretty
| interesting.
| peterisza wrote:
| Floating windows are worse than tiling imho
| person_of_color wrote:
| Until you want to work with media/creative apps.
| nsxwolf wrote:
| It looks like DESQView for MS-DOS.
| jmclnx wrote:
| I really liked DESQView, too bad the industry had to move to
| GUIs :(
| smusamashah wrote:
| This is amazing. Has there been anything like this before?
| DenisM wrote:
| Norton Commander / FAR commander.
|
| The latter is still in use and actively developed:
| https://www.farmanager.com/screenshots.php?l=en
| mightybyte wrote:
| Oh yeah. I'm going to date myself here, but I was just going to
| say this reminds me a lot of Borland Turbo C++ way back in the
| day. They had this thing called Turbo Vision for building text
| UIs. It seemed super cool back then.
|
| https://en.wikipedia.org/wiki/Turbo_Vision
| Phil-bitplex wrote:
| It was super cool!!! I had so much fun emulating it drawing
| single and double line text borders, with shadows. Oh ASCII
| chart how I miss thee.
| Minor49er wrote:
| It definitely was super cool. The windows had types, could be
| resized, had titles, dropdown menus, and form controls. The
| editor had syntax highlighting. And most importantly (at
| least for me at the time), there was a language reference
| included with the help system which had hyperlinking, so you
| could click through pages about the supported syntax and
| various topics, gleaning a wealth of information. All on DOS!
| makapuf wrote:
| Hypertext integrated help has been available earlier than
| turbo vision even. It has been available from turbo pascal
| 3 at least. For a young like me who ... copied it on two
| disks, it was awesome what you could learn.
| badsectoracula wrote:
| Turbo Pascal 3 didn't have integrated help (hypertext or
| not), it was introduced in Turbo Pascal 4 (which itself
| was AFAIK in general a big rewrite of the compiler and
| IDE).
|
| Though the integrated help really improved with version 6
| (when Turbo Vision was also introduced) since you could
| move a cursor freely inside the help window as if it was
| an editor, select and copy text, the help text was much
| more detailed and more organized and every
| function/procedure also had a small example showing its
| use (version 5.5 also had examples but the overall help
| was much more terse).
| makapuf wrote:
| Ah, maybe version 4. 5.5 was my favourite with objects.
| Later ones with turbo vision swapped on my 640k 8086.
| dewlinedew wrote:
| It had been open sourced i made a project using it:
|
| https://github.com/ivans5/BitMediaCentre
| guerrilla wrote:
| There are many tiling window managers for UNIXes and similar
| such things. There's also Plan9 which is in a sense text based.
| GrumpyNl wrote:
| Yep, around 1990
| Stratoscope wrote:
| 1985.
|
| https://en.wikipedia.org/wiki/IBM_TopView
|
| I had just started working at Gupta Technologies at the time,
| and for a short while we seriously considered developing for
| TopView instead of Windows.
| reaperducer wrote:
| Ashton-Tate did it with Framework in 1984.
|
| Though my memory is that it goes back a few years earlier
| to Valdocs on CP/M machines, but I can't find any pictures
| on the intarwebs.
| Stratoscope wrote:
| Framework was pretty great! My partner and I were working
| on some similar ideas at the time, and we got together
| with the Framework team to compare notes and brainstorm.
|
| The thing that stuck in my mind when Robert Carr took us
| on a tour of their office was the printer lab.
|
| It was a full size conference room with floor-to-ceiling
| shelves on every wall stacked with printers.
|
| Because back in those days, if you wanted to sell a DOS
| application that could print anything more than plain
| text, you had to write your own drivers for every printer
| you wanted to support. Ouch!
|
| I've sometimes thought that the real innovation in
| Windows 1.0 was having systemwide printer drivers so
| every app didn't have to provide their own.
| derefr wrote:
| Windows 1.0, while having a framebuffer-based layout engine,
| clearly evolved from a pure TUI, and retains elements (title
| bars, scroll bars, etc.) whose drawing algorithm _emulates_ a
| TUI within the framebuffer, by just drawing DOS-like lines or
| grids of box-drawing characters.
|
| In fact, it's only window _content_ that is arbitrarily
| graphical in Windows 1.0; if you only have DOS VMM windows
| open, you're essentially seeing a TUI, just with extra steps.
| Stratoscope wrote:
| Windows 1.0 didn't actually use box-drawing characters for
| any of this, of course. For example, the System menu in the
| top left corner of each window was three horizontal lines,
| just like a hamburger menu of today. Scrollbar buttons did
| not look like any box-drawing character.
|
| The Maximize button in the top right did look like a box-
| drawing character, but that's really about the only
| resemblance I see.
|
| (I developed a DOS GUI for email, Transend PC, in the early
| '80s that used box-drawing characters, and soon after started
| writing SQLWindows for Windows 1.0, so pretty familiar with
| both.)
| derefr wrote:
| Right, I'm not saying that the GUI was rendered using _the_
| DOS box-drawing characters, i.e. the monitor 's built-in
| codepage 437 text mode; nor were they using a monospace
| bitmap font _of_ codepage 437.
|
| What I'm saying, is that I'm pretty sure that a lot of the
| Windows 1.0 GUI was drawn by emulating the "technique" TUIs
| use to draw box-drawing characters, but on a framebuffer
| and with a custom (monospace) bitmap font:
|
| 1. create any-and-all graphical detail you need on screen,
| by repurposing the "leftover" parts of the bitmap font
| you're using to draw control-label text to the screen,
| adding a set of additional, custom symbol-drawing elements,
| which are all 'characters' of that bitmap font, and so all
| stuck being the same size+shape as the label text;
|
| 2. create a graphical "monospace text" drawing primitive,
| that takes as input a pair of buffers representing the text
| itself, and its hardware-text-mode-alike per-character
| drawing attributes (i.e. FG + BG color);
|
| 3. implement your OS widget library almost entirely in
| terms of calls into that graphical "monospace text" drawing
| primitive, passing a static data-section buffer holding the
| positional+attribute data for your box-drawing character.
|
| (For example, look at the drive icons in the File Manager.
| Those are just clearly just "text" composed of four
| drawing-element characters from the bitmap font, like this:
| [-=-]. So the whole drive-chooser area can be drawn with a
| single text-draw command, passing a string like "A[-=-]
| C[-=-] C: \WINDOWS".)
|
| -----
|
| You might say "but look at any screenshot of Windows 1.0 --
| the first thing you'll notice is that the menu-item labels
| in each window's menu bar are offset by a _half-character-
| width_ horizontally! And modal dialogs are, in their
| entirety, offset by a half-character horizontally _and_
| vertically! How 's that possible?"
|
| Well, the GUI "monospace text"-drawing primitive might be
| _drawing_ a grid of characters to the framebuffer; but it
| 's not drawing them _to_ an imaginary grid _on_ the
| framebuffer. It accepts an arbitrary pixel offset for where
| it should start to draw the block of monospace text.
|
| So, with that in mind, the algorithm for drawing the menu
| bar very likely has two passes:
|
| 1. render some box-drawing characters representing the
| "background" of the menu (i.e. yellow with a black border)
|
| 2. render a layer of regular non-box-drawing characters on
| top, offset by +4px on the X axis, in "black on
| transparent", representing the menu-item labels.
|
| It's pretty clear (to me, at least) how a drawing algorithm
| like this could be a natural _evolution_ and _outgrowth_ of
| a TUI: first, replace the TUI 's backing text buffer with a
| framebuffer, and the character-plotting calls with draw
| calls to a "draw monospace text character at emulated-grid
| position on framebuffer" primitive; then refactoring the
| draw calls to use a window-local coordinate basis; and only
| _then_ adding the ability to draw anything other than
| monospace characters--but gradually, starting only with
| defined grid-snapped "rich graphical content" regions
| within windows (sort of like how Windows today has
| "Direct3D drawing surface" regions); and then going back
| and gradually enhancing the GUI widgets with little
| flourishes like draw offsets.
|
| Within the Windows 1.0 codebase, I would bet money that--at
| least in some previous revision in early development--there
| was probably a #define flag for whether the "framebuffer
| driver" was enabled; and that all these windowing-system
| and common-controls drawing algorithms were written in a
| "hybrid" way where, instead of one TUI-based and an
| entirely-distinct framebuffer-based implementation, the
| framebuffer-based implementation is just #ifdef'ed
| ornamentation on top of the base TUI implementation.
| Stratoscope wrote:
| That's an interesting and creative theory. I have to
| admire your putting so much detailed thought into it! I
| mean this sincerely.
|
| Perhaps parts of the Windows 1.0 GUI _could_ have been
| implemented like that, but the truth is much simpler and
| more mundane.
|
| The bundled apps (including MS-DOS Executive) and the
| window decorations generally used the same GDI (Graphics
| Device Interface) calls as third party apps:
|
| Text was drawn with TextOut() or DrawText().
|
| Bitmaps were copied to the framebuffer with BitBlt() or
| StretchBlt().
|
| Lines were drawn with MoveTo() and LineTo().
|
| Rectangles were drawn with Rectangle() or RoundRect().
|
| This is not an exhaustive list but should give you the
| general idea.
|
| All of these functions operated on a "device context"
| (DC) that you obtained with functions like GetDC() or
| CreateCompatibleDC(). Some, like BitBlt(), used two DCs
| for the source and destination.
|
| The MS-DOS Executive drive icons were bitmaps drawn with
| BitBlt() with TextOut() for the drive letter. The
| selected drive letter and icon were inverted with
| InvertRect(), or possibly drawn with the DSTINVERT raster
| operation code.
|
| These are the same functions that any Windows application
| could use. The MS-DOS Executive was just another app.
|
| The non-client area of a window (titlebar and such) was
| drawn with the same GDI calls as the client area. Your
| app would get a WM_PAINT message to draw the client area
| and a WM_NCPAINT for the non-client area. Most apps
| passed WM_NCPAINT through to the default handler
| DefWindowProc().
|
| I was programming Windows apps starting with the first
| release of Windows 1.0. I spent a fair amount of time
| reverse engineering other Windows apps and Windows
| itself, along with people like Matt Pietrek and Andrew
| Schulman.
|
| Andrew in particular would have devoted an entire chapter
| of his book _Undocumented Windows_ to the text-based
| system you describe. It would be a field day for him!
|
| Also consider memory limitations and programmer time.
| Remember that Windows 1.0 ran (slowly) on a machine with
| 256KB memory and two floppy drives.
|
| Since they had to build GDI anyway, it would take more
| memory to also include this text-based system. It also
| would have taken more developer time, and provided less
| testing of the public APIs.
|
| But again I do appreciate your interesting speculation!
| edwinyzh wrote:
| It's very cool!
| ape4 wrote:
| I just ssh-ed in, there are multiple users, its crazy!
| blarglechien wrote:
| same, but I will come back later to actually try it. Right now
| it's displaying a bunch of colors and strobing really hard. Not
| sure what's happening.
| LukeShu wrote:
| Try a different terminal. It does that for me in URxvt, but
| works fine in xterm.
| raintrees wrote:
| This reminds me of the DOS menuing system we used to install on
| clients' computers several decades ago. Cannot remember the name,
| may have to dig out my old 5 1/4" floppy collection binder I used
| to always carry with me if not remembering starts to drive me
| crazy...
|
| That system remapped the function keys to launch batch files or
| call up sub-menus... Easiest way (at the time) to "customize"
| peoples' computers for them...
| otoburb wrote:
| VDOS/Norton Commander[1] jumps to mind when I read your
| description, except that was more popular when everybody was
| migrating to 3.5" floppies.
|
| [1] https://en.wikipedia.org/wiki/Norton_Commander
| stjohnswarts wrote:
| It was very common on some of the old vt220(etc) terminals to
| have menus and windows and such. However I never saw anything
| like this :) . Can't imagine those 9600 baud terminals having
| fun with all of this haha
| nocman wrote:
| like Borland Sidekick?
|
| https://en.wikipedia.org/wiki/Borland_Sidekick
| raintrees wrote:
| Ah, SideKick... TSR hell days...
|
| No, went and looked through my little 5 1/4 binder, not sure
| I still have the menu utility...
|
| But for those of you who were doing this back in 1991, here
| is a list of the utils I carried on 5 1/4":
|
| Gibson's SpinRite
|
| MS-DOS 6.22
|
| pcAnywhere 5.0
|
| PKUnzip 2.04G
|
| Everex - The Edge Utility (BIOS settings app)
|
| Easy Data 286 Setup for 10-12MHz
|
| Laser Digital Phoenix Setup
|
| Wyse Tech - Setup & Test
|
| IBM Diags PC/AT
|
| Utron Inc - Neat 286 Setup Disk
|
| Misc. Novell files
|
| QEMM 386 5.10
|
| Brief 2.0
|
| SuperStor V2.04
|
| XTreeGold
|
| Mountain Tape (tape backup)
|
| Norton Utils 5.0
|
| ProComm Plus
|
| Intel Satisfaction
|
| MicroHouse IDE
|
| Diagnose
|
| DOS 5.0
|
| DOS 3.3
|
| Checkit 3.0
|
| Scan80, Clean80, CPAV
|
| Norton Antivirus
|
| LapLink III
|
| And somewhere in my office I still have the multiple boxes of
| 3 1/2" disks, both the 10 disks boxes, and bigger 100 Disk
| box, that saw a lot of wear and tear in my backpack - I
| skateboarded to clients around Santa Cruz, so everything had
| to fit into my backpack at the time.
| globuous wrote:
| Insane.
|
| Well done brother ;)
| didip wrote:
| I am curious, how does it render images/videos?
| mixmastamyk wrote:
| Yes it does have some support, though the resolution is low.
| emilfihlman wrote:
| The demo doesn't seemt to work on putty
| moron4hire wrote:
| Worked fine for me in PuTTY.
| sfgweilr4f wrote:
| What settings? Mines more like an abstract color art piece
| but not so much a desktop environment.
| moron4hire wrote:
| IDK, Default? I'm on PuTTY 0.73. I haven't changed anything
| since I installed it.
| xellisx wrote:
| 0.74 is out
| forgotpwd16 wrote:
| Same on urxvt. Probably requires true color support. I had
| the same issue with browsh, a text front-end to Firefox.
| emilfihlman wrote:
| Same here
| bobuk wrote:
| Looks like a modern version of twin
| https://github.com/cosmos72/twin
| exikyut wrote:
| Ha, you beat me by a minute :D I agree!
| exikyut wrote:
| Reminds me of
| https://en.wikipedia.org/wiki/Twin_(windowing_system),
| https://github.com/cosmos72/twin/
___________________________________________________________________
(page generated 2020-08-22 23:00 UTC)