It's a neat project. Write cross platform desktop apps in C. Presumably it would not have been very usable in practice in the late 1980s, because of all the OTHER system interfaces that still weren't portable, even if the windowing system was available in a portable way.
I can remember the subsequent period in which Java desktop apps were relatively common. They had cross platform UI by default. But the problem was:
1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
2) in the Java case, it seemed heavyweight to install and sluggish compared to native apps;
Point 2 would not have applied to stdwin, as it would have produced small compiled binaries I suppose, but Point 1 would have.
So in the end, obviously web apps (and partly, Flash) took over the niche that "cross platform desktop apps" had once tried to fill, and then it was something of a dead zone until Electron, as far as I remember.
> cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
I think this is an implementation detail. It's up to the software stack whether it leaves off before drawing the UI elements on screen, or goes ahead and takes on that responsibility too. The wxWidgets toolkit uses the runtime platform's UI, so it does not draw the widgets themselves. Java Swing took on the task of drawing the UI elements on the screen in its own style.
When OS X was new, Apple was still under the assumption that Java on the desktop was important, and they built an in-house Java with full Aqua support. It was still _terrible_! All the Aqua-specific affordances like animation or shadows were janky or absent. Sizing and positioning always felt weird because the application was written assuming Windows-shaped controls.
Basically, cross-platform GUI only looks good on the platform that it was originally designed for. Unless the other platforms make zero interesting choices, they will always look worse.
> cross-platform GUI only looks good on the platform that it was originally designed for
Formulated more rigorously, cross-platform GUIs and outsider, non-Mac-first GUIs ported to Mac OS look (and feel) bad on Mac. The opposite is virtually never true though; there aren't really high standards for beauty or consistency on the other platforms. Windows, for example, in this decade is a mishmash of different toolkits (even from Microsoft). Desktop GNU/Linux people comprise a faction consisting of people that either doesn't care about GUI beauty or have standards that are about on par with Windows folks—and are generally so grateful just have an app that ships* their platform, that they won't reject outright any Mac-first app (and that would be true even if it painted itself as a pixel-for-pixel match of the Mac OS version).
* and runs; I still run into "cross-platform" apps that are Electron builds packaged as AppImages that still terminate at launch, even if you try to run them on something as unremarkable as Ubuntu
> Java Swing took on the task of drawing the UI elements on the screen in its own style.
Sun/Oracle also cheaped out by not having designers. If you see Flutter, they are able to recreate all of the platform specific widgets purely by having design engineers eyeball the implementations until they replicate the exact color and timing of every animation. Oracle/Sun was cheap and lazy.
Honestly, "native UI" gets so much worse with every passing year that I don't even want native UI. I want old windows UI.
I saw a screenshot of GTK 1 and the first thing I thought is that I'd rather make something using GTK 1 than GTK 3. Unfortunately I asked an AI chatbot about it and they advised against it because of "security" :(
That's the false assumption that unmaintained is insecure. Any old DOS game in Dosbox would be insecure by that logic.
So if I run Dune2 in dosbox, is that a security issue? Of course not, but if you were to load a bitmap from the network and feed it to GTK1 for displaying, there could well be an overlooked issue lurking around. But you need to look at the greater picture, not just "old==insecure"
1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
These two things don't connect. Not being identical doesn't mean ugly or only one GUI would be considered not ugly.
... was said reading it in a browser on who knows what OS/DWM.
I mean that 90% (if not more) of all UI interactions happen now in a browser or in multi-platform applications (e.g. messengers, SublimeText, VSCode, etc).
A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components.
Windows has keyboard shortcuts on buttons, but you can set per-user whether they appear underlined always or only when you hold Alt. Mac always has exactly one, immovable menu bar; and Enter doesn't close a dialog box. GNOME can rollup or pin windows from the title bar if you add the buttons for it. Whether the native dialog layout has the ok button to the left of the cancel button depends on the OS and the writing direction (p206 of [1]). Not every platform has a native calendar widget. And so on ...
Worse still, you're building an abstraction layer on top of several genuinely different systems, that users of different platforms will expect to work differently in the first place. Go down this rabbit hole and you end up with "show a help button on modal dialogs only on platforms where this is usual, and where you can open the help window without closing the modal first". "Portable native-GUI" is almost an oxymoron; wxWidgets is perhaps the closest we can get where at least you can ask for a wxFindReplaceDialog abstraction (p229 of [1]) and get the cancel button in the platform-default place, even if "Find-Replace Dialog" is not a feature included in the OS' component library itself.
This is all true, and if I were building a tool which I'd expect to be widely use I'd approach it as a common core with platform specific GUI layers like Ghostty (and I'm sure other applications) does.
Sometimes though you're throwing together a quick and dirty UI for a specific use case that you just want to run on a bunch of different platforms and this sort of toolkit is great for that. It can be the difference between the application existing at all and it being available on a range of operating systems.
HTML/CSS components were not available to Guido in 1988. It was in 1989 that Tim Berners-Lee defined the first version of HTML[0] and CSS was proposed five years later[1]. In 1988 Guido would have known about the Mac (1984) which he cites, and the X Window system, which was 5 years old.[2]
> A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components[…]
> […] an abstraction layer on top of several genuinely different systems[…]
> […] wxWidgets is perhaps the closest we can get[…]
For good reasons—because you'll likely exhaust yourself or starve of resources before you finish the project, and because it also doesn't tend to help with the readability of the codebase—it should be ingrained in all programmers to be strongly against "portability" approaches that try to make platform X work like platform Y by providing implementations of Y APIs that work on platform X. (See also yesterday's news by Wasmer about their AI-coded approach[1].) The goal is almost always better achieved by defining, up front, the minimum interface that the program needs to be able to work on the host—which forms the kind of abstraction you're talking about—and then connecting that to the actual host APIs (which usually suck to use, anyway), repeating for each platform. Almost.
Desktop UI toolkit APIs are one exception to this—which is unfortunate, because it's like the one use case where people actually try to do the opposite of the usual impulse, and we're all worse off for it.
The major desktop platforms are so few, and the APIs are so stable and so slow-moving, that it's well past the point where the cross-platform native app solution should have been adopting/implementing the platform Y APIs everywhere, where "platform Y" is Cocoa[2]. Like, at the latest, the Oracle v. Google decision in 2021 should have been the last hurdle. People get weird about this, though, and confuse APIs with implementations, or conflate Cocoa with Objective-C (and/or a mandate to program in Objective-C), or think this amounts to a claim that this means we should all be using GNUStep. It's not. It's not any of things. It's very simple: the window-and-widget APIs across all desktops should be Cocoa-shaped. That's it.
A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components.
Says who? This has already been done over and over. Tk, FLTK, JUCE, Qt, ImGUI and many more.
Worse still, you're building an abstraction layer on top of several genuinely different systems,
Features are pretty common across linux windows and macos. Clipboards, input, files, all sorts of stuff works enough that the lowest common denominator still covers about 90% of use cases.
I just turned 65. Own 1 person custom software development company and am very much active professionally. Started programming in the 80s while working as a research scientist.
> As a ~20 year old this feels so weird to read. I'm still considered young in ~10 years?
An anecdote for you...
In Summer 1997 i was 24 at a family reunion, listening to my grandmother and several other seniors talk about some recent interaction my grandmother had had with a delivery person. One of her friends asked her, "how old was he?"
i'll never forget either her response or my jaw-dropping which followed:
> As a ~20 year old this feels so weird to read. I'm still considered young in ~10 years?
One of these days, maybe as early as your mid-/late-40s, you will be consulting with your a medical doctor and realize that you are the oldest person in the room.
It's all relative. When I was 20, I'd consider myself old at 36. Now when I am 36, my definition of old has shifted and it's now somewhere past 50. I guess "old" for a person is just that person 10+ years older :)
Careers could be very very long. My relative was kicked out of academia after finishing his postdoc and has to work manual jobs till the end of comunism in my country. His career actually started after 60 and he died just a few weeks before his announced retirement at the age of 96, teaching 5 to 6 classes a year in CS department.
I remember running this on an Atari ST with MiNT as the multi-tasking kernel. It took a lot less resources from my 4MB STe than running X11 did. It was actually quite usable to compile with gcc in one window and edit (with vi, of course) in the other.
> Toga is a Python native, OS native, cross-platform GUI toolkit. Toga consists of a library of base components with a shared interface to simplify platform-agnostic GUI development.
> Toga is available on macOS, Windows, Linux (GTK or Qt), Android, iOS, for single-page web apps, and console apps
I also expected screenshots there, especially given the word "interface". Turns out, it's not about user interface (UI), it's about programming interface (kinda API). It allows calling window-related functions on Macintosh, X Window System, and Atari. So the resulting windows were looking like a native UI, I assume.
The readers' natural question is 'does this look reasonable on multiple platforms?'. A two-second glance at two or three screenshots goes a long way to answering that.
In hindsight, this sounds more reasonable in 2026 where graphical documentation is taken for granted. In those days I think anyone would have spooled the .ps to their nearest laser printer and begin building something quickly with it just to check the looks.
I remember following a "build your own text windowing system" tutorial printed in a hcontinous paper back then
The document looks to be nicely rendered, likely from Postscript. Maybe generated by roff, since it doesn't look like TeX. Screen cap bitmaps could be converted to EPS and inserted into the Postscript.
If it was a PS document, you would have to spool it to a printer or screen renderer to read it anyway. The X Window System debuted in 1984, so on-screen renders would have been not too hard to find in a CS department in 1989.
This should be linked as the original post: https://ir.cwi.nl/pub/5998
It says 1988 there.
the code from 1995
https://github.com/thomas-hori/mirror-cwi-stdwin
Still seems like it could be useful
It's a neat project. Write cross platform desktop apps in C. Presumably it would not have been very usable in practice in the late 1980s, because of all the OTHER system interfaces that still weren't portable, even if the windowing system was available in a portable way.
I can remember the subsequent period in which Java desktop apps were relatively common. They had cross platform UI by default. But the problem was:
1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
2) in the Java case, it seemed heavyweight to install and sluggish compared to native apps;
Point 2 would not have applied to stdwin, as it would have produced small compiled binaries I suppose, but Point 1 would have.
So in the end, obviously web apps (and partly, Flash) took over the niche that "cross platform desktop apps" had once tried to fill, and then it was something of a dead zone until Electron, as far as I remember.
> cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
I think this is an implementation detail. It's up to the software stack whether it leaves off before drawing the UI elements on screen, or goes ahead and takes on that responsibility too. The wxWidgets toolkit uses the runtime platform's UI, so it does not draw the widgets themselves. Java Swing took on the task of drawing the UI elements on the screen in its own style.
When OS X was new, Apple was still under the assumption that Java on the desktop was important, and they built an in-house Java with full Aqua support. It was still _terrible_! All the Aqua-specific affordances like animation or shadows were janky or absent. Sizing and positioning always felt weird because the application was written assuming Windows-shaped controls.
Basically, cross-platform GUI only looks good on the platform that it was originally designed for. Unless the other platforms make zero interesting choices, they will always look worse.
> cross-platform GUI only looks good on the platform that it was originally designed for
Formulated more rigorously, cross-platform GUIs and outsider, non-Mac-first GUIs ported to Mac OS look (and feel) bad on Mac. The opposite is virtually never true though; there aren't really high standards for beauty or consistency on the other platforms. Windows, for example, in this decade is a mishmash of different toolkits (even from Microsoft). Desktop GNU/Linux people comprise a faction consisting of people that either doesn't care about GUI beauty or have standards that are about on par with Windows folks—and are generally so grateful just have an app that ships* their platform, that they won't reject outright any Mac-first app (and that would be true even if it painted itself as a pixel-for-pixel match of the Mac OS version).
* and runs; I still run into "cross-platform" apps that are Electron builds packaged as AppImages that still terminate at launch, even if you try to run them on something as unremarkable as Ubuntu
> The opposite is virtually never true though; there aren't really high standards for beauty or consistency on the other platforms
The beauty is in the eye of the beholder. I don't find Apple UI beautiful and consistency is missing in some places at least on iOS.
And what are your thoughts on Frito chili pie?
> Java Swing took on the task of drawing the UI elements on the screen in its own style.
Sun/Oracle also cheaped out by not having designers. If you see Flutter, they are able to recreate all of the platform specific widgets purely by having design engineers eyeball the implementations until they replicate the exact color and timing of every animation. Oracle/Sun was cheap and lazy.
Point 2 nowadays feels like high performance when compared to Electron crap.
Honestly, "native UI" gets so much worse with every passing year that I don't even want native UI. I want old windows UI.
I saw a screenshot of GTK 1 and the first thing I thought is that I'd rather make something using GTK 1 than GTK 3. Unfortunately I asked an AI chatbot about it and they advised against it because of "security" :(
You might like FLTK if you don't care about matching native UI, and appreciate 90's design sensibilities. Unlike GTK 1.x it is still maintained.
That's the false assumption that unmaintained is insecure. Any old DOS game in Dosbox would be insecure by that logic.
So if I run Dune2 in dosbox, is that a security issue? Of course not, but if you were to load a bitmap from the network and feed it to GTK1 for displaying, there could well be an overlooked issue lurking around. But you need to look at the greater picture, not just "old==insecure"
Does the chat bot brush your teeth for you too?
1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
These two things don't connect. Not being identical doesn't mean ugly or only one GUI would be considered not ugly.
The other popular option for cross-platform UI apps was Tcl/Tk:
https://en.wikipedia.org/wiki/Tk_(software)
...which even leaked into other language ecosystems like Python:
https://docs.python.org/3/library/tkinter.html
Which had the ugliness problem then, although it is a lot better now.
AFAIK Tk simply wrapped native widgets though? E.g. when the result was ugly, then that was because the platform's native UI framework was ugly.
It did not. It had/has its own widget set.
It didn't look ugly by early 90s standards (basically Motif look&feel) but didn't evolve.
It also always felt like a foreign body inside Python because Tcl was always still there along with it.
Not all people love Material design. The fact, that the Label became the main UI widget, is an unfortunate accident.
> cross platform GUIs are ugly by default,
... was said reading it in a browser on who knows what OS/DWM.
I mean that 90% (if not more) of all UI interactions happen now in a browser or in multi-platform applications (e.g. messengers, SublimeText, VSCode, etc).
A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components.
Windows has keyboard shortcuts on buttons, but you can set per-user whether they appear underlined always or only when you hold Alt. Mac always has exactly one, immovable menu bar; and Enter doesn't close a dialog box. GNOME can rollup or pin windows from the title bar if you add the buttons for it. Whether the native dialog layout has the ok button to the left of the cancel button depends on the OS and the writing direction (p206 of [1]). Not every platform has a native calendar widget. And so on ...
Worse still, you're building an abstraction layer on top of several genuinely different systems, that users of different platforms will expect to work differently in the first place. Go down this rabbit hole and you end up with "show a help button on modal dialogs only on platforms where this is usual, and where you can open the help window without closing the modal first". "Portable native-GUI" is almost an oxymoron; wxWidgets is perhaps the closest we can get where at least you can ask for a wxFindReplaceDialog abstraction (p229 of [1]) and get the cancel button in the platform-default place, even if "Find-Replace Dialog" is not a feature included in the OS' component library itself.
[1] https://wxwidgets.org/docs/book/Cross-Platform%20GUI%20Progr...
This is all true, and if I were building a tool which I'd expect to be widely use I'd approach it as a common core with platform specific GUI layers like Ghostty (and I'm sure other applications) does.
Sometimes though you're throwing together a quick and dirty UI for a specific use case that you just want to run on a bunch of different platforms and this sort of toolkit is great for that. It can be the difference between the application existing at all and it being available on a range of operating systems.
HTML/CSS components were not available to Guido in 1988. It was in 1989 that Tim Berners-Lee defined the first version of HTML[0] and CSS was proposed five years later[1]. In 1988 Guido would have known about the Mac (1984) which he cites, and the X Window system, which was 5 years old.[2]
[0] https://en.wikipedia.org/wiki/HTML#Development
[1] https://en.wikipedia.org/wiki/CSS#History
[2] https://en.wikipedia.org/wiki/X_Window_System#History
> A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components[…]
> […] an abstraction layer on top of several genuinely different systems[…]
> […] wxWidgets is perhaps the closest we can get[…]
For good reasons—because you'll likely exhaust yourself or starve of resources before you finish the project, and because it also doesn't tend to help with the readability of the codebase—it should be ingrained in all programmers to be strongly against "portability" approaches that try to make platform X work like platform Y by providing implementations of Y APIs that work on platform X. (See also yesterday's news by Wasmer about their AI-coded approach[1].) The goal is almost always better achieved by defining, up front, the minimum interface that the program needs to be able to work on the host—which forms the kind of abstraction you're talking about—and then connecting that to the actual host APIs (which usually suck to use, anyway), repeating for each platform. Almost.
Desktop UI toolkit APIs are one exception to this—which is unfortunate, because it's like the one use case where people actually try to do the opposite of the usual impulse, and we're all worse off for it.
The major desktop platforms are so few, and the APIs are so stable and so slow-moving, that it's well past the point where the cross-platform native app solution should have been adopting/implementing the platform Y APIs everywhere, where "platform Y" is Cocoa[2]. Like, at the latest, the Oracle v. Google decision in 2021 should have been the last hurdle. People get weird about this, though, and confuse APIs with implementations, or conflate Cocoa with Objective-C (and/or a mandate to program in Objective-C), or think this amounts to a claim that this means we should all be using GNUStep. It's not. It's not any of things. It's very simple: the window-and-widget APIs across all desktops should be Cocoa-shaped. That's it.
1. <https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...>
2. <https://news.ycombinator.com/item?id=30359206>
A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components.
Says who? This has already been done over and over. Tk, FLTK, JUCE, Qt, ImGUI and many more.
Worse still, you're building an abstraction layer on top of several genuinely different systems,
Features are pretty common across linux windows and macos. Clipboards, input, files, all sorts of stuff works enough that the lowest common denominator still covers about 90% of use cases.
> A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components.
Win32 + Proton/Wine? No idea.
I'm pretty sure TFA is from before there was any widespread use of HTML for much of anything.
How old is this? 1989 or something like that? Guido was probably quite young when he wrote it. Looks like LaTeX?
Edit: Someone else wrote 1988 which I suppose makes sense, as the latest reference at the end is from 1988 too. So then Guido was 32 years old.
> quite young
> 32 years old
As a ~20 year old this feels so weird to read. I'm still considered young in ~10 years?
I’m nearly 64.
Back when I was a teenager, people in their 20s were “old farts.”
Nowadays, I look at people in their 40s, as “kids.”
Here’s my first ever engineering project (1987): https://littlegreenviper.com/wp-content/uploads/2022/07/TF30...
I was 25, at the time, and a fairly newly-minted EE.
Brother in arms ;)
I just turned 65. Own 1 person custom software development company and am very much active professionally. Started programming in the 80s while working as a research scientist.
> As a ~20 year old this feels so weird to read. I'm still considered young in ~10 years?
An anecdote for you...
In Summer 1997 i was 24 at a family reunion, listening to my grandmother and several other seniors talk about some recent interaction my grandmother had had with a delivery person. One of her friends asked her, "how old was he?"
i'll never forget either her response or my jaw-dropping which followed:
"Oh, he was a _young_ man. About 50, I guess."
(Yes, she actually stressed the word _young_.)
It's all relative. When you're 40+ (which most people attain), 30 does seem young.
> As a ~20 year old this feels so weird to read. I'm still considered young in ~10 years?
One of these days, maybe as early as your mid-/late-40s, you will be consulting with your a medical doctor and realize that you are the oldest person in the room.
It's all relative. When I was 20, I'd consider myself old at 36. Now when I am 36, my definition of old has shifted and it's now somewhere past 50. I guess "old" for a person is just that person 10+ years older :)
> As a ~20 year old this feels so weird to read. I'm still considered young in ~10 years?
You'll still feel young too! It's really weird when you get to your mid 30's and realise that all the 20-somethings view you as old
And later too! I'm 51 but mentally I still feel like 50.
You'll always be young according to yourself.
Young is relative. To an 80 year old someone who is 40 is young. To an 8 year old someone who is 20 is old.
Consider that careers run from 20 to 70 or so.
Careers could be very very long. My relative was kicked out of academia after finishing his postdoc and has to work manual jobs till the end of comunism in my country. His career actually started after 60 and he died just a few weeks before his announced retirement at the age of 96, teaching 5 to 6 classes a year in CS department.
Yes
I would say roff, not LaTeX
100% correct. The GitHub repo linked elsewhere include this documentation in (dit)roff (-ms) form.
I remember running this on an Atari ST with MiNT as the multi-tasking kernel. It took a lot less resources from my 4MB STe than running X11 did. It was actually quite usable to compile with gcc in one window and edit (with vi, of course) in the other.
Toga by Beeware (Dr Russell Keith-Magee,) realizes this goal, I think; https://toga.beeware.org/en/stable/ :
> Toga is a Python native, OS native, cross-platform GUI toolkit. Toga consists of a library of base components with a shared interface to simplify platform-agnostic GUI development.
> Toga is available on macOS, Windows, Linux (GTK or Qt), Android, iOS, for single-page web apps, and console apps
I find it amusing that the paper doesn't include any screenshots. Those were the days!
I also expected screenshots there, especially given the word "interface". Turns out, it's not about user interface (UI), it's about programming interface (kinda API). It allows calling window-related functions on Macintosh, X Window System, and Atari. So the resulting windows were looking like a native UI, I assume.
The readers' natural question is 'does this look reasonable on multiple platforms?'. A two-second glance at two or three screenshots goes a long way to answering that.
In hindsight, this sounds more reasonable in 2026 where graphical documentation is taken for granted. In those days I think anyone would have spooled the .ps to their nearest laser printer and begin building something quickly with it just to check the looks.
I remember following a "build your own text windowing system" tutorial printed in a hcontinous paper back then
The document looks to be nicely rendered, likely from Postscript. Maybe generated by roff, since it doesn't look like TeX. Screen cap bitmaps could be converted to EPS and inserted into the Postscript.
If it was a PS document, you would have to spool it to a printer or screen renderer to read it anyway. The X Window System debuted in 1984, so on-screen renders would have been not too hard to find in a CS department in 1989.
A GUI toolkit paper with no images. Weird choice. Text layout engines could handle images in 1988, so it's not down to that.
(1988)