On 13/04/2024 15:42, Fredxx wrote:
> 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.

Yup - DOS system calls were done using a INT 21H instruction. That made
for slightly shorter code (no need to use a 5 byte far call
instruction), and it also made it easy to "hook" OS calls if you wanted
by re-pointing the int 21 interrupt vector at your code, and then
chaining to the real one after you have done what you wanted.

> And I recall there was a timer ISR too. In the

Yup it updated the software version of system time, and turned off the
floppy motors after 5 secs of inactivity. Originally generated by an
8254 Programmable Interval Timer (these days built into one of the
"bridge" chipsets).

(I quite often used to disable it when I needed precise timing control
when writing simulators)

> 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!

:-)

Yup much fun could be had with TSR programs -

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

Yup the Program Segment Prefix (PSP) - a data structure built for each
COM or EXE program as it loaded, was based on the CP/M version[1]. It
included a far call instruction at offset 5, that would call the OS
entry point, so you could do a CALL BDOS instruction as you would on
CP/M and it would work.

[1] Which arguably much of DOS was since it was based on Seattle
Computer Products QDOS (Quick and Dirty Operating System), which was
basically a 16 OS shall we say "heavily influenced" by CP/M. MS Licenses
QDOS from SCP, and then later bought it outright.

--
Cheers,

John.

/=================================================================\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\=================================================================/