What happened to Process Hacker?

[ags1234]

Why was the name of the project changed?
Process Hacker was a good name and well known already.
ProcessHacker was of a higher quality and efficiency software.

ProcessHacker-x64-2.39 unpacked is 3,884,184 bytes.
SystemInformer-x64-3.1.24298 unpacked is 17,254,949 bytes.

A 4,4 increase in size that is not backed up by the same progression in features.

[Vasilich]

ags1234,
Any proof of "ProcessHacker was of a higher quality"?
Have you ever compared the content of folders insoide SystemInformer and ProcessHacker?
Haven't you seen all the new features in SytemInformer?
Have you read about false positives for many antivirus software now ant then for ProcessHacker? Have you read about driver signing and digital signatures for every executable in SYstemInformer to prevent false positives?

Learn to inform yourself before make false judgements and offensive comments.

[ags1234]

Thanks for the detailed answer.

Well, let's compare installed versions of PH and SI

Why change the versions? In my first post I was referring to unpacked versions from zip archives, not the installed ones.

there is no increase in 4 times, as you wrote before.

Well, I redid the math and there is about a 4.4 increase in size. See the sizes below.

It's just that there is a trend today among the developers to use whatever technologies and frameworks to build software. In most cases one could suspect it's the use of framework over skill. This makes the software bloated and slow. So users end up with software that have a few dialogs and a few buttons and no particularly large resources, but goes over 100 MiB.

A more concrete example to illustrate what I am trying to say is MediaMonkey.
MediaMonkey version 4 is about 56 MiB.
MediaMonkey version 5 is about 354 MiB (!!).
MediaMonkey 4's size could be considered normal for the amount of features it has.
In version 5 they made it into a browser, based it on Chromium and the size exploded. Version 4 was already a very good player with all the features most people need and I cannot possibly think that version 5, that has the same features is in any way better at 6.6 increase in size.

On the other hand, look at Total Commander, Double Commander or WinRar, to name just a few that come to mind now. Small disk size, small RAM consumption, extremely optimized and fast, packed full of options. They provide a lot of value per mebibyte. So yeah, that results in a higher quality software.

Anyway, please know that SI is still very good and all the work put into it is appreciated.
I was just trying to raise some awareness on using the technology responsible and as efficiently as we can.

[Vasilich]

you have compared the PH 2.39 only folder with x64 version with SI 3.xx bundle x32/x64 version. For comparison to be fair you need to compare either full folder of PH, or delete x32 folder from SI before comparison (and exclude all text files as you have done for PH).

[ags1234]

Is that Total Commander I see? ;)

[ags1234]

For comparison to be fair you need to compare either full folder of PH, or delete x32 folder from SI before comparison (and exclude all text files as you have done for PH).

Well I am not sure I fully understand what you think I am doing wrong. I compare exactly what developers released into the wild.

I downloaded PH and SI and I compared the x64 versions of both, extracted from the following archives:
processhacker-2.39-bin.zip
systeminformer-3.1.24298-release-bin.zip

From processhacker-2.39-bin.zip I take the directory x64, exactly as the developers left it.
From systeminformer-3.1.24298-release-bin.zip I take the directory amd64, exactly as the developers left it.
The SI archive also contains the directories arm64 and i386, but those are not the object of this comparison, because I compared x64 versions.

I have no idea why amd64 from SI also contains the 32 bit version again. But if it does, it is only fair to be included in comparison. I someone from the developers cares about the size at all, they should remove it, not me.

Also, I have not excluded any text files, I compared full directories as found in the archives.

PS:
However, since you suggested it... :))
If I remove x86 from amd64 from SI, goes down to 13.056.981 bytes from 17.286.075 bytes.
And PH is 3.884.184 bytes.

[Vasilich]

answer to "why amd64 from SI also contains the 32 bit version": #2347

[dmex]

Well, I redid the math and there is about a 4.4 increase in size. See the sizes below.

One of those zip files is using Deflate compression and the other is using LZMA2 compression. The PE file alignment of every binary image was also changed from 512 to match the native page alignment 4096.

On the other hand, look at Total Commander, Double Commander or WinRar, to name just a few that come to mind now. Small disk size, small RAM consumption, extremely optimized and fast, packed full of options. They provide a lot of value per mebibyte. So yeah, that results in a higher quality software.

Those applications have the luxury of a different threat landscape than we do. We're targeted by a large amount of malicious software that wants to conceal system activity and malware/spyware/etc.. We also spend a considerable amount of time reverse engineering Windows because Microsoft enforces severe restrictions on the development of third party task managers compared to Task Manager and Process Explorer.

raise some awareness on using the technology responsible and as efficiently as we can.

We don't have the luxury of using frameworks because task managers are expected/required to maintain system performance and stability, especially in critical situations where the system has no resources available, under stress or malfunctioning and terminate or troubleshoot issues with the system.

Microsoft still maintains the original taskmgr even on the latest versions of Windows for the same reason:

[Vasilich]

Counting all arguments (including links to other 2 discussions and direct answer from @dmex ) I believe the discussion can be closed because all the differences leading to binary size increase were cleared (at least for me).
@ags1234 isn't it?

[ags1234]

@dmex

One of those zip files is using Deflate compression and the other is using LZMA2 compression.

The names of the arhives were provided just to help in reproducing my observations. I think compression method of zip files has nothing to do with my observations, since I for the comparison I extracted the files from archive and at no point I compare archives.

@Vasilich, @dmex
Thanks you for taking the time to reply and provide your insight on the matter.