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

Comments

Fascinating

[friday2k]

It is really fascinating what you call small. I remember the VC20/C64 and those things required true small applications. Applications that had more features than most of the "tiny" ones there.
You guys might also want to check out the 4KB and 64KB demonstration pieces from parties around the world at Scene. This will show you what can be done in applications as small as 4KB (rendered demos with sound and stuff like that). Enjoy!

I nevertheless appreciate a movement towards essential, small applications ...

Reliability

[CrunchyMunchy]

This is where software has to go. If there's one lesson we should have learned by now it's that it's nearly impossible to produce enormous but reliable software. Small programs are the only way to produce reliability, at least for now, and that'll be necessary as computers take over more and more tasks.

These guys have got the right idea.

[guru_steve]

"How about BeOS, *nix, Amiga, QNX, etc?," I am asked. Those who are comfortable using these operating systems need no such guide as this; clean, well-made software is the rule rather than the exception.

These guys have got it right on. Outside of the windows software world, priorities are on well made software, in stark contrast to the windows feature bloat that we're becoming accustomed to. I'm not saying all windows software is ill-designed and bloated - it just seems to be the status quo.

It's nice to see that compact well made programs are still available outside of the "alternative" os's

GEOS

[wampus]

Anyone remember GEOS for the Commie64? Windowing system, word processor, paint program, etc. On two disks. If you flipped the first one, you got QuantumLink, an online service.

Strangly enough, I found my GEOS disks about a year ago and dialed their customer service number and got AOL... coincidence or not?

How to write tiny applications

[Black Acid]

Presently most Unix applications are written in C for portability reasons. In reality, C programs have to modified when ported from one Unix to another, unless something like GNU autoconf is used. Assembly has the advantage over C of being extremely fast and tiny.

A well-written tutorial about writing BSD assembly application is FreeBSD Assembly Language Programming. There is also a Linux Assembly Programming Resource Site. I suggest if you hate bloated software to contribute to solving the problem by writing small utilities in assembly. Of course, C remains the choice for large projects, but assembly has it's place.

1.44 MB?

[Daniel Franklin]

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

Re:Somewhat naive - so am I

[Soko]

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

Atari

[goingware]

I invited a couple friends who were old time Atari programmers to post here. I hope they do.

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.

Re:Atari

[Christopher Thomas]

Running Joust on 128 BYTES ram? I think you and Michael are pulling our legs. By way of comparison, this post is 129 bytes long.

The RAM is only used to store game state that changes while you play. This would be the level number, the score, the position and velocity of your character, and the positions and velocities of enemy characters and of the eggs that spawn.

This most certainly would fit in 128 bytes.

The Atari has a very, very bizzare internal architecture. A good page describing it is at:

http://www.alienbill.com/vgames/atari.tech.html

RISKS on Bloatware

[goingware]

Everyone should read The Forum on Risks to the Public in Computers and Related Systems for reasons I've posted here more times than I can count.

But pertinent to tonights topic is a thread called "The Bloatware debate" that ran for some issues on Risks:

A 100-company survey by Standish Group International found that 45% of a software application's features are never used, 19% rarely used, 16 % sometime used, 13% often used, and 7% always used; yet, in spite of the fact that most of an application is seldom used, software gets bigger all the time. For example, Windows went from 3M lines of code (Windows 3.1) to 14M lines (Windows 95) to 18M (Windows 98).

1. The Bloatware Debate
2. Response
3. Response
4. Response
5. Response

and also:

1. Bloat Dissections II
2. Response
3. Response
4. Response
5. Response
6. 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.

1.44 MB small?

[gdr]

Just a bit of fun. On my system.

$ find /usr/sbin /bin /sbin /usr/bin -size +1440k -type f | wc -l
10
$ find /usr/sbin /bin /sbin /usr/bin -size -1440k -type f | wc -l
2667

It's worth noting that both emacs and vim are in the 10 that would not fit on a floppy.

I know I'm ignoring libraries. I said it was just for fun. :-)

Coolest and Smallest app

[DjDanny]

This has got to be the smallest and coolest app ever. It's called Tube and it's 256 BYTES (yes, I said BYTES!). It can be found here:

http://www.pouet.net/prod.php?which=3397

It doesn't use any external libraries, DirectX or any cheating stuff like that. It also comes with full x86 sourcecode for you to enjoy.

Have fun now.