Assembles fine but wants to send MS an error report when I run it.
; wri_prof.asm Add a section in win.ini
.486
.model flat, stdcall ; 32 bit memory model
option casemap :none ; case sensitive
include \masm32\include\windows.inc
include \masm32\include\masm32.inc
include \masm32\include\gdi32.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\Comctl32.inc
include \masm32\include\comdlg32.inc
include \masm32\include\shell32.inc
include \masm32\include\oleaut32.inc
include \masm32\macros\macros.asm
includelib \masm32\lib\masm32.lib
includelib \masm32\lib\gdi32.lib
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\Comctl32.lib
includelib \masm32\lib\comdlg32.lib
includelib \masm32\lib\shell32.lib
includelib \masm32\lib\oleaut32.lib
.data
; Section I'm trying to put in win.ini
name BYTE "data", 0 ; [data]
key BYTE "weights",0 ; weights=45
value BYTE "45",0
.code
start:
main proc
; section name - pointer to key name- pointer to string
invoke WriteProfileString, "name", offset key, offset value
invoke ExitProcess,0
main endp
end start
[code\]
As far as I know you cannot use quoted text directly in an invoke statement in MASM, you have to use a macro CSTR() or something. GoAsm allows this and that is why you will find it in some of my example code but GoAsm has a much more powerful invoke statement than MASM does.
skywalker,
you should use a macro if you
want to do things like that.
here is one.
txt MACRO Text:VARARG
LOCAL dbText
.DATA
dbText BYTE Text,0
.CODE
ExitM < offset dbText >
ENDM
I use the one shown above, callled txt but you
can callit what ever you like.
some call it chr$, while others call it CSTR for me
txt is just 3 char's to type, yeah I am lazy. LOL
Zcoder....
...if you change "name" to OFFSET name it should work. :toothy
Andy,
invoke WriteProfileString, "name", offset key, offset value
Change this to,
fn WriteProfileString, "name", ADDR key, ADDR value
Any you can use the quoted text directly. "fn" is one of the masm32 macros.
Quote from: Mark Jones on March 07, 2006, 01:58:16 AM
...if you change "name" to OFFSET name it should work. :toothy
Afraid it didn't work, but Hutch's method did.
At some point I would like to learn how to bury it in the win.ini or whatever file I want it in.
Lot of things to consider for that to work.
I would have to search for some known section in the middle somewhere and make room for it
before writing the file.
Without Text macros it looks like this.
invoke WriteProfileString, addr szSection, addr szKey, addr szLine
Just an observation, maybe you should study the API you are using a bit more and understand the affects it has across OSes.
You could avoid a lot more debugging and/or asking for debugging help. At this stage of your skill and learning you should be to understanding more of the syntax and it's usage. And avoid making simple syntax mistakes.
Regards, P1 :8)
Quote from: P1 on March 07, 2006, 05:19:27 PM
Without Text macros it looks like this.
invoke WriteProfileString, addr szSection, addr szKey, addr szLine
Just an observation, maybe you should study the API you are using a bit more and understand the affects it has across OSes.
You could avoid a lot more debugging and/or asking for debugging help. At this stage of your skill and learning you should be to understanding more of the syntax and it's usage. And avoid making simple syntax mistakes.
Regards, P1 :8)
This is what I was going by.
I studied some other code when I came up with what I had.
Now I know that pointer means ADDR.
Then when macros are thrown in, it becomes a little confusing too.
My API reference is the first thing I look to see if there's already some built in function, etc.
LPCTSTR lpAppName, // pointer to section name
LPCTSTR lpKeyName, // pointer to key name
LPCTSTR lpString, // pointer to string to add
LPCTSTR lpFileName // pointer to initialization filename
Quote from: hutch-- on March 07, 2006, 02:10:04 AM
Andy,
invoke WriteProfileString, "name", offset key, offset value
Change this to,
fn WriteProfileString, "name", ADDR key, ADDR value
Any you can use the quoted text directly. "fn" is one of the masm32 macros.
Your code fixed it so it stores to win.ini but for some reason it only works with SP1 and not SP2.
That might be to prevent mal-ware from hijacking your win.ini under the "run" section... just a quess. WIN.ini is pretty useless in XP anyways. You could always put a NOP in the code before that line, load it in OllyDbg, press Ctrl-F,NOP,Enter,F2,F9, then F8 to step over the call. Then you can see on the right, the LastErr line change red if there is an error. This is the error condition windows reported for that function.
Quote from: Mark Jones on March 07, 2006, 08:27:35 PM
That might be to prevent mal-ware from hijacking your win.ini under the "run" section... just a quess. WIN.ini is pretty useless in XP anyways. You could always put a NOP in the code before that line, load it in OllyDbg, press Ctrl-F,NOP,Enter,F2,F9, then F8 to step over the call. Then you can see on the right, the LastErr line change red if there is an error. This is the error condition windows reported for that function.
There was no error showing on LastErr when I traced thru it. I actually put the NOP in the code before compiling.
Do they still use Int1 and 3's anymore ?
Int 3's will definately cause an execution error, and if OllyDbg is set as the JIT debugger then you can open the app that way, but my experience is that it's then unstable and cannot be traced... hence just use the NOP instead and retain the ability to step through the code. :P
This may be confusing but you do not put the int 3 into the code, OllyDebug does. It is a type of breakpoint.
From OllyDebug Help:
QuoteOrdinary breakpoint, where the first byte of the command you want to break on is replaced by a special command INT3
Sorry for any confusion, just be careful.
Paul
Quote from: PBrennick on March 08, 2006, 06:20:55 PM
This may be confusing but you do not put the int 3 into the code, OllyDebug does. It is a type of breakpoint.
Actually the way I usually use OllyDbg is to insert an Int 3 into my program just before the code I am having trouble with, assemble the program, load the program from within OllyDbg, then press the Run button, my program stops right at the Int 3, I step thru my program to find the bug/feature that I wish to observe.
hth,
farrier
Quote from: farrier on March 08, 2006, 06:40:40 PM
Quote from: PBrennick on March 08, 2006, 06:20:55 PM
This may be confusing but you do not put the int 3 into the code, OllyDebug does. It is a type of breakpoint.
Actually the way I usually use OllyDbg is to insert an Int 3 into my program just before the code I am having trouble with, assemble the program, load the program from within OllyDbg, then press the Run button, my program stops right at the Int 3, I step thru my program to find the bug/feature that I wish to observe.
hth,
farrier
It's good to know that int3s still work just like in 16bit code using debug.
I am still fairly new using Ollydbg. I am used to Tasm debugger where you can go instruction by instruction or go to the cursor.
Andy
Quote from: skywalker on March 08, 2006, 09:42:43 PMI am still fairly new using Ollydbg. I am used to Tasm debugger where you can go instruction by instruction or go to the cursor.
You can get that, if you debug in Visual Studio. I used the free Learning C edition.
Regards, P1 :8)
Quote from: P1 on March 08, 2006, 09:56:04 PM
Quote from: skywalker on March 08, 2006, 09:42:43 PMI am still fairly new using Ollydbg. I am used to Tasm debugger where you can go instruction by instruction or go to the cursor.
You can get that, if you debug in Visual Studio. I used the free Learning C edition.
Regards, P1 :8)
Is this what you are referring to?
It's a new language to me. C#
The Visual C# compiler to turn your programs into running applications. This is available as part of the .NET Framework SDK (a free download)