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).

  0: https://www.reaper.fm/download.php

▲ mananaysiempre 3 days ago | parent [-]

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?..

	▲	ogurechny 3 days ago \| parent [-]
		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.