Reading the following documentation:
https://learn.microsoft.com/en-us/windows/desktop/api/winuser/ns-winuser-tagkbdllhookstruct
The bit 4 (counting from 0), is defined as - "Specifies whether the event was injected. The value is 1 if that is the case; otherwise, it is 0. Note that bit 1 is not necessarily set when bit 4 is set."
What is the actual definition of "injected event?" in this context?
You'd think it was an easier thing to google.
If you look at Microsoft's documentation for the SendInput function it describes what it does as inserting or injecting input:
"The function returns the number of events that it successfully inserted into the keyboard or mouse input stream. .... This function is subject to UIPI. Applications are permitted to inject input only into applications that are at an equal or lesser integrity level."
Keyboard input generated by the user and sent from the device driver will not have the bit set. Input created using API functions will have the bit set.
Related
I'm using the libwebsockets v2.4.
The doc seems unclear to me about what I have to do with the returned value of the lws_write() function.
If it returns -1, it's an error and I'm invited to close the connection. That's fine for me.
But when it returns a value that is strictly inferior to the buffer length I pass, should I consider that I have to write the last bytes that could not be written later (in another WRITABLE callback occurrence). Is it even possible to have this situation?
Also, should I use the lws_send_pipe_choked() before using the lws_write(), considering that I always use lws_write() in the context of a WRITABLE callback?
My understanding is that lws_write always return the asked buffer length except is an error occurs.
If you look at lws_issue_raw() (from which the result is returned by lws_write()) in output.c (https://github.com/warmcat/libwebsockets/blob/v2.4.0/lib/output.c#L157), you can see that if the length written by lws_ssl_capable_write() is less than the provided length, then the lws allocate a buffer to fill up the remaining bytes on wsi->trunc_alloc, in order for it to be sent in the future.
Concerning your second question, I think it is safe to call lws_write() in the context of a WRITABLE callback without checking if the pipe is choked. However, if you happen to loop on lws_write() in the callback, lws_send_pipe_choked() must be called in order to protect the subsequent calls to lws_write(). If you don't, you might stumble upon this assertion https://github.com/warmcat/libwebsockets/blob/v2.4.0/lib/output.c#L83 and the usercode will crash.
I trying to use GetAsyncKeyState in a project I'm working on. The only problem is I don't know what value it returns, and in turn how to check for it. According to the MSN documentation:
Type: SHORT
If the function succeeds, the return value specifies whether the key was pressed since the last call to GetAsyncKeyState, and whether the key is currently up or down. If the most significant bit is set, the key is down, and 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; for more information, see the Remarks.
I know that type SHORT is a number, but I've seen a lot of different answers across StackOverflow, and the internet, but what is GetAsyncKeyState's return value when it evaluates to true, does it return 0 or 0x8001?
The return value can be one of 4 possible values:
0x0000
0x0001
0x8000
0x8001
Use & 0x8000 (or alternatively < 0 since SHORT is a signed type) to check if "the most significant bit is set" (which makes a signed type negative).
Use & 0x0001 to check if "the least significant bit is set".
In a midi file, if I want to change, say, panning I write
<delta_time> <176(ch1 control change)> <10(pan control)> <value>
This sets panning value to a number between 0 and 127 (msb). For more fine tuning I can also use control message 42 which sets a lsb for the panning. My question is, to set a precise tuning, do I have to repeat the whole message such as:
<delta_time> <176(ch1 control change)> <10(pan control msb)> <value>
<delta_time(0)> <176(ch1 control change)> <42(pan control lsb)> <value>
or can I send
<delta_time> <176(ch1 control change)> <10(pan control)> <value(msb)> <value(lsb)>
Also, what happens if I just send lsb? will it assume msb as 0?
Thanks
Each control-change event is an independent event, so it needs its own delta time, its own status byte, and its own parameter byte(s).
(The status byte can be omitted if it has the same value as the previous one, but this depends only on the status byte's value, and not on whether the events are actually related.)
What happens if you send the MSB message without the LSB message is not clearly specified, and even if it were, you could not be sure that devices would implement it correctly.
To be safe, to change a control with a 14-bit value, send both the MSB and LSB messages, in that order.
I'm just researching this myself. The answer above is not correct, it seems to me. If you reference the official MIDI spec...
(normally you have to pay for the spec but here's a free reprint:)
http://oktopus.hu/uploaded/Tudastar/MIDI%201.0%20Detailed%20Specification.pdf
On page 12, this MSB/LSB scheme is discussed. It says that sending the LSB values is OPTIONAL. I think it's safe to assume that the LSB will be zero if not specified. Furthermore, it clearly states that re-sending the MSB when only the LSB changes is also optional. The only thing that's required is that if you are using LSBs and you change the MSB, you must update the LSB as well.
In windows SEH data, there exists a facility to define for a given RUNTIME_FUNCTION some pseudo-operations which describe its effect on the stack. They are defined here in the documentation for UNWIND_CODE: http://msdn.microsoft.com/en-us/library/ck9asaa9.aspx
However, Microsoft have only documented version 1! In some things that ship with windows (such as notepad), the given version for the exception handling data is 2. It looks to me as though they are very similar (see also http://sourceforge.net/mailarchive/message.php?msg_id=31650579), except that there is a mysterious and very common operation code 6, which is not defined in the version 1 documentation.
From my admittedly small sample, it appears that the op info is always 0 or 1, and the operation appears to consume only one slot in the unwind op data.
It seems that in ReactOS, it is taken to mean UWOP_SAVE_XMM (see http://doxygen.reactos.org/d4/d85/rtl_2amd64_2unwind_8c_a552b9ed5f66cb1a0015f7523bfce2eb9.html#a552b9ed5f66cb1a0015f7523bfce2eb9). This is an unlikely meaning for it in this case (the "version 2" case), since the following slots contain valid unwind operations rather than sane memory offsets.
What is the meaning of unwind operation 6?
I am currently trying to figure out how sms classes are correctly represented in SMPP. However I am by now completely confused by the standard and it's documentation.
In normal sms we have
Class0: Flash sms, which are shown on the display
Class1: Normal Sms to be stored on the sim or internally in the device
Looking at the SMPP spec, I first find the parameter data_coding in the submit_sm operation, which is used to set the DCS sent via MAP. As far as I understand this, if we want to explicitly set the message class we need to set the first four bits of this parameter to ones, then two bits indicating the coding and then another two bits indicating the message class. So for Class1 Sms, we would set 1111xx01. Is this correct so far?
If we try to set this DCS, however currently we also set the data coding to "8-Bit data". It seems, several phones are not able to understand this. Is this specified anywhere, and can we just change this, or is a special coding needed when sending other message classes.
More confusion arises, when we try to use the SMPPv3.4 recommended way of setting the Message class. Since 3.4 there is an optional parameter in the submit_sm operation, called dest_addr_subunit. According to the standard this parameter should be set to 0 for unknown, 1 for MS-Display, 2 for Mobile equipment, etc. If I look at this, it seems the parameters are shifted by one compared to GSM message classes. Class0 is encoded as 1, Class1 is encoded as 2 and so on. Is this correct or is there any more complicated mapping behind this?
Also, if we set dest_addr_subunit, do we still have to set DCS as well, or can we just leave this parameter at it's default value?
I recommend to read 3GPP TS 23.038 specification with detailed DCS (Data Coding Scheme) description.
In case of DCS bits 7654 are 00xx, you should check DCS for bit 4 value.
bit 4 == 0 - no message class for this message (bits 1 and 0 are reserved)
bit 4 == 1 - bits 1 and 0 contains message class
So you should set data_coding SMPP parameter in accordance to 3GPP TS 23.038 specification to handle message_class properly.
By default GSM SMS message has no message_class and this is not the same as message_class = 1.