Tiny, single exe (and an ini for config) Windows programs have a special place in my heart. Perfectly portable, instant and lightweight.
I want to cry when I see simple software like Sticky Notes in Windows 10 using dozens of MB of memory and have a 30+MB install size with minimal functionality.
I don't have a big issue with .NET and Java based apps but I seem to be using more and more Electron based software and while the software isn't bad it sucks that every program comes with its own bloated framework :(
Although it was "removed due to copyright violations"[1] in 2003, TinyWindowsGames.com was a work of art. If you don't mind downloading random binaries you can still grab them via the Internet Archive. I will see if I can create a new screenshot of the playable, tiny thumbnail near the system tray (probably microscopic at today's resolutions).
[1] Nintendo reported us to some software theft agency over "Tiny Donkey
Kong" (I forget what the agency was called) and that got us threatened
us with scary emails. We tried to protest that we just supplied
emulators, and not ROM images, but it fell on deaf ears and we were
too young and intimidatable to stand our ground. It's a shame, since
it was a popular site in its day.
I miss GameHippo. Back when I had dial-up and a Pentium 100mhz with 16mb of RAM, it was the best place to download tiny games that would actually run; and it's why I got into programming -- a README with one of the games said a single person wrote it in Pascal, and that gave me the inspiration to learn to program myself!
I'm afraid (or perhaps the word I'm looking for is "glad" ;-) that the Internet has passed tinyapps.org on by. After its fleeting 15 seconds of fame back in 2001 (thanks to a Slashdotting and tiny blurb in Wired), the site has mainly served as an irregular tech blog lo these many years.
Clearly there is still tremendous interest in the type of efficient software you curated so well back in the day. So many of the programs still work fine today even though their original websites are long gone -- a testament to minimal dependencies, your efforts to archive local copies, and Microsoft's commitment to backwards compatibility!
Your blog is always a breath of fresh air any time I happen to stumble by one of your solutions in response to searching for help. Definitely one of my "trusted" sources - don't ever let that domain expire!
When I see the specs of things like the Raspberry Pi and Apps like this, it makes me wonder how great a system like that could be.
Executable size may not be the best measure of these things though. Ram usage of some things can be quite huge. tinyapps.org seems to avoid this by disallowing things needing runtimes, which while not the cause of RAM bloat, often tends to be a common factor.
I'd actually like to see an interface for micro controller style apps. Like An 8 bit AVR emulator that could do some kernel syscalls to the hosted environment. It would allow for a class of apps to be written that would have a fixed memory footprint. There's some Irony here in that this would also be a runtime.
I once had a volume knob widget on my task bar that used 4 meg of ram. Somehow I feel it could have been done better.
I've been thinking about this a lot, mainly due to being grumpy about the proliferation of Electron apps and the effect that's having on my available RAM.
When I'm not being so grumpy, I'm glad it's easier to write apps than ever before. I think someone on here posited that it's a choice between something written in Electron or not written at all. I think that's fair enough - maybe we just need to make it easier to write tiny apps. Rust and Go look great, even with a very steep learning curve coming from C# and Python.
And yes, I know as a C# developer sitting on top of hundreds of megabytes of runtime, I'm "part of the problem".
I'm glad it's easier to write apps than ever before.
But it was easy before. If you are willing to forego completely native UIs (which you are when you are using Electron), it's always been easy to make GUI apps with Qt. Drag together an UI in designer, use (py|whatever)uic to generate classes, hook up signals/slots, and you are done.
I can only pin it on intellectual laziness of front-end programmers not wanting to learn anything else than HTML/CSS/JS and companies wanting replaceable developers. There is virtually no benefit for the end user over native applications or cross-platform applications written with e.g. Qt.
I'd say that with Lazarus (http://www.lazarus-ide.org/) it even easier - just drag/drop the controls to forms to build your GUI, double click on buttons/checkboxes/radiobuttons/whatever or click on menus or double click on the event editor to automatically write the event handling boilerplate code and you just write the actual code in-place. Creates native executables without need for runtimes or big DLLs (you can use Qt as a backend if you like though and in Linux you have to choose between Gtk and Qt).
Here is an old video i made 2-3 years ago where i write a small 2D tilemap editor with Lazarus (the first 5-6 minutes are downloading and installing Lazarus and a tile editing tool i wrote since i used Windows 7 for that vidoe and the Win7 paint program sucks) https://www.youtube.com/watch?v=_3JgeIUo1X0
In my previous life as a cubicle drone in the late 90s I have worked with Delphi under Windows and always dreamed about it being ported/cloned/whatever on Linux. After seeing a demonstration of Kylix many years ago I almost lost any hope (slow as molasses and buggy), then one day I saw this new project called Lazarus which promised high compatibility with Delphi code and to allow building of native apps. Admittedly it was very buggy then, but eventually it matured over time and I'd say it has been damn ready to be used for production for some years. Give it a try and you won't be disappointed.
I've tried to use Lazarus five or six times now, as a one-time Delphi developer: the main issue is that the lazarus ide likes to crash on the slightest provocation (and the 64bit mac versions don't work very well either)
Which version did you use and when? 10 years ago the IDE would crash at you sneezing at it and it wasn't until 7-8 years ago that things became stable. However i cannot remember the last time i saw the IDE crash (and wasn't my own fault with a component i was making that caused it to crash, but even that that is rare).
Note that there are a few versions flying around that are unofficial builds, some with addons that break it. Sadly one of them is the one from getlazarus.org which is both unofficial and often comes with unfinished and buggy features from development versions that cause it to crash and be generally more unstable. Combine this with the fact that the guy behind getlazarus.org tries his utmost to promote Lazarus (his version from his site) and there is a chance people who first learn about Lazarus will use the buggy one. He obviously means well, but i really wish he would link to the official site (http://www.lazarus-ide.org/) instead. The builds there are much better tested and there are many week-long release candidate builds that are tested by many people in the mailing lists, forums, etc before an actual final release is made.
Also note that the native Mac version is really in a worse state than the Windows and Linux versions. Thanks to Apple discontinuing Carbon (which is what Lazarus uses on Mac by default), a ton of work has to be done to rewrite the backend in Cocoa and there are very few programmers working on the Mac version so this progress is slow (also AFAIK this was delayed to implement the "Objective Pascal" extension to the compiler that would allow using Objective C classes directly without needing an intermediate C layer). Today you can use both Carbon and Cocoa as backend targets, but between the two the Carbon one is still the most stable. As an alternative you can use the Qt backend though that is more stable and featureful (thanks to it being also worked by the Linux devs), but you'll need to bundle a bunch of shared libs and are throwing all notions of minimalism out of the window :-P. Still it is the only way to get full featured stable 64bit apps with Cocoa made in Lazarus, at least until the Cocoa backend improves. And it isolates the bloat to a single platform, which while not ideal, is better than nothing (and IMO even the Qt+LCL combo is still better than bundling an entire web browser with your program).
So, I do most of my work on Mac, so that's what I'm using. It took me forever to figure out how to rebuild it as a 64bit app using Qt (I built the Qt5 version, maybe that's part of my problem?). Anyways, once I did that, it started fine but I ran into several issues where changing properties of Data Access components would crash the IDE. (postgresql-related things in particular). If I find time, maybe I'll submit some sort of bug report with a reproducible scenario.
You are one step ahead of me, i never managed to build the Qt version myself :-P. Although i didn't try much, i rarely use Macs these days and mostly wanted to see if some minor issue i had with the Carbon build would go away with the Qt backend (the Cocoa backend was basically unusable at the time, although i think today it would work ok).
TBH i'm not sure if it would be Qt5 or the data access components as personally i don't use either :-P. I use Lazarus to make tools mainly for game development (and mainly for 3D stuff) so i don't use the database features at all. Also i tend to use the Gtk2 backend on Linux, mostly because it is the default but also because it tends to fit better the minimalistic window managers i am using (mainly window maker).
This is strange. The IDE once surely had stability problems, but I've never encountered them since years. I even installed Lazarus on small NanoPI and OrangePI boards and although definitely not fast it runs natively there and produces native code for them.
Don't you need to be using Lazarus' language (Delphi?) for that? In most cases, that's very prohibitive, since a language with a large ecosystem is usually what you'd want to be writing stuff in.
Yes, but there is a ton of functionality already out there, Object Pascal is popular enough to have almost everything available and for the stuff that aren't available it is trivial to call into other native languages (and there are many bindings already available). If you have a C header you can even use a conversion program that comes with Lazarus to create a binding for it.
Of course it all depends on what you want to do, but for me at least that was never a problem.
Is a PyQt app really more lightweight than Electron?
To be fair, Qt is a lot trickier than Electron - you've mentioned slots and signals which are not something you'd encounter every day (at least in webdev world).
Edit: I also don't buy any argument that relies on "intellectual laziness". There's enough elitism around already.
Is a PyQt app really more lightweight than Electron?
I just tried, because it's only 5 minutes of work. The demo apps (including a movie player and an image viewer) are generally in the 30MB of memory ballpark on OS X.
you've mentioned slots and signals which are not something you'd encounter every day
It's something that you can pick up in a few minutes. Widgets emit signals. You can connect signals of choice to slots to handle those signals. In Python, a slot is just a Python method. In C++ is slot is also a method, but you have to add a small 'annotation' that is processed by moc.
Well, I can't speak for today, but back in the early 2000s, I put together a simple web browser in Qt, which is easy because it already includes a simple web engine, added a simple JS engine, and the web browser was up and running.
I recall being disappointed it wouldn't run nicely on '98 for some people, because it used about 25mb of RAM, and many only had 128mb for their entire system.
The thing about electron is, there's a time and a place for it.
VsCode is an excellent use case for electron - a complex cross platform app with a very quick release cycle, a large plugin ecosystem and a requirement for display and processing of a lot of different types of markup.
But I've also seen a tray notification app worn in electron. It didn't even have a UI. There's also an sd card formatter, and a "quick" launcher.
Devs who wasn't to release some tiny single function app like this should rightly be ridiculed for using electron, but more complex stuff (gitKraken etc) should get a pass. Building a large, complex editor is hard work
I'm a python and clojure dev, and part of the reason for going in search of tiny apps with source code was to see how they managed it. I know I'm part of the problem too, I like working at a very high level, but I, too, am getting old and grumpy and detest how 16GB ram isn't enough these days.
I was actually, partly, looking for a community who built or curated lists of apps with artificial constraints, for example: app must not use more than N MB of ram, must be open source, etc.
there is the demo scene, but I want to build practical apps, and there is suckless, but I found their community and philosophy a bit ... hardcore and unaccommodating.
This is a wonderful trend. I've been griping about bloated apps for ages. There's a huge accessibility issue for people in Latin-America and Africa, where most people's computers still have no more than 2G of ram.
I think its less about a hard limit and more about comparing to other apps out there that do the same thing. Music players for instance. 1by1 < foobar < VLC < Songbird / Spotify
absolutely. I see a lot of css and js frameworks marketing themselves on how very small they are, both before and after minimization. I guess the first step is to accurately measure what is important.
it's a good point and something I'm still investigating. with the jvm you can set the maximum memory available to the instance.
I once did all the fundamental C and C++ type stuff, writing a memory manager and my own implementations of certain datastructures and algorithms, it doesn't seem unreasonable to write something that would enforce program limits in a transparent way.
> I'm glad it's easier to write apps than ever before.
I believe that it is Delphi which sits right at the sweet spot of 'native code', 'easy gui development' and 'easy deploy' and I am sad that it is not really in use anymore.
> And yes, I know as a C# developer sitting on top of hundreds of megabytes of runtime, I'm "part of the problem".
This should be a solvable problem, IMO.
I mean, C/C++ apps are not inherently tiny - they sit on top of a large runtime too, but one that usually comes with the OS. What makes Python or Lisp apps (in binary form) multi-megabyte by default is that they can't depend on users having the runtime installed, unlike C/C++ apps. JVM managed to cross that gap too - most users, at some point, will install a JRE, which allows .jar files to be small.
I wonder why generalized solution for managing programming language runtimes OS/user-side didn't materialize.
What makes managed/VM based languages big is that those runtimes are general purpose, and therefore have to embark what most people need. A C/C++ app embarks (mostly) only what's necessary.
I can compile a hello world for bare metal, replace puts with a routine that sends the characters to the serial output, add the necessary UART initializations, and the final program will still be a bunch of order of magnitudes smaller that a Python install. The comparison is unfair of course, but it proves one thing: no multimegabyte runtime in C.
Python runtime also uses that same C runtime so it's not as if you can replace one with another. Besides, stripped static binaries in C or even C++ can be relatively small. JRE is not installed by default on many desktops, let alone embedded.
> I once had a volume knob widget on my task bar that used 4 meg of ram. Somehow I feel it could have been done better.
Yesterday, I decided to finally retire my old self-written 'sticky notes' utility, and migrate all my notes to the built in Windows 10 Sticky Notes.
* My note app: ~3mb whilst running.
* Win10 Sticky Notes: ~22mb whilst running.
22mb might not be a lot of ram, but I do struggle to understand how it's using that much memory just to display small squares with text in them...
...
Anecdote: Two hours later, whilst trying to copy-paste text from one note to another, I lost the text completely, and Sticky Notes crashed... ~sigh~ back to my crappy app then...
Probably because the Sticky Notes on Windows 10 has a bit more functionality built in. If I remember correctly, it has integration with other systems (including Outlook), so you can make a note and create a calendar event with said note.
Basically there's just a lot going on under the hood for many of these "simple" apps that isn't user facing. For better or for worse, that's why.
One of the other things not yet mentioned here, is that Sticky Notes integrates all of Microsoft's new Inking and Typing features. On a touch/pen enabled system, you can write on the note, and if you have some of their cloud features enabled (I usually don't), it'll convert your handwriting into text, convert text items like addresses into clickable links, etc. If you put a flight number in there, it can turn it can add flight tracking, if you put a stock ticker in there, it can update you on that, etc.
"Stickes" from Zhorn Software currently running ~8MB private bytes. I've been using this software for...er...longer than I can actually remember. I don't recall it crashing once.
Writing tiny apps for small constrained systems isn't difficult at all. That's what we did thirty years ago. One neat trick is to use threaded interpretive languages (FORTH).
It's fine as long as the runtimes themselves are tiny and low-overhead. Most C and C++ programs carry around a mandatory "runtime", usually denoted by the module name "crt0". It's basically just a translation layer between the OS's executable calling conventions and main()/return that weighs a few dozen bytes and only runs during startup and exit of the app to do things like set up argc/argv/envp and put the exit code where the OS expects it. The C and C++ standard libraries provide many of the services that a framework runtime would otherwise provide, but they're usually much smaller than a modern "framework" and provided as part of the OS. Modern Windows desktop apps are supposed to install their own copies of the DLLs (msvcrXX.dll/msvcpXX.dll and friends). You can link against the "known DLL" msvcrt.dll, but I don't think linking to it is officially supported for any non-ancient version of Visual C++, and IIRC it has a bunch of carefully preserved bugs for backward compatibility. Maybe there should be something like musl for Windows?
> I'd actually like to see an interface for micro controller style apps. Like An 8 bit AVR emulator that could do some kernel syscalls to the hosted environment. It would allow for a class of apps to be written that would have a fixed memory footprint. There's some Irony here in that this would also be a runtime.
As rebootthesystem suggests, this sounds a lot like a niche that would be well-served by a purpose-built Forth interpreter. Such interpreters have been used to e.g. facilitate interactive development or hot-patching on actual microcontrollers and other constrained systems. There's a surprising amount of symmetry with Lisp systems, but the traditions of Forth tend to value small code for both application and implementation. There's probably nothing preventing a tiny Lisp from filling the same role.
I think the large ones are only as large as they are because they statically link with the CRT. I used to do the full /NODEFAULTLIB /OPT:NOWIN98 thing, and leave out the CRT entirely, so the EXEs were tiny and had no dependencies - but this was a bit of a pain to work with. And dynamically linking with the CRT caused me a couple of deployment problems here and there, since I used to share my binaries folder between several PCs in the past. So eventually I settled on the purely no-dependency option: statically linking with the CRT, and ignoring the EXE size. The average app just isn't made meaningfully larger in the grand scheme of things by this, and by modern standards it barely even counts as measurable. Even if it's a tiny app, and now 10x larger, it might still be only 90KBytes...
I was curious about how small (file size) and efficient (memory) I could write a program with a GUI and came across this old gem. Most of them have links to their source.
This is refreshing to see. I was just at the doctor today, and they mentioned how a recent system update (they use a system called Epic) made their receipt printing go from an abysmal 30 seconds to a full minute.
It seems that programs get bloated and slower with each passing day. I'd love to see a Renaissance of small, focused, efficient applications.
I wonder why this field hasn't been disrupted yet. It seems ripe for it. Established players. Arcane systems. Poor performance. From what I've heard from employees at Epic their software is something of a nightmare.
Is it just something waiting to happen? Is there a company that is already doing this? It could probably be done one independent hospital at a time. Eventually you could get a small network, etc. I understand there is quite a bit of complexity involved, but isn't that what technology excels at?
Edit: Did I forget to mention expensive? These systems are not cheap, and usually involve engineers spending weeks or months onsite setting it up. That means there should be a significant of margin to cut out for competition, and/or healthy revenue for a startup, at least further down the road.
I worked at Epic a long time ago. They're a bad employer -- churn that would make the worst valley sweatshop blush -- and even when I worked there had 10s of millions of lines of vb6 and the same in mumps/cache, the world's worst programming language. I'd imagine their systems have broken 100m lines of code by now.
You're essentially using software to automate how hospitals and outpatient clinics work. Each one of those has established workflows/procedures; each of those workflows have started or evolved to be (at bare minimum) subtly different than everywhere else. Each and every procedure has to be build into the software or adapted to it. Installs are comparable to installing ERP systems into fortune 500 or fortune 100 companies, with at least comparable risks. Imagine how risk adverse you would be if inaccessible, incorrect, or incomplete health records could quite reasonably contribute to severe medical problems for humans.
If you were ever in a hospital for something serious pre EMRs, you would be unsurprised to have a file that is several hundred sheets of paper. Every single scrap of paper in a hospital has to make it's way into Epic's EMR.
Oh, and hospitals / clinics often buy these systems piecemeal, starting eg with labs. Your code has to talk to their code.
Lots of these got started before web clients worked well, so they're deployed clients. You can't upgrade 10k seats simultaneously, so both the clients and the servers have to be compatible up and down protocol versions. Ponder just how much fun that would be.
Or ponder just how convoluted the logic would be to ask if a person who does X in clinic A is allowed to see record B for patient C. In, for example, a hospital chain that may employ 25k+ people in the hospital and various outpatient clinics.
And follow up with questioning the idea (and expense!) of retraining every nurse, doctor, aide, tech, etc in a hospital on a new system.
MUMPS really isn't a bad programming language. It has certain characteristics like allowing incredibly terse code, with abbreviations for all the commands and single letter variable names, but the trade-off of a NoSQL hierarchical datastore acting as variables to the programs with string values and string subscripts on arrays, hiearchical inter-process locking, high level variable management and garbage collection, run time code and variable evaluation, and other advantages. Modern MUMPS systems have high level database management systems as well.
I work in an industry you wouldn't think is similar (telecom). It's hard to establish trust, it's more complex than you think, it's more regulated than you think, more rules than you think, closing deals takes longer than you think (6 months is long? Try multi-year sales cycles!), big companies will ruthlessly undercut you to destroy you at their own expense...
You can't just slap together a single page javascript app and close a deal. You need credibility, capital, time, solid engineers... and most strong engineers will avoid EMR software like the plague given the riches they can make in other areas in 1/10 the time.
I wish everyone the best of luck, it needs to happen, but it will be hard.
There are companies that are trying. Athena was doing a good job in a lot of respects but then decided they wanted the hospital market and that hasn't gone well. The issue is that switching EMRs has a huge switching cost. You are looking at years just to get the sale. Then there is the time and cost to switch which can easily be 6-24 months depending on size. The biggest problem is that all the health care workers have to relearn a whole new flow and these things are not trivial. Add in that most health care workers are not as tech savvy as you would think.
Additionally, as was mentioned, the health care systems depend on the EMR for all government and compliance reporting. The EMRs also do NOT play nice together so even if you get customers, it is hard to get data out and shared with other systems. It is possible to disrupt this space but you better start with a war chest, start with a very focused niche (say Urologists) and be prepared to slog it out for a decade.
Thank you. It looks like Athena is trying to do just what I described. They even have an incubator for new health related startups[1]. Of course, it is difficult to know from the outside how well they are doing and their trajectory, but I am (foolishly?) optimistic.
The incubator program is fine but it is a little bit dependent on their cash flow. They sunk too much money into the hospital space and their free cash flow is down and so is their stock price. Johnathan Bush is a free spirit and willing to be disruptive which is their greatest strength. If I lived in Boston still, I would be working there.
(not an expert in this field obviously)
I believe that it might have to do with HIPAA compliance and the red tape overhead that scares away potential disruption. But I imagine if someone were willing and able to disrupt it, they'd make money hand over fist.
The quality of programmers working for companies like this is terrible. I'm talking about programmers who claim to "know" C++ because they used it once during a computer science project and just managed to avoid getting segfaults too often after lots of trial and error. Writing a small, effective program has been a sign of competence forever because we know that you can't "fake" it. You really have to know what you're doing.
Bloat wouldn't even account for a delay this long. This seems to be the realm of bad design or overly cautious developers. My guess is that 'printing the receipt' really means process the transaction hitting a bunch of different record stores and APIs along the way and that the system waits for all of that to complete before sending the print job.
I ruefully sort of wish CSS was 100% client side so that all sites would be delivered as plain, unstyled HTML and it would be entirely up to the user how they prefer to see content. Obviously not at all practical, but would make it so much cleaner and easier to read when browsing 90% of sites out there.
the old presto version of opera had an option to default to user css for the whole program instead of the various sites'. don't know if that's still available in the new version.
Progress is modern computing has only been exceeded in the increased in bloatware! Using these lean and mean apps on modern hardware is heavenly - the way I imagined, 10 years ago, of how things would be today.
I wish it were easy to write such small apps, particular cross-platform. I'm developing a cross-platform file manager [1]. It's way more bloated with dependencies than I would like. But I can't justify spending time on trimming its dep's when there is so much functionality that needs to be implemented. Having said that, I did choose PyQt over Electron for performance reasons [2].
One thing that you seemingly missed in your review of toolkits is that PyQt cannot be used freely by a proprietary application such as yours. Qt itself is LGPL, PySide (the official python Qt binding) is also LGPL, but PyQt is GPL-only unless you pay them $500.
Back in the 90s I used this DOS text editor that fit on a single floppy sector (512B). I forget the name, but it was a part of my standard toolkit for many years.
These days, I run "evilwm" for my home desktop. That's about as small and efficient as a DE/WM gets anymore, and I love it.
I've been using a replacement of network>Proxomitron proxy filter tool called Proxydomo available on github. God bless the guy that reverse engineered the original.
Perfect thread to mention AnyDesk, our remote desktop application. We practice minimalism as an art form, the size of the Windows executable is 1,8 MB. [0]
tangentially related: wasn't there a website of single page web apps a few years ago? I'd love to see tiny SaaS or software solutions listed somewhere.
You can write all sorts of tiny apps. We need to have 100 people just to tell the other 100 people what process to follow, how to write everything, what it should look like, etc. Plus another 100 people to run the process. Also another 100 people to manage those people. Bonus: the following version in this monster must be complete before the previous version is even live. No tiny for us...
Ninite also follows an interesting concept and saved me some good time in the past. Can be really useful if you need to install the same subset of apps on more machines.
https://ninite.com/
I want to cry when I see simple software like Sticky Notes in Windows 10 using dozens of MB of memory and have a 30+MB install size with minimal functionality.
I don't have a big issue with .NET and Java based apps but I seem to be using more and more Electron based software and while the software isn't bad it sucks that every program comes with its own bloated framework :(