We already have a TMDReader, so let's actually use it.
And move ESFormats to IOS::ES, since it's definitely part of IOS.
This adds a DiscIO dependency on Core which will be fixed in a
follow-up PR.
This prevents Dolphin from writing to /sys/uid.sys (on the host; root
partition) when installing a WAD before starting emulation, because
the session root is not initialized at that moment.
Incidentally, this also gets rid of a singleton.
These two functions load either a signed ticket or a raw ticket from the
emulated NAND.
The ticket signature skip is refactored out of the ticket writing in
order to be usable by the raw ticket reading function.
Refactor the existing DiscIO::AddTicket to not require the caller to
pass the requested title ID. We do not have the title ID in the ES case,
and it needs to be extracted from the ticket. Since this is always a
safe operation to do (title ID is always in the ticket), the
implementation is made default.
Instead of needing different switch cases for
converting countries to regions in multiple places,
we now only need a single country-to-region switch case
(in DiscIO/Enums.cpp), and we get a nice Region type.
This would previously fail to compile when included in files that do not
include FileUtil.h due to lack of a type declaration.
This moves the constructor and destructor into the cpp file in order to
satisfy the requirements of unique_ptr construction and deletion. That is,
unique_ptr requires a concrete type at the point of construction and
destruction. If the constructor or destructor is left in the header, then
at the point of construction or destruction, IOFile will still be
considered an incomplete type, as unique_ptr's deleter will still only be
able to see the forward declaration, which it can't use.
At first there weren't many enums in Volume.h, but the number has been
growing, and I'm planning to add one more for regions. To not make
Volume.h too large, and to avoid needing to include Volume.h in code
that doesn't use volume objects, I'm moving the enums to a new file.
I'm also turning them into enum classes while I'm at it.
instead, leave all the management with the NANDContentLoader.
for file data (directly on the NAND), this opens the file on-demand and
returns the requested chunk when asked for it.
for on-the-fly decrypted WAD data, we just keep the decoded buffer in
memory, like we've done before - except that we don't give away any objects
we don't want to.
