try rc4 crypt just text "testtesttest" under key "tahci".
Result:
pure VC++ 6.0+ RC4 Krypton lib:
lÎSÔpÿ'–™ø.
PHP with http://prdownloads.sourceforge.net/rc4crypt/rc4crypt.zip:
lÎSÔpÿ'–™ø.
C# with Mentalis.org library:
lNSTp'x.


submit my C# code????

Trust me, our RC4 implementation works perfectly. We've tested it against official RC4 output values and we use it extensively in our SSL library.
If you're not seeing the output you expected, you're doing something wrong [either in the PHP or C# code].

In Visual Basic 6, you cannot use either the ASC or the ASCW function when encrypting.

ASC doesn't handle Unicode, and discards half the data in VB 6's UCS2 string. ASCW doesn't handle surrogates, and corrupts some Asian languages. You have to get the string into a byte array.

Also, you can't use the built in function to perform this conversion (the assignment operation), because this also corrupts the data for certain Asian languages, instead you have to pull in the appropriate copying and conversion functions from the Windows kernel itself.

That is assuming you want to not corrupt your data.

Additionally (yeah, there is, sadly, more), You cannot use CHR or CHRW to store the resultant encrypted data back into a string, because the string follows Unicode rules and you may introduce Byte Order Markers, Surrogates or other characters with special meaning, and so you might farther corrupt the data.

Usually you will see no problems until you hit one of the magic cases that hits one of the special cases, and usually (and this is the really bad part), you won't notice your encryption isn't handling Unicode correctly until you try to go to Europe or Asia with your product, and have someone enter the data.

More than likely, this is why the VB 6 example is producing different results. It's probably discarding alternating bytes of data, not handling surrogates correctly, etc.

It appears to work because both sides of the connection are corrupting the data in the same way, so while you're only copying half the data, you'll never notice until you send a Kanji character (for example) across the wire.

And the C++ one, incidently, produces the same results as the VB 6 one for the simple reason that Visual C 6 doesn't do Unicode by default. Do a Unicode build, on the C side, and you should get identical results.