FILE structure and file reference numbers

[Tobi]

I'm using fopen(), fclose(), fread() and such functions to read in every game data. In OS 9 it was possible to get the file reference number of a file opened with fopen() and pass it to function that require the ref number. Here's a sample:


FILE *fp;
short ref;
Movie music;

fp=fopen("music.mp3", "r");
ref=fp->handle;

NewMovieFromFile(&music, ref, NULL, NULL, newMovieActive, NULL);


But in OS X the FILE structure does no longer have a "handle" field which contains the ref number. I don't know why they changed the structure but damn, they did. :mad: So my question is:
Do you know a way to get the file reference number out of FILE structs?

Thanks for any help,

-Tobi

[CMagicPoker]

I dont recommend that.

Im not an OSX developer, but I think you should use the Cocoa or Carbon apis instead for your files when you use platform specific functions.

I think it's possible to use 'NewMovieFromFile' in Windows too, probably apple ported their file accesses api for it as it done with Quicktime?

I done recommend fopen etc for this kind of job, you should use FSOpenDataFork or something like that, instead.

As for your question, I don't know. Probably in OSX the handle is the system file handle, as given as a Cocoa object?

[OneSadCookie]

stdio on MacOS9 and below was an illusion created by the Metrowerks standard libraries. On MacOSX, it's the "real thing"; the BSD implementation. That means it knows nothing of any MacOS9-isms.

There are ways to go from a FILE* to a POSIX file descriptor, becuse that's the layer stdio is built on. Probably not useful to you though :)

I'd suspect the best solution is to start using the Carbon file APIs where you need to interface with QuickTime. There's a function in Carbon called FSPathMakeRef which you may find useful.

[Tobi]

(CMagicPoker)

Im not an OSX developer, but I think you should use the Cocoa or Carbon apis instead for your files when you use platform specific functions.


I'm using the stdio calls because they are quite crossplatform. I don't want to learn too much Windows code when porting my app. And I think that the file I/O functions provided by the stdio a very powerful, perhaps even better than the Classic/Carbon funtions. I don't know how things are with Cocoa as I haven't started with it yet.

(OneSadCookie)
stdio on MacOS9 and below was an illusion created by the Metrowerks standard libraries. On MacOSX, it's the "real thing"; the BSD implementation. That means it knows nothing of any MacOS9-isms.


OK. This seems to be a good reason that the struct is very different in OS X.



There are ways to go from a FILE* to a POSIX file descriptor, becuse that's the layer stdio is built on. Probably not useful to you though :)

I'd suspect the best solution is to start using the Carbon file APIs where you need to interface with QuickTime. There's a function in Carbon called FSPathMakeRef which you may find useful.



The main reason why I don't like the Carbon file APIs much is because they work with FSSpecs. If I want to open a file and now it's full path, this won't be enough for an FSSpec. I will have to find out vRefNum and parID parameters first to make it a valid FSSpec. This is painful as you can just call fopen(pathname, "r") to open a file instead. However, perhaps I need those Carbon functions now in OS X. This move-around with the "handle" field inside the FILE struct has gone. :(

Thanks for the hint with FSPathMakeRef. But this one converts POSIX files to FSRefs. Now if you could tell me how to get the POSIX file descriptor from a FILE structure (as you mentioned above), I could first convert my FILEs to POSIXs and then to FSRefs. ;)

[OneSadCookie]

FSPathMakeRef converts a POSIX file path to an FSRef, which you can then convert to an FSSpec.

stdio on MacOSX only understands POSIX paths as far as I know, so I don't think there'd be a problem. Just switch to POSIX paths everywhere.

The other possibility (if you have CW6+) is to use Metrowerks' Carbon MSL, which should have the same definition of a FILE as it does on MacOS9. Just be very careful when choosing that route that you don't mix MSL's standard library headers with MacOSX's!

[Tobi]

Thanks, OneSadCookie. It works!

I was just confused because the prototype for "FSPathMakeRef" uses "const UInt8 *" for the pathname parameter, which I now see is the same as "const unsigned char *".

:cool:

-Tobi