Ask HN: Examples of desktop software with 20+ years of longevity?

66 points by open-source-ux ↗ HN
Some desktop apps have been developed for 20+ years and still running and available. There are not many desktop apps with longevity (and rewrites).

Examples of apps still available:

- Quarx: QuarkXPress (1987)

- Corel: WordPerfect (bought by Corel in 1996), CorelDraw (1989)

- Xara: Xara (1994) - a Windows vector illustration app still in development

- Fontlab: Fontlab (1993 for Windows)

- Bare Bones Software: BBEdit (1993)

- UltraEdit: UltraEdit (1994)

- Borland/Embarcadero: Delphi (1995)

- Fantaisie Software: PureBasic (2000 for Windows)

- IBM/Eclipse Foundation: Eclipse (2001)

What other examples of desktop apps 20+ years old and still in development? (Excluding Microsoft, Apple and Adobe examples because everyone recognise their apps.)

127 comments

[ 2.9 ms ] story [ 167 ms ] thread
Vmware workstation, released 1999
The parasolid geometrical kernel is from the 80's, underlies many of the major CAD products today. Same for Dassault's ACIS and its lineage.

Also: VLC, Matlab, Mathematica, many of the major DAW programs like Cubase

My mind immediately jumped to CAD (that being my domain)

While a lot of packages have come and gone, the heavy hitters have been around a while:

  Siemens NX (Unigraphics) 1973
  DS CATIA 1982
  Autodesk AutoCAD 1982
  PTC Creo (Pro/Engineer) 1987
The baby of the bunch is DS Solidworks 1995, still 27 years.
Notepad++ is close: https://en.wikipedia.org/wiki/Notepad%2B%2B, 19 years ago. It's text editing engine, Scintilla, is 24 years old https://en.wikipedia.org/wiki/Scintilla_(software)

Staroffice which became OpenOffice and Then Libreoffice would be another

AutoCAD is 40 years old

I love Notepad++. I dual-boot Windows and Linux and on Linux side it's all fancy neovim setups. But when I boot Windows to play games, it's always Notepad++ I use to edit game mods or their configuration etc.

Happy to see it's still maintained, according to Wikipedia, last update this month. Even happier to see it's open source(!?) I can't remember if it was always open source or if it became open source at some point.

On Linux, I use Kate, the (imo superior) Notepad++. It even has vim bindings (which I turn on accidentally and then have to burn the editor with fire until it stops)!
Does Kate have a function list panel that supports Markdown headings? And the ability to define projects that include files from all over the file system rather than just one directory? Those are killer NP++ features for me.
I have similar fond memories. I think it's the first development tool I ever paid for, and I do think I paid for it.

There was another editor that I liked at that time, though, and it's possible I'm confusing which one I paid for. But Notepad++ won in the end.

Emacs comes to mind: it has a codebase stretching back to the 1970s and is still actively developed, with a dedicated following of users (myself included).
Emacs is not really the classical desktop-app. It's a terminal-app that just happened to also have a GUI.
I think most people use it with the GUI, and the GUI version has features that the terminal-only version doesn't.
I also use the GUI, because of additional keys supported by it. But like most(?) people, I've deactivated the GUI-elements, as they are pretty useless. But ok, I guess it could be called a desktop-app because of this.
I also routinely rely on the GUI version’s ability to display images inlined in the buffer. It is true that it doesn’t have the UX of other, newer GUIs, but it is still meaningfully different from the terminal version.
Well, technically, this depends on the environment and is also working in proper terminal. But all the proper terminals are AFAIK GUI-terminals, so it's a thin line I guess.
Or perhaps an operating system just missing a good text editor ;-)

(to be clear, I love emacs, and use spacemacs as my distro!)

I consider any user-facing application that presents its own interface and that a user runs on their own computer a desktop-app. Whether the UI gets rounded corners, animations and smooth scrolling is not important, and neither is whether your UI elements are submitted for display through an Wayland/X11 socket or through command sequences over stdout.
By that logic, any android or iOS-app would be also a desktop-application. As also any DOS-App and anything with curse-interface. What about interactive commandline-apps? Like a database-shell? They also have their own interface, it's just made of text.
Any DOS app with a curses interface is a desktop application, yes. Any terminal tool with a TUI is a desktop application. A command-line tool without an interface (just arguments and pipes) is not, because it does not aim to be interactive. A terminal tool that just asks questions is a bad desktop applications, but simple form apps exist in the GUI world too.

All UIs are made of text and symbolic visual elements. Whether you draw your button with unicode block characters, a GtkButton, a Flutter TextButton, or a HTML <button> does not matter in the slightest from the perspective of being a desktop app or having a UI.

The reason an Android an iOS app is not a desktop app is because it does not run on a desktop. A minor distinction, but the way we use our pocket computers is different from how we use our desk computers and so we distinguish between them. The line gets beautifully blurred once you run the iOS app on macOS or Android app on Windows 11, but humans are bad at categorizing things in ways that remain consistent for more than a few years - just ask any biologist.

> Any DOS app with a curses interface is a desktop application, yes. Any terminal tool with a TUI is a desktop application. A command-line tool without an interface (just arguments and pipes) is not, because it does not aim to be interactive. A terminal tool that just asks questions is a bad desktop applications, but simple form apps exist in the GUI world too.

Ok, fair, but a very unusual definition.

> All UIs are made of text and symbolic visual elements. Whether you draw your button with unicode block characters, a GtkButton, a Flutter TextButton, or a HTML <button> does not matter in the slightest from the perspective of being a desktop app or having a UI.

But it does matter for a _G_UI whether you have actual graphical elements, or just text. There is a significant differences in ability coming with those.

> The reason an Android an iOS app is not a desktop app is because it does not run on a desktop. A minor distinction, but the way we use our pocket computers is different from how we use our desk computers and so we distinguish between them.

Android and iOS do not run only on smartphones. People working on tablets, use them similar to the normal laptop/notebook/PC table-setup. Taking a classical PC-Desktop as the base of your definition falls apart very fast today.

> humans are bad at categorizing things in ways that remain consistent for more than a few years - just ask any biologist.

The established definition of desktop, mobile, gui, tui and commandline is pretty consistent for some decades now I would say.

I would say that the distinction between TUI and GUI - outside "how would I use this tool remotely" - is mainly one for the developer. Take ImGui (https://github.com/ocornut/imgui, an immediate mode GUI library) for example - the examples are much closer to TUI interfaces than a Swift UI app - the only difference between that an a terminal UI would be that the lines are thinner and that text has non-uniform spacing.

Does that make ImGui a TUI? Or make TUIs a GUI? Why are those thin visual lines graphical, if the slightly thicker visual lines drawn by your graphical terminal emulator with support arbitrary color precision and inline image rendition is not?

Maybe the issue is that it there is a terminal emulator to visualize the representation. But if an application that is not graphically heavy and needs an intermediary is a TUI, does that make most utility electron apps TUIs?

The difference between a TUI and a GUI is just an implementation detail, and these do not matter in the distinction of desktop app or not. Heck, some modern terminal UIs are more graphically appealing than some GUI apps.

And remember, the question was about desktop, not GUI specifically.

> The established definition of desktop, mobile, gui, tui and commandline is pretty consistent for some decades now I would say.

Considering that all good desktop apps were TUI apps 3 decades ago, that mobile apps are in their modern form has basically only existed for 1.5 decades, and that running mobile apps as desktop apps and the general merge between the disciplines is only a few years old at most, I'd say that this statement doesn't quite hold.

> Take ImGui (https://github.com/ocornut/imgui, an immediate mode GUI library) for example - the examples are much closer to TUI interfaces than a Swift UI app - the only difference between that an a terminal UI would be that the lines are thinner and that text has non-uniform spacing.

What I see there is a spatial interface with complex layout, z-axis and graphical elements. A bit hard to replicate on a normal terminal.

> Does that make ImGui a TUI?

TUI and GUI are not defined by the actual complexity of a real application, but the environment which gives them theoretical abilities. With a GUI, you can have pixel-perfect control over every element. With a TUI, you are normally limited to character-level of control. Of course can you also use pixels without a desktop, but you would still leave the terminal-environment and enter the framebuffer for this or something similar. Though, to be fair, at this point it indeed can become a bit fuzzy.

> With a GUI, you can have pixel-perfect control over every element. With a TUI, you are normally limited to character-level of control.

So when I have pixel-perfect content render in a terminal emulator through Sixel graphics, and have inconsistent font rendition and problematic CSS box wrapping in a Web or Electron app, does that make the former GUI and the latter TUI? ;)

> TUI and GUI are not defined by the actual complexity of a real application, but the environment which gives them theoretical abilities.

And indeed, this gets to my point. The difference between a GUI and a TUI framework is more akin of the difference between, say, SwiftUI and WinForms, than something presenting a different mental model or experience for users. There are aesthetic differences, but there are just as stark differences between Win32, Aero, Metro and Sun Valley Windows GUI styles.

Sure, modern GUI applications can do more, but no user cares that Outlook could have had pressure-sensitive, angle-dependent Wacom tablet tool integration, and no so user would care that a TUI email client can't.

Emacs by default can show images. With Exwm can be your window manager. With EMMS, your audio and video player. With doc-view and even more, with PDF-tools, your document viewer. With Org-Mode, your brain on stereoids. With ERC, your IRC client. With Telega, your Telegram client. With Malyon, your Z-Machine interpreter. With M-x Calc and Gnuplot, your CAS lite. With Maxima and Texlive, your medium CAS with inline equation output and plotting.
Basically creative suites:

- Photoshop

- Gimp

- Blender

- Maya 3D

- 3ds Max

- Audacity

- Ableton Live

Office stuff:

- Microsoft Office

- SAP ERPs

This was my first thought. I remember using Photoshop in the 1990s.
Reason (music making software). Released in 2000 and still an actively developed code base. Still some code from 23 years ago running in production :)
music software is a full field of long-running products:

Cubase: 1989

Pro Tools: 1991

Logic Pro: 1993

FL Studio: 1997

Ableton Live: 2001

Max/MXP: 1980s, 90s as commercial product

Also notation software:

Musescore 2002

Sibelius 1993

Encore 1984

Finale 1988

FL Studio (aka Fruity Loops)

>The first version of FruityLoops (1.0.0) was developed by Didier Dambrin and was partially released on December 18, 1997.[13] Its official launch was in early 1998

This is very normal in the open source world: Half of the desktop software included in a modern Linux distro I was using in the late 90s!

From memory: VLC, GIMP, Blender, Audacity, Firefox, Gedit, OpenOffice, XBMC (now Kodi), FileZilla - the list is HUGE

Find your favourites here: https://en.wikipedia.org/wiki/List_of_free_and_open-source_s...

Emacs is from the 80s. (vi probably older, but it might be considered more different from a modern vim.)
Wikipedia says that vi was first released in 1976.
Vim is not Vi. It's a project that initially emulated its behaviour and then extended it. So I would say that Vim is from 1991.
Vim was a fork of the Amiga port of Stevie which was first released in 1987.
(comment deleted)
mIRC

Initial release date: February 28, 1995

(comment deleted)
Beyond Compare by Scooter Software.

Beyond Compare is perfect software (in my not so humble opinion). I use it every day.

https://www.scootersoftware.com/

I used it 20 years ago when I was forced to use Windows and Windows had zero adequate tooling for software development. For 15 the last years I have used only Linux and getting proprietary software feels very remote. I can get more than I'll ever be able to learn with just a single installation command.
(comment deleted)
I think a lot of b2b ERP software gets to be this old. I know of multiple.
Supermemo v7, Piotr Wozniak's spaced repetition (and a bunch of other things) platform, was rewritten in Turbo Pascal in 1993. The most recent version, 18, is an obvious continuation of the same interface (to me, the most striking difference from Windows 3.1 to modern is window decorations).

https://supermemo.guru/wiki/SuperMemo_7

Cubase (1989) DAW

Finale (1988) Music notation software

I finally released version 2.0 of my own desktop software after 10 years development (Free SQL tool): https://www.timestored.com/b/qstudio-2-05-dark-theme-and-hig... 1.0 supported one database only, 2.0 added postgres/mysql/etc. so felt like the time to bump versions :) It's been the same code base in java that whole time, no big rewrites. I guess it helps that I was working in the SQL area for 5 years before writing the tool, so I knew what I wanted. I must say java/jfreechart/swing have kept working perfectly all this time with very minor changes. The most painful was a)xstream/logging/security vulneribilities causing dependency changes b) misc.sun deprecation, I used internal class DSA for encryption of license keys, had to migrate users to new keys. Changing a contract with users is always painful. I'm very very glad that I automated tests from the start, it's the only thing that catches edge cases I've forgotten after all this time.