Reading a file - Dynamic size

[skywalker]

A better solution to check and see if a file exists on the hard drive would be:

Code Select Expand


   EAX = 0  ( file doesn't exist )
   EAX = 1  ( file does exist )

DoesFileExist PROC PUBLIC FileSpec: dword
    LOCAL  findInfo : WIN32_FIND_DATA <>
   
    ; check to see if the file exist on the hard drive by simple using a single API call.
    invoke FindFirstFile, [FileSpec], addr [findInfo]
   
    ; check to return value of FindFirstFile.  If the value is INVALID_HANDLE_VALUE,
    ; the file didn't exist, otherwise it did.
    cmp eax, INVALID_HANDLE_VALUE
    je NotFound

My Win32.hlp isn't showing INVALID_HANDLE_VALUE in dwFileAttributes.
Is that something new that's been added?

Could you give me an example of this.

Thanks.

[hutch--]

The technique works fine without having to open the file but you have a notation mistake of using square brackets around named variables that is incorrect in MASM.


invoke FindFirstFile, [FileSpec], addr [findInfo]


Should be,


invoke FindFirstFile,FileSpec, addr findInfo


MASM simply ignores the mistake but it can lead to other mistakes by not using the named variable addressing mode correctly.

In MASM a named variable in this context is something like,


varname equ <[ebp+8]>


Adding the extra brackets effectively gives you [[ebp+8]] which MASM ignores.

[Relvinian]

Skywalker,

That's because the WIN32.HLP file isnt always updated like the platform SDK (or online help from Microsoft).

Here's what the platform SDK says about FindFirstFile:

Code Select Expand


Return Values
If the function succeeds, the return value is a search handle used in a subsequent call to FindNextFile or FindClose.

If the function fails, the return value is INVALID_HANDLE_VALUE. To get extended error information, call GetLastError.


Relvinian

[Relvinian]

The technique works fine without having to open the file but you have a notation mistake of using square brackets around named variables that is incorrect in MASM.


invoke FindFirstFile, [FileSpec], addr [findInfo]


Should be,


invoke FindFirstFile,FileSpec, addr findInfo


MASM simply ignores the mistake but it can lead to other mistakes by not using the named variable addressing mode correctly.

In MASM a named variable in this context is something like,


varname equ <[ebp+8]>


Adding the extra brackets effectively gives you [[ebp+8]] which MASM ignores.

MASM may not care about the brackets and can ignore them but when you look at the op-code output of what MASM generates, putting brackets around variables names becomes a personal preference choice (and in some assemblers, necessary). This was already mentiioned by me in this thread near the beginning when I first wrote that example.

Relvinian

[Relvinian]

Thankyou before I have a look (currently at school) at the masm32.lib I will tell you my parsing routines. Ok I want to check if a file exists,  I have already done that in my code using 'createfile' with 'getlasterror'. However when I read in the text file it reads in names of files (which is what I want it to do), now with this I want to use it to check if the files exist (the filenames read in from my initial txt file). I am really stumped on this. But trying to use some logic could I use findfirstfile and findnextfile, and then when it has found all the files I could compare it against a text file that lists the filenames to see if it matches? A bit of a long shot but I want to prove I am trying myself not just asking endless questions without first trying it myself. Thanks again.

Nilrem,

Here's some psuedo logic to help you with the logic of parsing and accomplishing what you wanted to do.

Open text file which has contents of filenames to check and see if they exist
read the text file into memory
close text file
while not end of buffer
   read line of text
   check to see if that file exist with FindFirstFile/FindClose
   do something with check result
   loop back to while loop
free memory (if dynamically allocated)

Now, with something like this, it is easier to grasp what the goal is. Always take a task and break it down as much as possible. Even with what I provided, you can take it and break each one down a little farther to get more details. Once you have it broken down into the smallest tasks, it will be easy to write the code behind it to accomplish the main task.

Relvinian

[Nilrem]

Thankyou for the reply. If I have problems I'll post again, but it might not be soon because I am fairly busy.