The demo scene inspired me to keep my next‑gen terminal [0] tiny: it is under 5MB (Mac download was once 900 KB) and my aim is to get all downloads down to ~1MB. If demosceners can do it, regular indie devs really have no excuse.
This scene isn’t dead; we should just look beyond 3D glitter. See File Pilot [1] for another compact, clever example.
> If demosceners can do it, regular indie devs really have no excuse.
Demosceners and indie devs are working under different constraints. For demosceners, the file size (4kb, 40kb, etc.) is the goal. For devs, especially those making a tool that you download and install, extreme size constraints seem unnecessary (although avoiding bloat is always good).
Instead, it seems to me that primary constraints for indie devs should be things like being easy to maintain, well documented, easy to use, easy to fix bugs, easy for other people to work on and extend. Small size should be a secondary target rather than primary.
Of course, one of the advantages of being indie is that you can set whatever constraints and targets you like for yourself.
For me, one of the greatest examples of this style is Reaper[0]. A completely functional professional audio DAW in a 12 to 20MB download (depending on your architecture and OS).
--
On one hand, seeing multiple megs described as slim makes me want to pinch myself, because that’s very far from my understanding of reality. On the other, today these apps always seem to include a bespoke toolkit of some description (as both File Pilot and Reaper demonstrate), whereas slim golden-age Windows apps leaned very hard on the GDI/USER/COMCTL one, and those libraries are quite hefty.
(Unlike, say, the Visual Basic IDE, which had two custom toolkits—the one the apps used and the one the IDE did—or Office, which AFAIU included three or four divergent versions—for Access, for Word and Excel, for VBA apps, and for the VBA IDE, with the last two being effectively identical to the respective VB ones, though I don’t know if the IDE and the Word/Excel ones were actually different. And that’s not counting IE’s toolkit, which basically displaced USER controls in HTML forms by the time of IE6. None of these count as slim, is my point.)
But what really makes me wonder here is how File Pilot manages to display what looks in the screenshot like a shell item’s (file’s) full context menu using its custom styling.
My impression was that the atrocious and discordant two-level Explorer context menu Microsoft is pushing in Windows 11 was because the traditional (Windows 95-era) way to provide context menu items with was to write a shell extension (an Explorer plugin, which would get loaded not only into the bloody system shell but also into every app that used common file dialogs) that would get called when the menu was being built. And that callback interface was built around the assumption of menu items being traditional HMENUs (and allowed the shell extension to set up arbitrary drawing routines for the items it added). So changing the toolkit that Explorer used for context menus away from USER was essentially impossible, and even styling it differently from Windows 95 was fraught (I do remember seeing the occasional flat-gray menu item on Windows XP with Luna enabled). There was an attempt to transition to more declarative context menus around (IIRC) Windows 7, but evidently adoption wasn’t good. And thus the Windows 11 Explorer was forced to use the embarrassing hack of initially showing the declarative context menu, drawn using its new toolkit, then grafting the real one, drawn using USER, onto it as a submenu.
And yet.
File Pilot draws the full context menu with a look very similar to Explorer’s preferred one.
How?..
Extending the user shell was always for the benefit of Microsoft first, and for the rest of us second. Companies who tried to add serious advanced functionality through that found out that they were not really welcome, even though in theory everything was object-oriented, loosely coupled, language-agnostic, yada yada. It probably was mainly a solution to decrease the amount of territory wars over code inside Microsoft, and let teams work independently without demanding synchronous fixes.
We shouldn't forget that half of the documentation on how everything should work was only released after anti-trust investigation and pressure from courts.
https://www.geoffchappell.com/studies/windows/shell/index.ht...
By that time, Windows had already switched to shiny fresh undocumented technologies.
You should remember that a lot of software around the Millennium simply re-implemented latest fashion trends (Office controls, XP styles, etc.) on their own in not quite exact ways, not just because programmers back then wore skins, and ate raw meat, and feared nothing, and because such third party toolkits were available commercially, but also because official interfaces to do the same were not offered until later releases (or sometimes ever). I vaguely recall discussions of teams within Microsoft sometimes doing the same, resulting in Office controls sharing no code with common controls used by the rest of the system which look exactly the same.
The irony is that web browsers, being the most popular kind of application, and interfaces built on top of their technology simply ignore the native interface toolkits, and do everything independently, which is even more extreme than some old school custom paint handlers. A lot of work has been spent on re-implementing native look and behaviour there, multiple times.
One of the examples of actively supported applications interfacing with shell object hierarchy without using system dialogs I can name is Tixati, which needs to have file picker(s) at hand inside its own dialogs. It's not open source, but it has been using GTK, custom controls, and probably some sauce on top. Given the user complains about its performance or missing items, and regular appearance in change log over the years, I'd say it's a wrestling game for the author. At the moment the tree is lazily populated at the first appearance, which is fine, but not unnoticeable.
It is a bit hilarious that showing a list of file names in some directory is a trivial example on using system-provided iterators for the novice programmers, but adding icons matching those that Explorer shows (handling links and other special files, special directories, non-filesystem-based locations which still have files user might want to choose in them, etc) to that list suddenly becomes a nightmare.
Regulars devs don't need an excuse, they have a good reason: their optimization targets are different. The people that turn their work into their salary, and mostly the people who buy into those software, don't go away because of how large the thing is, so, why sacrifice other goals, to further this particular goal?
"If demosceners can do it" is not a good argument to talk about software, because demosceners are the cream of the software crop, when it comes to the specific thing that the demoscene is all about. It's like saying if racers can make that corner doing a 100, regular drivers have no excuse. Or I'm greatly misunderstanding your point.
Filepilot looks great. I wouldn't pay, as Double Commander serves me just fine, but an 1.8 MB download is impressive. DC is 10 MB in comparison. Still perfectly fine.
Early access for a terminal... $60 for a (year subscription???) file explorer... I expect more MBs if I'm paying for these things!
That got a loud laugh from me. Also joining early access for a set period grants you a lifetime license - check the fine print :)
Tiny files and tiny text?! What can't this person shrink