Ive got an annoying problem, I cant append any text to the text file. Every time I open it for writing, I overwrite the data. I tried to move the file pointer to the end of the file, but no result (no writing to the file at all).
Here is the code:
INVOKE CreateFile, offset filePath, GENERIC_WRITE, FILE_SHARE_WRITE, 0, OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,0
mov hFile, eax
mov edx, 10
INVOKE SetFilePointer, hFile, 0, 0, FILE_END
INVOKE WriteFile, hFile, offset buffer, edx, ADDR SizeReadWrite, NULL
INVOKE CloseHandle, hFile
Any ideas? Thank you in advance!
You're setting the value of edx before the call to SetFilePointer and using it after the call. However, Windows API functions use the stdcall calling convention which is not guaranteed to preserve the edx register, so the value in it is destroyed, and the call to WriteFile fails.
Related
I've spend lot of time trying to solve this problem and I don't understand, why it doesn't work. Problem's description is in comments below:
.386
.MODEL FLAT, STDCALL
OPTION CASEMAP:NONE
.NOLIST
.NOCREF
INCLUDE \masm32\include\windows.inc
.LIST
.CODE
DllEntry PROC hInstDLL:HINSTANCE, reason:DWORD, reserved1:DWORD
mov eax, TRUE
ret
DllEntry ENDP
caesarAsm proc string: DWORD, key: DWORD, stringLength : DWORD
mov esi, 1 ; I cannot use this register, mov esi, (anything) causes Crash:
; Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention
mov eax, string
ret
caesarAsm endp
END DllEntry
I searched "whole" Internet, I found that the problem is connected with stack, but no operation on stacks helped me to solve it.
I'm using Microsoft Visual Studio 2012
I assume the error does not occur in this function, rather, it is triggered elsewhere. The esi register is a callee-saved register. You must make sure its value is the same at function exit as it was at entry. You can use it in your function, but you must save and restore its value. Such as:
push esi
mov esi, 1
mov eax, string
pop esi
ret
This is all well documented. You may only use eax, ecx and edx without saving.
Side note: you are using high-level features of your assembler, you might want to check the actual generated code or refrain from using them until you are confident in what the result is going to be. Incidentally masm has a USES keyword which would do the save/restore for you.
I have been only programming in assembly for 2 weeks now so I am kind of new to assembly and I need some help.
I need to watch a directory and all sub directories for changes. The only changes I need to be notified of are file creation and when a file is edited, but if you include others that is fine.
I need to be notified of the file who made the changes to a message box. I do not need to know what change the file made, I just need the file path to a message box. I tried to search the web but cant find anything for how to do this in assembly particular masm.The only stuff I could find was this code that I think was written for masm and I tried it but it message boxes A or other letters and that is it and it blocks me from changing the name of any file in that directory, and i do not want it to do that.
.data
FolderPath3 db "C:\users",0
.data ?
hFile dd ?
FileBuffer DB 200 DUP(?)
ThreadProc PROC uses edi esi Param:DWORD
LOCAL lpBytesReturned:dword
invoke CreateFile,addr FolderPath3,GENERIC_READ,FILE_SHARE_DELETE or FILE_SHARE_READ,0,\
OPEN_EXISTING,FILE_FLAG_BACKUP_SEMANTICS,0
mov hFile,eax
invoke ReadDirectoryChangesW,hFile,addr FileBuffer,sizeof FileBuffer,TRUE,FILE_NOTIFY_CHANGE_LAST_ACCESS,\
addr lpBytesReturned,0,0
.if eax==0
invoke MessageBoxA,0,0,0,MB_OK
.else
xor ecx,ecx
##:
add edi,ecx
lea edi,FileBuffer
mov esi,[edi].FILE_NOTIFY_INFORMATION.Action
.if esi==FILE_ACTION_MODIFIED
invoke MessageBoxA, NULL, addr [edi].FILE_NOTIFY_INFORMATION.FileName, offset BoxCaption, NULL
.elseif esi==0
invoke CloseHandle,hDir
ret
.endif
mov ecx,[edi].FILE_NOTIFY_INFORMATION.NextEntryOffset
.if ecx==0
invoke RtlZeroMemory,addr FileBuffer,sizeof FileBuffer
jmp ThreadProc
.endif
jmp #B
.endif
ret
ThreadProc ENDP
if anyone can fix the above code or show me different code that works it would be great,
thank you
The essence of the task is the operating system specific services and handling the notifications.
If you are lost doing this in assembly, code it in a high level language (C, C++, Perl, etc.) and get that working. It should not be hard to find examples of doing just this from MSDN. Once you have learned how to do that, it will then be pretty clear what the assembly language has to do.
I'm new to windows programming and started working on a text game a few months ago. I decided to rewrite the WM_PAINT section of my code, I normally had the entire client area continually redrawn but thought I'd try redrawing specific regions instead to reduce flicker. I noticed in one specific section of my code, InvalidateRect/UpdateWindow doesn't seem to want to work, but if I replace the 2 functions with RedrawWindow, it displays perfectly. Should there be an instance where InvalidateRect/UpdateWindow fails to work but RedrawWindow works fine in it's place?
Would there be any drawbacks to just replace all InvalidateRect/UpdateWindow calls in my code with RedrawWindow?
Thanks for an info!
.if uMsg==WM_PAINT
invoke BeginPaint,hWnd,ADDR ps
mov hdc,eax
.if (PAINT_DMGMSG>0) ;contains ->to a char's DMGMSG
invoke CreateFont,16,12,0,0,400,0,0,0,OEM_CHARSET,OUT_DEFAULT_PRECIS,CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,DEFAULT_PITCH,NULL
invoke SelectObject,hdc,eax
mov hfont,eax
invoke SetTextColor,hdc,COLOR_SNOWWHITE
mov esi,TS_MSG2
mov edi,TS_MSG1
mov ecx,len(TS_MSG2)
rep movsb
mov BYTE ptr [edi],0
mov esi,TS_MSG3
mov edi,TS_MSG2
mov ecx,len(TS_MSG3)
rep movsb
mov BYTE ptr [edi],0
mov esi,PAINT_DMGMSG
mov edi,TS_MSG3
mov ecx,len(esi)
rep movsb
mov BYTE ptr [edi],0
invoke TextOut,hdc,0,500,TS_MSG1,len(TS_MSG1)
invoke TextOut,hdc,0,518,TS_MSG2,len(TS_MSG2)
invoke TextOut,hdc,0,536,TS_MSG3,len(TS_MSG3)
mov PAINT_DMGMSG,0
.endif
invoke EndPaint,hWnd,ADDR ps
.elseif uMsg==WM_CHAR ;used to handle keyboard input
push wParam
pop char
.if(SDWORD ptr [ebx+OFFSET_ALLEGIANCE]<0)&&(DWORD ptr [ebx+OFFSET_STATUS]!=STAT_DEAD)
invoke Combat,[esi+12],ebx
mov ebx,[edi+4]
mov eax,[human.color]
mov [ebx+OFFSET_CHARCOLOR],eax
mov ebx,pChar
mov ebx,[ebx+OFFSET_MOBMEM]
.if (DWORD ptr [ebx+OFFSET_MOBMEM_DMGMSG]>0)
mov ebx,[ebx+OFFSET_MOBMEM_DMGMSG]
mov XYrc.left,0
mov XYrc.top,500
push wWin
pop XYrc.right
mov XYrc.bottom,560 ;+font height
mov PAINT_DMGMSG,ebx
; invoke InvalidateRect,hWnd,ADDR XYrc,TRUE
; invoke UpdateWindow,hWnd
invoke RedrawWindow,hWnd,ADDR XYrc,NULL,NULL ;<- WORKS FINE!
.endif
.endif
Assuming you use 0 as the last argument for the RedrawWindow() (as you do), there indeed is one important difference:
UpdateWindow() sends WM_PAINT immediately, before the function returns.
RedrawWindow() (unless flag RDW_UPDATENOW is used) just places WM_PAINT into the message queue so the painting actually happens later.
This can make difference, if you invalidate the rectangle, but change the window state then after. In case (1), the control is painted using the "old" data, but (2) "works".
If your issue is caused by this difference, you may try to use InvalidateRect() only (do not call UpdateWindow(), nor RedrawWindow(). The rect invalidation will cause then WM_PAINT will come when the queue has no other event in it. (Originally UpdateWindow() prevented that as the immediate WM_PAINT validates the window as a side effect of the painting).
OK, I'm new to PC Assembler. I"m trying to write an program, but it won't stop looping. I'm guessing the ECX register is being modified? How can I fix this? Thanks.
DATA SECTION
;
KEEP DD 0 ;temporary place to keep things
;
CODE SECTION
;
START:
MOV ECX,12
TOPOFLOOP:
PUSH -11 ;STD_OUTPUT_HANDLE
CALL GetStdHandle ;get, in eax, handle to active screen buffer
PUSH 0,ADDR KEEP ;KEEP receives output from API
PUSH 5,'bruce' ;5=length of string
PUSH EAX ;handle to active screen buffer
CALL WriteFile
XOR EAX,EAX ;return eax=0 as preferred by Windows
LOOP TOPOFLOOP
ENDLABEL:
RET
In most x86 calling convention, including the stdcall convention used by Windows API functions, ECX is a caller-save register -- the called function is not required to make sure the value of the register is the same when it returns as when it was called. You have to save it somewhere safe in your own code.
I need to access the WinMain parameters using assembly, but I don't seem to be able to do so despite that I supposedly know where they are in the stack (DWORD offsets 0 to 16, and 0 to 20 when pushing EBP before operations). Below there's an example for showing the lpszCmdline string which contains the command line of the program, but it always seems to contain 0, so nothing is displayed. If I try to use other arguments in the assembly code, no valid string pointer seems to be present and/or the program crashes, as expected.
;[esp+20]==nCmdShow
;[esp+16]==lpszCmdLine
;[esp+12]==0 in win32
;[esp+8]==hInst
;[esp+4]==EIP
;[esp+0]==EBP
push ebp
mov ebp,esp
mov eax,[ebp+16]
push dword 0x00001030 ;UINT uType
push eax ;LPCTSTR lpCaption
push eax ;LPCTSTR lpText
push dword 0 ;HWND hWnd
call dword[MessageBoxA#USER32.DLL]
pop ebp
However, if I use GetCommandLine I can get a valid pointer to the command line string, and it displays.
call dword[GetCommandLineA#KERNEL32.DLL]
push dword 0x00001030 ;UINT uType
push eax ;LPCTSTR lpCaption
push eax ;LPCTSTR lpText
push dword 0 ;HWND hWnd
call dword[MessageBoxA#USER32.DLL]
Where's the error in the first code block? What do I need to get the parameters, and being able to implement my own code to return a valid pointer to lpszCmdLine just like GetCommandLine and as a result, to the other WinMain parameters? If I can't get the command line pointer from the stack, then I presumably won't be able to get the other parameters, like nCmdShow, for other important initializations.
Please let me know if you need more code than the provided above. If it is useful for you to know, I used no linker but fully manual EXE generation (does it make any difference in WinMain, like further stack parameters?), but basically it's just a program for which Windows automatically calls its entry point and the above would be the 2 different options of what program it would contain.
#include <Windows.h>
int CALLBACK WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow ) {
__asm {
mov eax, [ebp+16]
push 0
push eax
push eax
push 0
call dword ptr ds:[MessageBoxA]
}
return ERROR_SUCCESS;
}
This runs just fine for me within Visual Studio. Oddly running it in a debugger and single stepping causes an access violation when the MessageBox is called. I'm unsure why this is, but running in debug without single stepping as well as running the final binary gives the expected result, ie. a messagebox with caption/message as the argument