Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

yeokhengmeng.com

Post reply on HN
Print view View original

221–230 of 248 posts

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

#221

Post by benibela »

noonespecial wrote: post #141
benibela wrote: post #107

Earlier quoted context omitted.

There is Delphi and Lazarus as open-source clone of it Lazarus can use the Windows API on Windows, gtk/qt on Linux, and carbon/cocoa on Mac. There is also a custom drawn mode that draws the GUI directly rather than using platform apis. That also runs on Android, but it not maintained anymore, so only up to Android 5 or something Delphi is supposed to run on Android and iOS. And Delphi 1 ran on Windows 3.1, so you cou…

There is Delphi and Lazarus as open-source clone of it Shhh! Ixnay on the Lazarusay. If people find out, I'll lose my magical secret weapon for blasting out little windows gui apps. Seriously though, if you ever find yourself needing a few buttons on a windows desktop that do simple things, Lazarus is amazing for whipping that up in a few minutes and still looking professional.

Nah, when people find out it is Pascal, they run away. Can't type begin and end, such words are just too long

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

#222

Post by therealdrag0 »

xg15 wrote: post #214
harshitaneja wrote: post #149

Earlier quoted context omitted.

And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client that is cross platform. I am not a fan of electron and would very much prefer a desktop app. But we are finally seeing emergence of desktop applications from major players for Linux because of electron. It's not ideal but so wasn't the previous solution.

> But we are finally seeing emergence of desktop applications from major players for Linux because of electron. In my experience, Electron applications seldomly follow the UI conventions of the host OS or offer much in terms of integration. If the desktop app is really just the web site in a locked-down browser, then what benefits does this offer to just the normal web page?

I like the conceptual separation. I like alt-tabbing to "Slack" not "Chrome". It also doesn't have any of the header bar so the electron app has more UX control, including access to OS level window menu options. Also it can do things that you can't do inside the browser. E.g., I've seen electron apps that come with other background processes. I also think it performs better in terms of versioning/caching resources. So an electron app could be just a web-site, but they often are much more.

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

#223

Post by DaiPlusPlus »

tomjen3 wrote: post #216
DaiPlusPlus wrote: post #71

Earlier quoted context omitted.

Before Electron people had the arguments about bloated apps when it came to WPF and Qt. And Java apps, like WPF (and most Qt apps I’ve used lately) lacks true integration with native OS widgets so as a user I get an uncanny-valley feeling. At least with Electron you’re essentially forced to style everything - and ever since Windows 8 (or Windows Vista) Microsoft has been actively uglifying native widgets.

I did consider Java as I was writing it, but at the same time Java is actually pretty fast, but there is no doubt that it doesn't use native components most of the time (there is a gnome toolkit bindings for Java, so it is possible). Still Java feels speedy, I think because it is compiled and doesn't need wacked workarounds like not having non-floating point numbers.

I’ve never seen Java running on Windows 3.x - how long did they maintain it for? Or did it use Win32S?

Update: ah, Microsoft released their own port in 1997: https://www.cnet.com/news/ie-gets-java-for-windows-3-1/ - I wonder how long they maintained that for.

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

#224

Post by muststopmyths »

efreak wrote: post #203
muststopmyths wrote: post #193

Earlier quoted context omitted.

64-bit Windows has never supported 16-bit. This has nothing to do with "whoever is running Windows development these days" Back when 64-bit Windows came out (with XP and Server 20003), the adoption was pretty small since most applications were not 64-bit and did not need 64-bit address spaces. Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64…

Wasn't 64-bit windows 2k/64 itanium-based, not x86-based? If so it would have required supporting existing binaries compiled for a different architecture. My understanding is that the only 16-bit support in 64-bit windows is a few specific loaders for things like 16-bit installers (please correct me if I'm wrong)

Yes, the initial 64-bit OS was IA64 and that was the perfect excuse to dump NTVDM, instead of trying to do a W16OW64 or something of that sort. x64 XP and 2003 further solidified that decision because they were "professional" SKUs and Microsoft could dictate that they didn't care about DOS/Win16 for the "new" platform.

It didn't exactly run 16-bit installers. https://devblogs.microsoft.com/oldnewthing/20131031-00/?p=27...

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

#225

Post by [deleted] »

rvanmil wrote: post #45
userbinator wrote: post #42

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…

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

[deleted]

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

#226

Post by Shorel »

butz wrote: post #198

Considering that Windows 3.1 takes less space than Electron binary, one can actually run this program in VM and get better performance and less RAM usage than official app.

For Slack without Electron there's Ripcord

It runs in Windows, Mac and Linux

https://news.ycombinator.com/item?id=19617699

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

#228

Post by CivBase »

xg15 wrote: post #214
harshitaneja wrote: post #149

Earlier quoted context omitted.

And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client that is cross platform. I am not a fan of electron and would very much prefer a desktop app. But we are finally seeing emergence of desktop applications from major players for Linux because of electron. It's not ideal but so wasn't the previous solution.

> But we are finally seeing emergence of desktop applications from major players for Linux because of electron. In my experience, Electron applications seldomly follow the UI conventions of the host OS or offer much in terms of integration. If the desktop app is really just the web site in a locked-down browser, then what benefits does this offer to just the normal web page?

Web pages are constrained by the functionality made available to them by the browser - which is (purposely) very limited. Electron apps run on a native JavaScript interpreter (NodeJS) and have full access to the OS.

As far as UI inconsitencies go, most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS. Many developers simply can't afford to support multiple UIs just because they subjectively look a bit better.

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

#229

Post by zzo38computer »

butz wrote: post #198

Considering that Windows 3.1 takes less space than Electron binary, one can actually run this program in VM and get better performance and less RAM usage than official app.

I have DOSBOX, but Windows 3.1 runs very slowly on DOSBOX.

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

#230

Post by core-questions »

harshitaneja wrote: post #149
shaan7 wrote: post #140

Earlier quoted context omitted.

His point is that this bare bones get/post app in Electron will be much, much "larger".

And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client that is cross platform. I am not a fan of electron and would very much prefer a desktop app. But we are finally seeing emergence of desktop applications from major players for Linux because of electron. It's not ideal but so wasn't the previous solution.

Most likely, the real solution here is to make a very highly performance tuned Electron for Wayland, and make it possible for multiple Electron apps to share at least some part of the footprint of that runtime.
Post reply on HN