Modified copymemory for pointers

[Barabajagal]

Make a function that loads the files and use it. That's the best way you're gonna get.

[Newby]

This function is completely retarded imho, ante is a lame ass programmer he must smell like dog shiat.  He is a horrible programmer.  I wont even touch on how many bad programming practices are in this function...

You rock.

[Joe[x86]]

Private Declare Sub RtlMoveMemory Lib "kernel32" ( _
    ByRef dest As Any, _
    ByVal src As Any, _
    ByVal length As Long)

Public Sub Main()
    Dim str As String
    Dim byteArray(0 To 19) As Byte 'they're all initially null
    Dim i As Integer
   
    str = "0123456789" ' 30 31 32 33 34 35 36 37 38 39
    Call RtlMoveMemory(byteArray(0), str, 10)
   
    For i = 0 To 19 Step 1
        MsgBox Hex(byteArray(i))
        ' 30 31 32 33 34 35 36 37 38 39
        ' 00 00 00 00 00 00 00 00 00 00
    Next i
   
End Sub

[brew]

x86] link=topic=16610.msg168218#msg168218 date=1177213410]
Private Declare Sub RtlMoveMemory Lib "kernel32" ( _
    ByRef dest As Any, _
    ByVal src As Any, _
    ByVal length As Long)

Public Sub Main()
    Dim str As String
    Dim byteArray(0 To 19) As Byte 'they're all initially null
    Dim i As Integer
   
    str = "0123456789" ' 30 31 32 33 34 35 36 37 38 39
    Call RtlMoveMemory(byteArray(0), str, 10)
   
    For i = 0 To 19 Step 1
        MsgBox Hex(byteArray(i))
        ' 30 31 32 33 34 35 36 37 38 39
        ' 00 00 00 00 00 00 00 00 00 00
    Next i
   
End Sub

No.
VB6 strings are NOT just byte arrays. They are BSTRs which follow this format:
[DWORD](4) String Len [BYTES](String Len * 2)String Here, in unicode [WORD](2) Double null terminator.
EDIT** Way to not read the entire topic
EDIT 2** Decided to correct joe on a few things...
You really want to message box each individual character....
And For... Next loop is by default Step 1.
But I was intrigued by your use of copymemory. "Call RtlMoveMemory(byteArray(0), str, 10)"
When you use the first element of a byte array, VB6 is really smart enough to move the other byte elements into the other arrays? Also you had to define the length of your string on your own, not very handy. Nice though... I guess. Also I was looking to do something with pointers, not just move a string into a byte array. You could easily enough do that using Split(String, vbNullString). And it allocates the array scope automatically. (which is pretty good) And also why did you do "Dim ByteArray(0 To 19) as Byte"? 0 is assumed to always be the base unless otherwise specified (Option Base 1) which is plain retarded, imo. Thanks for your effort, Joe.

[Joe[x86]]

They are not BSTRs. I tested that code and it's output is exactly as intended.

Also, this was only meant as a demonstration. Correct calling to the base of the byte array would be byteArray(LBound(byteArray)).

For defining the length of the string, I didn't really have to do that either. I could have done Len(str).

Using Step 1 is a good coding habit -- it prepares you for stepping up to C++, and makes it easier for your code to be understood by non-VB users. I'll reiterate the demonstration only clause for the repeated MsgBox calls.

Lastly, VB6 is not smart at all, let alone smart enough to position the bytes correctly. That is done by the Win32 API, but doesn't take any smartness on it's behalf. The lowbound of the byte array points to the first byte in memory. A byte array is stored in memory as a pointer to a bunch of bytes, that pointer pointing to the first one. RtlMoveMemory works somewhat like this:

; void RtlMoveMemory(void dest, void src, int length)
; {

    xor esi, esi
_start:
    cmp esi, length
    je _bottom
    inc esi

    lea [dest+esi], [src+esi]

    jmp _start:

_bottom:
: }

EDIT -
If you want a pointer to the string, pass an Integer ByVal in dest. Make sure you specifiy ByVal, though, because if it's passed ByRef it will be returned with the value 0x33323130 (little endian) and the 6 bytes following it will be murdified. Well.. the bytes after it will get owned anyhow, which is why the API is dangerous if you don't know what you're doing.

[brew]

x86] link=topic=16610.msg168254#msg168254 date=1177265059]
They are not BSTRs. I tested that code and it's output is exactly as intended.

VB strings are stored in the BSTR format, always. Possibly VB was smart enough to make the conversion first?

If you want a pointer to the string, pass an Integer ByVal in dest. Make sure you specifiy ByVal, though, because if it's passed ByRef it will be returned with the value 0x33323130 (little endian) and the 6 bytes following it will be murdified. Well.. the bytes after it will get owned anyhow, which is why the API is dangerous if you don't know what you're doing.

Like I said, read the entire topic. You would have seen that I already have gotten that far.

[TheMinistered]

x86] link=topic=16610.msg168254#msg168254 date=1177265059]
They are not BSTRs. I tested that code and it's output is exactly as intended.

Also, this was only meant as a demonstration. Correct calling to the base of the byte array would be byteArray(LBound(byteArray)).

For defining the length of the string, I didn't really have to do that either. I could have done Len(str).

Using Step 1 is a good coding habit -- it prepares you for stepping up to C++, and makes it easier for your code to be understood by non-VB users. I'll reiterate the demonstration only clause for the repeated MsgBox calls.

Lastly, VB6 is not smart at all, let alone smart enough to position the bytes correctly. That is done by the Win32 API, but doesn't take any smartness on it's behalf. The lowbound of the byte array points to the first byte in memory. A byte array is stored in memory as a pointer to a bunch of bytes, that pointer pointing to the first one. RtlMoveMemory works somewhat like this:

; void RtlMoveMemory(void dest, void src, int length)
; {

    xor esi, esi
_start:
    cmp esi, length
    je _bottom
    inc esi

    lea [dest+esi], [src+esi]

    jmp _start:

_bottom:
: }

EDIT -
If you want a pointer to the string, pass an Integer ByVal in dest. Make sure you specifiy ByVal, though, because if it's passed ByRef it will be returned with the value 0x33323130 (little endian) and the 6 bytes following it will be murdified. Well.. the bytes after it will get owned anyhow, which is why the API is dangerous if you don't know what you're doing.

Joe, I didn't even read your whole reply but the first sentence.  You retarded pig dog of a communist mother frackin pile of hot shit, VB6 strings ARE FRACKING BSTRS!!! LOOK AT MSDN YOU FRACKIN WHORE

A BSTR has a Long prepended to it containing the strings length, then a unicode string followed by a null terminator you silly peice of shiat

Further more, you don't "call" a byte array, you should have said correct reading, of the memory, of the base of the byte array... yadda yadda anywho i'm done busting on your ass... but I assume you meant "calling rtlmovememory on a byte array" you should be more clear

[Joe[x86]]

I didn't mean calling as in Call, I meant naming it.

And yeah, I forgot that BSTR has the Int32 before it, not in it. That's a retarded format, by the way.

BreW, you've gotta get it through your head somehow that VB isn't smart enough to do a conversion between Sting and Any for you. Learn about stacks. This is what happened:

; sub Main

str = dword ptr [esp-14]     ; 10 bytes
bytArry = dword ptr [esp-34]   ; 20 bytes

mov [str+0], 30h
mov [str+1], 31h
mov [str+2], 32h
mov [str+3], 33h
mov [str+4], 34h
mov [str+5], 35h
mov [str+6], 36h
mov [str+7], 37h
mov [str+8], 38h
mov [str+9], 39h
; VB: str = "0123456789"

push 10
push str
push bytArry
call RtlMoveMemoryA

xor esi, esi
_loopStart:
    cmp esi, 19
    jge _loopEnd:

    ;VB MsgBox(byteArray(esi))

   jmp _loopStart
_loopEnd:

call GetCurrentProcess
push eax
call TerminateProcess

; end sub

[Newby]

x86] link=topic=16610.msg168293#msg168293 date=1177298458]
BreW, you've gotta get it through your head somehow that VB isn't smart enough to do a conversion between Sting and Any for you. Learn about stacks. This is what happened:

[assembly goes here]

Spewing off random assembly (that probably isn't even completely accurate of what actually occurs) to someone who doesn't understand assembly is not going to help him, smartass.

Where do the concept of a stack and the conversation from "Sting" and "Any" intermix? Maybe explain to him the "stack" and how it would matter to him, a high-level VB programmer.

@ your assembly in the above quoted post: I thought all Windows API calls were pushed in the Pascal convention, and not C-style convention?

@ the assembly in this post:

x86] link=topic=16610.msg168254#msg168254 date=1177265059]
; void RtlMoveMemory(void dest, void src, int length)
; {

    xor esi, esi
_start:
    cmp esi, length
    je _bottom
    inc esi

    lea [dest+esi], [src+esi]

    jmp _start:

_bottom:
: }

Wouldn't it be necessary to increment esi after the lea operation, so as to get src+0 moved over as well? :|

(My assembly is incredibly rusty, so eh.)

[Joe[x86]]

Yeah, good point. That was using a 1-based array.

Spewing off random assembly is a subtle sign that he needs to learn assembly.

The fact that he's using VB doesn't matter. He's calling the C API, and pushing a series of pointers on to the stack. What VB thinks it points to doesn't matter, C++ receives it as a pointer, not a BSTR, CSTR, PSTR, PWSTR, DWORD, LPDWORD, or whatever else you might want to call it.

As far as pascal, nope. Here's the first call I saw when I loaded up a random IDA database (lockdown04::GetVerHash, if anyone cares):
.text:00ED12AD                 push    esi             ; lpData
.text:00ED12AE                 push    edi             ; dwLen
.text:00ED12AF                 push    [ebp+dwHandle]  ; dwHandle
.text:00ED12B5                 lea     eax, [ebp+sFilename]
.text:00ED12BB                 push    eax             ; lptstrFilename
.text:00ED12BC                 call    GetFileVersionInfoW ; C++: (bool)eax = GetFileVersionInfoW(sFilename, dwHandle, edi, esi)

[brew]

x86] link=topic=16610.msg168305#msg168305 date=1177319467]
Yeah, good point. That was using a 1-based array.

Spewing off random assembly is a subtle sign that he needs to learn assembly.

If you say I don't know any C++ at all, then why are you saying I need to learn assembly? That'd be murder. (I'm not too good yet-- The best I could do is probably is manipulate registers so on. Also getting an assembler to assemble my programs so i can learn more wouldn't be a bad idea either. I've tried MASM32, but I don't like it's C syntax. It's either asm or not asm.)

The fact that he's using VB doesn't matter. He's calling the C API, and pushing a series of pointers on to the stack. What VB thinks it points to doesn't matter, C++ receives it as a pointer, not a BSTR, CSTR, PSTR, PWSTR, DWORD, LPDWORD, or whatever else you might want to call it.

Sure it does, but ANY string that vb stores in memory is in UNICODE. this means it stores a word of data for each character. Therefore the length in bytes of "hello world" wouldn't be 11, but instead 22. 28 for the entire length. You're thinking of a byte array.... dammit, sorry to say but GO back to C or what ever you code in. You usually speak down about vb and whatever, but you clearly don't know specifics about the VB language-- This board is for vb specific discussions, therefore it wouldn't be a good idea to go on about some language you obviously don't use much if at all.

[Joe[x86]]

I'm not speaking down about Visual Basic. Replace each instance of VB with C# in there and I'd say it again. Your compiler is not intelligent, it relies on you to be intelligent. For example try this:

Private Declare Sub RtlMoveMemory Lib "kernel32" (Void as Any) ' This obviously won't work

Public Sub Main()
    Call RtlMoveMemory("ngrplz")
End Sub

It'll get past your compiler no problem, but when you try running it your world comes crashing to reality.

[l2k-Shadow]

x86] link=topic=16610.msg168316#msg168316 date=1177365079]
I'm not speaking down about Visual Basic. Replace each instance of VB with C# in there and I'd say it again. Your compiler is not intelligent, it relies on you to be intelligent. For example try this:

Private Declare Sub RtlMoveMemory Lib "kernel32" (Void as Any) ' This obviously won't work

Public Sub Main()
    Call RtlMoveMemory("ngrplz")
End Sub

It'll get past your compiler no problem, but when you try running it your world comes crashing to reality.

how the fuck can the compiler know that you're not passing the correct amount of variables to a function located outside the program defined by the user?

The same would happen in C++ if the function wasn't defined in windows.h

[brew]

how the fuck can the compiler know that you're not passing the correct amount of variables to a function located outside the program defined by the user?
The same would happen in C++ if the function wasn't defined in windows.h

hahaha so true
and joe why do you keep using instead of

Code Select Expand

thats so annoying

[Joe[x86]]

how the fuck can the compiler know that you're not passing the correct amount of variables to a function located outside the program defined by the user?

The same would happen in C++ if the function wasn't defined in windows.h

I hope you know that you just reiterated exactly what I said.