Easy enough to do with early days DOS programming. PC's would cache various disk drive information in unprotected system memory (disk type, number of sectors, number of tracks, number of platters, clusters/sectors chains of open files), then write that stuff back when the file was closed. Anything that corrupted this area of memory would make the PC unbootable. Things could be well and truly messed up if you didn't use the same memory model as third-party API's (tiny, small, medium, large, huge), so 32-bit pointers became 16-bit pointers and vice versa.

Just about everyone those days used Norton Utilities to defragment their drives, clean up lost cluster chains, cluster rings, shared sectors, and everything else that could go wrong like losing files if the PC crashed while the files were still open. Recovering deleted files was the biggest selling point. Fortunately, journaled file systems were invented because of this.

I remember tracing through the BIOS instructions to do basic VGA graphics like drawing a single pixel; save *all* registers, unlock *all* VGA registers, mask, shift, add and write pixel byte, relock *all* VGA registers, restore *all* registers.

Like Africa - they take a standard openbed truck, add a mounting point for a machine gun and turn it into a "technical".

http://en.wikipedia.org/wiki/Technical_(fighting_vehicle)

Sometimes the driver uses special optimized paths depending on the name of the executable. That was known in the past, so they could optimize for benchmarks and games. Even certain configurations of GL function calls were faster than others eg. glDrawArrays

http://www.spec.org/gwpg/gpc.static/Rulesv16.html

My parents wanted the ability to call me at any time - they really got annoyed that I wasn't going around with a mobile while downtown or going to work by bus.
Some workplaces want to know when you are being held up in traffic and won't be able to get into the office for an early meeting. Being able to call a taxi or emergency services is a big help, especially when there are no longer telephone boxes. Other employers are using Skype to handle IRC style discussions that don't require reserving meeting rooms.

Having a smartphone helps you navigate your way round a new town with unfamilar streets. The Google maps have helped me avoid getting lost several times. The worst time before I had the smartphone was when I went for dinner into a Burger King with entrances on two corners of the building, and ended up having my return path rotated 90 degrees, ended up in a completely different area of the city.

Graphs, bar charts and selection lines are still too complex. A smart cooker would see what was going into the oven, determine the current temperature and know how long the item should be cooked for in order to achieve a perfect temperature.

I know that for my cooker, fish fingers from the freezer need 10 minutes at 200C, burgers take 15 minutes each side at 200C, chips take 15 minutes at 200C, so they should be put in halfway through

What would replace them? The obvious architecture would be a node based system like a scene graph or composition editor that would allow data-flow programming. Most of the components are already in place.

At each end of the systems, you would need framebuffers objects (GL Framebuffer Objects, GL multiple render targets), uncompressed and compressed textures (GL Texture Objects), geometry objects (Vertex buffer objects), program objects to transform vertex and texture data (GL vertex, geometry, fragment shaders). You would need occlusion culling (GL occlusion queries).

You could add mesh objects which would define the type of connectivity (regular square mesh, regular triangle mesh, either open or closed, list of triangles), though for the desktop GL these are represented as display lists. You have transform feedback, but geometry feedback and fragment feedback could also be added.

OpenGL ES is adding the following features which were on desktop GL:

Framebuffer Objects - you can bundle up a color buffer, depth buffer and stencil buffer into a single framebuffer object. Basically the equivalent of a SDL surface. You can have as many as the hardware supports. This eliminates the need to render-to-backbuffer and read-into-texture for shadowing effects.

Multiple Render Targets - now you don't just get one framebuffer color buffer, depth buffer and stencil plane as destinations, you can get as many as the hardware can support.
New Compressed texture formats (ASTC) - requires the use of external texture compression software to get 1-bit per pixel, working with 2D, cubemap and 3D textures. But you can't use compressed textures as render target destinations.
Shaders are evolving too - there are precision specifiers for floating point (high, medium and low), You can also have uniform blocks which are a bit like C++ namespaces.
Transform feedback with varying values - you can tap into the data being sent out from the vertex shader.

OpenCL is also becoming available in order to allow mathematical algorithms to be implemented as kernels, rather than mangled into shaders.

That's not the fault of Microsoft - many other vendors brought out their own 2D and 3D API's

Borland - BGI - Borland Graphics Interface - designed for monochrome, 4-color and 8-color graphics CGA and EGA screens. Disappeared when VGA came out.
TIGA - Texas Instruments Graphics Architecture - designed for 256, 16-bit and 32-bit VGA, Super-VGA screens. Featured programmable pixblitting, point and line-drawing chip. Up to four TMS34082 floating-point coprocessors could be paired with the .Disappeared when Intel brought out the video bus
Phigs - An early high-level 3D API.

Many have evolved - either an API evolved or it went extinct.

Microsoft always aimed to be the middle man between the hardware and the user, through the windows system, widgets and API specifications. For business users, that was all they needed, they didn't really want to mess about with DMA interrupt channels, extended memory, device driver memory allocations every time someone needed a new PC.

Usually, the company will have two teams - the first writes all the applications code. The other team writes automated tests which try to break the application code.

One of the most interesting things in doing things in a hurry is that you write the absolute minimum of code necessary to solve a problem, but will need to continuously add new features in the future . In the past, design by committee with sub-committees, technical reports, and you will get an PI with more layered architecture, but lots of extra functions and a smorgasbord of data structures, will last longer, but take years to be considered to be reliable and trusted by customers. In the past, such systems would have to wait for the advance of CPU's before they became usable.

Used to be called "macho-management" - managers would decide to take the change of a short-cut or cut corners to save time. Maybe skip the design or layout stage, and just get everyone to start hacking away. Then as new features get added, more and more special-cases are added until the complexity becomes unpredictable and unmaintainable. What could have been a simple filter/matching system implemented from the first day, has become a tangled heap of if-else cases in multiple functions. The situation isn't helped by manuals written in poor translations or API's having undocumented features. The stress becomes so high, that the only way to keep everyone sane is to have hard-drinking sessions.

There were several short sci-fi story on this topics. The first story had two advanced technology countries at war with each other. Gone were the days when orders or messages or even mathematics were written down on pen and pencil. Layer and layer of defence and and attack technology was developed. Long range radar, missile shields, interceptor drones, attack satellites, jammer satellites, space mines, all networked and controlled by defence computer systems. At the same time, an archeologists rediscovered hand-written mathematical notes. After deciphering them, he figured out a way that a human could navigate and pilot a high-altitude aircraft without the danger of being jammed. Then the military became interested.

Another story had two space battalions engaged in a permanent game of three-dimensional chess in deep space. For every move recommended by one strategic computer system, the enemy's strategic computer system would formulate a counter move. For generations this extra-solar game of chess had been played with people graduating from space warfare academy, assigned a position, climbing up the ranks and retiring on a pension. Then one person figured out a way of winning this game - sending the order to attack at random.

Because they are jealous - that the Chinese could afford to remission a probe to do something "trivial" as photograph an asteroid. Of course when NASA decides to remission probes to deliberately crash into the Moon then that is "discovery". To me, deliberately crashing anything man-made into an extra-terrestrial object runs the risk of contaminating samples for future experiments.