> "It followed a set of five rules to benefit the end user: no installers, no archives, no registry keys, no additional runtimes and a single executable file."
Reading this sentence made me feel warm and happy. I get why the registry exists and things work the way they do today around the Windows software ecosystem but... damn, I really miss the days when most desktop software was more like this. These days I try to use portable installs whenever they're available, I just wish it was more common. The time, inconvenience and uncertainty I'll be able to fully restore all my preferences makes me actively avoid reinstalling Windows.
There are lots of useful actions an installer does that (some, if not most) end users actually want, including but not limited to adding shortcuts to start menu so you can find it or search for it, associating file formats, registering to Windows' program list, etc.
I was a big fan of "portable" software, but nowadays if a software offers both ways, I actually prefer using installer. Otherwise I have to manually add them to Start Menu to be able to search for it, to begin with.
I do hate registry keys, simply for the fact they are often lost after reinstalling the OS. Please just keep all the settings in %appdata%!
I’m really fond of the way macOS does this, which is to stick this information in the executable.
Back in the day, this worked via a flag in the metadata for each file. When you got a new executable, the flag was unset. The OS would see a file with an unset flag, ask “Is this an executable? What files can it open?” and then add this information to a database called the desktop database.
This is why file associations work on a Mac without an installer, and without writing any code (you just have to write the code for “open file in response to OS request”).
If only everyone actually kept up with Windows development best practices, including Microsoft teams themselves[0].
Configuration via XML files, AppData, registry free COM activation, MSI installers, only to quote a few examples, are decades old by now, at very least since Windows XP.
[0] - To be fair, nowadays many young employees seem to only ever used Windows after joining Microsoft, so what else can we expect, if apparently they don't get the right mentoring.
>There are lots of useful actions an installer does that (some, if not most) end users actually want, including but not limited to adding shortcuts to start menu so you can find it or search for it, associating file formats, registering to Windows' program list, etc.
This, I don't really mind unzipping some random small utility, but for things like games and larger applications where you'll actually be saving data and preferences, a real installer that knows how and where to put things following the correct methods for the operating system is much preferred. Then I can run the uninstaller to clean it up when I'm done with it.
If I want to use a program once, I’ll just use a portable version. And I’ll be angry if it decides to add itself to the context menu of all Explorer files.
But I agree, for things I use more often, installers are the way to go, and I am not a fan of projects that just give you a zip and ask you to figure out where to put it.
After using Microsoft Intune I will never again complain about installers. At least installers mostly work, and when they don't you can run them again.
That is one of the reasons I like GO language. Single executable, which makes tooling easier for others to use. My alternative method is using single executable packaged with NSIS that extracts everything to a temp directory before running.
Sorry, Window Registry is a cornucopia of inconsistency and poor design. Gnome's Registry is well designed, comparatively. Key descriptions, value options with limitations and which is the default is a quality User Interface design. Just look at the Windows group policy to registry mappings, they are all over the place for the same logic layout with double negatives for keys.
Yeah, that's why Go is a solid win - single binary, no installer headaches, just build and run. Rust's powerful but comes with build complexity and dependency juggling. Go keeps it clean, fast, and dead simple to deploy.
The original purpose of the registry was to tell COM where to look for a DLL file given a GUID. Then COM could create instances of objects.
You still see that in there with HKEY_CLASSES_ROOT.
You can technically create objects without the registry, if you load up the DLL, then call the exported functions to create a Factory object, then use the factory object to create instances. It's what COM itself does.
That simplicity and lightness of design also resonated with me.
By the way, really cool read-off. The only thing I missed though was a deeper discussion of some of the challenges that the author alludes to in the beginning. But that’s just me being pedantic, the post is really nice and actually seems to be quite an impressive work.
I’m not sure what the best path forward is for making single-binary apps without static-compiling in of the libraries. Licensing usually makes that untenable.
AppImages still leave traces in your home directory. If you're luck it's just a dot file or folder that can easily be deleted but I've seen some that pollute a lot more.
You could replace that year with any year since the start of the GIMP project and it would still be true. It's the epitome of an open source project run by people who care about technical features, not real world users.
As a student I used a ton of warez software in the 90ies. As such, I didn't have any real prejudice back then, and photoshop was the worst of the bunch from my perspective. I held that view for a long time, akin to how I consider autocad from autodesk one of the worst cads you could use despite being outrageously popular.
I have no longer an opinion on it as I didn't use it for such a long time. I'm cycling between krita and GIMP, and GIMP's UI is just fine to me, in the same way I suppose a ton of designers-with-big-opinions are more familiar with photoshop due to all the training they did on it (and probably, _mostly_ on it).
It also did lack some important features. It still doesn't have proper support for different colorspaces, for example, and it's really not very on board with non-destructive editing in general.
> But I didn’t promote it. A few months later, I landed a C++ job. So in the end all that effort paid off.
It's interesting how instinctively we know our hard work deserves to be paid off, but it's a shame how often open source developers put hard work into code that never really gets paid off, especially when it's widely used in production. I guess this explains why so often they look for reputation credits, or why NPM added the "maybe you should donate to the authors of these libs" feature, or why GitHub built in Patreon. There's got to be a better model than what we have now, that doesn't take advantage of naive but hard working young thinkers.
There was a project called "pixel32" and later "Pixel Studio Pro" in the early 2000s. It looked really nice and was sold as early access. But became vaporware, people that paid became really pissed and the guy creating it turned from hero to villain quickly.
Author of this article said he finished at Warsaw University of Technology - it was always considered to be one of the better ones here.
That being said, what also strikes me is how different the thesis were back in times. I did mine recently in another university of technology in some bigger city (without wanting to dox myself that much) and 90% of our engineering theses were of very subpar quality; mine included.
Is it any different nowadays? AFAIK the goal isn't to advance the field, but to prove to the people giving you the Bachelor/Master's degree that you're able to create a "paper". Some theses stand out, but most of them are probably quite boring.
It seems to me like their tasks were way heavier. For us, most of us did basic CRUDs with some implemention twist, and our papers were your standard: do a short theoretical introduction to the domain, make a few UML diagrams, explain how it works + some code examples, then testing.
This is why I love Windows. There is a TON of small, open source software that serves a niche. Used to browse sourceforge.net and freshmeat (is that what it was called?) to find them!
Not complaining about downvotes but it seems a very odd thing for Hacker News to dislike. I would have imagined an internal story about a SW eng’s hack project would be interesting. Oh well.
I didn't downvote, but I fully understand if anyone would. Your comment shows some serious lack of understanding of the complexity of software like photoshop and the complexity of porting software. We may believe that's what your friend told you, but we have troubles believing he really did that. Maybe exaggerated (a lot)?
Readit News
Reading this sentence made me feel warm and happy. I get why the registry exists and things work the way they do today around the Windows software ecosystem but... damn, I really miss the days when most desktop software was more like this. These days I try to use portable installs whenever they're available, I just wish it was more common. The time, inconvenience and uncertainty I'll be able to fully restore all my preferences makes me actively avoid reinstalling Windows.
I was a big fan of "portable" software, but nowadays if a software offers both ways, I actually prefer using installer. Otherwise I have to manually add them to Start Menu to be able to search for it, to begin with.
I do hate registry keys, simply for the fact they are often lost after reinstalling the OS. Please just keep all the settings in %appdata%!
Back in the day, this worked via a flag in the metadata for each file. When you got a new executable, the flag was unset. The OS would see a file with an unset flag, ask “Is this an executable? What files can it open?” and then add this information to a database called the desktop database.
This is why file associations work on a Mac without an installer, and without writing any code (you just have to write the code for “open file in response to OS request”).
Configuration via XML files, AppData, registry free COM activation, MSI installers, only to quote a few examples, are decades old by now, at very least since Windows XP.
[0] - To be fair, nowadays many young employees seem to only ever used Windows after joining Microsoft, so what else can we expect, if apparently they don't get the right mentoring.
This, I don't really mind unzipping some random small utility, but for things like games and larger applications where you'll actually be saving data and preferences, a real installer that knows how and where to put things following the correct methods for the operating system is much preferred. Then I can run the uninstaller to clean it up when I'm done with it.
But I agree, for things I use more often, installers are the way to go, and I am not a fan of projects that just give you a zip and ask you to figure out where to put it.
Sorry, Window Registry is a cornucopia of inconsistency and poor design. Gnome's Registry is well designed, comparatively. Key descriptions, value options with limitations and which is the default is a quality User Interface design. Just look at the Windows group policy to registry mappings, they are all over the place for the same logic layout with double negatives for keys.
You still see that in there with HKEY_CLASSES_ROOT.
You can technically create objects without the registry, if you load up the DLL, then call the exported functions to create a Factory object, then use the factory object to create instances. It's what COM itself does.
By the way, really cool read-off. The only thing I missed though was a deeper discussion of some of the challenges that the author alludes to in the beginning. But that’s just me being pedantic, the post is really nice and actually seems to be quite an impressive work.
This is exactly the experience nowadays with AppImages.
Deleted Comment
In 2006, GIMP had a ton of features, but compared to Photoshop’s UI it was positively awful.
As a student I used a ton of warez software in the 90ies. As such, I didn't have any real prejudice back then, and photoshop was the worst of the bunch from my perspective. I held that view for a long time, akin to how I consider autocad from autodesk one of the worst cads you could use despite being outrageously popular.
I have no longer an opinion on it as I didn't use it for such a long time. I'm cycling between krita and GIMP, and GIMP's UI is just fine to me, in the same way I suppose a ton of designers-with-big-opinions are more familiar with photoshop due to all the training they did on it (and probably, _mostly_ on it).
The main thing I missed were stackable layers, but it was not a huge issue for me.
Deleted Comment
>As I’m getting older I look back on all the things I’ve done as a creative developer, and I see so many cool projects!
Such modesty...
https://github.com/f055/fedit-image-editor
It's interesting how instinctively we know our hard work deserves to be paid off, but it's a shame how often open source developers put hard work into code that never really gets paid off, especially when it's widely used in production. I guess this explains why so often they look for reputation credits, or why NPM added the "maybe you should donate to the authors of these libs" feature, or why GitHub built in Patreon. There's got to be a better model than what we have now, that doesn't take advantage of naive but hard working young thinkers.
https://discuss.haiku-os.org/t/pixel-studio-pro-in-past-call...
That being said, what also strikes me is how different the thesis were back in times. I did mine recently in another university of technology in some bigger city (without wanting to dox myself that much) and 90% of our engineering theses were of very subpar quality; mine included.