sam henri goldhey wanna see something kinda interesting? this was the entire fix to the iPhone Antennagate in 2010. 20 bytes.
(this is going to be a very long thread 🧵)
For context, back in 2010 when the iPhone 4 came out, people noticed you could grip the phone in a certain way and the signal bars would plummet from 5 to, like, 2.
A few weeks later, they published a letter (https://www.apple.com/newsroom/2010/07/02Letter-from-Apple-Regarding-iPhone-4/) admitting fault, blaming a bad formula.
The letter was shared around and clowned upon (https://daringfireball.net/2010/07/translation_iphone_4) but nobody really looked into what the formula between 4.0 and the patch in 4.0.1
I was a stupid eight-year-old at the time, but now I’m a stupid adult with access to a disassembler.
I downloaded both firmwares and started poking around. In the CoreTelephony framework, I found a promising looking binary: CommCenter. Looking at the strings gave me a pretty good sense that this is where the bar formula was.
The actual calculation is dead simple. When converting signal strength to bars, CommCenter loads each threshold from memory and compares until it finds the right range.
This code is not the problem...
...this is. This is the lookup table. When you convert the bytes to actual dBm values, you get:
-115, -111, -107, -103, and -99
(the closer to zero, the better the signal)
For example, here you need -107 or better signal to see 3 bars.
When you plot this onto a chart, you can see how the values are kinda screwed up since the values are really optimistic. Most of the time, you would see 4-5 bars. But when you gripped it, since the falloff is so sharp, you’d see a catastrophic drop from 5 to 2 bars.
In 4.0.1, they changed these values to be way smoother. Mapped onto a chart, you can see that it takes a lot to drop from 5 to 0 bars. It’s harder to see 5 bars, but it’s harder to plummet bars.
So there ya go. 20 bytes.
This has concluded a Tech Thread. Back to shitposting.
oh also in 4.0.1 they changed the height of the lower bars to be taller lmao
Jim Luther@samhenrigold I’m reminded again of a change I made in Mac OS 8.1 for HFS Plus.
I had to change the Start Manager code that loaded extensions so extensions would continue to load in MacRoman order. To keep Conflict Catcher working, I had to add new API it could use to control the order of extension loading.
Another engineer at Apple (IIRC, Mike Pucket) saw the new Start Manager API and changed the boot progress bar code to use the new API to make the progress bar’s updates smoother and more accurate, and that made Mac OS “seem” to boot much faster.
It’s funny how small UI changes can fool the mind.
Chris Gervais 🎸🥁💻@jimluther @samhenrigold Since I've been spending time in System 7 again (because, let's find any mechanism to distract my from the outside world) and have to reboot a lot (hey, memory management is hard) it's funny how I use the extensions loading as the progress bar and it took me a beat to realize that I missed the progress bar in the startup window.
europlus 
@jimluther @samhenrigold there are studies about the perception of progress based on how the progress bar, well, progresses.
Fascinating!
@jimluther @samhenrigold gah, autocorrupt did me in - although it works with printers, too, but the studies are more general than that.