File System discussion

[Cyberman]

I'm looking at the code that's been commited ...
I'm uncertain where to insert the ISO file code...
clue me in here
I found some commented code though!

1) do we create a ISO9660FileSystem.(h, cpp) file(s)?
2) how does this 'link' in with the main code?
3) I don't believe I will be able to compile this (though I'll try the linux variant first I guess).
4) ISO.cpp is in Kernel/Filesystem... It should be in src/Kernel/Filesystem right? So this needs changed... or are we thinking src/filesystem/ISO/?

Comments
Readme's for each directory so people aren't apt to put thinggs where they don't belong.. or a FileOrg Readme.txt file... <I think you get the idea>
Comments at the begining of a file describing
Where it belongs in the big scheme of things
What it does
Change log information for the file

perhaps we should use Doxygen for making help information from comments?  This will force commenting and fast help information for new contributers.

Anyhow.. does anyone KNOW where to put the ISO code? It's not apparent to me where it belongs at the moment.
Second do I need to create a new file in filesystem or in driver to use the ISO Image functions.
Third what naming convention are we going to use for the new object?
Fourthly are there compilor switchs that need to be defined to use a particular FS type?

Cyb

 

[Akari]

1) do we create a ISO9660FileSystem.(h, cpp) file(s)?

Nope

2) how does this 'link' in with the main code?

Don't try to link with the main code yet, just add Driver class and make sure it works correctly.

3) I don't believe I will be able to compile this (though I'll try the linux variant first I guess).

Why? I think it's not that hard. I can fix some compilation errors on windows, but I dont has Linux so you must do it yourself  :|

4) ISO.cpp is in Kernel/Filesystem... It should be in src/Kernel/Filesystem right? So this needs changed... or are we thinking src/filesystem/ISO/?

This should be in src/filesystem/driver/iso/
Always use lowercase names, just for equal name style =)

Comments
Readme's for each directory so people aren't apt to put thinggs where they don't belong.. or a FileOrg Readme.txt file... <I think you get the idea>
Comments at the begining of a file describing
Where it belongs in the big scheme of things
What it does
Change log information for the file

perhaps we should use Doxygen for making help information from comments?  This will force commenting and fast help information for new contributers.

I'm bat at writing documentation. Maybe Halkun can do this.
Doxygen is good thing!
Change Log can be generated automaticly from SVN update comments.

Anyhow.. does anyone KNOW where to put the ISO code? It's not apparent to me where it belongs at the moment.
Second do I need to create a new file in filesystem or in driver to use the ISO Image functions.
Third what naming convention are we going to use for the new object?
Fourthly are there compilor switchs that need to be defined to use a particular FS type?

You should write driver isofiledriver.cpp/h and place it in src/filesystem/driver
All support files place in src/filesystem/driver/iso

I think we don't need any compilator defines for selection of FS, it will be good if application will support different image formats without recompilation. For time beeing we just will work with ISO. Maybe when we have some results we add more CD image formats.

As for coding styles - I like this http://www.possibility.com/Cpp/CppCodingStandard.html
This is standart that we use in our company, so I getting used to it =)
Maybe we will use it? It's simple and easy to use and understand.

 

[Cyberman]

Progress:
Nearly done setting up ISOfilesystem[h/cpp]
Added ISOFile.[h/cpp] this contains the ISO file system access functions that ISOFileDriver uses.

removed isofilestream.[h/cpp] and other files not really needed anymore.

You need to pass ISOFileDriver a path to the ISO image currently (it handles the rest).

I'll need to figure out how to test it with the current set of functions.
Akari?

Cyb

 

[Akari]

Progress:
Nearly done setting up ISOfilesystem[h/cpp]
Added ISOFile.[h/cpp] this contains the ISO file system access functions that ISOFileDriver uses.

removed isofilestream.[h/cpp] and other files not really needed anymore.

You need to pass ISOFileDriver a path to the ISO image currently (it handles the rest).

I'll need to figure out how to test it with the current set of functions.
Akari?

Cyb

could you upload them to SVN?

mFileDriver.GetFileSize(path) and mFileDriver.ReadFile(path, buffer, start, length)
must be working correctly. If they are - everything else would.

 

[Cyberman]

I've made some progress but it would be faster if I get this thing to compile.
Currently (As if people really were interested ) I'm working on the 'simple' task of taking a path and finding the file from it.
Which is to say it's not as easy as I wished it were LOL.

My compilation is urping on (of all things) the open GL functions. Whereas it has no problem with the include files it just thinks the OpenGL functions are undefined.
Has anyone else had this issue? I'm using the included Makefile for this but as I said it doesn't seem particularly happy.
I have the same deal with the SDL and zip code.

The following files complain about the functions but not the include files that contain there definitions.. (boggle)
displayogl.cpp
windowssdl.cpp
bingzipfile.cpp

The files I've added have warnings instead hehehe

Anyhow ideas?
halkun how is the automake coming along.. and what do I need to do to add my code to the beast?

Cyb

 

[Cyberman]

The Return of this thread means I'm working on the ISO image stuff (halkun if this begins to work it means you can abuse this on Linux).

A few issues cropped up however:

1) Remangling paths.
Since currently we are using windows path naming conventions and the PS1 data set, we now have a, file naming convention situation.
An example would be \CDROM\KERNEL\KERNEL.BIN;1
which in windows is <cdrom letter>:\kernel\kernel.bin
the real name path is \KERNEL\KERNEL.BIN;1
windows translates the ISO9660 system to \kernel\kernel.bin
the ';D' is actually ISO9660's method of file versioning of the file system (lame but ... ) this means there are lots of ;#'s to ignore for a normal path.
Internally I can raise the case and append a ';1' to all the files to make this translation possible.
What will we do for windows? It's completely different.  So I'm concerned about making a 'messed up' approach doing this.

2) ENDIANESS STRIKES BACK!
Right so we want this to run on MACS, allright ISO supports both endianess's normally in it's FS.
Almost the entire file set is in little and big endian format.
Now here comes the... not so fun part, it's possible some of the stuff is in one.. or the other format (only). 
In truth it's likely that we need absolute sector reads and we just need to ignore the rest. Many of the files have there file size included at the begining of them. Some do not.  I suspect what is happening here is that the files that do not include there size are loaded using the ISO filename internally (somehow) and the ones that do include the file size are loaded by absolute sector.  Essentially some use the PATH and DIRECTORY tables and some do not, is my guess.  I say this because it would be very difficult for them to read the file, if they did not include the file size at the begining of the file, because there is no indication of when the file should end.
I would like to know if there is some globally defined macro for ENDIANESS.
What I plan on doing is using both MSB and LSB based numbers and find the one that makes sense putting it in the RIGHT local format as well.  DIRECTORY table locations of 0 or some impossible location would indicate the other contains the information I need.  Ditto for file size as well.

Anyhow this will let me know how the classes are going to be used.

I've noticed -DMACOSX seems to be the switch in the make file to determine if one is compiling for the MAC.  Should there be some intellegence to decide endianess etc added in?

Akari good job, I'm sure you are waiting to abuse the battle models, as am I.


Cyb