Have a question about File Access.....

When my App saves its Project Data to disk it takes too long to complete for my liking(or the clients probably). In Delphi I was able to create a TMemoryStream object that behaved identical to a disk drive. The same drive access functions worked on this memory. So all the looping and calculation that goes into saving were done to this memory object and then you copied this Object to the drive. Made things extremely fast.
And you also used it in reverse. Created the object moved the disk file you wanted to read all into this memory object and then accessed the memory object instead of the disk drive. Again a huge performance increase.

I guess my question is.. is their a method in API programming that lets you do this? And if so what is it.

I have heard of Memory Mapped Files, but do they do what I mentioned above , or should I just implement my own Memory File system?

thanx guys
Posted on 2002-01-12 11:21:32 by Rockinronstar
Memory mapped files make a file behave like memory, it looks like you want memory to behave like a file :(
But I believe this is even easier though, I don't really understand what the problem is??? Just read the data from the file into memory and start reading it???
Posted on 2002-01-12 11:53:47 by Qweerdy
wasn't really a problem. Just wondering whether there are standard file access functions that will work with memory as well as disk. I'd like to be able to copy a file to memory and then treat that chunk of Ram as a drive. Use File pointers, Read/Write, buffers, basically the same way you do with direct Drive access.

Wondering if this exists, or do I just read it into a big linear buffer and get a pointer to it and read from there. Only thing is that the data I save it very different. Some DWords, some Bytes, some Structures. Would I read this all into memory and then use a Byte pointer to access it?
Posted on 2002-01-12 11:59:51 by Rockinronstar
Sounds like file mapping is the way to go... (memory mapped files)

To treat it like ram with multiple types of data is quite easy. Just like it was ram, organize your file sequentially with what you have to work with.

The catch is simple enough as well. This is a dynamic and will be loaded into a different address everytime (the base pointer of the memory mapped file). So all you need to store is the base pointer dynamically, and then have the offsets to each type of data stored as constants (you can define them with equates if you like).

So to access stuct1 (For say), just do:

lpStruct1 equ 32 ; 32 bytes in
lpDword2 equ 4 ; 4th byte in
etc etc.

Struct1 Struct
Struct1 ends


; mem map file
mov Base, eax ; save the base pointer in memory

; to get a pointer to a data type in the file..
mov esi, Base
mov edi, esi
add esi, lpStuct1
add edi, lpStruct2

mov eax, (Struct1 PTR [esi]).DataField_1
mov ebx, [esi].Struct1.DataField_2 ; Some like this alternate
mov [edi].Stuct2.DataField_1, ebx
; when finished close the file to save any changes made..

Hope this helps..
Posted on 2002-01-12 13:18:00 by NaN
Also, to continue this thought of structures, you can define one BIG structure to hold all the data you want.. then you dont need to deal with equates anymore:

Data1 BYTE ?
Data2 DWORD ?
Data3 BYTE 32 dup(?)
Data4 Sprite_Stuct <>
Data5 PlayList_Struct <>


mov Base, eax

mov esi, Base ; Get the pointer in esi

; now access memory stucts from the "maintaining" struct

mov eax, [esi].BIG_FILE_STRUCT.Data4.lpSpriteName
mov edx, [esi].BIG_FILE_STRUCT.Data2
mov [esi].BIG_FILE_STRUCT.Data1, dl

etc. etc.

; Close file mapping when done.

Well theres another solution... Enjoy..
Posted on 2002-01-12 13:26:08 by NaN
looks good NaN. The one struct idea will work well for most applications. I'll try that one first

thanx again
Posted on 2002-01-12 13:38:00 by Rockinronstar