On 13/04/2024 03:50, John Rumm wrote:
> On 12/04/2024 10:41, Tim Lamb wrote:
>> In message <uv8eck$1kr6i$1@dont-email.me>, John Rumm
>> <see.my.signature@nowhere.null> writes
>>> On 11/04/2024 10:35, Tim Lamb wrote:
>>>> In message <uv6ict$13bk3$1@dont-email.me>, John Rumm
>>>> <see.my.signature@nowhere.null> writes
>>>>> On 10/04/2024 15:12, Tim Lamb wrote:
>>>>>> In message <uv5oop$ssev$2@dont-email.me>, John Rumm
>>>>>> <see.my.signature@nowhere.null> writes
>>>>>>> On 09/04/2024 17:44, Mark wrote:
>>>>>>>> John Rumm wrote:
>>>>>>>>
>>>>>>>>> On 08/04/2024 09:59, Tim Lamb wrote:
>>>>>>>>>
>>>>>>>>>> How do I print a screen showing detail from a CD?
>>>>>>>>>> Herts. CC Tithe map. Original display size prints ok but
>>>>>>>>>> enlargements
>>>>>>>>>> invariably revert.
>>>>>>>>>
>>>>>>>>>> PrSc? Does that need Alt key as well? What then?
>>>>>>>>>
>>>>>>>>> PrintScreen will capture the current (logical) screen to the
>>>>>>>>> clipboard.
>>>>>>>>>
>>>>>>>>> If you want to actually print that, you will need to past that
>>>>>>>>> into
>>>>>>>>> something that can handle bitmap images (like Paint etc), and
>>>>>>>>> then  print
>>>>>>>>> from there.
>>>>>>>>>
>>>>>>>>> PrtScr+ALT just captures the currently active window, rather
>>>>>>>>> than the
>>>>>>>>> whole logical[1] screen.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] Logical in the sense that windows support multiple monitors if
>>>>>>>>> desired, and you can have your windows desktop spread over several
>>>>>>>>> physical screens. PrtSc on its own will  in those cases capture
>>>>>>>>> more
>>>>>>>>> that one physical screen's worth.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>  winkey+shift+s crops wanted bit on screen and saves to clipbourd
>>>>>>>
>>>>>>> Only if you have the snipping tool enabled - that might not
>>>>>>> always be  the case on Win 7
>>>>>>>
>>>>>>> (snipping tool also has an editor that will let you save the snip
>>>>>>> to  disk without needing to past it into another app first)
>>>>>>  Not been keeping up on this. The original issue was to print off
>>>>>> a map  section, enlarged for clarity.
>>>>>> The job was for a neighbour who seems happy with the lower
>>>>>> resolution  copy.
>>>>>> W7 does not have *clipboard* and the keyboard with a PrSc button
>>>>>> may  not  have been supplied with the original PC (re-furb).
>>>>>
>>>>> PrtSc to copy to clipboard is standard (has been there since at
>>>>> least  Win 3.1!)
>>>>>
>>>>> (The "Snipping tool" was a later addition - possibly not in win 7)
>>>>>
>>>>>> Thanks for all the advice but please remember I'm at the
>>>>>> agricultural  end of computer knowledge:-)
>>>>  Hmm. *search programs and files* fails to find anything called
>>>> *clipboard*
>>>> Snipping tool is found.
>>>
>>>
>>> Clipboard is not a "program" as such - but the name for the shared
>>> "cut'n'paste" buffer that is a part of windows.
>>>
>>> Hence you can copy or cut information in a program, and paste it
>>> elsewhere. This works within one program - say moving a section of
>>> text in a word processor, but also works between unrelated bits of
>>> software - say pasting text from your word processor into notepad, or
>>> a form on a web page.
>>>
>>> It also works with graphic data. So open a program that can handle
>>> pictures and create a new empty document if necessary. Press PrtScr.
>>> That will capture a snapshot of the screen and hold it in the windows
>>> clipboard. Now select "paste" in the program, and you should be
>>> rewarded with a picture of your desktop pasted into the doc.
>>>
>>> So for example, if I press PrnScr + ALT while this windows is active,
>>> and then open Paint, and do paste, I get this :
>>>
>>> https://wiki.diyfaq.org.uk/index.php/File:DemoClipScreenshot.png
>>
>> Ok. Thanks John and Paul for the detailed explanations.
>>
>> My technical education stopped in 1983 when I took up farming full
>> time. I guess anyone shunting photographs into word files would have
>> learned these processes as technology progressed
>
> ISTM much of the conceptual difficulty with the Print Screen key is the
> fact that it is still called that!
>
> There was a time (when DOS ruled), you pushed it[1], and a snapshot of
> the (text mode) screen popped out of the printer. It pretty much did
> what it says on the tin.
>
> In windows world, it has never really done that, but by that time all
> the key caps were printed and standardised...
>
> A "Copy Screen" key might be more aptly named. You push it, it makes a
> copy "somewhere", which you can later paste into something (including
> something that could print it out)
>
>
> [1] Odd bit of tech trivia... (for geek entertainment only!)
>
> x86 CPUs (like pretty all the others), support an interrupt handling
> capability - a way for an external device to signal to the CPU that it
> needs attention. When this happens, the CPU will stop whatever it was
> doing, jump off to some code (aka an an "Interrupt Handler" or
> "Interrupt Service Routine" (ISR)) to deal with the needs of whatever
> was signalling it, and then resume normal execution from where it left off.
>
> To achieve this voodoo there is typically a jump table of interrupt
> vectors that point the CPU toward those interrupt handlers - so
> different sources of interrupt can be linked to the required handlers.
>
> Now normally interrupts are a "hardware thing" - some electronic device
> is wired to an interrupt line into the CPU, so that it can signal when
> it wants to interrupt.
>
> The x86 range also has a software interrupt capability that uses the
> same trick for handling some "exceptions" that can be generated in the
> CPU itself. In the 8088 used in the original IBM PC, the CPU could
> generate 5 such exceptions - numbered 0 to 4 (for things like a divide
> by zero event or an overflow, but also single step debugging).
>
> The idea being that you could have an ISR that could "handle" some kinds
> of software event if wanted. Intel in their published data books for the
> CPU highlighted that although the 8088/8086 only used 5 of these
> exceptions, they reserved more of them for extra facilities that may be
> added to later CPUs. They told developers not to used any of those
> reserved ones.
>
> So what did IBM do? They implemented the print screen routine as if it
> was an ISR.  Now having the print screen code implemented as an ISR is
> quite nifty - you can call it anywhere at any time, and it will make a
> note of what it was doing, go off and print the screen, and then carry
> on where it left off.  So even in the body of the code that handles key
> presses (also done in an ISR that handles the key up/down events that
> interrupt the CPU), it could generate a software interrupt to call the
> print screen code. So far so good. However they also decided to make
> this handler the sixth one - one of the reserved ones that Intel said
> "don't use".
>
> All was fine and dandy until the 80286 came out and found it way into
> the IBM PC-AT. That had a new "bounds" exception internally wired to the
> sixth interrupt (and another couple of exceptions using the next two
> reserved ones). The bound exception could be used to automatically
> validate that data the CPU was processing fell within certain limits or
> "bounds". Not often used, but it did have the nice side effect that if
> your code generated a bounds exception unexpectedly, and had not
> bothered to install its own ISR to handle it, the PC would respond by
> printing the screen!
>
> (and if you were using bounds processing, and your implemented your own
> ISR to handle the exception, it now also had to deal with the problem of
> your code getting called at random times by the PC BIOS whenever the
> user pressed Print Screen key!).

ISR 21h was used by DOS. And I recall there was a timer ISR too. In the
days of shared PCs I wrote a TSR program that looked for directory names
and if a perpetual offender used the machine (who shouldn't be using it)
and the active directory included his name, characters would fall down
the screen, Matrix style!

I thought there were legacy CP/M commands accessible in DOS too?