Today I came across this cool library and one of the options there is to be able to check if the running application is running as admin. There are quite the number of uses for this so its worth implementing.

I have observed that not all processes get enumerated on Windows in certain situations. A good example of this is a process running as another user. This needs to be further investigated. The same problem might exist with window enumeration as well.

Would it be possible to allow input such as a key or mousepress on a specific window, without it being active? All inputs are currently global. I'm not entirely sure if this is possible cross platform, but windows itself should allow this.

PS: loving the node version of robot so far, it's great!

Hey, guys. I love this library. I'm currently developing a bot for a game that should also work in the background. Most of my bots I developed with C#. There I was also able to send keystrokes for games in the background.

I also want this functionality for robot-js. REF: MSDN::SendMessage function

Best regards

Right now it's a huge pain to test the library. There's no way of skipping specific tests and some of those tests take up a lot of time to perform. We need to streamline the whole process and only select tests that need to be ran on a test by test basis.

As $ is the special character for typing the system key, you can't use it normally. I tried escaping it ({$} or {DOLLAR}) and it doesn't work either. I see no mention of this in the documentation or code. I may be missing it, but it doesn't seem like there is any way to type a literal $ using the Robot Keyboard.

Since C++11 already provides standardized data type declarations, it might be worth just removing the ones defined by robot. This means that types like int32 will turn into int32_t. Not yet sure whether this type of breaking change qualifies a major version bump. Perhaps this will be done in two parts: Deprecate the current types and point them to cstdint, then, after some time, remove them entirely.

I believe that this project should provide a standard interface from its Makefile. This change changes the default command to make build instead of make help. It also makes a blank configure script.

This is a potential fix for #17 . I have tested several configurations for windows and Ubuntu, including static and shared library configs with Clang, GCC, MinGW and visual studio community edition.

I am quite confident this will work with any Linux that is at all adheres to the LSB, like Red hat, Fedora and less so for Gentoo, Arch (I still think it'll work).

I do not have a Mac OS X machine to test with. But I suspect that will not work because it is missing some linking options.

There are a few functions that could be implemented better for MinGW, Process::Open I pretty much implemented as No-op. It also looks like a few shortcomings in the winuser.h and winbase.h implementation in the MinGW SDK, these will likely require bugfixes in MinGW.

Here are some things that this does not address that the previous build files do:

• This does not address the install process.
• This does not add "d" to the name.
• Mac OS X linking options and Objective-C++ options are missing.
• The Peon testing tool is not included.
• This removed .BIN from the executable names.
• I am unsure if I am missing any msvc options.

Need to add an ability to create windows:

static Window Window::Create ( ... );

From there, we can look into ways of creating transparent overlays, rendering graphics, etc. The biggest hurdle is figuring out the scope and what we could actually do. Obviously writing a UI framework is out of the question but how would we go about displaying stuff on windows? Perhaps we'll need to integrate with a library of some sort? Maybe just have one function to draw an image?

On Windows, in order for some functionality to work, such as manipulating a process owned by another user account, an application must have a method of granting itself elevated privileges. Specifically, SE_DEBUG_NAME. This is typically done through: OpenProcessToken, LookupPrivilegeValue and AdjustTokenPrivileges. Such a function would probably need to be implemented in a System class (#50) and would need to have the ability to be enabled and disabled.

Since SE_DEBUG_NAME is one of the few privileges that is required by Robot, it might be the only one worth supporting, however, it might be just as easy to support all possible privileges, all in one function. We'll see.

When Image.Create() is called, it may (if the existing buffer is not already large enough, or if no buffer yet exists) allocate a new buffer. It allocated the buffer without initializing it, so whatever data happens to be in memory already ends up in the image. This can lead at best to some weird images if the new memory happens to contain non-zero pre-existing data, and a security issue at worst if the image with uninitialized pixels is being output somewhere non-privileged. I'll file a PR to fix this.

Currently, the Hash class has abysmal performance when compared to other CRC32 algorithms. Looking at our options here, here and here, it's clear that there's a lot of improvements which could be made. Read the table below to see how we compare (Ignore the differences in the result as the comparison uses the iSCSI/Castagnoli polynomial where as we use the Ethernet/ZIP one).

| Option | Result | Performance | |:---------------------|:-----------|:--------------------------------| | Naive - CPP | 0xA0B96C51 | 147.0 MB/s = 0.29 bits/cycle | | Tabular - 1 byte | 0xA0B96C51 | 556.6 MB/s = 1.11 bits/cycle | | Robot - Hash | 0x1D75653D | 561.1 MB/s = 1.12 bits/cycle | | Tabular - 2 bytes | 0xA0B96C51 | 795.3 MB/s = 1.59 bits/cycle | | Hardware - 1 byte | 0xA0B96C51 | 1324.1 MB/s = 2.65 bits/cycle | | Tabular - 4 bytes | 0xA0B96C51 | 1369.0 MB/s = 2.74 bits/cycle | | Tabular - 8 bytes | 0xA0B96C51 | 2416.1 MB/s = 4.83 bits/cycle | | Checksums - AWS | 0x1D75653D | 2682.3 MB/s = 5.36 bits/cycle | | Tabular - 16 bytes | 0xA0B96C51 | 4011.5 MB/s = 8.02 bits/cycle | | Hardware - 8 bytes | 0xA0B96C51 | 10538.0 MB/s = 21.08 bits/cycle | | Golden - AMD | 0xA0B96C51 | 19564.9 MB/s = 39.13 bits/cycle | | Golden - Intel | 0xA0B96C51 | 30507.4 MB/s = 61.01 bits/cycle |

Contrary to superficial appearances, GetKeyState and GetAsyncKeyState actually have significantly different behavior, aside from skipping the input buffer queue.

GetKeyState: docs

If the high-order bit is 1, the key is down; otherwise, it is up. If the low-order bit is 1, the key is toggled.

• Allows detection of lock-key toggle state (e.g. "is CapsLock on?")
• Allows detection of currently-pressed state (e.g. "is CapsLock being pressed?")

GetAsyncKeyState: docs

If the most significant bit is set, the key is down If the least significant bit is set, the key was pressed after the previous call to GetAsyncKeyState. However, you should not rely on this last behavior

• Does not detect toggle state (try it! Note, this is different from the way Robot works on OSX)
• Allows detection of "recent" keypresses (almost useless since this can get reset by other processes, and is different from the way Robot works on OSX)
• Allows detection of currently-pressed state (e.g. "is CapsLock being pressed?")

I think Robot should probably be using GetKeyState rather than GetAsyncKeyState. The reasoning for using GetAsyncKeyState is that it allows you to check the current realtime keyboard state regardless of queued input to your process, however it is your process so you could just as well drain your input before calling GetKeyState to get the same result, with the added benefit that you can obtain lock-key toggle information, and can also obtain input-buffer key information if you want.

One still-missing feature would be the ability to distinguish between CapsLock-on-and-down, CapsLock-on-and-up, and CapsLock-off-and-down. Unfortunately, sorting this out would probably require a new method signature other than bool Keyboard::GetState (Key keycode), and it's fairly rare to need to know if CapsLock (or ScrollLock or NumLock) is actually being pressed at the moment.