im having a problem using an inistring inside a thread... if i hardcode the location of the exe name it works fine in the thread
notepad db "c:\windows\notepad.exe",0
.. but if i pull the exename from out of an ini file and try to winexec it , it doesnt work ,,, am i missing something? does the szPath db 64 dup(?) screw it up?
notepad db "c:\windows\notepad.exe",0
.. but if i pull the exename from out of an ini file and try to winexec it , it doesnt work ,,, am i missing something? does the szPath db 64 dup(?) screw it up?
.data
notepad db "c:\windows\notepad.exe",0
keyP db "Path",0
ini db ".\ad.ini",0
.data?
szPath db 64 dup(?)
; contents of .ini file
;[install]
;Path=c:\windows\notepad.exe
Init proc
LOCAL id:DWORD
INVOKE CreateThread, 0, 0, Thread, 0, 0, ADDR id
mov hThread, eax
.IF eax != 0
mov fRunning, 1
mov eax, 1
.ENDIF
ret
Init endp
;;;;;;;;;;;;;;;;;;;;;;;;;;;this thread works because the path to the exe is hardcoded;;;;;;;;;;;;;;;;;;;;;;;
;Thread proc param:DWORD
; invoke WinExec, addr notepad, SW_SHOW
; ret
;Thread endp
;;;;;;;;;;;;;;;;;;;;;;;;;;;this thread doesnt work;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Thread proc param:DWORD
invoke GetPrivateProfileString, ADDR inihead, ADDR keyP, ADDR nostring, ADDR szPath,64, ADDR ini
invoke WinExec, addr szPath, SW_SHOW
ret
Thread endp
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
if i use the code normally outside of a thread like this example it works fine
.386
.model flat, stdcall
option casemap :none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\masm32.inc
include \masm32\include\user32.inc
include \masm32\include\advapi32.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\masm32.lib
includelib \masm32\lib\advapi32.lib
includelib \masm32\lib\user32.lib
.data
inihead db "install",0
keyP db "Path",0
ini db ".\ad.ini",0
nostring db "N/A",0
.data?
szPath db 64 dup(?)
.code
start:
invoke GetPrivateProfileString, ADDR inihead, ADDR keyP, ADDR nostring, ADDR szPath,64, ADDR ini
Invoke MessageBox,0,addr szPath,0,0
invoke WinExec, addr szPath, SW_SHOW
invoke ExitProcess,0
end start
you might try, GetLastError() for more detail on that the error is.
try to check what the GetPrivateProfileString returns inside the thread... if it is a normal string just like C:\windows\notepad.exe then it should work....
replace the WinExec call inside the thread by a MessageBox...
greeting to ill bill, by the way :)
Dominik
replace the WinExec call inside the thread by a MessageBox...
greeting to ill bill, by the way :)
Dominik
thought it might be a global variable problem
weird though the msgbox doesnt show szpath2... the thread is started from Service Control Manager so this app gets started as a service...i even checked marked 'Allow service to interact with deksopt' to show the msgbox but its empty .. if i hardcode szPath2 to szPath2 db "c:\windows\notepad.exe",0 .. everything works perfect.. why is this thread and ini giving me a problem ... the same proc works in the other ini example and the other ini keynames are getting picked up fine
weird though the msgbox doesnt show szpath2... the thread is started from Service Control Manager so this app gets started as a service...i even checked marked 'Allow service to interact with deksopt' to show the msgbox but its empty .. if i hardcode szPath2 to szPath2 db "c:\windows\notepad.exe",0 .. everything works perfect.. why is this thread and ini giving me a problem ... the same proc works in the other ini example and the other ini keynames are getting picked up fine
Thread proc param:DWORD
LOCAL szPath2[256]:BYTE
invoke GetPrivateProfileString, ADDR inihead, ADDR keyP,0, ADDR szPath2,64, ADDR ini
invoke WinExec, offset szPath2, SW_SHOW
invoke MessageBox,0,addr szPath2,addr szPath,0
ret
Thread endp
This is my code. It run well on my computer.
Regards,
.data
notepad db "c:\windows\notepad.exe",0
keyP db "Path",0
ini db ".\ad.ini",0
inihead db "install",0
nostring db 0
.data?
szPath db 64 dup(?)
.code
ThreadProc proc param:DWORD
invoke GetPrivateProfileString, ADDR inihead, ADDR keyP, ADDR nostring, ADDR szPath, sizeof szPath, ADDR ini
invoke WinExec, addr szPath, SW_SHOW
ret
ThreadProc endp
Main proc
LOCAL id:DWORD
invoke CreateThread, 0, 0, ThreadProc, 0, 0, ADDR id
invoke WaitForSingleObject, eax, INFINITE
ret
Main endp
start:
invoke Main
invoke ExitProcess,0
end start
Regards,
If your first (main) thread executes ExitProcess before the second thread gets a chance to call WinExec, then you get the observed results. Retrieving data from a disk file (like your INI) can cause enough delay for this possibility. The OS can switch back to your first thread while it waits for the disk access to finish. Notice that TQN uses a synchronizing function, WaitForSingleObject, to prevent premature termination of the program.
i figured it out .. my app starts as a service so i need to get the full path of the ini file in order for it to work.. i guess when it starts as a service it automatically makes your current directory system32.. so if the ini is in another foler it doesnt work