Talk:Killer poke

From Wikipedia, the free encyclopedia

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

Contents

[edit] Wanted: PET killer poke details

I have a question: How exactly did the PET poke damage the CRT monitor? --Anonymous 14:02, 28 October 2005 (UTC)

Thanks for asking! I will describe this in detail in the PET article itself shortly. Stay tuned. :-) --Wernher 02:20, 30 October 2005 (UTC)


The article cites the damage must be physical then elaborates to advise that is should be permanent and irreversible - these seem unrelated definitions and serve therefore to confuse the issue (for me at least). Reading the article I cannot tell if I have even been the executor of a killer poke or not!

On the microbee computer one could poke to start ones basic code on startup, and one could poke to disable the keyboard handler, as the RAM was battery backed, one could effectively "brick" the unit by combining these into a 2 line BASIC program. When I tried the only solution was to remove the very large soldered on battery by sniping its leg and then resoldering the broken wire back together.

Though this was not a change of hardware it effectively required the hardware to be modified to restore the unit operation, it rendered the unit non-functional yet it could be repaired as cited. —Preceding unsigned comment added by 60.242.17.174 (talk) 15:30, 2 November 2007 (UTC)

[edit] About the note...

Could someone please add an explanation for the note ("Any system that meets Popek and Goldberg virtualization requirements is immune (or can be made immune) to any killer poke."). I don't understand, why this is the case, so I think an explanation would be useful for the readers of this article.

I just changed it by removing the "is immune" part, and I'll add an explanation now. Rbarreira 08:13, 11 July 2006 (UTC)

[edit] Virtual memory should be enough

It seems to me that meeting the mentioned virtualization requirements is more than is needed to protect against killer pokes. While it is true that a properly virtualizable machine can be protected from killer pokes, so can any virtual memory system with memory protection, which protects memory-mapped registers from unprivileged code, either by preventing unprivileged writes or by simply not mapping the registers into the code's virtual address space. Of course, this can be bypassed if the code is running without memory protection and outside a virtual address space (like device drivers or x86 real mode applications) or is somehow able (perhaps by mmap or a similar facility) to map the sensitive registers into its virtual memory space with privileges to write to them. Port-mapped I/O could conceivably also produce similar effects to a killer poke, but this is technically not a poke, and port-mapped I/O operations tend to be privileged anyway. —71.39.6.137 06:54, 25 August 2007 (UTC)

[edit] IBM PC

The term is used especially of various fairly well-known tricks that can overload the analog electronics in the CRT monitors of computers lacking hardware sanity checking (notable examples being the IBM PC [...] ) [...].

We need proof for the IBM PC being poke killable. --Abdull (talk) 11:33, 9 December 2007 (UTC)