Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Back in typing/HyperCard programming class in the mid 1990s, one of my friends jammed the Mac lab's AppleTalk network. He told me he did it by taking his computer off the network at the moment he held the AppleTalk token.

He didn't seem to be lying... he did something using mouse/keyboard on his machine and my machine couldn't use the network, and then after a couple kids complained about the network being down, he discretely did something on his machine and things were fixed.

I was always confused as to how he was fast enough or even that his computer having the token was user-visible without installing specialist tools on the school's computers. If he were to start a large file transfer, would that cause him to hold the AppleTalk token for a long time, and give him visibility via the progress bar?

I thought there was sub-second upper bound on how long the token would be held, even if your machine still had data to send. Am I mistaken about AppleTalk token ring networking?



This reminds me of anecdotes I’ve heard whereby MacOS’ lack of preemptive multitasking led to the situation whereby if somebody were to open and hold the apple menu on their machine it would receive but not yield the token (because network processing was essentially suspended while it followed the user’s every action with the GUI of that menu).


There was no memory protection on those machines so nothing to stop you from patching the network driver while it was running.


I think HyperCard and AppleScript were the only programming environments installed on those machines, and he was a big PC proponent, so I don't think he had a Mac at home. I don't think he used any specialized tools, and I don't think he was using AppleScript to bit-bang binaries into the network driver's region of memory.

That does remind me of a story I heard, that the zero page was mapped, and the first 64 bits of the zero page were initialized to zero at startup. So, if you derefernced or duble-dereferenced NULL as an *int, *float, *double, **int, **float, **double, etc., there would be no error and you'd get 0 or 0.0. Apparently, the Excel port for Macs had quite a few NULL double-dereferences, either intentionally taking advantage of this "feature" or by accident. Many developers installed a system extension that would set the first 32 bits of memory to a value larger than the amount of installed memory, guaranteeing an error if NULL were double-dereferenced.*




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: