[tobi11]

Hi!
I could not find many information on the DllLoader in the forum or wiki, so I am going to ask here. Is the only purpose loading .dll's under Windows and on the XBox or is this class also relevant under Linux and OS X? What does it do there, if that is so? You certainly cannot use Windows .dll's under Linux or OS X, or am I missing something?
I am having some trouble getting it compiled under OpenSolaris and wanted to know if I can save me the trouble?

[jmarshall]

It's used to load .so's on linux and os x, yes. It's not used to load windows dll's on *nix operating systems.

Cheers,
Jonathan

[tobi11]

Hmm okay this makes sense, although the name is confusing. Nethermind .

I hope someone can help me with this problem I have with the code.
EmuFileWrapper.cpp in DllLoader/exports/util contains the following lines:

Code:

m_files[i].used = false;
m_files[i].file_emu._file = -1;
....
object->file_emu._file = (i + FILE_WRAPPER_OFFSET);

The problem is, that it isn't really recommened/supported to write into _file under (Open)Solaris (some info for the ones interested). With the first two lines I should be able to prevent writing to _file, because "used" is also set to false.
But I don't know what to do with the line where it is set to something other than -1. What should this line do? Does somebody have an idea how do this without writing into _file?

[elupus]

It doesn't really matter if it's recommended or not. It's not a normal FILE handle. It's one crafter for our purposes.

The os should never get that FILE pointer.

[spiff]

it's the identifier for the files we track. we export custom fopen/fwrite/fread/etc which allows us to plug the vfs into .so files through using the wrapper.def file. we need to keep track of these files since they point to objects inside xbmc.bin. you need somewhere to store the identifier, maybe you have a suitable field you can use on solaris? (my knowledge on this os is close to zilch unfortunately).

[tobi11]

It doesn't really matter if it's recommended or not. It's not a normal FILE handle. It's one crafter for our purposes.

The os should never get that FILE pointer.

Hmm okay the option file_emu is of type FILE, not FILE*, but my compiler nevertheless complains that there is no element named _fileno/_file ...? What am I missing?
Normally you would read _file/_fileno of a FILE pointer through the function fileno(FILE *fp), but there is no function to write into it.

@spiff:
Ah thanks for this information. Can you tell me where this code for interpreting the _file attribute is, you talk about?

[spiff]

emumsvcrt.cpp iirc. nm the name

[tobi11]

emumsvcrt.cpp iirc. nm the name

Ah okay thanks, found it. Will look into that when I find the time

[tobi11]

So I finally found the time to look into that.
Wouldn't it be the best solution, to save the identifier in the EMUFileObject struct as an extra element? Why save it in the file descriptor? Shouldn't that be something the OS manages? It seems kind of quick'n'dirty to me.