Slashdot Mirror
Tiny Apps
box2321 writes: "There's a time and a place for large and feature-filled software. And there's a place for tiny apps - in fact, there's tinyapps.org. This is a mighty-fine resource for free and shared Win/DOS programs that weigh in under 1.44 MB. I learned of TinyApps from a pleasant source."
Tell me that after installing a GUI desktop on your Linux box. Are you really claiming that X+GNOME or X+KDE and a plethora of widget sets in order to get a decent number of programs running is less-bloated and better-designed than Windows desktop?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Interesting concept. Linux's standard utilities are unnecessarily bloated, replacing them with smallutils allows a respectable distribution to fit on a 1.44MB floppy. According to the documentation, these utilities are included:
Tired of free ipod spam sigs? Opt ou
PicoBSD's applications are really small. Fitting a whole OS onto a single floppy diskette is quite beneficial, and often means that the expensive hard disk can be eliminated. There are also several other small Unix clones, including Minix and Alfalinux (Slackware on 2 floppies). BBIAgent Router is simply amazing: it's a single-floppy Linux-based router and firewall.
Tired of free ipod spam sigs? Opt ou
Does anyone else see the irony (and perhaps the futility) in creating a site devoted to tiny apps that run on the most buggy and bloated OS known to man?
Contrariwise. When your OS is big, all you got left is room for tiny apps.
(I [heart] Boxer for DOS, myself. I'm pretty sure it's floppy-sized or less, at least in minimal version. If I could find my stupid interface cable, I'd put it on my HP200LX.)
Slashdot's token middle-aged housewife
QuantumLINK is AOL. Back in the late 80's the people who ran QuantumLINK realized that running a service for a steadily decreasing number of C64 and C128 wasn't a good long term strategy. So they shutdown Qlink and reinvented themselves as AOL. The rest, as they say, is history.
I'm sorry, 1.44 MB is not tiny :)
:)
I co-wrote a fine piece of fractal generating software, that came with its own windowing system, mouse driver and midi-like music synthesiser (it played a tune of your choice when it had finished rendering the fractal - this was in the days of 386s being power machines), it could do mandelbrot (+ several variations), julia, sierpinski and logistic fractals (plus a few chaotic dynamics plots done in phase space), save and load BMP files of the images and a whole heap of other cool stuff - and it was written in Borland Pascal which had a limit if 64 kB for the compiled program! Those were the days... taught me good programming discipline.
Still remember the excitement of discovering the limits of machine precision by rendering magnified Mandelbrot sets on my 386
- Daniel
You might need to take a look to RiscOS which makes it quite easy for the hosted apps to be *tiny* (a complete DTP package supporting plugins weights several hundreds kB)...
RiscOS is around as old as Windows3 but has always been well designed, quick, compact and responsive.
But I understand such tinyness might seem mythical for PC users.
Trolling using another account since 2005.
OK, but why objects and not actual programs? IANAP (I Am Not A Programmer), but an idea I've recently subscribed to is using several small, fast programs that work together in concert be roughly the equivelent of a bigger app. It would work like so (apply NaCl liberally):
:-] )
A stand alone, plain, small generic text editor knows when there's a spellchecker, font manager etc. available, and would spin them up as separate processes and let them modify the data as needed. These too would be stand alone apps - you could use
"[user@machine MyDir]spellchk Mydoc.txt -lang USEnglish"
and it would open the doc and spell check it outside the Text Editor, if you wish. Inserting a spreadsheet into a document would cause the program to context switch to a generic spreadsheet, which would do the calculations and then spin up the layout/font manager, which would tag the spreadsheet data with appropriate formatting info and then pass it back to the Text editor/Word Processor program.
Registering one of these mini apps with the application broker (not an object broker!) means that any other mini app can call on it to do a task - this would make things totally pluggable, and allow for infinite customisation options. You like the KDE interface best, but wish you could use the GNOME spreadsheet? Yank KDEs spreadsheet app and plug in GNOMEs. Need a funtion that you don't have? Go download it and plug it in. Have a function that you don't ever want to see again? Un-plug it and toss it. Want bloat? Use 100s of plugins. Want Speed? Use 10. Get the idea?
Sounds a lot like the development today from KDE, GNOME et. al, but the difference is in the object libraries - those huge, incompatible obfuscated buckets of code snippets (on both Windows and *nix) that always seem to cause problems for each other. Why can't we single purpose them all, and tie them to a mini app? Instead of a library of widgets to edit text that any program can use, why not limit the use of text editing widgets to a single program - the registered text editor. Program then calls test editor program already running. IMHO, development teams would then be able to concentrate on a single function, not 20, and would likely be able to produce small, fast quality code by throwing everything out of thier libraries not pertaining to the function of thier mini app. And if a mini-app is un-installed, the library goes with it, period full stop.
Perhaps then we would end up with code of reasonable size and quaility?
P.S. - Please don't flame me for careless suggestions of shared memory amongst other transgressions, but I'm interested in why the object model is better than programs that communicate actions on data, not just data. Like I said, I don't really know the nitty gritty technicalities of what I'm talking about, but I'm interested. (I'm wearing my asbestos jammies, too.
Soko
"Depression is merely anger without enthusiasm." - Anonymous
to some excellent comments and feedback, I'd like to offer the following:
1. Yes, 1.44mb can hardly be called "tiny". To be honest, the reason it was chosen is that I just *had* to include the QNX Demo Disk and the OffByOne Web Browser. But much of the site is dedicated to apps in the 2 to 200kb range, which I think can fairly be called "tiny". One example is EVE, a very cool vector graphics editor whose executable is a mere 39k. There are many more listed along these lines.
2. Yes, Windows is very bloated, but by customizing the shell, removing IE, and performing a host of other surgeries, it can actually be quite a nice little OS. I just received an email reply from the author of Optimizing Windows (published by O'Reilly). His book explains (among many other things) how to get Windows 95 down to 17 mb.
3. I realize that Slashdot is generally geared towards *nix users and want to thank you for being kind enough to list a site mainly covering DOS/Windows apps. As I mention on the home page, folks (from any OS) interested in contributing to the site or having a link posted are more than welcome to contact me.
Also, many thanks to those responsible for the mirror mentioned in one of the posts.
Much aloha,
Miles Wolbe
miles@tinyapps.org
http://www.TinyApps.org/
But in case they don't, I'll tell you what the Atari programmers had to deal with. I'm hazy about the model, but I think it was the 2600.
The unit had 128 BYTES of RAM, which included both the heap and the stack. It had a one byte framebuffer, and you effected the drawing of objects and animation by carefully timed changes of its value during the horizontal or vertical blanking intervals.
One big help is that collision detection was implemented in hardware.
You had a choice of a 2k or a 4k cartridge to store the executable code and graphics. You could do a lot more with 4k, and potentially make a game with greater appeal and thereby greater sales, but it came at the cost of the 4k cartridge yielding the programmer half the rolyalties per unit, because the ROM chips were more expensive.
Dave told me of the long hours the programmers would put in trying to get the last few bytes out of a program, to make the transition from 4k to 2k. Suppose you had a program that absolutely required 2050 bytes - wouldn't that be heartbreaking? Sometimes the programmer would think he had a way to shrink the code enough, but it had the effect of screwing up the timing on the graphics.
The royalties could be considerable on those little cartridges. I understand the 19-year-old who wrote Pac Man for Atari received $1 million in royalties.
Again I say: Kids These Days.
-- Could you use my software consulting serv
Refreshing to see you all bragging about "Who has the smallest"
Help fight continental drift.
But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:
- The Bloatware Debate
- Response
- Response
- Response
- Response
and also:- Bloat Dissections II
- Response
- Response
- Response
- Response
- Response
One culprit that I think is mentioned in there somewhere is the use of virtual functions in C++. Even if a virtual function never gets called because of the way it is possible to run a program, it must be included to satisfy the linker. Virtual functions are necessary to enable polymorphism, though, so I don't see a way around it. However, I suspect they are overused; many C++ programmers do not know when it is appropriate to make a member function non-virtual vs. virtual.-- Could you use my software consulting serv
His stuff is always small (www.grc.com). Trouble in Paradise is a complete Iomega drive diagnosis package self-running at 52KB under Windows.
1.44Mb is f***ing huge compared to what it was like in the good old days.
I used to write commercial apps for the BBC Microcomputer. You probably didn't have that in the US, but it was a neat bit of kit in its day (about 1984?) and very popular in the UK.
As I remember it had 32Kbytes of memory, most of which was taken up as screen memory. I think you were left with about 8K to program in. And you had to get everything in there because there was no hard disc or other storage.
I remember I wrote an educational program for schools which included an image drawing system that worked in a similar way to Macromedia Flash. Literally every bit of memory was used. In fact, there was 'spare' to store upto 32 images drawn in the format.
Tell that to programmers today, they don't believe you.
Being a windows user, I have to watch my applications to make sure they don't eat up memory, i.e. memory leaks. So I downloaded a tinyapp called "MemLoad" which should help me do this... but here's the kicker: From the Readme file: Current issues >
There is a small memory leak present in Memload
M@
Krispy Cream is people