[VB2005] Stops in the middle of my Sub

[iNsaNe]

There is something that I cannot figure out, and that there is some bug in my code that makes VB 2005 stop in the middle of my sub. It is C->S SID_AUTH_INFO:

Code Select Expand

    Private Sub winSock_ConnectEvent(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles winSock.ConnectEvent

        strSendData = vbNullString
        AddChat(Color.SpringGreen, "<- Connected!")

        If strProduct = "Warcraft III FT" Then

            '// C -> S 0x50 (SID_AUTH_INFO)

            winSock.SendData(Chr(1)) '// Sub Stops Here...

            InsertDWORD(&H0) '// Protocol ID (0)
            InsertNonNTString("68XI") '// Platorm ID (IX86)
            InsertNonNTString("PX3W") '// Client ID (W3XP)
            InsertDWORD(&H15) '// Version Byte
            InsertDWORD(&H0) '// Product Language
            InsertDWORD(&H0) '// Local IP address
            InsertDWORD(&H0) '// Time zone information
            InsertDWORD(&H0) '// Locale ID
            InsertDWORD(&H0) '// Language ID
            InsertNTString("USA") '// Country Abbreviation
            InsertNTString("United States") '// Country Name

            SendPacket(&H50) '// PacketID = &H50 = 0x50

        End If

    End Sub

If any visual basic 2005 users out there could point out whats going wrong.. i would appreciate it.

[MyndFyre]

Have you tried debugging?  I'd bet that if you stepped through line by line, you could find out which line was causing it to stop.

Visual Basic 2005 has GREAT support for this kind of thing.  It's called "setting breakpoints" and then clicking the arrow button that looks like a play icon on a VCR or DVD player for you youngsters out there.

[l)ragon]

If he's useing the winsock 6.0 control, that could be the source of his problem to.
I found a few of the old controls will crash and disapear for no reason with .Net.

[iNsaNe]

I used breakpoints, revised it, now it passes winSock.SendData line and stops at the next one, which the problem I believe is due to CopyMemory (my question in the other topic). MakeWORD is my problem.

Code Select Expand

    Public Declare Sub CopyMemory Lib "kernell32.dll" Alias "RltMoveMemory" (ByVal Destination As String, ByVal Source As Integer, ByVal Length As Long)

    Private Sub winSock_ConnectEvent(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles winSock.ConnectEvent

        strSendData = vbNullString
        AddChat(Color.SpringGreen, "<- Connected!")

        If strProduct = "Warcraft III FT" Then Send_SIDAUTHINFO()

    End Sub

'// Now my module

    Public Sub Send_SIDAUTHINFO()

        'C -> S 0x50 (SID_AUTH_INFO)

        frmMain.winSock.SendData(&H0)

        InsertDWORD(&H0)
        InsertNonNTString("68XI") 'Platorm ID (IX86)
        InsertNonNTString("PX3W") 'Client ID (W3XP)
        InsertDWORD(&H0) 'Version Byte
        InsertDWORD(&H0) 'Product Language
        InsertDWORD(&H0) 'Local IP address
        InsertDWORD(&H0) 'Time zone information
        InsertDWORD(&H0) 'Locale ID
        InsertDWORD(&H0) 'Language ID
        InsertNTString("USA") 'Country Abbreviation
        InsertNTString("United States") 'Country Name

        SendPacket(&H50) 'PacketID = &H50 = 0x50

    End Sub

    Public Function InsertDWORD(ByVal Data As Long)

        strSendData = strSendData & MakeWORD(Data)

    End Function

    Public Function MakeWORD(ByVal Value As Short) As String

        Dim Result As String
        Result = CStr(CDbl(Result) * 2)

        CopyMemory(Result, Value, 2)
        MakeWORD = Result

    End Function

That's all the code you need to see. The code stops functioning at MakeWORD. I used Visual Basic 2005's code upgrader to convert the original MakeWORD function from VB6. Just wondering if its the Long/Short interferance or just the converter trouble or some other problem 

[Chriso]

Perhaps you should use .NET's Bitconverter class instead of CopyMemory?

Also, your code says 'InsertDWORD' then you are making a WORD instead of a DWORD and I'm pretty sure dealing with a Byte Array is faster than a String in VB.NET

[brew]

Please..... .NET or not, a string IS a byte array. How could it be faster?

[iNsaNe]

Problem solved.

[brew]

Okay, what's the problem? Just incase I get stuck with .net and I encounter this problem too....

[iNsaNe]

Bah nvm, I have run into a stupid problem.

Code Select Expand

0030  ff ff 2b 92 00 00 00 00  00 00 ff 50 35 38 30 30   ..+..... ...P5800
0040  30 30 30 36 38 58 49 50  58 33 57 30 30 30 30 30   00068XIP X3W00000
0050  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   00000000 00000000
0060  30 30 30 55 53 41 00 55  6e 69 74 65 64 20 53 74   000USA.U nited St
0070  61 74 65 73 00                                     ates.

All these 0's are making me cry. They wont go to "00" instead of "30".

EDIT:

Is this right? :

Code Select Expand

    Public Function MakeDWORD(ByVal Value As Integer) As String

        Dim Result() As Byte
        Result = BitConverter.GetBytes(Value)

        Dim i As Integer
        For i = 0 To Result.GetUpperBound(Result(i))

            MakeDWORD = MakeDWORD & Result(i)
        Next i

    End Function

[Sorc.Polgara]

EDIT:  0x30 = 48 = ascii value of the character 0.

I'm guessing it's because your treating them as strings.

[iNsaNe]

EDIT:  0x30 = 48 = ascii value of the character 0.

I'm guessing it's because your treating them as strings.

It's

Code Select Expand

InsertDWORD(ByVal Data as Long)

How can I change these to "00" ... I don't see where I'm treating them as strings. I'm looking at all the codes on this forum and I do not see a difference.

[MyndFyre]

Okay, what's the problem? Just incase I get stuck with .net and I encounter this problem too....

That's because you're wrong:

Please..... .NET or not, a string IS a byte array. How could it be faster?

In .NET, a string is NOT a byte array.  A string is an array of Unicode characters, each of which is two bytes wide.

Not to mention that strings in .NET are immutable.  That means once declared, they cannot be changed.  When you make an assignment like this:

Code Select Expand


// C#
string abc = "abc";
abc = abc + "def";
' VB
Dim abc As String = "abc"
abc = abc & "def"

what actually happens is that a string is allocated in the CLR that says "abc".  That string is, by itself, about 16 bytes (some internal state, a marker to the runtime object type, and then two bytes for length and two bytes per character - .NET strings are stored wide Pascal style).  Then, on the second line, the CLR allocates a string "def" which takes the same amount of space.  And then, the CLR allocates a third string variable of about 22 bytes (7 * 2 bytes for the text + length prefix and 8 bytes for internal state), and that's what the variable abc finally gets the reference to.  The CLR string "abc" and the CLR string "def" are marked for garbage collection at the end of the method's execution because they no longer have outstanding referenced (unless they're used as constants elsewhere in code, in which case they're interned - for more information look up .NET String Internment).

The end result of making lots of allocations like this is that you end up with a LOT of generation 0 garbage collections, resulting in poor performance and high memory usage.  On the other hand, if you use byte arrays, or one idea I'm considering is using a List<byte[]>, or EVEN BETTER is a MemoryStream since that dynamically resizes according to performance research and a logarithic formula which has been shown to be efficient (you'll notice that this is the way that JinxBot's DataBuffer works, designed after spending lots of time in CLR Profiler).

[Sorc.Polgara]

EDIT:  0x30 = 48 = ascii value of the character 0.

I'm guessing it's because your treating them as strings.

It's

Code Select Expand

InsertDWORD(ByVal Data as Long)

How can I change these to "00" ... I don't see where I'm treating them as strings. I'm looking at all the codes on this forum and I do not see a difference.

Well all of the code you've been looking at on the forum has likely been VB6 code and not VB.NET.

And the common VB6 way of adding data to a buffer is by treating everything as a string.

So, your code:

Code Select Expand


Public Function InsertDWORD(ByVal Data As Long)

        strSendData = strSendData & MakeWORD(Data)

End Function


Thus, someone correct me if I'm wrong, the above code is treating the WORD (2 bytes) returned by MakeWORD() as a string because it's typecasting the WORD to a string and concatenating it to variable strSendData, which I'm assuming is a String.  I'm not familiar with .NET, so I could be wrong.

But yeah, stop treating the buffer (strSendData) as a string, and treat it as a byte array.

EDIT:  Why the hell is InsertDWORD() calling MakeWORD()?  I'm assuming that's what was causing this topic's original problem, which you fixed.

[iNsaNe]

That's not my code. I changed it:

Code Select Expand

    Public Function MakeDWORD(ByVal Value As Integer) As String

        Dim Result() As Byte
        Result = BitConverter.GetBytes(Value)

        Dim i As Integer
        For i = 0 To Result.GetUpperBound(Result(i))

            MakeDWORD = MakeDWORD & Result(i)
        Next i

    End Function

And I'm not sure if it has errors or not, but I feel it is working. The only problem is is that when I go to pause, I go to check strSendData (yes its a string), and each array is set to 0. That is why there are so many 0's. I am trying to convert them so they are "." and I can't figure out how.

Code Select Expand

000068XIPX3W000000000000000000000000USA.United States.

[MyndFyre]

Part of the problem is that you're using the concatenate (&) operator.  When you concatenate a number and a string, the number is converted to string.  That's why you're seeing the 0s there.

Allow me to suggest using MBNCSUtil - using the DataReader/DataBuffer or derived classes rather than the VB6 garbage.  VB6 packet handling code simply does not translate to .NET.

That is why there are so many 0's. I am trying to convert them so they are "." and I can't figure out how.

You don't want the literal character ".".  That's what packet capture tools use to represent values that aren't ASCII.