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?
Building a new Windows 3.1 app in 2019: A Slack Client
81–90 of 248 posts
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#82Re: Building a new Windows 3.1 app in 2019: A Slack Client
#83Earlier 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?
[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
#84Notice 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?
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
#85Earlier 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.
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
#86Earlier 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.
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
#87Notice 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?
Wikipedia says "However, no single process can use more than 16 MB.". Not sure where is the source of that though.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#88Earlier 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.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#89I am going to be using this line a lot in the future.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#90Earlier 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"…
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.