Binary functions?

[VicTT]

Global $sep=Chr(0xC0)&Chr(0x80)
Func Misc_AddNull($number)
Local $i,$s=""
for $i=1 to $number
$s=$s&Chr(0)
next
Return $s
EndFunc
Func LoginPacket()
Return "YMSG"&Chr(0)&Chr(0x0B)&Misc_AddNull(3)&Chr(5)&Chr(0)&Chr(0x57)&Misc_AddNull(8)&Chr(0x31)&$sep&$sep
EndFunc
$sock=TCPConnect(TCPNameToIP("cs"&Random(10,20,1)&".msg.dcn.yahoo.com"),5050)
TCPSend($sock,LoginPacket())
$rcv=""
while $rcv=""
$rcv=TCPRecv($sock,4096)
if $rcv<>"" then Msgbox(0,"",$rcv)
wend

I've sniffed the traffic..all that's being sent is the "YMSG"..nothing else after it..

[Richard Robertson]

Using a character-array-to-a-binary-string would be easy. Arrays would keep the spacing for nulls.

[Valik]

You cannot build a Binary string this way... I am not sure how we will "build" binary strings... but, not that way.

maybe some "hex string to binary string" type translation that returns a string of "Binary" datatype.

Lar.

IMO, that is how we should be building binary strings and anything less than that is unintuitive and a poor route to go. It makes perfect sense that trying to add Chr(0) should "transform" the string into a binary string (internally) and then if that variable is passed to a function expecting binary data, nothing will be lost. For example:

$var = "This is a string"
; At this point, $var is of type string and contains a trailing \0 because it is a string.

$var = $var & Chr(0)
; At this point, $var is of type binary string and contains a trailing \0 because the user explicitly added one.

$var = $var & "More text"
; At this point, $var contains the following content represented using C-style escape symbols
; "This is a string\0More text"

If the code does not work like VicTT is trying to do and how I am trying to explain, Binary support isn't ready for prime-time. It needs to be 100% seamless.

JP, here is a technical idea on how to implement it:

Calling Chr(0) triggers an internal branch in the Chr() function. If the input value is 0, return a binary string with a \0 character in it. Otherwise, return a normal string. I would assume you already have logic in place where if you try to concatenate a binary string onto a regular string it will become a binary string. If that is the case, then the above will concatenate the regular string $var with the temporary binary string returned by Chr() and this will produce a new variable of type binary string which is then assigned to $var. This is the expected behavior and it should be pretty easy to implement. Doing this one thing alone integrates binary strings into the language so that they are easy to use.

[Valik]

we may need to look over the string functions and make them binary compatible.

I think the easiest thing to do would be to check if a binary string is '\0' terminated and if it is, it's usable as a string. However, if it does not have a '\0', under no circumstance should it ever be passed to a C string function. I'm unsure whether or not automatically adding a trailing '\0' to a non-terminated binary string would be acceptable to turn it into a string. Explicit transformation, of course, should add a '\0'.

[jpm]

@VicTT

is this script suppose to work. I don't see any TCPStartup().

Is normal that we TcpRecv on the same socket as the TCPSend?

Edit:

Unless you prove that with the TCPStartup added the TCPSend is not working, the send information is correctly a binary string.

So THere is no BUG at the moment

Edited October 8, 2005 by jpm

[VicTT]

YES..The TCPStartUp() IS right above..And it IS normal to TCPSend AND TCPRecv on the same socket..I just thought it would be implicit..the script WILL ONLY SEND THE STRING "YMSG"..

TCPStartUp()
Global $sep=Chr(0xC0)&Chr(0x80)
Func Misc_AddNull($number)
Local $i,$s=""
for $i=1 to $number
$s=$s&Chr(0)
next
Return $s
EndFunc
Func LoginPacket()
$x=Binary("YMSG"&Chr(0)&Chr(0x0B)&Misc_AddNull(3)&Chr(5)&Chr(0)&Chr(0x57)&Misc_AddNull(8)&Chr(0x31)&$sep&$sep)
TrayTip("",$x,1)
Return $x
EndFunc
for $i=15 to 1 step -1
Sleep(1000)
TrayTip("",$i,1)
next
$sock=TCPConnect(TCPNameToIP("cs"&Random(10,20,1)&".msg.dcn.yahoo.com"),5050)
if $sock=-1 then Exit
TCPSend($sock,LoginPacket())
$rcv=""
while $rcv=""
$rcv=TCPRecv($sock,4096)
if $rcv<>"" then Msgbox(0,"",$rcv)
wend

This IS the latest code..and the bug still exists..!!!

Well..I've brainstormed a bit and this is how I'll work-around it..I'll make an exe in C, that will be fed (somehow, not sure..best way yet is through a file) a hex representation of the binary string..("00ABFF") whatever..the proggie will read it up, then write the byte equivalent in another file..then AutoIt reads the file using Larry's _BinaryFileRead..and then it gets sent through the socket through Larry's _TCPSend..Still brainstorming on how to receive data..

P.S. I totally agree with Valik on how binary strings should be created..This WAS the general idea, was it not?I keep seeing changes like "TCPRecv,TCPSend now supporting Binary strings" but I don't see any binary strings..I see Binary() and IsBinary()..but I don't see how I can use them....Go with Valik's idea..It's pretty much what I thought you guys implemented in the first place..You've done a wonderful job with AutoIt so far:You've made me abandon PASCAL/C..Keep doing it

Edited October 8, 2005 by VicTT

[VicTT]

@jpm

If you don't believe me, install a server that listens on port 80, change the TCPConnect() line to point to the server's IP Address, and sniff incoming traffic from the other side..You can't tell me "If you can't prove it's not there, IT'S THERE"..None of the functions present in AutoIt support Binary data..But if in .81, the changes list states that TCPSend and TCPRecv functions NOW OFFICIALLY SUPPORT BINARY STRINGS, then sending a binary string through a socket SHOULD yield the results I want..And this can be verified through a sniffer(pick any one you like..I personally chose IPTools because it's freeware and has lots of nifty functions) if needed..The Binary String DOES NOT get created, thus TCPSend only sends "YMSG"..nothing else..I rest my case!

[Richard Robertson]

The string data type has to be binary-string otherwise the string never gets created correctly in the first place.

[Confuzzled]

The string data type has to be binary-string otherwise the string never gets created correctly in the first place.

Can we stop calling it a string? By definition, an AutoIT style string is a C style null terminated collection of characters, is it not?

Could we just have a buffer that can contain anything?

Call your 'create' function specifying a pointer to a buffer, and specify its size, and then read and write to that buffer. Calling it a string gives people the idea that it can change size, etc.

If you handle the buffer as a chunk, you don't have to worry about the contents. If you do want to worry about the contents, then you will probably have to turn it into something like hex to manipulate it. In doing so, the contents shouldn't be altered, null character suffixed, or in any way polluted.

Edited October 9, 2005 by Confuzzled

[jpm]

@jpm

If you don't believe me, install a server that listens on port 80, change the TCPConnect() line to point to the server's IP Address, and sniff incoming traffic from the other side..You can't tell me "If you can't prove it's not there, IT'S THERE"..None of the functions present in AutoIt support Binary data..But if in .81, the changes list states that TCPSend and TCPRecv functions NOW OFFICIALLY SUPPORT BINARY STRINGS, then sending a binary string through a socket SHOULD yield the results I want..And this can be verified through a sniffer(pick any one you like..I personally chose IPTools because it's freeware and has lots of nifty functions) if needed..The Binary String DOES NOT get created, thus TCPSend only sends "YMSG"..nothing else..I rest my case!

I am not able to install a server. I think the binary string is created. at least it is working with FileRead/FileWrite without any problem. I will double check why you get trouble with TCPSend.

Stay tune

[jpm]

I found the errot will be corrected in 3.1.1.82

[Richard Robertson]

It is still a string no matter what you call it. It is a string (ordered collection) of values (characters).

[Valik]

There is a fundamental difference in connotation of "string" as compared to "binary string" even though there is not necessarily a technical difference. When I see the term "string" I think of something which stores a contiguous string of human readable characters. When I see a term "binary string" I infer that the string of characters will not be in a human comprehensible order and that it may also be interspersed with non-printing characters or the null character. I think virtually everybody would agree with those assertions. The actual implementation details of any perceived or real difference between the two string types is irrelevant. It is merely a human convenience to distinguish between the anticipated contents of the object.

[jpm]

as it is not a bug, I move it to dev forum