I'm inclined to say using the KVM over RDC isn't possible, but why would you want to do it that way? Consider how it all connects together - the keyboard (& mouse & monitor) plug into the KVM, which in turn connects to the two desktop PCs, which are both on the LAN. The two PCs know nothing about being connected to a KVM switch - the double scroll lock press to switch is handled entirely by the KVM itself. Remote Desktop, on the other hand, is connecting to the actual PCs. Am I correct in understanding that you have a third PC on the other side of the house from the two on the KVM, and it is this third PC that you are wanting to work from. I.e. your setup looks something like this:

/-----\ control remote PC 1 /-----\
| | PC | |.........
\-----/ \-----/ :
| | :
=====================LAN====================== KVM switch
| :
/-----\ :
remote PC 2 | |......:
\-----/

If this is how you are set up, then when working from the control PC you can ignore the KVM entirely and just use Remote desktop on the two PCs. It is perfectly possible for you to sit at the control PC and have remote desktop sessions open on each of the other two machines, and switch between them at will.

Expand the hex string 00 00 02 01 to binary, and you get 00000000 00000000 00000010 00000001. Now, we ignore the most significant bit (left-hand end of each byte) giving the bit string 0000000 0000000 0000010 0000001, which when read as normal 8-bit bytes and padded to fill the top byte (padding in brackets) is (0000)0000 00000000 00000001 00000001, or hex 00 00 01 01 which is, in decimal, 257. This following is a C function to get the size of the tag (assumes int is 32 bits and char is 8 bits.) The first of the four bytes from the ID3 tag is placed in the first position in the array, so for the example input, encodedSize[0] = 0x0, encodedSize[1] = 0x0, encodedSize[2] = 0x2, encodedSize[3] = 0x1.)int getTagSize(char encodedSize[4]) { int retval = 0; retval = encodedSize[0] << 21 | encodedSize[1] << 14 | encodedSize[2] << 7 | encodedSize[3]; return retval; }
Not that this function doesn't do any form of sanity check on the input data, which is a Bad Thing™ in real code you must check that each byte of the encoded size is < 0x80, and do whatever is appropriate in your app when encountering an invalid ID3 tag if the test fails. As for the aside about maximum tag size, the max value with this encoding is $7f 7f 7f 7f, which represents 268435455 bytes, or 256 MB, of ID3v2 tag. I don't see where you're getting 4*127*127 from, but the reason why 127*127*127*127 = 260144641 is wrong is that, while the maximum value for each byte is 127, the total number of values for each byte is 128, and so there are 128*128*128*128 = 268435456 possible values for the tag size (0-268435455)

Bah, smart-alec. I only said "many numbers", I didn't say anything about which numbers, other than the example I gave. 1 (or any other integer until you get big enough that precision becomes an issue) can, of course, be precisely represented in a double. I dunno why Oliver was having problems when using the value 1, but I was addressing hte general case. That's my story, and I'm sticking to it ;P

It is inherant in how floating point works that many numbers cannot be precisely represented with a finite number of bits. Just as in base 10, a number such as 1/3 needs an infinite number of digits to be written out (0.33333.....) Take, for example, the number 1/10. Suppose you write double d1 = 0.1 - internally this decimal is converted into binary which (simplfying somewhat, floating point numbers are actually stored in the binary version of scientific notation) is 0.0001100110011001100... where the bits to the right of the point at 1/2, 1/4, 1/8, 1/16, 1/32, etc. Since any actual data type has a finite number of bits (in the case of double precision floating point, 53 bits are available from the first "1") we can only store an apporximation of many values. When using floating point data, you should never test numbers for equality (unless you're certain that the numbers need to be the same sequence of bits) you should instead check if the difference between two numbers is sufficently small.

Try RS or Farnell, both are good for electronic components.