Windows 11 and WSLg and cross platform GUIs: a lesson from Smalltalk
Windows 11 - the one where Microsoft throw their hands in the air
I'm not the only one to complain about the inconsistancies that have built up in Windows 10. The Microsoft guys admittedly have a huge job to do preserving backwards compatibility with all sorts of garbage from the last 40 years. One thing that's always made me laugh is the device manager (devmgr.msc), something I still find useful because they never finished moving it's functionality entirely into the remade Settings system.
Hilariously, the old girl is still present and correct in this build of Windows 11
But wait, what's this WSLg thing? Why it's a full-fledged Wayland implementation on Windows. Like, that Wayland. If I didn't know any better I would guess that trying to get the old Win32 interface into any kind of reasonable shape again has beaten them. I'm quietly a little excited by this development, not least because I'm a Unix guy at heart even though I spent the last 25 years doing Windows development.
What's that got to do with Windows and cross platform GUIs? Well first a little personal history lesson
The past doesn't repeat but it does rhyme
Back in the 1990s I was working at a merchant bank that had two desktop systems to support: Sun Sparcstations and Windows 3.11. I was on the Sun side of things (initially as a systems administrator, later as a developer) and as part of the modernisation strategy in the bank, they were looking for some new tools. At the time, either you were developing command line stuff written in C and the then still fresh C++ for the Sun machines (or maybe we had a few things in OpenLook, I honestly can't remember) or you were doing stuff on their IBM mainframe. They had no real desktop apps. Except for one crazy guy who was running the Sparc version of Lotus 1-2-3, simply because his insane spreadsheet was so huge it no longer ran on the MS-Dos version. As you can imagine, simple stuff like transferring files around was a major hassle, might have been Netware mixed in there, definitely a whole load of coaxial cable and whatnot running under desks. Yes, that coaxial cable of the kind that if somebody undid one of the T intersections to add a new machine, he took out the network on that entire section of the floor. You kids have it easy today with your wifi.
Kinda lost my train of thought there. Anyhow, they sent one of the leading eggheads on a whirlwind tour to see what other people were using. This was before the internet was anything much more than Usenet of course, there was no way you were getting information on software development out of alt.swedish.chef.bork.bork.bork. Anyhow, Mr Egghead was thankfully sent overseas with somebody practical to reign his worst impulses in and the intrepid team came back with two suggestions: ParcPlace VisualWorks and Powerbuilder. Both of them fitted the brief (new fangled, client server systems that could talk to Sybase running on the Sun servers) but they were very, very different beasts.
Powerbuilder
Powerbuilder was meant as a replacement for all the stuff running on the IBM mainframe. Obviously this was a monstrous fools errand (as the mainframe developers knew) because while it was super quick to hack up a nice new Windows app, getting the app to do anything other than CRUD stuff was painful i.e. they all suddenly came to the realisation that the mainframe transaction processing system (CICS) was never getting replaced with the child's toy that was Powerbuilder. Don't get me wrong, Powerbuilder was object-oriented (kinda) and the developers doing CRUD were very productive. But they were never going to get anywhere near the programs that did cash money stuff. After a while the guys who chose the Powerbuilder path felt it was a bit of a dead end.
VisualWorks
If you drew the straw that had Smalltalk on it, you found yourself in the big leagues. VisualWorks was not only spoken about in hushed tones by Mr Egghead as being the second coming of a deity, it ran cross platform, you could write your program on your fat Sparc 10 and copy the image over to your pathetic friends Windows box and it ran. With windows buttons and menus and talking to Sybase and everything. Something of a miracle. That was until the end users saw it. The complaints were endless, starting with "why don't the buttons and widgets look and work like the ones in Word? It's so slow! Ordinary users, feh, they will be the death of you. Always with the complaints about stuff not working and the endless requests to get it fixed when you had much better things to do.
The object oriented miracle that wasn't
Initially, the Powerbuilder guys looked like they were winning. Not only were the Sparcstations disappearing (slowly) from desks, but they could churn out new screens and new systems with wild abandon. Their users were happy, the apps looked and felt like Windows apps and there were no weird surprises when they tabbed around the window instead of using the mouse. The Smalltalk guys...were mired by the over-thinkers like Mr Egghead who insisted on building a "new foundation, a new repository of shared code that will save us all time". Guess who drew the short straw on that one (me). VisualWorks at the time didn't really have any kind of code repository, everything had to be "filed in" so we did our level best to keep different versions of the Smalltalk image around, tried desperately to integrate it with PVCS (a failure) and generally scrambled around trying to keep everything working. The developers, fresh to Smalltalk, would regularly do something that would completely bork their images, requiring them to start again from one of the foundation images we kept and tediously file in whatever app they were developing so they could continue. The Visualworks guys would regularly subject their users to regression issues with their builds (oh forgot to file that fix in etc). Powerbuilder guys? Just kept on trucking.
Desperate times call for desperate measures, in the form of a tool from an obscure object company called OTI. They had a miracle system called "Envy/Developer" which not only solved the version control / change control / regression problems but might be the best source code control system I've ever seen. In Smalltalk, everything depends on snippets of code called "methods" and you were encouraged to keep them as small as possible, Envy/Developer was able to capture all the miniscule little changes to methods and objects and keep them in a nice little bundle. The bundles could then be packaged together in releases. It was beautiful. Borking your Visualworks image was insanely easy to do because you can override even the most basic methods on Object and it doesn't care, it just drops it's drawers and takes a dump on your desk. Now, the developers fired up a pristine Envy/Developer image, browsed over to their app and loaded up the branch they were working on.
It was fun while it lasted
Dude, we were cool. Not only were we getting paid stupid amounts of money, we were playing with the hottest tech, getting trips to Silicon Valley to go to the VisualWorks conferences. Living large in a superfly style muchacho. The complaints from the users kept coming though: I can't drag and drop anything into my Visualworks program, the menus are weird, the buttons are weird, I could swear I pressed that and it did something else. What the peons wanted was Native Widgets. ParcPlace never delivered them of course and by the time any of the monstrous developments in Smalltalk were ever delivered, the world had suddenly awoken and moved onto Java (SO HAWT RIGHT NOW) and Visual Basic and having a Sparcstation on your desk meant you were legacy and not only that, you were probably going to be co-opted into a horrifying project in the bank that used CORBA that I refuse to talk about to this day.
Fast forward - do native widgets even matter any more?
Two things happened, one slowly and one quickly. Java didn't do native widgets and for most internal development at that bank, Visual Basic was the king. If you needed to do something complicated you used DCOM (yuck), I mean DCOM was horrible but it was easier to get anything working in it that CORBA. The other thing that happened was the Web took over. Half our developers were stuck doing Y2K panic stretches and the other half were joining dog poo startups. Users got very used to clicking on unresponsive buttons in their web browsers and the whole "consistent look and feel" directive that used to be an iron rule in GUI development has never been heard from since.
So right now, I'm thinking that no, native widgets haven't mattered for nearly 2 decades. Microsoft can't make their mind up on how to get GUIs working in .NET Core in a proper cross-platform way, developers are using things like Electron to deliver great apps to end users.
It seems to me that the important things about software development (source code control, listening to your users) have little to do with native GUIs and that having something like Wayland on your Windows machine gives an easy end-run around all the 40 years of cruft that has built up in Windows. If I could just target Wayland for desktop GUI stuff, who cares what language I'm using, what IDE is my favourite or what operating system I have installed. If you got a Mac, well I hope somebody ports a good Wayland compositor over there.
