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

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.