OSDev.org

Im at a little crossroad. I can load files with a fat12 floppy filesystem, but only executables. I need to be able to somehow open the file and return the binary / text ( even plain binary would be good ) to the c function as a *char. Anyone have any examples i could use or an explanation of how to do this? Basicly i need a FILE stuct...

What exactly do you mean? Do you want to implement functions like read() or fread(), or do you want to read the whole file into memory and return a pointer to the data?

I want to first simply be able to load a pointer to it. If you knew how to implement reaf() and readf() that would be a huge bonus

A pointer to what? A 'FILE' structure? Or an array of chars corresponding to the data in the file?

The latter is trivial, the former is only meaningful for fread().

I think you may be in luck when PDCLib 0.5 is released.

Ok ill put this as simple as i can

i need a function like *char load(*char fname) which i can call using load("settings.ini")

Again its fat12 as the filesystem.

The problem I'm having, is that if you can load executables you must be able to get data from the disk to memory. This means you can open the file and you must have some function to read the data. If not, I'm confused.

The first step once you have used the filesystem to work out which blocks you need, would be to allocate a region of contiguous memory (either virtually contiguous or physically contiguous, depending on whether you use paging or not). Then, you read the blocks in either directly to the appropriate place in the array you've just allocated, or into temporary DMA buffers and then copy these buffers into the right places in the array.

I've tried to cover everything there and keep it simple.

If you're happy to load single file at a time (don't need to consider files larger than memory or such, probably not with FAT12) then it's really just the same as loading a program.

So read the file into memory, add a NUL after it (the file probably didn't have one, and C strings would need that) and then cast the address into a char pointer.

Simple as that.

Obviously you need to be able to somehow allocate memory for the file. But too much then depends on other design in your system, so ask more specific questions if you need more help.

add a NUL after it

thats very unreliable you should instead have a GetFilesize()

but anyway

now then the only way i can see to go about this is having a 32bit kernel

then do this

1.when load is called then have it read ohh say the first 512bytes of the file(with the virtual address being above the 2gb part)

2.setup paging to where that whole little part of memory where the file is to be UNavailable so that you get a page int every time they try to load it

3. when they load adress 10 from memory then you just redirect it to where those first 512 bytes are, then when they go to say 513th byte since you didn't load that have you page int catch that and load the next sector of the file and then just redirect it and so yea you can see where that goes


or if your using bios ints or whatever and aren't quite advanced to where i'm talking about just load the whole file to memory and yea then just return the pointer i guess, of course though that is very impractical

Jordan3 wrote:

add a NUL after it

thats very unreliable you should instead have a GetFilesize()

In what way is it unreliable? He wants to read in a text file as one giant c-string. So you read in the file, stick a NUL after it, return a pointer to the start, job done. All the string handling functions (or char array handling functions rather) would be happy and play nicely with it. Note that the NUL isn't directly for finding the size as you seem to think, it is in fact to make the file contents a legal c-string.

yea sry misread but I thought it was more for binary stuff

For binary stuff, you obviously just want to load the string, and return it's length, since with binaries you have to deal with pointer+length. Otherwise the same. But for text, adding NUL is fine.

Ofcourse if you add a NUL after the file when loading as text, then there's a problem if the file contains any NULs, because your string handling will then only handle the file up to the first NUL.

Whether this is a problem depends on what you are trying to do, ofcourse.

Then again, sometimes such behaviour can be a good thing: for example, if a program like Unix "cat" or DOS "type" handles files only up to first null, then it's possible in many cases to put a textual string that tells what the file contains first, and then the actual binary data, so that cat/type/whatever gives just the first string. I remember this being done with some files under DOS actually.

Except that DOS's "type" cuts it off when it hits 26, not 0.

Ahm, right. I should have known that, but I really couldn't remember, because it's been over 10 years now since I last used DOS for anything...