Changed the title of theis topic to reflect the heart of the conversation.
Originally I asked if anyone has a copy of Haiku x86_64 from before package managment was introduced, but the heart of the matter is the Deskbar, how packagement has effected it, and how we might get back to it’s original simplicity and elegance.
Also interested in this, for archival purposes. The version I have is Alpha 4 or something I think. I’d have to check.
Is R1A4 OK? Or do you want nightly after R1A4 but before R1B1?
If it’s the second, then it could be hard to find. The nightlies page doesn’t contain the old images. Perhaps grabbing the code at that point and building it yourself could make you have what you want.
I think R1A4 might work. I’m interested in playing with the old Deskbar. I want to see if it had certain features that post PM is lacking, like-
The ability to drag and drop an icon to the menu to add it to the top level of the menu
The ability to open menu folders in Icon View (don’t know why that went away…)
(Both features shown in this picture…)
alpha4 is still listed on the site, but it seems without thr amd64 version
What about this FTP mirror, then:
https://ftp.osuosl.org/pub/haiku/r1alpha4.1/
They have all official releases, starting from r1alpha1 (just goes one folder up and see).
EDIT: oh, x86_64 !? Not sure any official x86_64 release was made before the first Beta. Do you really needs x86_64 version to do the checks you want to do?
Can’t the gcc2h 32bits version far enough for that?
That will be before hrev46113
x86 wont run on my hardware
x86 runs on any hardware amd64 does… and even then you can run it in qemu
Perhaps @shaka444’s PC is EFI-only, with no legacy booting. The current 32-bit has EFI, I believe (it’s been a while), but that was added long after hrev46113. In that case, qemu is certainly the best bet.
Well, you can just ask 
Yes, of course the deskbar used to do that, and, in fact, deskbar code still knows how to do that.
The problem lies in the “blue folders”. There are a terrible hack that was put in place temporarily until a better solution could be found. It’s been 10 years. The hack is still there.
Why are these needed?
The blue folders are a quick and dirty way to show the content of several directories in a single Tracker window, in order to preserve most of the feel of how it worked previously (deskbar menus used to be regular folders). This allows to merge the non-packaged and packaged parts of the deskbar, as well as the system and user parts. All four deskbar directories are combined in a single menu, and a single Tracker window.
But it falls very short of what it is supposed to achieve. The window cannot show large icons because Tracker renders these blue folders using the same code as queries. It is not editable directly (again, just like queries).
The goal is to make deskbar show entries from packages from a read-only folder, combined with customizable entries from the user in a non-packaged place.
Obviously, the blue folders are confusing and should be removed. They weren’t meant to stay for long. But no one has offered a sufficiently convincing replacement. I think it’s not really possible to get the simplicity of the old behavior back without an in-depth rethinking of the deskbar menu. For example, making the menu clearly separate packaged and user-editable parts, just as it is organized in the filesystem?
Maybe we can trick some things into working (for example: dropping things in deskbar could add them to the nonpackaged directories). But it will still be an unsatisfying solution: playing magic tricks to hide the underlying complexity. Personally I would hrefer to remove the complexity, and not hide it…
I doubt that the amd64 version from that time then would have had EFI either… and if your computer has EFI only, with no CSM it’s probably powerfull enough to run qemu 
How did it work in BeOS?
deskbar comes directly from BeOS
I mean how did BeOS handle deskbar entries? Was it just one folder?
Same as Haiku, it’s the same code.
The only difference is that we use these wierd blue folders to merge the underlying folders…
Yes, BeOS didn’t have package management, so just one writable folder. App installer would usually create files there automatically. App uninstallers didn’t really exist and it was up to you to delete things you didn’t want anymore.
We could go back to that, or have the writable directory receive new apps by package post-install scripts creating and deleting links there, but it seems a bit fragile (for example, if the user has moved or deleted the shortcut, what happens when you update the package? Should it reinsall its link? How to locate the moved shortcut when uninstalling a package?)
Could we have the app menus in a single hpkg that gets modified?
Each hpkg file can come with its own menu entries. If you move the entries outside of the package, you have to handle keeping it in sync with the installed packages somehow.
The simplest way I can see is to keep the menu entries inside each package file (as it is done now). But there is no customization possible.
If we decide to have the menu entries outside their originating package: keeping them in sync with installed packages and allowing the user to customize them is going to be a problem, since these two ideas conflict with each other. I don’t think putting them inside an hpkg file solves this conflict. It does allow making them all part of a single folder, so we could remove the blue folders. But then, that single folder is read-only from Tracker point of view, and so the old way to edit the menu by just putting file in a Tracker window will not be available. Some other way to edit that menu will be needed.
Couldn’t this be implemented a bit like overlayfs or similar under linux, where a writable mount is built from a readonly and a read-write storage? I thought this was how this was implemented
