On non-latin non-Unicode locales, sending and receiving data on scripting suffers the same problem that it did internally before. When you call winsock.SendData STRING or winsock.GetData STRING, vbString, VB6 will mangle the data.
One workaround is to have VB6 use Byte() when interacting with Winsock. This is done in the internal program, now. The problem is, VBScript doesn't have that easy an access to Byte() data since it lacks the VB6 As keyword and types, It settles for dynamic typing with the Variant type. Existing scripts would have to be updated too.
A possible solution is to "wrap" the Winsock objects shared with scripts with CreateObj and handle the SendData and GetData calls as special cases, converting the Variant strings to Byte() and back for the actual calls to the object. Much like how clsSLongTimer wraps a Timer object.
On non-latin non-Unicode locales, sending and receiving data on scripting suffers the same problem that it did internally before. When you call
winsock.SendData STRINGorwinsock.GetData STRING, vbString, VB6 will mangle the data.One workaround is to have VB6 use
Byte()when interacting with Winsock. This is done in the internal program, now. The problem is, VBScript doesn't have that easy an access toByte()data since it lacks the VB6Askeyword and types, It settles for dynamic typing with theVarianttype. Existing scripts would have to be updated too.A possible solution is to "wrap" the Winsock objects shared with scripts with
CreateObjand handle theSendDataandGetDatacalls as special cases, converting the Variant strings to Byte() and back for the actual calls to the object. Much like how clsSLongTimer wraps a Timer object.