Hacker News Reader

Comment by userbinator | Hacker News Reader

I don't actually use any of these services so I had no need to, but just being curious, I downloaded the Windows client; and while it may be smaller than Electron apps and native, it's still quite large for a native app --- over 30MB, and also 64-bit only (why? Do you expect to need more than 4GB of RAM for this?)

To contrast, MSN Messenger 4.7, an app with similar capabilities (IM, voice, and video calling), is only ~2MB --- with several third-party reimplementations being <1MB. Makes you wonder how small you can make an app for today's messaging services if you really tried... they don't need to be that big even if they don't include an entire web browser.

View on HN

Most of the stuff is taken from the fact that Ripcord is multiplatform. It uses Qt5, it takes lots of space, but works everywhere. Ripcord also bundles lots of libraries for lots of file formats (audio, video), bundles OpenSSL for cryptography support (although the library is from 2014, and probably should be updated), should theoretically support Wayland (at least it has some libs for supporting it), etc.

MSN Messenger probably uses WinAPI and being a Windows-only program it can get away with it.

Its not like 32 bit applications are more efficient than 64 bit applications.

There is place for 32 bit applications but not here! The job of a program is to do what it is supposed to do efficiently and get out of the way, and it better use all registers and instructions needed to do it.

Its not like 32 bit applications are more efficient than 64 bit applications.

Yeah it is. You need to move 7 bits through memory and through the CPU, is it more efficient to pad it with 25 blank bits and move 32 bits overall, or pad with 57 blank bits and move 64 bits overall?

Which is doing things "more efficiently" and "better using" the hardware?

thats not the question you have to ask though.

your cpus arent capable of 32 bit calculations anymore... so the questions is: is the software emulation of your OS for 32 bit more efficient than the programming language overprovisions.

The CPU is still perfectly capable of 32bit calculations. Even 8 bit calculations. What you can't do is use 32bit pointers (though, strictly, you can, but x86-32 isn't well supported, I wonder why?)

You are technically right, but only because I expressed myself very poorly.

The CPU is naturally still able to do 32 bit calculations.

What you can't do is run a 32 bit application without emulation after a 64 bit system has booted.

The libraries are obviously also required, but it still won't be able to start without the emulation adding 0 to the memory blocks.

Source? Not that I don't believe you, I just don't understand from your comment

It's not -entirely- true but it's not false, either as far as I'm aware.

Windows in specific uses WOW64 -- Windows 32 on Windows 64. It's an emulation layer that doesn't actually hamper performance but does do things a bit differently than a native OS -- such as running all 32bit programs in 'user mode' rathe than with elevated permissions.

You can get a brief synopsis here - https://www.techsupportalert.com/content/how-windows7-vista6...

If you use eax instead of rax, you can do both. Compilers are smart these days and will use the appropriate register size when necessary. If you need to move 7 bits, it'll likely use the al register.

I can't edit, but it seems my reasons for thinking 32-bit can be faster aren't entirely daft - but the gains of 64-bit x64 include it having simply more registers, having smaller faster floating point precision, being able to request more memory at once, and the hits to pointer size overheads or processor cache holding less real data are rare and mostly from buggy or odd conditions, and that for a lot of normal programs there'll be no difference either way:

https://stackoverflow.com/questions/2378399/are-64-bit-progr...

https://stackoverflow.com/questions/324015/supplying-64-bit-...

https://stackoverflow.com/questions/2334148/is-there-any-rea...

interesting.

I'm surprised at the criticism about 64-bit only. Are people still using 32-bit operating systems?

Yes.

A 32-bit binary will work just fine on a 64-bit OS, but not the other way around, and there's no reason such an app needs 64-bit, so why unnecessarily restrict compatibility?

I think you're in a minority. Are there any 32-bit CPUs being produced for the mass market these days? Making a 64-bit only software is not only about wanting more than 4gb of ram; it's about debugging support, tooling, installation size and installation packages, etc. It's easier to distribute 64-bit only software than both 32-bit and 64-bit, and you can't distribute 32-bit only software because:

1. macOS will deprecate 32-bit completely soon,

2. Linux needs 32-bit libs installed on the system, and many people don't have them,

3. Windows has really good backward compatibility and still supports 32-bit. But it's the only system.

So, distributing a 64-bit-only software actually makes sense.

This exactly.

When I install something, if it pulls in a ton of stuff, I'll reevaluate whether I actually need it. In fact, I was pretty excited when I finally got rid of my dependency on 32-bit stuff and could eliminate the 32-bit repo.

I like 64-bit because it keeps my system clean, but because it's "better". I definitely want a 64-bit OS so some things can use more than 4GB RAM, so why have two copies of everything? Just standardize on the thing nearly everyone uses: 64-bit.

Are there any 32-bit CPUs being produced for the mass market these days?

Can we stop assuming that people are always going to have the latest hardware? Even then, 32-bit SoCs running Linux are still pretty common in various embedded things and other low-power devices --- exactly the use-case for a small and native chat client.

You don't need the latest hardware to have a 64-bit CPU.

Slack client on an embedded platform? Are you ok?

Not exactly true for Linux - a modern Linux desktop usually has only the most basic (libc, ...?) 32 bit libraries installed. Though an AppImage (which Ripcord uses) might work because it's mostly self-contained anyway. On Linux, approximately nobody still uses 32 bit systems.

Honestly I would criticise if it was 32-bit.

When can I finally get rid of this stupid "Program Files (x86)" folder which annoys me every time I click into the wrong one looking for my program, when even new programs are released as 32-bit?

> it's still quite large for a native app

It's not native (as in native windowing toolkit), it's Qt based which is probably where most of that 30MB is going, MSN Messenger is/was built on win32. Still, in the age of electron apps that's a huge improvement, it's good to see real desktop developers still exist.

Reply on news.ycombinator.com