View Single Post
Old 17th April 2009, 18:03   #421  |  Link
KenD00
Registered User
 
Join Date: Jan 2007
Location: Internet
Posts: 378
Quote:
Originally Posted by Rupan View Post
If your platform is Linux, look in /etc/bluray/aacs
Ok, you convinced me that this is necessary, but regarding the unix directory structure i would propose another location, either /etc/aacskeys or, because these files aren't configuration files but more some kind of data files, /usr(/local)/share/aacskeys.

Quote:
If your platform is Windows, look in C:\bluray\aacs
This is not the windows way and i really hate applications which install themselves on c: . Either take the files from the application directory (which is a little tricky when using the library, how can it figure out the directory it is executed from?) or use the Application Data directory under Documents and Settings. I currently don't know how to query these locations but i will look into this later.

Quote:
Originally Posted by Rupan View Post
My current focus is on moving the command-line parsing routine out of main, into a new main() then renaming main() to aacs_main().
I always wanted to convert the code more to c++ but never found the time for this. The main logic is still all in main(), its a first step to move this to another location and make main() "dumb" and let it only initialize the program.

Quote:
I've also defined a structure that will hold all user-supplied runtime information, which will be passed to aacs_main().
This is a c approach and i don't encourage this, i prefer c++, the code isn't c conform already and i already started with that (see ioctl files).

Quote:
Do you have any suggestions as to how to deal with nonfatal errors and status messages? If it is to function as a library these must go away. Maybe I can redirect them to a log file...
Well, i would/want to split the code into multiple smaller function units that can be called externally, like getting the VID, decrypting the MKB and so on and use error codes or exceptions that the caller needs to evaluate. However, this way the caller needs to know what to do, maybe it's still possible to use one method that does it all and use a big list of error codes so that you can still figure out in detail what failed.

A library doesn't need to output status messages itself, if you want that information (e.g. MKB version, etc) provide methods for this and the caller has to query that information and display it. The current "library" just executes the program, this is the main problem and should be changed. But i'm still not sure how to do this without writing double code just to do the same things one time in the main program and the second time in the library. Oh well, i could put #ifdef's around every printf .

I'm currently not working on aacskeys because i'm spending my time on the BDVM/BD-J connection so a new aacskeys release will take some time.

KenD00 is offline   Reply With Quote