Slack is either an online collaboration tool, or a religion, depending on who you talk to. Naturally, it’s accessible across all manner of modern platforms, from Windows and MacOS to smartphones. However, some prefer to go further back. At a recent company hackathon, [Yeo Kheng Meng] decided to create a Slack client for Windows 3.1.
Programming for an older OS, in this case, Windows For Workgroups 3.11, requires setting up a viable development environment. Visual C++ 1.52 was pressed into service in this case, being the last version capable of targeting Windows 3.11. The development environment is run on a Windows 2000 virtual machine running on a Mac laptop. This was chosen for its ability to run 16-bit apps, and its Samba compatibility with both Windows 3.11 and Windows 10 and modern Macs.
There were several challenges to face along the way. Old school Windows simply isn’t capable of dealing with HTTPS, necessitating a proxy to handle the exchange of packets with Slack servers. Additionally, memory management was a hassle due to the limits of the 16-bit architecture. Thankfully, an old programming manual from the era was of great help in this regard.
At the end of the hackathon, a usable Slack client was up and running, complete with garish colors from the early Windows era. There’s a few key features missing, such as the ability to resolve user IDs, but overall, the concept works. We’ve seen [Yeo]’s work with this vintage OS before too. Video after the break.
I need this for GNU/Linux with HTTPS.
Search the net, there are lots of alternative clients. e.g. https://github.com/erroneousboat/slack-term
For windoze 3x, would not recommend VC++, but would choose Borland C/C++ and OWL.
They’d be better off spending their time making it less of a laggy resource hog on a modern OS. I’ve seen Slack use well over a gig of RAM on numerous occasions.
You’re assuming “they” wrote the original Slack client… no one is suggesting Yeo Kheng Meng works for the company that produces Slack.
Nobody said Yeo works for Slack, but the line “At a recent company Hackathon” could be confusing. Sure, the first line of the linked article clears it up, but it’s an easy mistake to make.
Well done. This is just as “dear god why would anyone do this” impressive as that project that got Linux running on an ATMega328.
“necessitating a proxy to handle the exchange of packets with Slack servers”
Oh, boo. So it’s not a slack client at all?
Could one write a DLL to handle that?
Absolutely, or even just inline. It may be very CPU intensive though if we assume older architecture as well
Sure, or just inline with your code
Memory management in this version of Windows was editing one file to allow the OS to address extended memory. Looking that up in a book gave me a reputation at the time as someone who knew what he was doing and bought me a lot of unsupervised time in the workplace… “Uh, I’m fixing a memory problem! Yeah, that’s the ticket!”
Lol we had this ages ago, it was known as IRC and on windows you used mIRC.
Exactly what I was thinking of in light of a 2005 era Dell I recently turned on after at least 10 years. I chuckled it had Pirc , Yahoo Chat installed. Like a time capsule of my past social media madness
There was/is dozens of protocols and clients. ICQ, Powwow, LOLchat, AIM, MSN, seems like a new one launches yearly, what have we had more recently, teamspeak, xmpp, discord, telegram, whatsapp.. then all the “pro” ones from lotus, IBM etc. I can barely be bothered keeping track.
Surely something like mbedtls could be ported to this platform to help with the HTTPS stuff?
Nice effort though even if not very practical.
Hi I’m the author of the app. Here are the reasons why the HTTPS stuff was not solved.
I spent many months worth of weekday nights and weekends to clean up the hackathon code, solve bugs and write the unit test. So I felt it was time to stop and document things.
In terms of technical challenges, the 64K segmented memory model is unusual and the effort to get modern SSL libraries to work might not be that straightforward. The C89 language support might pose considerable difficulties. The tiny stack and local heap of 16-bit Win 3.1 apps will definitely up the challenge factor.
Given enough time, I’m sure TLS features can be added to this Win 3.1 app. But the time required will probably exceed the development of the main app functionality itself.
This is the best I can do with my abilities in a reasonable amount of time.
:partyparrot:
Why would you even bother with this?
A pimp who was about to be killed asked John Terrence Kelly a similar question in Tom Clancy’s Without Remorse.
The answer? “Practice.”
Fun is its own excuse.
Take your pick.