It's Motif on VMS, which is not remotely UNIX-like
eventually HPE got tired of dealing with VMS customer requests and sold the rights to VMS Software Inc, who ported it from Itanium to x86 as soon as humanly possible
now VMS Software Inc, is stating that they wish to support ye olde DECWindows and Motif on the modern, x86-enabled VMS
OpenVMS was UNIX-certified, so it's like UNIX enough to have the trademark.
Of course the UNIX stuff ran on top of the VMS stuff, and the early 1990s X11 stuff run on top of that. You can run CDE on Windows or Mac too, I don't see what's interesting about it.
That's a cruel alternate universe, I would've hoped that Motif being in use by more people than just the devs of one homebrew Unix desktop would mean that we wouldn't have suffered through that much versionitis.
The version number was just a joke. But if the "standard unix gui toolkit" was under an open source license back in the 1990s, I am sure people would have run with that rather than inventing something else.
from 1989 to 2005 everyone used more or less the same version (from 1989) because vendors and standards are painful
it wasn't like, meaningfully standardized. just no one ever updated anything. or set a meaningful version string. you just guessed which bugs were un-fixed based on `uname`
I miss Motif. This is a portal to a time when men were men and UNIX(R)—or in this case, VMS—desktops were utilitarian and did exactly what you needed and nothing more.
Now we live in a time where we allocate GBs of RAM to eye candy that functionally accomplishes nothing. Then we make the case to rewrite the eye candy in increasingly "safe" languages, requiring even more RAM.
"did exactly what you needed and nothing more" You can still do that. Build a config for openbox or dwm. While the wm still compiles you can ignore the fads.
> Now we live in a time where we allocate GBs of RAM to eye candy that functionally accomplishes nothing.
Well, of course it takes more ram when we run 4x the pixels for the same size screen. And we double the refresh rate, but then hold everything back a frame to composite it. :P
I think the one frame delay is due to X11 clients rendering a frame, then the X compositor rendering a frame, both according to the usual timing rules. With Wayland, it should be easier for client and compositor to render in the same frame interval because the compositor properly controls frame timing. It can just tell clients to render slightly early, then use the remaining few milliseconds for compositing.
The Motif default theme was quite handsome, and the "demo" Motif Window Manager worked pretty well, but Motif was something of a nightmare to work with
The API sucks real bad, and even at the height of Motif popularity, the package itself was riddled with bugs because proprietary UNIX vendors never updated that shit
Motif was super-obviously designed by C++ programmers who could not ship a C++ library for technical reasons. So they tried to do a C++ API in C. And it hurts like a pineapple thrust into the wrong orifice, leafy-part-first.
I'm rather tempted. I'm funemployed at the moment and live over in Stockholm so it's just a (long) train journey away. I used to enjoy messing around on Vaxen in my college days.
I can't see myself ever using VMS professionally though, and it has a somewhat vague description of the actual content. It's not super expensive but I'd have to fork out for the travel and accommodation.
I'd love to hear about it if anyone does a write-up after the fact.
I used to work for a convention planning company, so I shouldn't be surprised, but I somehow am surprised that there are enough VMS users to justify a conference. I have genuinely not heard of anyone using VMS in any context in more than twenty years.
So, I guess the history of 'windows NT' is lost on many. 'NT' started with version 3.1 as the MS/IBM breakup from the joint OS/2 venture happened. It was their first real push into 32 bit protected mode operating systems and supported really crazy cool things like 'multiple processors' and totally different architectures than x86, like DEC. Give the link a look.
the common element between VMS (the subject of this post) and Windows NT, is Dave cutler.
Cutler lived in an extremely overcomplicated world of VMS kernel primitives, and given the chance to let his freak flag fly, he really overcomplicated his past work for Windows NT
In case you ever wonder why your 1 gb/s ssd has ~100 mb/s throughput on windows. there are often quite literally hundreds of layers of filters on even the simplest i/o
but it is super flexible! just slower than iced treacle. aren't you glad you had an object oriented I/O subsystem supporting microkernel services and aspect-oriented programming? i bet you use those features way more often than you read or write files from disk
Edit: the previous poster has since completely rewritten this comment to talk about windows NT. they originally talked about Windows (without the NT) then linked to an NT wiki. Hence my reply.
I put '[edit]' and new comments below that and didn't edit anything above, including the link. The post above the edit is all original. I'm sorry you have been confused through this.
I think NT is correct; NT was designed by Dave Cutler, who famously worked on VMS stuff before working for Microsoft. I think the poster was correct in posting NT.
I purchased a copy of OSF Motif for Linux (x86) sometime in the early 1990's (before it was free). I had used it before on SunOS and I liked it.
One of the most annoying things about it was that it did not address the endianness of the arguments to the library functions. So it worked fine on big endian platforms, but not so fine on little endian ones (such as Intel).
It would still work okay if you byte swapped the arguments in and out of the library functions, but it just seemed silly to need to do that, and it made it more difficult to write portable code.
Readit News
https://sourceforge.net/projects/motif/files/
https://en.wikipedia.org/wiki/Motif_%28software%29
(in some alternate universe, motif was under the x11 license and you would have motif v13 instead of GTK.)
eventually HPE got tired of dealing with VMS customer requests and sold the rights to VMS Software Inc, who ported it from Itanium to x86 as soon as humanly possible
now VMS Software Inc, is stating that they wish to support ye olde DECWindows and Motif on the modern, x86-enabled VMS
> VMS, which is not remotely UNIX-like
OpenVMS was UNIX-certified, so it's like UNIX enough to have the trademark.
Of course the UNIX stuff ran on top of the VMS stuff, and the early 1990s X11 stuff run on top of that. You can run CDE on Windows or Mac too, I don't see what's interesting about it.
from 1989 to 2005 everyone used more or less the same version (from 1989) because vendors and standards are painful
it wasn't like, meaningfully standardized. just no one ever updated anything. or set a meaningful version string. you just guessed which bugs were un-fixed based on `uname`
Now we live in a time where we allocate GBs of RAM to eye candy that functionally accomplishes nothing. Then we make the case to rewrite the eye candy in increasingly "safe" languages, requiring even more RAM.
Which contrary to UNIX did not had the C mistake.
Rather Structured BASIC, Extended Pascal, COBOL, Modula-2, Fortran and Bliss.
It is really sloppy programming nowadays, regardless of the languages.
Well, of course it takes more ram when we run 4x the pixels for the same size screen. And we double the refresh rate, but then hold everything back a frame to composite it. :P
The API sucks real bad, and even at the height of Motif popularity, the package itself was riddled with bugs because proprietary UNIX vendors never updated that shit
Motif was super-obviously designed by C++ programmers who could not ship a C++ library for technical reasons. So they tried to do a C++ API in C. And it hurts like a pineapple thrust into the wrong orifice, leafy-part-first.
Enhanced Motif Window Manager https://fastestcode.org/emwm.html
and the full-fledged CDE desktop that uses Motif also:
https://sourceforge.net/projects/cdesktopenv/ (note that you want to firewall this somehow as the default settings on the background process ttdb can be a security hole)
[1] https://events.vmssoftware.com/bootcamp-malmo-2026
I can't see myself ever using VMS professionally though, and it has a somewhat vague description of the actual content. It's not super expensive but I'd have to fork out for the travel and accommodation.
I'd love to hear about it if anyone does a write-up after the fact.
https://en.wikipedia.org/wiki/Windows_NT_3.1
[edit]
So, I guess the history of 'windows NT' is lost on many. 'NT' started with version 3.1 as the MS/IBM breakup from the joint OS/2 venture happened. It was their first real push into 32 bit protected mode operating systems and supported really crazy cool things like 'multiple processors' and totally different architectures than x86, like DEC. Give the link a look.
Cutler lived in an extremely overcomplicated world of VMS kernel primitives, and given the chance to let his freak flag fly, he really overcomplicated his past work for Windows NT
In case you ever wonder why your 1 gb/s ssd has ~100 mb/s throughput on windows. there are often quite literally hundreds of layers of filters on even the simplest i/o
but it is super flexible! just slower than iced treacle. aren't you glad you had an object oriented I/O subsystem supporting microkernel services and aspect-oriented programming? i bet you use those features way more often than you read or write files from disk
They were entirely different OSs.
Edit: the previous poster has since completely rewritten this comment to talk about windows NT. they originally talked about Windows (without the NT) then linked to an NT wiki. Hence my reply.
@OP Poor show on your ninja edit.
One of the most annoying things about it was that it did not address the endianness of the arguments to the library functions. So it worked fine on big endian platforms, but not so fine on little endian ones (such as Intel).
It would still work okay if you byte swapped the arguments in and out of the library functions, but it just seemed silly to need to do that, and it made it more difficult to write portable code.
https://access.redhat.com/solutions/6113101
which would be unremarkable except none of the UNIX vendors has produced a new build in like 30 years
so if they are still shipping CDE it is probably 32 bit binaries from AIX 4 or AIX 5L
it can take literally decades for a deprecated package to actually get removed, because customers get mad
The entire 32-bit subsystem (multilib) is also removed from rhel10.
Deleted Comment