BYTE PTR [parameter] / SMTP suggestions

[Gabbadar]

Hello! I've been around before, with only a few posts under my belt. I'm back, and hopefully yous can teach me something new again.

Below is my procedure. Essentially, what I'm having trouble with is null terminating a string via it's pointer. As you can see Line 2 works, but I'm trying to get rid of the need to use the extra register just to hold a string pointer that's already a parameter. Is this possible? I assume Line 1 doesn't work because pszsendBuf is equal to the value at EBP+8 - which is the string pointer, and I logically follow it down to wanting to use the value at the value at EBP+8, or [[EBP+8]], which doesn't work.. or am I a very confused person?

Second, this is from an SMTP DLL for use in a VB project. It works great until I try sending a message which exceeds the maximum message chunk size allowed by SMTP standards (my error log, for exampls  :lol ). What I've decided to do is break the transmission up into 512 byte chunks if the message exceeds 512 bytes. I'm curious to know if creating a local variable 512 bytes in size for a string is bad practice, or if you'd have any suggestions for a better way of going about this. Also, since I'd eventually like to allow attachments with this thing, wouldn't using lstrlen be a bad thing because 0's will likely be in the attachment data. Has anyone got any better suggestions? I scrapped this thing together and it worked great until I wanted more out of it..

Code Select Expand


Winsock_Send PROC
pszsendBuf equ [EBP + 8] ; String Pointer to sendBuf

push EBP
mov EBP,ESP
sub ESP, 512

push ESI

mov ESI, pszsendBuf

; C equivalent: send( m_socket, sendbuf, strlen(sendbuf), 0 );
invoke lstrlen, pszsendBuf ; Get length of data to send

invoke send, m_socket, pszsendBuf, EAX, 0

; Null terminate the send buffer NOT WORKING
mov BYTE PTR [pszsendBuf], 0 ; Line 1: Not working
mov BYTE PTR [ESI],0 ; Line 2: Works..

Exit_Function:
pop ESI

leave
ret 4

Winsock_Send endp


[Tedd]

What you intend by [[ebp+8]] is not allowed. It's just not a valid instruction, so the cpu will not do it, no matter how nicely you ask :bdg
So yeah, you have to do it the 'long' way. You only get one level of indirection :wink

I wouldn't recommend allocating much over 256 bytes on the stack, though in most cases (not recursion!) it will work okay. You can allocate a big chunk of memory with either GlobalAlloc or HeapAlloc (your preference) and use that. Although, a more efficient way would be to forget copying to the buffer and send the chunks right out of the data at pszsendBuf - just add the offset each time, and off you go (stopping when you've sent the required number of bytes.)
To avoid problems with finding the length of a message, it would make more sense for the caller of Winsock_Send to provide the length of the data to be sent (i.e. another parameter) since it would most likely be known at this point. Saying that, lstrlen shouldn't be a problem with attachments as they should actually be mime-encoded first, so there won't be any zeroes in the message anyway. (I'd still pass-in the length of message to be sent in any case :wink)

[Gabbadar]

Of course, allocate memory!

But yeah, that's an even better idea to add an argument and send size based on that. I can just loop the function then until remaining string size is = 0.

Awesome, thanks!