Function keeps returning -1, can anybody tell me what is wrong with my code?

Started by David, January 16, 2010, 03:43:04 PM

Previous topic - Next topic

David

Hi, my function keeps returning -1.  I am using GetPrivateProfileInt (http://msdn.microsoft.com/en-us/library/ms724345%28VS.85%29.aspx).  Yes, the function is 16bit, but I am using it in a 32bit compiler.  It should be working.  I got the idea from one of Iczelion's tuts. (32bit)

Here is my directory:
test\test.asm
test\win.ini ; <---------- This is my ini file that I am trying to fetch data from.
test\test.obj
test\test.exe
test\assemble.bat

Here is what my ini file looks like:

[fetch]
value=1


Here is my code (it compiles, it just returns -1 meaning it didn't work... I am not sure why it did not work.)

.386
.model flat, stdcall
option casemap:none

include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib

.DATA
lpAppName   db "fetch", 0
lpKeyName   db "value", 0
lpFileName  db "\win.ini", 0  ;same path of my executable

.CODE
start:
   ;GetPrivateProfileInt(LPCSTR lpAppName, LPCSTR lpKeyName, INT nDefault, LPCSTR lpFileName);
    push offset lpFileName          ;My file is in the same folder as my executable
    push -1                                  ;This is my default return value if the function fails, it is returning this... the only problem is I do not know why it is returning this?  Can you point out something in my ;code
    push offset lpKeyName         ;The name of the key to fetch the value from.  In my file: value=1 I want to fetch the value of value (1)
    push offset lpAppName         ;The name of the section in the initialization file.   [fetch]
    call GetPrivateProfileInt

cmp eax, -1
je @bad

push 1000
push 1000
call Beep

@bad:
push 0
call ExitProcess

end start

dedndave

"win.ini" is a standard windows file name
just for testing, i might try a different name
windows may, by default, locate the win.ini file in the c:\windows folder
another way to go would be to specify the full path in the filename

EDIT - oh - i see you have specified "\win.ini" - that will look in the root directory of the current drive for the win.ini file
take the "\" out

David

Thanks for responding, changed the files name and removed the "\".  However, it is still returning -1  :(

dedndave

David
give me a few minutes
i will assemble it and see if i can make it play the right tune   :bg

dedndave

QuoteThe name of the initialization file. If this parameter does not contain a
full path to the file, the system searches for the file in the Windows directory.

it appears you either have to provide a full path, or place the ini file in the windows folder
you could build the path string by getting the current folder or the folder of the executable that is running (best way)

GetCurrentDirectory
http://msdn.microsoft.com/en-us/library/aa364934(VS.85).aspx

then, just tack the filename onto the end of the path string

donkey

Hi David,

First off GetPrivateProfileInt is a 32 bit function, it was provide for source level compatibility with 16 bit Windows not binary level. I would choose a different name that win.ini for your file, it is a Windows file and might cause some confusion. Finally, INI files are only really supported through virtualization in Vista and above if you keep them with your application in the Program Files folder so you might think about storing it in %AppData%, after all its going to be copied there whether you like it or not. To find the %AppData% folder you can use ExpandEnvironmentStrings. This will give you a folder with enough permission to be able to modify you INI file under Windows 7 without elevation. Unless you have a really good reason for using INI files, usually to allow the user to edit it directly, you should think about using the registry to store program related data, it will help to ensure compatibility as INI files and access to them are slowly being squeezed out of existence.
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

jj2007

Quote from: donkey on January 17, 2010, 09:41:35 AMUnless you have a really good reason for using INI files, usually to allow the user to edit it directly, you should think about using the registry to store program related data, it will help to ensure compatibility as INI files and access to them are slowly being squeezed out of existence.

ini files are plain text files in a very simple format. Even if GetPrivateXX were to disappear one day, nobody can stop a moderately gifted coder to waste a few 100 bytes to rewrite the functionality. Apps are reading and writing text files all the time, often in the folder where the executable sits. The registry may have been a good idea in the early days of Windows, but nowadays it's just a big pile of obscure junk that hangs around in memory for no good reason.

EDIT: Just saw that Hutch blows into the same horn ;-)

evlncrn8

if i remember right you have to make up the path - ie: getmodulefilename then append the \win.ini onto that string and use that as the filename for getprivateprofileint... should work fine then... \win.ini won't work and (to the best of my memory) .\win.ini won't work (and it definately won't work if someone sets the working directory of your program to some place where the exe (and ini files etc) isn't located..