No human being can know the heart of another.

Whatever your intentions, I think your posts may be triggering warning bells because in each and every one, you seem to want to control/intercept things outside of a specific application, particularly the user interface used by other applications. Here is a summary of your questions:

• In checking mouse events on desktop you want to monitor mouse activity for the desktop and all windows, not just the one's controlled by your application. Why? An application should only be concerned about its own inputs. I can't think of a "white hat" reason for such broad-based mouse capture other than a window manager or window manager extension.
• In Manipulate Desktop-Windows with Perl you want to manipulate all desktop windows, not just the one's used by your application.
• In Fast way to compare two picture-files you tell us that you want a rapid way to compare two picture files so you can compare before and after snapshots of desktop areas. Apparently, you decided to do this on your own: Alternate for GetPixel asks for a faster GetPixel routine.
• In use the return code of another program you want to write a process monitor that will run in parallel with program X, and capture its output to stdout and its return code. stop pipe apparently concerns a problem with getting said process monitor to stop.
• In Capture Keystroke, the current post wants all keyboard input, not just that destined for a specific widget. And you want to send the key strokes out to the "system", rather than to the application that owns the widget.

Now, of course, Perl is often used for system level programs. But the system level programs written in Perl normally concern themselves with the non-interactive portions of the computer ecosystem. The kind of cross-application GUI monitoring you seem to want to do is normally done by windowing systems and desktop managers. Desktop managers are generally written in a language that has rapid direct access to system APIs - for example C/C++ or C#

That isn't to say Perl is never used for desktop-wide GUI programs. tye recently used Perl to fake mouse movements so that he could listen to music as he biked to work. He wasn't trying to hurt anyone, but this is the exception that proves the point. He was doing this to subvert a screen saver time-out that the previous IT administration at his work had instituted as a "security" feature.

System level programs with GUI access has been such a common vector for black-hat software that Vista essentially put an iron wall between the two. In Vista, system and desktop processes run in different "sessions". Even if a remote process logs in as user X it gets its own (non-GUI) session and cannot get access to X's desktop enabled session without a fair bit of fancy systems and permissions footwork.

Perhaps the other issue that raises red flags is the level of expertise suggested by your posting style. The white hats that do these kind of system wide GUI things are usually, like tye, pretty experienced programmers. Usually experienced programmers do a fair amount of research before they post. They don't want superficial answers, so they make it clear they've read the manuals and searched the expert forums. They ask focused questions about alternatives, not "Does anybody have a clue?".

Now I'm not saying that a learner won't want to do some cool GUI wide programming. A successful program can be fun to write and very empowering, BUT, if you are a learner, I wonder, given the security issues and level of expertise, if this really is the best project to start on.

Best, beth