Live data from Hacker News

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

yeokhengmeng.com

81–90 of 248 posts

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

#81

Earlier quoted context omitted.

It feels a lot closer to write for MCUs if you write for 16-bit programs nowadays. The only difference is that MCUs are much more barebone and so less managed, but the constraints set by hardware however is the most distinctive common spot.

MCU?

Think MCUs are of the kinds like Arduino and microBit. There are also SBCs where bigger and more power hungry devices like Raspberry Pi belongs to.

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

#83
post #47

Earlier quoted context omitted.

Qt and to some extent GTK+ come close. GTK+ can be programmed in Vala which is a fine language that transpiles to C and supports idioms such as asynchronous programming.

That's cross platform for Windows, Mac and Linux, but what about Web, Android and iOS?

Beeware [0] does it too, natively in python. The architecture and code base are very nice as well. [1]

[0] http://www.beeware.org [1] https://dan.yeaw.me/posts/gui-widget-for-beeware/

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

#84

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…

There is no direct correlation between the size of an executable (64kb) and the size of the RAM usage (can be hundreds of MB). I could not find any information about the total memory usage of the application, is it described anywhere?

Its running on a ThinkPad 390e, 64mb as standard, and tops out at 256mb, so there is your upper bound.

Even at an absolute worst case it still beats the pants off Slack.

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

#85
post #47
post #45

Earlier quoted context omitted.

> 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. If you’re so sure that this is possible, then where is the Electron competitor which allows us to build cross platform applications like this, with the same levels of productivity and a consistent and decent user interface? No…

Qt and to some extent GTK+ come close. GTK+ can be programmed in Vala which is a fine language that transpiles to C and supports idioms such as asynchronous programming.

> Qt and to some extent GTK+ come close

Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug. I'm proficient in C++ (programming for living since 2000), but I wouldn't pick the language for 2D GUIs in 2019.

> GTK+ can be programmed in Vala

Picking a non-mainstream languages is risky. Harder to find developers. Way more likely to find bugs in the toolchain and these can easily cost weeks to fix.

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

#86

Earlier quoted context omitted.

There is no direct correlation between the size of an executable (64kb) and the size of the RAM usage (can be hundreds of MB). I could not find any information about the total memory usage of the application, is it described anywhere?

Its running on a ThinkPad 390e, 64mb as standard, and tops out at 256mb, so there is your upper bound. Even at an absolute worst case it still beats the pants off Slack.

You are correct. My 390E has 384MB of RAM but only 256MB is accessible by Win 3.1.

An earlier blog post shows this http://yeokhengmeng.com/2016/09/windows-for-workgroups-3-11-...

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

#87

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…

There is no direct correlation between the size of an executable (64kb) and the size of the RAM usage (can be hundreds of MB). I could not find any information about the total memory usage of the application, is it described anywhere?

Win 3.1 apps can also access memory in 64K segments which I only use 1 to hold the humongous HTTP+JSON reply from Slack.

Wikipedia says "However, no single process can use more than 16 MB.". Not sure where is the source of that though.

https://en.wikipedia.org/wiki/Windows_3.1x

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

#88
post #45

Earlier quoted context omitted.

> 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. If you’re so sure that this is possible, then where is the Electron competitor which allows us to build cross platform applications like this, with the same levels of productivity and a consistent and decent user interface? No…

Windows 3.1 apps are somewhat cross-platform because they can be run with Wine on Linux.

Indeed. This point is usually missed. You can even run Windows apps in BSD and macOS.

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

#90

Earlier quoted context omitted.

I've been programming since 1983. The internet opened up publishing to the masses, which means that non-professional people could also publish, resulting in much more documentation than ever before. But now the amateur documentation writers are competing with the professional ones; the quality of the professional documentation is still as high as ever, but it can be drowned out by the amateur quality documentation. A…

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"…

So much this.

It depends on which docs you are looking at, but some are very broken, with broken links, broken tables, broken text formatting...

Do you know of any way to get a handle to the old docs or perhaps a full MSDN dump of 3 years ago or so? (other than the web archive)? Perhaps the latest MSDN offline release or something?

I don't even mind paying.

Post reply on HN