1996: Small Screens, a Bigger World
· 60 min read · Views --

1996: Small Screens, a Bigger World

Author: Alex Xiang

Essays

Many years later, when I think about my relationship with IT, I still feel that it did not begin with the Internet.

It began with a heavy computer.

Around 1994, I got my first PC. Looking at its configuration today, it reads like a museum label: a 386DX40 CPU, 4 MB of memory, a 210 MB hard drive, a double-speed CD-ROM drive, two floppy drives, and a 14-inch CRT monitor. Computers then did not come with the vocabulary of “thin,” “silent,” or “all-day battery life.” A computer was a piece of furniture. The boot sound, hard-drive noise, and fan noise all seemed to remind you: this was not something you casually mastered.

That screen was small, and the world looked small too.

Only later did I understand that before the world grows larger, it often arrives on your desk in a heavy and awkward form.

AMD 386DX-40 processor

An AMD Am386DX-40 processor. Image source: Wikimedia Commons.

The characters 386DX40 were not cold numbers on a spec sheet then. They were almost the whole imagination of a machine. 40 MHz meant it was faster than 33 MHz. 4 MB of RAM could decide whether a program ran smoothly. A 210 MB disk meant you might need to delete one tool before installing another. Today we discuss GPUs, memory, SSDs, screens, cooling, and ports. Back then, each number felt closer to a hard boundary.

Boundaries shape people.

When the disk is small, you learn to organize directories. When memory is scarce, you care about footprint. When the machine is slow, you learn patience and become sensitive to the word “efficiency.” Many programming habits formed in different eras were shaped by the first machines people used. Some came from mainframes and minicomputers and learned rigor. Some came from PCs and learned to tinker. Some came from the Web and learned compatibility. Some came from mobile Internet and learned product experience.

My own starting point was probably this: the machine was weak, but I badly wanted it to do more.

Around 1995, I installed Linux on that 386.

The distribution was Slackware Linux. My memory is that the kernel version was still in the 1.x series. The installation medium was not an ISO casually downloaded from the Internet; it was a purchased CD. Installing Linux then was not “Next, next, finish.” It was a small expedition: how to partition the disk, how to boot, whether the graphics card and monitor could work together, whether the network could wait until later, and first of all whether the system could start.

Slackware felt hard and clean. It did not try to make every choice for you the way later desktop distributions would. It placed many things directly in front of you. You needed to know where directories were, where configuration files lived, and what happened during system startup. It was not gentle to beginners, but it forced you to understand the skeleton of a Unix-like system.

Looking back, that matters.

I did not enter the Linux industry until after 2002, but the seed had already been planted in that Slackware CD in 1995. I did not yet know that I would spend years in Linux companies, live through the golden age of domestic Linux distributions in China, or spend a month in an office in Mountain View. I was only sitting in front of a 386, watching an unfamiliar system slowly boot, thinking that a computer could take a completely different shape.

From PDP-11 to 386

In 1992, I entered the Computer Science program at Shanghai Jiao Tong University. The smell of a CS department was very different then. Today many students begin with Python, web apps, mobile apps, AI, and cloud services. Our entrance was harder and slower.

Computer Organization was taught with the PDP-11. For people who encountered computers later, the PDP-11 may only be an old machine in textbooks. In that era, it represented a way of teaching computing: first understand how a machine is organized. Registers, instructions, buses, memory, addressing, control flow, one layer after another.

DEC minicomputers including a PDP-11

DEC minicomputers in a museum, including a PDP-11. Image source: Wikimedia Commons.

The PDP-11 has a strong sense of history. It was not a PC sitting on every desk, and not a cloud instance reduced to a name in a console. It had cabinets, switches, panels, tapes, and the smell of scarce computing resources.

When we studied it, it was no longer a cutting-edge machine. But it was good for understanding computers because it sat closer to the world before abstraction. Instructions were not magic. Function calls were not magic. Memory addresses were certainly not magic. Once the fetch-decode-execute cycle, jumps, state saving, and memory movement enter your head, you will later see high-level languages, operating systems, virtual machines, and containers with an extra layer of background.

After many years of engineering work, I increasingly feel that this training mattered. Not because I wrote assembly every day at work, but because I knew software did not float in the air. Every layer of abstraction has a cost. Every convenience hides complexity somewhere.

The computer graphics course was even more interesting. Professor Yu Yong assigned ray tracing as a course project. Today we can drag a real-time 3D scene in a browser or ask a model to generate an image and see a result in seconds. Back then, after changing code, many teams had to wait overnight for rendering to finish. The next morning you might discover the shadow was wrong, the reflection was wrong, or the sphere edge had artifacts. Then you changed it again and waited again.

That was an old kind of patience.

It taught one thing very naturally: a program is not finished when you finish writing it. It must be judged by the machine. The machine does not explain and does not comfort you. It only gives you a result, slowly.

So when I was doing assembly-level development in 1996, it did not feel strange. Programming was simply closer to hardware and operating systems then, and farther from what we now call “business logic” or “product experience.” You had to know how instructions moved, how memory changed, and how one wrong byte could change everything.

That is where my thirty years in IT began: not with a grand slogan about the Internet changing the world, but with a young person staring at a screen and trying to make a machine move according to his idea.

IBM PC 5150 with CRT monitor

IBM PC 5150. It was not my 386, but the beige case, CRT, and floppy drives are part of the shared visual memory of that era. Image source: Wikimedia Commons.

A Desktop Was an Ecosystem

A computer desk today may only have a laptop, a charger, and an external monitor. A desk in the 1990s was not like that. The host machine, monitor, keyboard, mouse, speakers, floppy disks, CDs, phone line, manuals, driver disks, and installation disks together formed the computer.

“Installing software” did not mean clicking a download button. You started from floppy disks or CDs. You needed to know which disk came first, which came next, where to install it, how to set environment variables, and whether drivers conflicted. If the system broke, reinstalling it was not a matter of a few minutes. If a tool worked reliably, you treasured it.

This is why programmers of that generation often had deep feelings about IDEs, compilers, and editors. A tool was not a service casually registered in a browser. It was something you spent time installing, tuning, and learning. It was not only a set of features; it was a way of working.

Later, for a long time, I felt Delphi was the best IDE. That was not simply nostalgia. Borland tools made many people feel for the first time that programming did not have to be only a fight against command lines, libraries, headers, and linker errors. It could have a smooth UI designer, an event model, and a practical database-development experience. It made Windows desktop application development approachable, which mattered a lot for enterprise software in the late 1990s.

But in 1996, that desktop had not fully moved toward Delphi, and it had not fully moved toward the Web either. It was like a room between seasons: on one side were floppy disks, assembly, DOS/Windows, and CRTs; on the other were browsers, scripts, phone lines, and a network that was about to grow much larger.

In 1996, the Web Was Not Yet Today’s Web

If we only look at the result today, it is easy to treat the Web as something inevitable: HTML, CSS, JavaScript, open a browser, the page renders, interaction happens.

1996 was not like that.

The Web was moving from static pages toward interactive applications, but standards, implementations, and commercial competition were mixed together. Netscape and Microsoft both wanted to control the browser entrance. Page authors were excited and miserable at the same time: the same code could produce different results in different browsers.

In August 1996, Microsoft released Internet Explorer 3.0. It supported CSS, JScript, ActiveX, and other technologies, clearly as a counterattack against Netscape. In the same year, the W3C published CSS Level 1 as a Recommendation. Looking back, CSS1 was modest: fonts, colors, spacing, borders, and simple presentation. But its importance was this: the Web could not permanently depend on browser vendors each doing their own thing.

Standards began trying to pull a chaotic world back to the same table.

But standards on paper and browsers on user machines are separated by a long road. Programmers and web authors in 1996 were often not “writing Web standards.” They were taming browser differences. To make a page work across browsers, you wrote checks, branches, and many tricks that only people of that era still remember.

An imagined early-browser compatibility scene

The same page rendered differently in several early browser windows. This is a period-inspired illustration.

In 1997, I wrote a small JavaScript program that made a butterfly fly around a web page. Today it sounds like a toy, not worth a resume line. But at the time it felt vivid. That butterfly was not flying on a mature, unified, stable platform. It flew through the cracks of the browser war.

You thought you were writing animation. In reality, you were writing compromise.

The butterfly has become a metaphor in my memory.

It was small. It was not complicated. It did not solve any serious problem. But it showed that browsers were no longer satisfied with displaying documents. Pages began to move, respond, and show a little of what applications would later become. When we talk today about frontend engineering, web apps, SPAs, low-code, and online IDEs, we can still find their shadows in those rough little scripts.

History rarely changes direction in a grand scene. Sometimes it is a button changing color, a dialog appearing, or a butterfly flying across a web page a few times.

Between Assembly and Browsers

Looking back at 1996, the most interesting feeling is the split.

On one side was assembly. You faced instructions, registers, memory addresses, and machine state. The world was small, and the boundaries were clear. If the program did not run, you were probably wrong.

On the other side was the Web. You faced browsers, networks, scripts, standards, and vendor competition. The world suddenly became bigger, and boundaries blurred. If the program did not run, it was not always your fault; perhaps the browser understood it differently.

These debugging experiences were very different.

Assembly problems were cruel but direct. A register value was wrong, a jump address was wrong, the stack was damaged, or memory had been overwritten. It was hard, but you knew you were wrestling with the machine.

Web problems felt like wrestling with a crowd: browser vendors, standards bodies, operating systems, networks, user habits, screen sizes, plugins, and security restrictions. Later, frontend engineering would grow build tools, compatibility layers, polyfills, frameworks, and tests. At root, all of them were ways to manage this uncertainty.

The two experiences shaped programmers differently.

Assembly trains a sense of determinism. You believe the machine is strict, the lower layers are explainable, and a problem can be traced downward. The Web trains comfort with uncertainty. You begin to accept environmental differences, version differences, network differences, and user differences. You are no longer writing only a “program”; you are writing something that runs inside a pile of real-world conditions.

1996 was that fork.

I was still working close to the lower layers. But another direction had already appeared. Browsers pulled users, pages, networks, scripts, and commercial companies into the same field. Software was no longer only something installed on a machine. It was becoming an entrance, a service, and a way of connecting people.

I did not know then that this path would lead to portals, search, IM, e-commerce, social networks, mobile Internet, cloud computing, and today’s AI agents.

If I had known, I probably would not have believed it.

Tools Had Their Own Personalities

Tools around 1996 had a strong physical presence.

Floppy disks failed. CD-ROM drives were picky. Hard-drive space had to be calculated carefully. A 210 MB disk sounds like a joke today, but it could hold quite a lot then: an operating system, a compiler, documentation, a few games, and some work space.

A close-up of a 3.5-inch floppy disk

A 3.5-inch floppy disk. Image source: Wikimedia Commons.

A floppy disk today looks like the origin of the save icon, but back then it was real removable storage. A 1.44 MB floppy had pitiful capacity, yet it carried assignments, source code, drivers, tools, and small programs for many people. You wrote on the label. You worried about bad sectors. You could waste a trip by forgetting one disk.

The capacity limit was concrete. A source directory, a few object files, and one small tool could force you to decide what must be kept and what could be deleted. Today, when we talk about technical debt, dependency bloat, and image size, we are still facing the same problem at a different scale: resources look larger, but software can always fill them again.

Software today is too easy to download, upgrade, and reinstall. It was not like that then. A development tool, a CD, and a thick book might stay on your desk for a long time. You repeatedly opened it, read it, and learned its temperament.

That relationship later became clearer with Delphi. Delphi mattered more to me after 1998, but it represented a peak of great developer tools in that era: open the IDE, drag controls, write event handlers, connect to a database, and compile a proper Windows program. Borland deserves a separate essay. It gave many programmers the powerful illusion that software development could be that smooth.

But in 1996, I had not yet reached that point. One foot was still in assembly, hardware, and course training; the other was only beginning to move toward the Web, enterprise software, and more complex commercial systems.

Looking Back at 1996 After Thirty Years

1996 is not the flashiest year in IT history.

It was not 2007 with the iPhone, not 2012 with AlexNet, not 2022 with ChatGPT. It was more of a transition: the old world was still solid, and the new world had begun to appear.

But for me, that year matters.

It placed me between two kinds of programmers. One believed in machines, determinism, and the fact that code ultimately lands on instructions and memory. The other began to believe in networks, entrances, standards, ecosystems, and software running in environments you could not control.

Those two programmers have been arguing inside me ever since.

When I write C/C++, debug Redis, work on graph databases, or write Rust, the first one comes out. When I build web systems, big-data platforms, mobile APIs, or AI toolchains, the second one appears. Today, when I use Codex and Claude Code to write software, a third kind of programmer has appeared: one who not only writes code but learns to collaborate with tools that can write code.

But wherever I go, I have not forgotten that 386 and that 14-inch CRT.

The screen was small. The world had just begun to grow.

In the next essay, I want to write about 1997. That year, I used JavaScript to write a butterfly that could fly. It flew roughly, of course, but it flew through an era of browser-standard chaos, when every vendor wanted to define the future. Thinking about it now, that butterfly looked a lot like the Web itself.

1996 IT Milestones

  • Java 1.0 was released. Sun officially released Java 1.0 in 1996. The later slogan “Write Once, Run Anywhere” was extremely tempting in that context: PCs, servers, browsers, and operating systems were all changing quickly, and developers wanted a language that could cross platform differences. Java would later deeply affect enterprise software, Internet backends, the Android ecosystem, and many MIS, banking, and enterprise systems after 1998.
  • CSS1 became a W3C Recommendation. In December 1996, CSS Level 1 became a W3C Recommendation. It looked like a modest presentation layer for fonts, colors, margins, and borders, but the implication was large: the Web could not forever rely on HTML tags for layout, nor could it let browser vendors each define presentation in their own way. The split between HTML for structure and CSS for presentation became clearer from here.
  • Internet Explorer 3.0 was released. IE3 supported CSS, JScript, ActiveX, and other capabilities, and Microsoft began to push hard in the browser battlefield. For web authors, this was not merely a software release. It was the beginning of the compatibility era: you had to face both Netscape and IE, and two companies’ different visions of the Web.
  • Windows NT 4.0 was released. Windows NT 4.0 brought a Windows 95-like interface to the NT line while continuing to target servers and workstations. Many enterprise systems, development environments, and server applications would grow under the influence of the Windows NT family.
  • USB 1.0 was published. USB was not yet an everyday desktop interface for everyone, but it represented a long-term shift in how PC peripherals would be connected. Keyboards, mice, printers, USB drives, external disks, development boards, and debugging devices would later be reorganized around this interface.
  • Hotmail and ICQ appeared. Hotmail launched in 1996, and ICQ also appeared that year. The former helped many people realize that email could be a web service. The latter brought presence and instant messaging to a broad audience. Both were early signals that Internet services would move from “reading web pages” toward “living online.”
  • BackRub began to appear. Larry Page and Sergey Brin’s Stanford search project BackRub appeared around this period. It was not yet Google, but it already treated links between pages as calculable signals. A few years later, search engines would become one of the most important entrances to the Internet.

References

More in this column

View all posts in "Thirty Years in IT and Me"