FileSystem functions

Started by Shantanu Gadgil, September 16, 2006, 08:17:32 AM

Previous topic - Next topic

Shantanu Gadgil

Hello,
Some file/directory/volume related functions.

Can also be "string functions" but they are primararily to do with file/directory names, so called "FileSystem" functions.

FS_AddTrailingBackSlash
FS_CreateDirectoryEx   *check this one in particular...pretty nifty!!!  :bg :bg
FS_GetVolumeInfo
FS_GetVolumeName
FS_IsDirectory
FS_IsPathRoot
FS_MakeFullFilePath
FS_MakeParent
FS_RemoveTrailingBackSlash

Regards,
Shantanu

[attachment deleted by admin]
To ret is human, to jmp divine!

PBrennick

Shantanu,
These all look like very useful funtions.  Keep up the good work and thank you for your support.

Paul
The GeneSys Project is available from:
The Repository or My crappy website

PBrennick

Shantanu,
I was able to test all of your functions with no problems except for one.  FS_CreateDirectoryEx had a problem until I added the following line:
INVALID_FILE_ATTRIBUTES equ -1
How are you able to assemble that function? As near as I can tell, you would need to convert winbase.h to winbase.inc (or use Japheth's copy).

I am not sure why this does not exist in masm32 or in GeneSys (we both use a different fileset).  I think I will ask Vortex.

Paul
The GeneSys Project is available from:
The Repository or My crappy website

Shantanu Gadgil

Hi Paul,
INVALID_FILE_ATTRIBUTES is not defined in the WINDOWS.INC

In the MS Platform SDK, its there in WinBase.h. I have posted in the WINDOWS.INC sub-forum, regarding the same.

I have added that to my WINDOWS.INC, forgot to mention that! Sorry!  :red :red

Regards,
Shantanu
To ret is human, to jmp divine!

PBrennick

Yeah, I figured that one out eventually.  One last problem that I encountered is ...
FS_GetVolumeInfo            PROTO :LPFSVOLUMEINFOSTRUCT

I had to change it to:
FS_GetVolumeInfo            PROTO :DWORD

Now, everything assembles.  I examined your code and I see that the structure is set up correctly. In this case, I probably caused the problem by breaking up FileSystem.asm into individual module files so as to improve granularity.  So it is a trade off.  I like efficiency so I always improve granularity whenever I can.  Assigning DWORD is safe because that is what it is.  This way, everything gets initialized as needed.

This one gave me a headache but I finally figured it out!

Paul
The GeneSys Project is available from:
The Repository or My crappy website

Shantanu Gadgil

Actually...keeping everything DWORD gets really really confusing. More so when there are more than one parameter.

I have purposely made the MS PSDK style LPxxx names  :bg :bg in case an assembler (hopes resting on POASM  :green2 :green2) adds functionality to enforce data-type checking while passing parameters around.

Right now if I PROTO a function with say "PTR <whatever>" and the actual function is declared with a DWORD parameter, POASM flags an error (which I think is healthy  :lol :lol)

Regards,
Shantanu
To ret is human, to jmp divine!

PBrennick

Shantanu,
The bottom line for me is it must assemble.  If it does not then I have to spend time trying to find out why.  In this case, it was not too hard.  I did not change any of the other declarations.

Everything is updated and available for downloading.

About PoASM, don't hold your breath.  He will get there as long as he does not lose interest, but it is going to be a slow process.

Thanks again,
Paul
The GeneSys Project is available from:
The Repository or My crappy website