Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Screenshots of Old Desktop OSes

typewritten.org

Post reply on HN
Print view View original

201–210 of 407 posts

Re: Screenshots of Old Desktop OSes

#201

Post by otherme123 »

hecifato wrote: post #153
skydhash wrote: post #107

Earlier quoted context omitted.

My pet peeve is spacing. My usual resolution is 1920x1080 (scaled or not) and it feels I could cram more information in an old 1024x768 desktop. You have to maximize most windows to get it to show enough information.

This drives me crazy. Even looking at these old screenshots you just know that these systems we outputting a display resolution lower than 1024x768. When I was checking out the MacBook Neo a while back I was disappointed that the resolution is not natively x2 scaled. It uses fractional scaling when macOS handles fractional scaling quite poorly. I've set the resolution on my M1 MBP to 1280x800 so it was x2 scaled and…

[dead]

Re: Screenshots of Old Desktop OSes

#202

Post by abanana »

daneel_w wrote: post #164
abanana wrote: post #110

Earlier quoted context omitted.

Regarding Amiga screenshots, they've taken care to get the DigiPaint aspect ratios right, but the Workbench 2.04 screenshot is in a resolution that comes from an add-in graphics card rather than the Amiga's custom chips. It's a resolution Workbench wasn't graphically designed for, so it looked wrong in such a resolution at the time. If you double the screenshot's height, then everything (text, icons, window gadgets e…

The aspect ratio is correct on all screenshots and are accurate de-interlaced representations of a 640x400/512 workbench setup, even though these particular screenshots are in RTG dimensions. Starting with ECS, the Amiga was also capable of true non-interlaced 640x400 output (and even 480 vertical lines unless I misremember) in what was commonly called "productivity mode", limited to 4 colors (2 bitplanes). Interlace…

> The aspect ratio is correct

Yes it is, was my post unclear? Following your suggestion that someone might contribute a screenshot of 1.x, which I agree would be a nice addition, I'm suggesting a "HiRes" screenshot of 2.x or 3.x would be a better representation of how it looked in-period to the vast majority of users. The point is just that the icons, text, and general UI chrome were designed for that lower vertical resolution.

I ran the interlaced modes later after buying a flicker-fixer, but didn't know of anyone who used them without one - the flicker meant those interlaced modes weren't generally considered to be very usable.

Re: Screenshots of Old Desktop OSes

#203

Post by thesuitonym »

BoppreH wrote: post #168
thesuitonym wrote: post #162

Earlier quoted context omitted.

Titlebar buttons are actually bad. The titlebar exists (or existed) for a reason, so you'd have somewhere you could grab to manipulate the window. Now it's kind of a guessing game with every app on where you can grab without causing the app to do something you didn't want.

If that's a problem for you, you have much to gain with better window management shortcuts. On KDE I have the Windows key + left click set to drag a window from anywhere , and win + right click to resize depending on the quadrant the cursor is on. It's incredibly satisfying not having to hunt titlebar empty spaces or thin edges.

fwiw, when I'm on an OpenBSD desktop, I use cwm which doesn't supply titlebars, and I use Meta+click to move windows. That's great...On OpenBSD. But sometimes I'm using a Windows computer. Sometimes I'm using a Mac.

...And sometimes I'm using OpenBSD, so titlebar buttons introduce a titlebar I didn't want, and didn't need, which doesn't match the rest of my desktop customizations.

It's just a bad paradigm.

Re: Screenshots of Old Desktop OSes

#204

Post by WillAdams »

masfuerte wrote: post #152
WillAdams wrote: post #102

Earlier quoted context omitted.

Older OSs had pixel fonts, which were carefully hand-crafted --- vector fonts were something which folks dreamed about having, or which were accessed when using incredibly expensive printers. Font rendering on Windows 3.11 was pretty decent, so long as one used the nicer TrueType fonts --- Times New Roman and Arial had man _years_ of hinting effort by Monotype which kicked in at typically screen sizes --- that said,…

RISC OS (1987) had built-in support for anti-aliased vector fonts, though they aren't shown in the screenshot. The OS was in ROM and had insufficient space for the actual fonts so they needed to be loaded from disk. This was fine if you had a hard disk but a pita with floppies.

Need to find the time to try that out on a Raspberry Pi....

Re: Screenshots of Old Desktop OSes

#205

Post by whartung »

vessenes wrote: post #95

Amazing walk through memory lane, and super useful. One big omission though - starting in the early 1990s, we should be seeing some Linux desktops in there, but I didn’t see any through 1995 or so when I stopped browsing. Also, Irix would be nice to get — although I don’t recall if SGI had much in the way of custom vibes for their window managers, they certainly had amazingly cool 3D demos. A nice vibe coding project…

> It’s hard to understand just how different NeXTStep (Did I capitalize that correctly?) felt from Windows — part of it was refresh rates, but part of it was going from 800x600 to 1132x800-ish on the monitor.

You can't really get it from these screenshots, but I'll give an example of what you're talking about.

I remember GEM when it came out, and it simply looked terrible. Not just their color choice, but simply that low resolution display there were stuck with in the day. It looked cheap, and like a toy. Specifically in contrast to the Mac, which, while it was a smaller monitor, and even lower pixel count, the overall display was crisper, and cleaner, brighter, better contrast.

The Amiga suffered similarly. Big and blocky and fuzzy.

Also, don't forget that the NeXT computers were striving for being "3M" computers. "3M" for 1M pixels, 1 MIPS, and "1 Megapenny" ($10,000). Definitely a different class of machines to OTS PCs of the day.

https://en.wikipedia.org/wiki/3M_computer

Re: Screenshots of Old Desktop OSes

#208

Post by reaperducer »

BoppreH wrote: post #75
bronlund wrote: post #32

I can't help thinking about how much we have lost. Just finding the scrollbar nowadays can be a challenge. Not to mention if you want to resize a pane - in some applications they seem to have taken extra steps to make it difficult to find the line to grab.

We also lost clearly identifiable buttons, loading bars (replaced with throbbers), status bars that tell you what you're hovering over and what the program is doing, stable UIs to develop muscle memory, etc. But we did gain some nice things! - Tabs. - Titlebar buttons and other space-saving measures. - Document editors remembering unsaved changes. - Forms that validate on focus lost, instead of submission. - Ctrl+P m…

But we did gain some nice things!

None of the gains you list have anything to do with user interfaces. They would all or mostly be possible in any of the older desktop environments shown.

Re: Screenshots of Old Desktop OSes

#209

Post by reaperducer »

lelanthran wrote: post #150
BoppreH wrote: post #75

Earlier quoted context omitted.

We also lost clearly identifiable buttons, loading bars (replaced with throbbers), status bars that tell you what you're hovering over and what the program is doing, stable UIs to develop muscle memory, etc. But we did gain some nice things! - Tabs. - Titlebar buttons and other space-saving measures. - Document editors remembering unsaved changes. - Forms that validate on focus lost, instead of submission. - Ctrl+P m…

> loading bars (replaced with throbbers) There is a very practical reason for this; most GUI apps are webapps (whether local or not is irrelevant), and the fetch API was so poorly thought out that it was not possible to get an indicate of progress - all if gives you is inprogress or done (nothing in between). As a result the loading indicator can only indicate in-progress or done. There might have been worse ways to…

As a result the loading indicator can only indicate in-progress or done.

This is a failure of whatever framework the web dev is leaning on instead of actually programming the computer.

It is perfectly possible to get real progress information other than yes/no. Web sites had it for years before lazy spinners took over.

Re: Screenshots of Old Desktop OSes

#210

Post by mlhpdx »

BoppreH wrote: post #163
lelanthran wrote: post #150

Earlier quoted context omitted.

> loading bars (replaced with throbbers) There is a very practical reason for this; most GUI apps are webapps (whether local or not is irrelevant), and the fetch API was so poorly thought out that it was not possible to get an indicate of progress - all if gives you is inprogress or done (nothing in between). As a result the loading indicator can only indicate in-progress or done. There might have been worse ways to…

With a better API we could have a progress bar that goes through the TCP/IP stack: advance when the domain is resolved, when a handshake is finished, when the request is sent, when the response starts streaming back, when the response finishes. It'd be a very jumpy bar, but it helps develop intuitions. "The first part is always slower on this machine", "when it gets stuck on this spot I need to reset my router", "thi…

Perhaps an aside, but the things we do to compensate for the warts of TCP are staggering.
Post reply on HN