Just wondering how it would be possible to create a file on the hard drive and use the addresses/offsets within the file to write/read from?

You can't be serious, can you?

C is for old people, I'm still a young guy.

Just which magical presto-chango "Make Game" button type language did you have in mind?

Python. I also wonder, is this possible with assembler somehow?

Google is your friend.

If it's possible in a higher level language, it's possible in assembler, and then some. It may take an unreasonably long time to write, though.

Thats why I prefer C over assembler sometimes.

Grow up kid, C turns children into men in the blink of an eye

Jokes aside, C is great when you need to work with files at low level.

FTFY.

For a second I thought he was talking about getting an actual pointer. In which case he'd want mmap.

That does sound interesting except I have Xp. Damm piece of sht. XP and Borland turbo assembler are very similar btw, neither will ever catch up with time.

I found this thread amusing.

What makes you think windows doesn't have a similar feature? You did attempt to google it no?

VirtualAlloc/VirtualProtect is the windows equivalent of mmap. They cannot be used to get an actual pointer to the hard drive, as they only manage pages.

To directly access the hard drive on windows, one would use CreateFile, which, I suppose, is a bit like mmap.

Verthex, it's time you switch to an OS completely developed in assembly

http://mikeos.berlios.de/

Its not the only one

I'll look into it, thanks.

You get a virtual memory range that has a backing store on disk. It's more or less a pointer to data on the HD. Though the OS is free to also assign real memory as well.

I thought CreateFile was like fopen or open. not mmap...

With VirtualAlloc, you don't get the ability to specify if the memory is swapped out or not. Writing to memory returned with VirtualAlloc might be writing to the disk, but that doesn't really mean it is anything like a pointer to the disk. (Your changes will be lost, they can only show up in the paging file, etc)

CreateFile can also be used for device access. To do so, you must specify the OPEN_EXISTING and FILE_SHARE_WRITE flags. Then, the device will be:
"\\.\PhysicalDrive#"
Where # is a 0-indexed number.

If you want access to a particular partition, it would be something like:
"\\.\C:"
Note, if you add a backslash to the end ("\\.\C:\"), you'll be opening the filesystem, not the partition.

Either way, the handle returned can be used with DeviceIoControl to directly read and modify data.

That's probably too advanced for the OP.

I think Arthur nailed this topic right of the bat though, his explanation is definitely superior to everyones elses.

How so, what other pointer can there be besides the one Arthur mentioned?

The ones Thomas Fjellstrom and I have mentioned are pointers to directly modify the hard drive with no filesystem interference. The pointers Arthur mentioned are for modifying files within the hard drive's filesystem.

Are those the ones with virtual memory addresses?

Basically I want to be able to use memory on the disk that is a file called some name X for example and I want to be able to write to locations of that file, using pointers. Which approach is the better one, Arthurs or Thomas?

Arthur's, without a doubt. What Thomas and I were talking about would be more useful for creating filesystems, inspecting disks, and things of that nature.

You derailed the thread and made me think otherwise, hisses at you and Dustin!

It rather sounds to me like MapViewOfFile is the functionality you are seeking as it allows you to map a file into memory and so you get pointers to the data (as it is in memory ) and can manipulate them as regular memory (:)).
Of course, if you just meant "how do I open and manipulate a file" (which is what I see that Arthur answered) then you are asking that in a rather weird fashion.

The farther I stay from windows.h the better, at least I'm assuming thats where the function is.

Um, mmap gets you a virtual memory address range for a file on disk.

If you want to work under the level of the FS, you need to actually open a handle to the disk, with I assume CreateFile.

On linux the equivalent would be open (NOT fopen).

Sorry, it's been a while since I looked up mmap documentation.

mmap's primary purpose is to save the memory copies that come about with typical file read and write methods. It moves the workload into the kernel, which is in a better position to do the work in an optimized fashion. It also can make certain kinds of operations easier for huge files.

But it's much more complex to setup (and requires care to destroy properly) that I wouldn't recommend it for the OP. Just the number of parameters could be considered daunting.

void *mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset);

I don't plan on having too many hard disk look ups. I just needed it to save data in a formatted way.

So yeah, just use the standard file functions. Either stdio, or C++s iostream stuff.

Nope that would be too difficult... just imagine the row major order calculation for an array and thats how I want the formatting to exist. Basically I want to save my world in a 3d coordinate system, sort of like a 2d bitmap. The problem with that is that STL file routines are messy with lookup and replacing operations.

You do realize the functions Arthur pointed out are stdio, and iostream has all the same functionality, correct?

No, had no idea, the operator he mentioned didn't seem related to it at all.

fseek and ftell fstream equivalents are seekg and tellg respectively. Both sets work about the same. Regardless, seeking around in files isn't the fastest thing in the world. Normally, you're better off just using multiple files.
Try decomposing your world into chunks and then just loading those instead of having large files you seek in.

I guess I could use ftell, but wouldn't using pointers make more sense, since you have addresses in memory that are contiguous and then incrementing or doing some other operation to find the offset would land you somewhere in the file?

If you want to use pointers, this is not the correct api. I mean, you could wrap it in a class in c++ such that it looked like a pointer, but that is beside the point.

Because of the way hard drives' drivers are optimized for contiguous reads and writes, not jumping all over the place to write tiny bits of data as you would in memory. This, however, is probably irrelevant as there is probably a better way to do what you are trying to do than trying to use a large file on the hard drive as a big block of contiguous memory.

If you would, state exactly what you're trying to do. I or someone else will be able to tell you the best way to go about it.

Based on what you've said thus far, I'm currently thinking you want a large 3D world which you're only loading pieces of. If this is the case, it is certainly a better idea to break your world up into chunks, with each chunk being an individual file. You would then load entire files whenever you needed to load different parts of the world. This would perform much better.

Well its more of a one time deal saving the world in a file, I'm sure there are better ways but the ghetto method works wonders too.

What do you learn if you aren't doing things in new and better ways?

There is no way to get a "pointer" to a file on disk, other than something like mmap.

Storing/Reading fixed length record files in stdio is dead simple. I'm surprised you think its "too difficult". Each record is RECORD_LEN bytes in size, say you want the 1023'd record, just do: fseek(fh, 1023 * RECORD_LEN, SEEK_SET); fread(ptr, RECCORD_LEN, 1, fh); (but with more error checking).

It really isn't hard working with files, especially with fixed length records. It's more dynamic formats thats hard.

I'll try that, thanks Thomas.