When I was at Amazon my manager told me that several years earlier he was responsible for updating the 404 page so he scanned a picture of a cat his daughter drew and made that the body of the page. In 2009 when I started, that was still the image, but at some point someone must have noticed and replaced it with a stock photo of a dog. The asset was still called kayli-kitty.jpg, though. It’s since been changed again to rotating pictures and references to the original are gone.
I also found this comment from him on a blog: https://www.davebellous.com/2006/09/25/what-the/#comment-290...
Playfulness isn't the only thing we've lost. Software bloat has reached comedic levels.
void outchar (char c) {
c = c | 0x80;
asm volatile ("jsr $fbfd\n" : : "a" (c): "a");
}
void outstr (char* str) {
while (*str != 0)
outchar(*str++);
}
void main () {
outstr("Hello, world!\n");
}
lda #$c8 ; ASCII H | 0x80
jsr $fbfd
lda #$e5 ; ASCII e | 0x80
jsr $fbfd
...
For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?
I couldn't find this elusive picture of a cat on archive.org, but I found this dog instead:
https://web.archive.org/web/20030113144310/https://www.amazo...
June 2016 appears to be when Amazon adopted the current error pages with the large dog images.
https://web.archive.org/web/20160612232820/http://www.amazon...
http://telcontar.net/Screenshots/worldwidewonk/Amazon-404-eh...
mastry found a screenshot of the image in his sibling reply.
0 - http://g-ecx.images-amazon.com/images/G/01/x-locale/common/k...
1 - https://web.archive.org/web/20071030172825/http://www.amazon...
Another anecdote: somewhere in that time period we (Prime) were using comments for various metadata and pre-release and post-deployment checks would verify the comments were in place. The team responsible for the edge proxies decided they were going to rewrite all the HTML going out on the fly to remove extraneous comments and whitespace in an effort to reduce page-size.
In the middle of testing a release all of the tests related to a particular feature started failing and (I believe) different devs were getting different HTML on their systems (the feature wasn't rolled out to every session). Our QA team was extremely pedantic in the best way possible and wouldn't allow the release to continue until testing could complete, so we had to track down the responsible parties and get them to dial down their transformation. They eventually tried again without stripping comments, but I can't imagine much was saved after compression without much of anything removed (they might have been rewriting other tags as well).
Serious question: Is this possible when a guardian gave consent earlier?
AFAICT, kids own the copyright to things they create[0], but guardians are responsible and can use it on the child’s interest. IANAL, consult an attorney, etc., etc.
0 - https://www.copyright.gov/help/faq/faq-who.html#:~:text=Can%....
it's still right here every day when Firefox says "gah this tab crashed".
Ah, the old times when one could purchase a RAM upgrade or upgrade RAM after buying a computer. Now this would be:
"Symbol table full - fatal heap error; please go buy a new Mac with more RAM"
Regarding "everything had to fit in RAM": prior to real virtual memory, the Macintosh Resource Manager was capable of loading and unloading resources on the fly. Resources marked purgeable could be discarded when memory was needed. Code segments (another type of resource) could be loaded by automatically by the Segment Manager, but as you said would not unload until the application requested it or exited. INITs (system extensions) unloaded all code after initialisation by default (requiring extra steps to keep anything in RAM).
Virtual memory was built-in by System 7 (and I think available on supported hardware via 3rd party utilities earlier?).
"a typedef name was a complete surprise to me at this point in your program"
"No! But they'll only let me warn you. Danger Will Robinson! Danger!"
"Really! If you are fussing around with void *, just go home or at least back to your editor!"
Dereferencing a void pointer has no meaning. The compiler can do anything it wants because it doesn't know how to interpret the memory. It could give you the correct thing, it could warp a civilization in from a distant planet, or it could open a world-ending black hole. All are equally probable.
...also remember 45 minute builds when a header file changed.
I remember these error messages coming up and laughing out loud when I saw the rare ones. Nice work, whoever did it!
The MPW C compiler code generation was so predictable in part because of the symmetry of the 68k instruction set. They wrote a simple compiler and it worked. For the most part effort was spent elsewhere. Since you could reasonably predict what code would be generated if you were unhappy with the code generation you fixed the source. I like that the javac compiler has a similar ethos, With similar effect. Once you know the patterns to use you can generate fairly close to optimal byte code.
That, Sir, is none of your business.
Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.
It's super-useful to temporarily comment out a bit of code, and then to comment out a larger block surrounding it. Especially when debugging.
Sadly I've never used a language that supported that.
e.g. '/*' and '*/' would match each other, '/**' and '**/' would match, and so on.
That way, you would have full control of the depth of the comments, removing other comments wouldn't break the inner comments, etc.
I do run into the same issue you're describing, so I think there's value in the idea.
I've seen this list so many times and this one makes me laugh out loud every single time.
To inline my comment in the previous thread:
Just for some context, the MPW C compiler that produced those messages was actually not developed internally at Apple, but was rather done by Green Hills Software [1] under contract as mentioned on the wikipedia page [2] and its source [3] which is funnily enough about this exact same topic.
[1] https://en.m.wikipedia.org/wiki/Green_Hills_Software
[2] https://en.m.wikipedia.org/wiki/Macintosh_Programmer%27s_Wor...
[3] https://web.archive.org/web/20140528005901/http://lists.appl...
(dBase code looks like https://github.com/harbour/core/blob/master/tests/ntx.prg , and https://github.com/harbour/core/blob/master/include/std.ch is an open-source reimplementation of Clipper's preprocessor definitions).
also, the note on the copyright is hilarious.
Did it seriously not let you have a goto label inside a switch?! This seems like an odd restriction, as all 3 are the same kind of thing.
Been able to have a worksheet with random shell commands I’d built up, triple-clicking a line and hitting enter to run the selection.
It was quite a thing.
As in megabytes.
Nearly all of clang and LLVM are linked as libraries.
Including EDIED and EIEIO
What I'm not sure of is whether there's an edge case I haven't thought of which would make this problematic.
But you can't do a trade-in, the RAM they sell is extremely overpriced, and as mentioned elsewhere there's no excuse for the SSD.
Due to lack of protected memory, a few programs, especially on the earliest machines, with the least memory, 'abused' the display buffer by using it as RAM. Of course, this corrupted the screen, but it would all just be drawn again as soon as the program yielded time to the OS. Back then, only one user program could be running at a time, and it mostly had the screen to itself, so why not use it to copy floppies with less disc swapping?
(Yes, the Intel Mac had memory compression as well. And my Windows 11 PC also has memory compression, but only if you also enable swap because Microsoft says "fuck you".)
IIRC Windows doesn't like to overcommit memory and its allocation calls will actually fail instead, but I don't remember the details.
> IIRC Windows doesn't like to overcommit memory and its allocation calls will actually fail instead
Yeah... one of the reasons why I dislike it.
Isn’t this actually good practice on the 6502? The processor treats the first page of memory (called the zero page) differently. Instructions that address the zero page are shorter because they leave out the most significant byte. Addressing any other page requires that extra byte for the MSB.
Furthermore, instructions which accept a zero page address typically complete one cycle faster than absolute addressed instructions, and typically only one cycle slower than immediate addressed instructions.
So if you can keep as much of your memory accesses within the zero page as possible, your code will run a lot faster. It would seem to me that treating the zero page as a table of virtual registers is a great way to do that because you can bring all your register colouring machinery to bear on the problem.
"An overview of the PL.8 compiler", circa 1976
jmp $fbfd
?Nitpick 2: why ldx #0 txa rts? I would think lda #0 rts is shorter and faster
Back to my question: if it can’t, the claim “an assembler programmer couldn't do better” isn’t correct.
I think an assembler programmer for the 6502 would consider doing a jmp at the end, even if it makes the function return an incorrect, possibly even unpredictable value. If that value isn’t used, why spend time setting it?
A assembly programmer also would:
- check whether the routine at 0xFBFD accidentally guarantees to set A to zero, or returns with the X or Y register set to zero, and shamelessly exploit that.
- check whether the code at 0xFBFD preserves the value of the accumulator (unlikely, I would guess, but if it does, the two consecutive ‘l’s need only one LDA#)
- consider replacing the code to output the space inside “hello world” by a call to FBF4 (move cursor right). That has the same effect if there already is a space there when the code is called.
- call 0xFBF0 to output a printable character, not 0xFBFD (reading https://6502disassembly.com/a2-rom/APPLE2.ROM.html, I notice that is faster for letters and punctuation)
On a 6502, that’s how you get your code fit into memory and make it faster. To write good code for a 6502, you can’t be concerned about calling conventions or having individually testable functions.
People have aesthetic complaints about "bloat", but again this is orthogonal to the actual speed of anything.
Bloat making software bigger will in many cases also make it slower.
Also, the UX on Windows 95 was consistent and easy to learn. Now, much software fail on stuff like disabling a button when you have clicked it and the computer is working.
MacOS is on a steady curve to the bottom. It is not alone.
The software bloat and decreasing quality is a serious issue.
Latency when the system is under low load was definitely better, although a big contributor to that is changes in input and display hardware. But otherwise I'd much rather have today's "bloated" experience over the real world of the '90s.
In the case of Apple, it's often Apple software eating up the benefits of Apple hardware.
Unfortunately subtle differences (such as improved reliability/security or a streamlined workflow) are lost in the computing market, where people are attracted to the new and shiny rather than the old and usable. Also designers like to mess with things.
And yet Electron apps often garnish that memory bloat and computational inefficiency with sluggish performance and a clunky user experience.
It's a shame when an 8GB Mac mini doesn't have enough RAM to run apps comfortably. Of course there's a bit of a corrupt bargain going on between bloated software and Apple since the latter wants to upsell you to a more expensive model.
I wouldn't consider an iPad Mini 1st generation to be very retro, but I still need to run a MITM proxy for it to be able to browse Wikipedia(!).
Monthly bills are stopping me. Can I use Apple's MPW C compiler to build for iOS?
You need to search for it on old ftp sites.
> For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?
The compilers have "evolved". Compiling old code is challenging, to say the least. I do compile old programs when the new seem to explode: xpdf, xsnow.
Compiling old compilers is impossible because they rely on ancient kernel headers.
I'm not a Mac fanboy by any means. But SSD write endurance has become ridiculous. Even on a cheap-ish read-intensive server-class 1 TB NVMe SSD (~$300) you get around 1 petabyte total write endurance, meaning you can write essentially the entire contents of the disk every day for 5 years and still be within the warranty. That is orders of magnitude beyond what any consumer is going to subject their disk to.
There is always a possibility that a part of the computer will fail. But if the SSD is less likely to fail than any other random IC on the motherboard, having it soldered on doesn't factor significantly into the failure statistics.
Of course it's super annoying that you can't upgrade the disk size, but that's another point.
Since I bought an M2 Pro to replace it, it hasn’t had the issue I think because I’m just leaving it at home and not flexing or squeezing it much. Perhaps the issue could be fixed permanently and properly with a bit of hot air to re-flow the solder balls.
This is by no means certain, certainly not enough to SHOUT about.
Modern SSDs have lifetimes that make them impractical to literally wear out, short of some kind of fault.
macOS icons also used to have distinct silhouettes which made them easier to distinguish, but now everything is a square tile. Screen controls which used to be visible and targetable are now hidden and are harder to hit when they do appear.
It feels like we are still under the tyranny of the (Jony Ivian?) streamlined aesthetic over usability and functionality, as if a library decided to organize books by size and color.
If you take software from 20 years ago, and run it on modern hardware, it will be instant in most operations.
Regarding this specific unrolled loop, I would expect a 6502 programmer would just write the obvious loop, because they're clearly optimizing for space rather than speed when calling the ROM routine. They'll be content with the string printing taking about as long as it takes, which clearly isn't too long, as they wouldn't have done it that way otherwise. And the loop "overhead" won't be meaningful. (Looks like it'll be something like 7 cycles per character? I'm not familiar with the Apple II. Looks like $fbfd preserves X though.)
I have done a lot of all of this sort of code and I am quite familiar with the 6502 tradeoffs. But for printing 15 chars by calling a ROM routine, I stand by my comments.
I just wanted to use 6502 code (so many seem to be able to read it!) with C side by side. x86 would have worked as well. Where the fastest answer would also be the same construct, assuming the dependency on an external routine.
You know what, I'm gonna nitpick that nitpick: void main() is fully allowed on a freestanding target, which is still standard C.
Given the C standards historically generous interpretation of undefined behaviour and other miscellany, I think it's a reasonable interpretation of the standard to pretend that a target that allows something other than int main(...) is freestanding rather than hosted, and therefore fully conforming.