So picture this. You are sitting in a coffee
shop right now, totally untethered, just streaming
video or working on your laptop. Yeah, completely
relying on those bleeding edge lithium ion batteries.
Exactly. And you have this incredible freedom
to just compute anywhere. It feels completely
normal to us now. Right, you probably don't even
think about it until, you know, that little battery
icon turns red. Oh, I panic when it turns red.
But the real reason your laptop hasn't died yet,
it actually comes down to a completely forgotten
microscopic software trick from way back in 1989.
It really is one of the more obscure yet, I mean,
highly consequential hidden histories in modern
computing. Totally. And for our deep deck today,
we are pulling from a single source, a really
comprehensive Wikipedia article detailing a technology
called Battery Max. Yeah, Battery Max, such a
great 90s name. Oh, the best. So our mission
today for you, the listener, is to uncover the
wild trajectory of this specific piece of software.
We are going to look at how it fundamentally
changed the math on battery life. And how it
somehow became a total commercial failure. despite
being, you know, objectively superior technology
at the time. Right, and then decades later how
it miraculously resurrected from the archives
to basically save the world's biggest tech giants
in a massive high -stakes lawsuit. It is quite
the journey. It really is. OK, let's unpack this.
Because to understand the elegance of battery
Macs, we really need to understand the architectural
nightmare of early portable computers in the
late 1980s. Oh, it was a nightmare. The landscape
back then was incredibly primitive regarding
power management. You have to remember, engineers
were just starting to figure out how to untether
these machines. Right. Laptops were basically
like carrying around a cinder block. Exactly.
The earliest laptops used these heavy, really
inefficient batteries. And the way they tried
to conserve that precious power relied entirely
on hardware. Specifically, they used hardware
inactivity timers. Which, I mean, it sounds sophisticated,
but in practice, it was a totally blunt instrument.
Oh, completely blunt. The motherboard's hardware
would basically just sit there and monitor physical
inputs. Like waiting for you to hit a key. Yeah,
it would check if you were typing on the keyboard.
Or it would check if the hard drive platters
were physically spinning or like the serial ports,
right? If the serial ports were transmitting
data if it didn't detect any of those physical
mechanical actions for a set period Usually several
minutes it would finally assume the computer
was idle and then it would trigger the switch
to a lower power consumption state Exactly. It's
basically like leaving the lights on in a massive
empty warehouse for five full minutes just in
case someone decides to walk back in. That is
a great analogy. And you're doing this in a building
that runs on a very finite, very quickly draining
generator. I mean, it is a massive waste of energy.
It really was. The computer is just sitting there,
burning power, staring at a blinking DOS prompt,
waiting for those minutes to tick by before it
finally decides to turn the lights off. What's
fascinating here is why the hardware was forced
to operate that way. The motherboard was fundamentally
blind to what the software was actually doing.
Blind how? Like they couldn't talk to each other.
Basically, yeah. The hardware only understands
electrical signals and physical inputs. It has
zero conceptual awareness of the operating system's
tasks. Oh, I see. It doesn't know if the software
is intensely calculating a massive spreadsheet
in the background or if it is literally doing
nothing but waiting for you to press the space
bar. So the hardware is basically wearing a blindfold.
It has to wait those several minutes just to
be absolutely certain you are actually gone.
Exactly. Because if the hardware timers were
set too aggressively, say shutting down after
10 seconds of no typing, they ran the risk of
interrupting actual work. Oh, right. Because
you might not be typing, but the computer is
thinking. Yes. Imagine you initiate a complex
database sort that takes 20 seconds to process.
You aren't typing, so the hardware thinks you
left. It just powers down the CPU right in the
middle of the calculation. Right. That would
be disastrous. So the engineers had to be super
conservative. They left the timers at five or
10 minutes, accepting the mass of power drain
as a necessary evil to prevent system crashes.
Well, the only way to solve a hardware blind
spot is to put the intelligence into the software,
right? Because the operating system actually
knows what the programs are doing. Exactly. which
leads us directly to August 1989 and a company
called Digital Research. Okay, so who are these
guys? Specifically, we are talking about their
European Development Center in Hungerford in
the UK. This is where two British engineers,
Roger Alan Gross and John P. Constant conceptualized
battery mags. And this got integrated into Docker
DOS 5 .0, right? Around 1990? Yep, it was incorporated
in 1990. And this made it the very first personal
computer operating system to feature a native
software -driven idle detection system for power
management. The performance jump here is what
really stands out in the source material for
me. We just established that hardware timers
took several minutes to figure out if you were
idle. Right. Agonizingly slow. But battery max
reduced that idle detection time down to microseconds.
I mean, it could detect that you weren't actively
typing, switch the computer into a low power
state, and then wake it back up entirely seamlessly.
and it could do this roughly 18 times a second.
18 times a second, that is mind -blowing. The
technique was officially named dynamic idle detection.
Basically, the operating system halts the CPU
for periods of just a few microseconds, pausing
the power drain. And then a hardware event wakes
it up. Yeah, like a keyboard interrupt occurs
to immediately wake it back up so you don't even
notice. So it's basically taking microscopic
power naps. Between every single letter you type,
the computer is going to sleep and waking back
up. It's napping between the H and the E and
hello. That's exactly what's happening. Well,
logically, I mean, there has to be a hurdle here.
If the software is shifting power states instantly,
how does it differentiate between a program that
is merely waiting for a user input and a program
that is actively executing a background task?
That is the big question. Because going to sleep
while saving a file to the disk is just as disastrous
as the hardware timer problem we just discussed.
Right. And that is the core engineering challenge
they had to solve. And it basically comes down
to a layered model of detection software encapsulated
into a DOS device driver. The IDLE driver? Yes.
They call this driver IDLE. Spelled with dollar
signs on both ends, which is deeply characteristic
of 90s computing nomenclature. Oh, absolutely.
So, 90s. This IDLE driver contained the hardware
-dependent code acting as an intermediary. OK.
The core operating system, the Dodor DOS kernel,
was programmed to constantly monitor API calls.
An API call is simply a request that a software
application makes to the operating system to
access hardware resources. Right, like a program
asking the computer to do something physical.
Exactly. By monitoring these requests, the kernel
builds a real -time behavioral profile of the
application. So the driver acts kind of like
a bouncer at a club, checking every single request
the software makes to the hardware. I like that.
It's looking for a specific pattern of request
that gives away the fact that the software is
doing absolutely nothing. And the specific pattern
they were looking for is called a tight loop.
In the DOS era, if a program needed you to press
a key, It wouldn't just sit patiently. It would
constantly ask the operating system, over and
over, is there a key pressed? Is there a key
pressed? Oh, just relentlessly bothering the
OS. Relentlessly. It would pull the keyboard
buffer. Certain combinations of these API calls
strongly signaled to the kernel that the application
was stuck in one of these pulling loops. Wait,
both an idle program and a busy program might
check the keyboard, right? I mean, a busy program
calculating math might still occasionally check
the keyboard just to see if the user pressed
escape to cancel the calculation. That's a very
good point. So how does the bouncer tell the
difference between the two? This is where the
genius comes in. The driver functions as a highly
precise stopwatch. It monitors the time elapsed
between those keyboard polling requests. OK,
so it's timing the request. Yeah. It relies on
a dynamic local variable called idlyCNDTDN idleCountdown.
This variable sets a very specific minuscule
time limit. A microsecond limit. Exactly. If
the software circles back to ask is a key pressed
within that tiny time limit, the driver concludes
the program hasn't had time to do anything else.
Because it asked too fast. Right. It hasn't processed
any math, hasn't written to the screen, it is
genuinely stuck in an idle tight loop, and when
it sees that, It confidently halts the CPU and
saves power. Wow. And if it takes longer than
that microsecond limit to ask again? Then the
driver deduces that some actual processing must
have occurred between the keyboard checks. The
program is busy doing real work. So it lets it
run. Yes. In that scenario, the IDEA lead driver
immediately overrides the power down sequence,
passes the authorization back up the chain, and
allows the application to continue running at
full power. And it does all this math 18 times
a second. It performs this dynamic calculation,
checking the interval. deciding to halt or override
18 times a second. It's an incredibly elegant
workaround to a severe hardware limitation. I
mean, they completely bypass the hardware's blindfold
by putting a hyper -vigilant stopwatch directly
inside the operating system kernel. It was revolutionary.
But you'd think an architectural shift, this
revolutionary, something that fundamentally alters
the viability of portable computing, would make
digital research the undisputed king of the 1990s
laptop boom. You would think so. So why is battery
max an obscure footnote? Well, the origins of
the technology provide some crucial context for
its eventual commercial failure, because initially,
this idle detection mechanism wasn't engineered
to save battery life at all. Really? From the
source material, it looks like battery max was
actually a byproduct of trying to fix a completely
different problem involving selfish software.
Exactly. It was originally developed for an operating
system called Concurrent DOS 386. OK, what was
that? This was a multitasking multi -user system,
meaning it was designed to run several programs
at once. But the problem was that most software
at the time was written for single -tasking operating
systems, like standard MS -DOS. And those single
-tasking programs were inherently greedy. Oh,
incredibly greedy. In a single -tasking environment,
a program assumed it owned the entire computer.
It didn't need to share the processor with anything
else. Exactly. When those single -tasking programs
needed a user input, they would enter those relentless
polling loops we just discussed, consuming 100
% of the CPU's processing cycles. simply waiting
for a keystroke. Which is fine if it's the only
program running. Right. But in a multitasking
environment, that greedy behavior brings the
whole system to a crawl. If one program is monopolizing
the processor just to wait for a key, the operating
system can't allocate CPU time to other programs
that actually have work to do. Ah, so the bouncer
wasn't originally checking IDs to turn off the
lights. It was checking IDs to kick the greedy
programs off the dance floor. That is a great
way to put it. Digital research deployed idle
detection to forcefully suspend those greedy
programs when they were caught in a bowling loop.
This freed up the processors so the operating
system could schedule other concurrent processes.
And the battery saving was just an accident?
Pretty much. It was only later that they realized
halting the CPU to manage software could also
physically stop the CPU from drawing electrical
current, thereby saving massive amounts of battery
on these new laptop devices. So what does this
all mean? I mean, digital research invents this
brilliant architectural rookery to manage software.
They realize its profound application for battery
life. They package it into Docardos 5 .0 in 1990.
And they later deploy it in novels Palmdose 1
.0 in 1992 for early palm tops. Right. They even
secure the intellectual property, filing a patent
in March 1990, which is granted in 1994. They
checked every box for a major tech breakthrough.
Why did it fade away? It succumbed to a classic
convergence of corporate instability and industry
standardization. As it always goes. Yeah. In
1991, digital research was acquired and integrated
into Novell, Inc. The aftermath of that acquisition
was highly disruptive. Oh, mergers are always
a mess. Totally. Internal focus fractured, projects
were reorganized or sidelined, and momentum just
stalled. And in the tech industry, a stalled
momentum of even 12 months can be fatal. Because
someone else is always building something. Exactly.
By 1992, Microsoft and Intel jointly launched
APM, or Advanced Power Management. The two undisputed
heavyweights of the PC era moving in on the exact
same territory. Yeah. But APM took a different
approach. It wasn't just a driver tied to one
specific operating system, like DaggerDOS. It
was an industry -wide standard interface that
connected the hardware BIOS directly to the operating
system. So a totally different architecture.
Right. It allowed the OS to communicate power
management requests to the motherboard in a standardized
language. Which means every hardware manufacturer
in the world could adopt it, and it would work
seamlessly with Microsoft's dominating MS -DOS
and Windows environments. If we connect this
to the bigger picture, it illustrates a brutal
reality of the technology sector. Having a technically
superior patented methodology does not guarantee
market survival. It rarely does. Digital research
had the OS level intelligence figured out first.
But while they were navigating a chaotic corporate
merger, Microsoft and Intel created a unified
hardware ecosystem. Network effect. Exactly.
Industry standards routinely kill superior proprietary
tech because manufacturers will always choose
the path of least resistance and broadest compatibility.
Battery Max was essentially buried by the sheer
gravitational pull of the Microsoft and Intel
standard. It basically became a dead end. A brilliant
piece of code relegated to the archives while
APM went on to define portable computing for
a decade. It was gone. Until it wasn't dead.
Because nearly 20 years later, the very companies
that rendered Battery Max obsolete suddenly found
themselves in desperate need of it. They really
did. The catalyst was a massive 2009 patent troll
lawsuit. Here's where it gets really interesting.
In 2009, an entity called St. Clair Intellectual
Property Consultants launched a sweeping legal
offensive. Sweeping is an understatement. Right.
They filed civil actions against a massive roster
of hardware manufacturers. We're talking about
Iser, Dell, Gateway, Lenovo, Apple and Toshiba,
the entire foundation of the laptop industry.
St. Clair's legal strategy was extremely aggressive.
They operated as a non -practicing entity, what
is colloquially known as a patent troll. So they
don't make anything, they just sue. Exactly.
They had acquired a portfolio of U .S. patents
originally filed by an inventor named Henry Fung.
These patents broadly cover the concept of software
power management under operating system control.
Okay, so the core idea we've been talking about.
Right. Sinclair asserted that Fung was the definitive
pioneer of OS -level power management. And therefore,
every modern laptop utilizing these techniques
was actively infringing on their intellectual
property. And they were demanding retroactive
royalties, which if you extrapolate a royalty
fee across the sheer volume of laptops sold by
Dell, Apple and Toshiba over years of production,
you are looking at an existential financial threat
to the entire hardware ecosystem. Billions of
dollars. It escalated to the point where Microsoft
and Intel, the architects of the APM standard
that every manufacturer was relying on, legally
intervened. They had to step into the courtroom
to defend the hardware makers. Because if St.
Clair prevailed, the entire A higher standardized
ecosystem that Microsoft and Intel had cultivated
would be permanently taxed by a third -party
holding company. They couldn't let that happen.
No way. The defense required a silver bullet.
So the legal team representing the hardware manufacturers,
a Seattle -based firm named Perkins Coy, went
on the offensive. Their mandate was to locate
prior art. Perkins Coy was on a desperate hunt
for prior art. For you listening, that means
any documented publicly available proof that
OS -level power management had been successfully
invented and deployed before Henry Fung filed
his patents. Right, because if they could demonstrate
the concept was already known to the industry,
Fung's patents would be invalidated. And St.
Clair's entire multi -billion dollar case would
just evaporate. Exactly. So the lawyers had to
dig deep into the architectural history of 90s
computing. They were scanning through old operating
system manuals, forgotten technical journals,
and archived patent filings. Just looking for
a needle in a haystack. And in that search, they
unearthed the remnants of battery max. Specifically,
they found U .S. patent 5 ,345 ,392 for an idle
detection system, filed by Roger Alan Gross and
John P. Constant. The British engineers from
Digital Research's Hungerford lab, the bouncer
and the stopwatch. Yes. Crucially, the priority
date on the gross patent predated Fung's patents.
So in February 2011, Intel took a remarkable
step. This is my favorite part. The very company
that had partnered with Microsoft to push APM
and Sideline Battery Max in 1992 now hired Roger
Alan Gross as a subject matter expert witness
to testify on their behalf. That is just incredible.
Gross submitted a detailed expert report asserting
that he and Constant had pioneered software power
management under OS control, utilizing Battery
Max and his 1994 patent as incontrovertible proof.
Man, St. Clair's legal team must have seen the
writing on the wall. Oh, they panicked. They
reacted with immediate hostility. Sinclair filed
formal motions to exclude Gross's opinions and
dismiss his expert report entirely. Because he
was the silver bullet. Exactly. They understood
that if the court admitted battery max into evidence
of legitimate prior art, the foundation of their
infringement claims would be completely destroyed.
The court, however, saw through the procedural
maneuvers. In March 2013, the district court
delivered a decisive ruling against St. Clair.
They declared Gross's testimony fully admissible.
A huge win. Yeah, the judge specifically noted
that the defense had provided sufficient corroborating
evidence proving battery max was available to
the public prior to the priority date of the
Fung patents. And the ruling went even further.
The court noted that even if the exact timeline
of public availability was contested, Gross's
testimony was highly relevant to demonstrate
that OS -level power management was obvious to
persons having ordinary skill in the art at that
time. Obvious is a legal term, right? Yes. In
patent law, proving a concept was obvious is
a primary mechanism for invalidation. So BatteryMax,
the technology that was abandoned due to corporate
restructuring, became the definitive legal shield
that protected the modern computing industry.
The historical irony is staggering. Intel and
Microsoft created the unified standard that drove
BatteryMax into the ground. They functionally
killed the product. They really did. But two
decades later, facing potentially ruinous royalty
litigation, those same giants had to excavate
the archives, dust off the code they defeated,
and present it to a federal judge to save their
own. ecosystem, they survived because of battery
max. It highlights a fascinating reality about
technological progress. The timeline of innovation
is rarely a straight line of continuous improvement.
No, it's messy. Very messy. It's heavily influenced
by corporate strategy, legal battles, and shifting
industry standards. So let's synthesize this
journey. We started with an intricate software
mechanism originally designed to referee greedy,
single -tasking DOS programs that refuse to share
the processor. Right, the bouncer. That mechanism
evolved into a microsecond stopwatch, a power
-saving breakthrough that fundamentally enabled
the modern laptop. Then it became a casualty
of the brutal 90s tech wars swallowed by the
novel merger and steamrolled by the Microsoft
Intel APM standard. A forgotten relic. And finally,
it emerges from obscurity as the ultimate trump
card in a high stakes legal showdown. This raises
an important question, and it's something I'd
love for you to consider long after we wrap up
today. Think about the sheer volume of brilliant,
fully patented innovations currently sitting
in the failed bin of corporate history. Oh, there
must be thousands. Easily. We are conditioned
to view failed technology as useless ideas that
simply weren't robust enough to survive the free
market. But how many other forgotten lines of
code, born from bankruptcies and abandoned projects,
are sitting in the dark right now? just waiting,
waiting for the right moment or the right billion
dollar lawsuit to suddenly become the most critical
piece of prior art in the world. It completely
reframes how you look at the tech graveyard.
So the next time you are sitting in a coffee
shop untethered from the wall, watching your
battery hold steady while you work, just remember,
remember that you aren't just relying on modern
chemistry and hardware efficiency. You're coasting
on the invisible microsecond legacy of an obscure
1989 software patch that refused to stay. dead.
Thanks for joining us on this deep dive. We'll
see you next time.