Building a new Windows 3.1 app in 2019: A Slack Client

Notice the binary size of the app is only 64KiB.

In the demoscene this would be a disqualification as it's 676 bytes over the limit, but in this case I'll overlook it because of the sheer awesomeness of what you've done (and I'm sure trimming off 676 bytes wouldn't be too difficult ;-)

More seriously, this is an excellent proof-of-concept that a Slack client does not need to use hundreds of MB of RAM and consume most of a modern CPU core to provide its basic functionality. I'm a long-time Win32 programmer who started in the tail-end of the Win16 days and one of the things I've wanted to write if I had the time and need was a Win32 native Slack client, to show that it can be done with far less resources, but you've gone even further with Win16. Win32 has native TLS support (via SChannel library, not well-documented but examples exist) and you'd be able to even use it practically (32-bit applications will run on all current versions of Windows, both 32 and 64-bit.)

Note that C89 only prevents declarations of variables in the middle of a scope; you can simply create an inner scope with new variable declarations at its start. Like so...

    case WM_PAINT: {
      PAINTSTRUCT ps;
      HDC hdc = BeginPaint(hwnd, &ps);
      ...
    }

Another small tip: if you make it a dialog-based application, you won't have to bother with WM_PAINT and drawing text yourself --- you can just make the "statusText" and "settingsText" edit controls, and use SetWindowText (or SetDlgItemText) to set their content. They will paint themselves automatically just like the listboxes that you used for the chat contents and userlist. At least you'll save some of those 676 bytes that way...

I can't help but agree with you. Honestly I think it went to hell when we decided that it was acceptable to call an electron app native, but that may have been a symptom, not a cause.

This is so amazing, I love all you people who take the time to do these super mega awesome tinker/fun projects and then share them with to the world!

The quality of Microsoft's own documentation has also fallen considerably; the latest nail in the coffin is that docs.microsoft.com thing that started to replace MSDN several years ago, that created tons of ridiculous fuckups in the "migration process". While doing that they also "open sourced" their documentation on GitHub, which to me sounds more like they're just trying to rely on free labour from the "community" to fix the mess.

One of the more memorable WTFs I've seen is this, which is still wrong as of this post:

https://docs.microsoft.com/en-us/windows/win32/api/wininet/n...

Compare to the old version of the page on MSDN:

http://web.archive.org/web/20080828050103/http://msdn.micros...

See what's missing? The newer version is not the correct one... in "migrating" the document to the new site, for a reason that completely defines all rational explanation, the return type of the function declaration became void. There are plenty of pages on the new site with this serious error, and they've remained unfixed for well over a year. People report such problems on their GitHub, and they get fixed --- individually --- as they're reported, but it still boggles the mind how such a blatant and widespread error could go through (and the old, correct, content deleted flippantly) without someone in power shouting "STOP!":

https://github.com/MicrosoftDocs/windows-driver-docs-ddi/iss...

As a side note, since TFA mentions you can't run 16b apps on 64b Windows, I'd like to mention that otvdm/winevdm actually allows you to do it by running Win16 apps on Win32 using Wine!