...in addition to the existing function CreateVolume
(renamed from CreateVolumeFromFilename).
Lets code easily add constraints such as not letting the user
select a WAD file when using the disc changing functionality.
Since C++17, non-member std::size() is present in the standard library
which also operates on regular C arrays. Given that, we can just replace
usages of ArraySize with that where applicable.
In many cases, we can just change the actual C array ArraySize() was
called on into a std::array and just use its .size() member function
instead.
In some other cases, we can collapse the loops they were used in, into a
ranged-for loop, eliminating the need for en explicit bounds query.
In terms of order of operations, the move would occur first before the
construction of the relevant reader would occur. However, given the
local variable 'path' was declared const, this bug actually wouldn't
occur, as std::move on a const variable does nothing (in a non-mutable
context), resulting in a copy instead, masking this issue.
Given this is a bug waiting to happen, we correct the code.
This fixes the The Last Story prototype that GerbilSoft was testing,
because the apploader is a bit more lenient with the max size of DOL
sections when it detects that you're using a devkit console.
As suggested here: https://dolp.in/pr7059#pullrequestreview-125401778
More descriptive than having a std::tuple of FS::Mode, and lets us
give names to known triplets of modes (like in ES). Functions that
only forward mode arguments are slightly less verbose now too.
This allows avoiding two copies of the executable data being created in
the following scenario (using pseudocode):
some_function()
{
std::vector<u8> data = ...;
DolReader reader{data};
...
}
In this scenario, if we only use the data for passing it to DolReader,
then we have to perform a copy, as the constructor takes the std::vector
as a constant reference -- you cannot move from a constant reference,
and so we copy data into the DolReader, and perform another copy in the
constructor itself when assigning the data to the m_bytes member
variable. However, we can do better.
Now, the following is allowable as well:
some_function()
{
std::vector<u8> data = ...;
DolReader reader{std::move(data)};
...
}
and now we perform no copy at any point in the reader's construction, as
we just std::move the data all the way through to m_bytes.
In the case where we *do* want to keep the executable data around after
constructing the reader, then we can just pass the vector without
std::move-ing it, and we only perform a copy once (as we'll std::move
said copy into m_bytes). Therefore, we get a more flexible interface
resource-wise out of it.
Gets rid of the need to construct UReg_MSR values around the the actual
member in order to query information from it (without using shifts and
masks). This makes it more concise in some areas, while helping with
readability in some other places (such as copying the ILE bit to the LE
bit in the exception checking functions).
Since all FS access will go through the new FS interface (PR #6421)
in order to keep track of metadata properly, there is no need to return
absolute paths anymore.
In fact, returning host paths is a roadblock to using the FS interface.
This starts the migration work by adding a way to get paths that are
relative to the Wii NAND instead of always getting absolute paths
on the host FS.
To prepare for future changes, this commit also makes returned paths
canonical by removing the trailing slash when it's unneeded.
Eventually, once everything has been migrated to the new interface,
we can remove the "from" parameter.
Some homebrew expect exception handlers to be present -- which is
almost always the case on console, since most of the time homebrew are
launched from either a libogc or SDK title) -- and break if they are
not. To fix this, we just need to include default, dummy handlers.
Set HID0, HID4, GPR1 to values that are used by libogc for
initialisation. This makes boots more similar to a launch
from the HBC or another loader, since normally the registers
have already been initialised by the loader.
This fixes a crash in homebrew that assume GPR1 points to a correct
location and attempt to use it before initialising registers.
This removes the hack that enables directly booting from WADs
without installing them first for the following reasons:
1. It makes the NAND content handling much more complicated than what
it should be and makes future changes like permissions or booting
NAND titles without a WAD more annoying to implement.
Because of this hack, we needed an extra level of abstraction
(NANDContent*) which has to read tons of things from the NAND, even
most of the time it's useless. This in turn forces us to have
caching, which is known to break titles and requires manual cache
invalidations. Annoying and error prone.
2. It prevents the WAD boot code from being easily accurate. With this
change, we can simply reuse the existing launch code, and ask IOS
to launch the title from the NAND.
3. The hack did not work that well since it did not cover a lot of ES
commands. And it works even less since the ES accuracy fixes.
This results in Dolphin returning inconsistent results: a
lot of the ES "DI" commands will just fail because the active title
is not installed on the NAND. uid.sys is not changed, etc.
And I'm not even talking about FS stuff -- where this would still
totally fail, unless we add even more unnecessary hacks.
This is not just theoretical -- the system menu and the Wii Shop are
known to behave strangely because the hack damages the NAND
structure, and we've already had several users report issues.
This commit makes it so WADs are always installed prior to launching.
A future commit will remove any code that was there only for the hack.
Settings that come from the SYSCONF are now included in Dolphin's
config system as part of the base layer. They are handled in a
special way compared to other settings to make sure they are only
loaded from and saved to the SYSCONF (to avoid different, possibly
contradicting sources of truth).
It's not specific to WADs. The BS2 emulation boot code will also need
to update the state file.
Move the struct to Boot and add a helper function that will handle
reading + computing the checksum + writing the state file.
This lets VolumeDirectory/DirectoryBlob skip implementing
various volume functions like GetGameID, GetBanner, etc.
It also lets us view extracted discs in the game list.
This ends up breaking the boot process for Wii
DirectoryBlobs due to workarounds being removed from the
boot process, but that will be fixed later by adding
proper DirectoryBlob support for things like TMDs.
We now expect the directories to be laid out in a certain
format (based on the format that WIT uses) instead of requiring
the user to set the DVD root and apploader path settings.
The old approach to detecting DOL/ELF files doesn't fit
with the new way of implementing extracted discs.
The game list is already doing it in a way that's similar
to the approach that this commit uses.
Some code was calling more than one of these functions in a row
(in particular, FileUtil.cpp itself did it a lot...), which is
a waste since it's possible to call stat a single time and then
read all three values from the stat struct. This commit adds a
File::FileInfo class that calls stat once on construction and
then lets Exists/IsDirectory/GetSize be executed very quickly.
The performance improvement mostly matters for functions that
can be handling a lot of files, such as File::ScanDirectoryTree.
I've also done some cleanup in code that uses these functions.
For instance, some code had checks like !Exists() || !IsDirectory(),
which is functionally equivalent to !IsDirectory(), and some
code was using File::GetSize even though there was an IOFile
object that the code could call GetSize on.
They're essentially the same. To achieve this, this commit unifies
DolReader and ElfReader into a common interface for boot executable
readers, so the only remaining difference between ELF and DOL is
how which volume is inserted.
* Move out boot parameters to a separate struct, which is not part
of SConfig/ConfigManager because there is no reason for it to
be there.
* Move out file name parsing and constructing the appropriate params
from paths to a separate function that does that, and only that.
* For every different boot type we support, add a proper struct with
only the required parameters, with descriptive names and use
std::variant to only store what we need.
* Clean up the bHLE_BS2 stuff which made no sense sometimes. Now
instead of using bHLE_BS2 for two different things, both for storing
the user config setting and as a runtime boot parameter,
we simply replace the Disc boot params with BootParameters::IPL.
* Const correctness so it's clear what can or cannot update the config.
* Drop unused parameters and unneeded checks.
* Make a few checks a lot more concise. (Looking at you, extension
checks for disc images.)
* Remove a mildly terrible workaround where we needed to pass an empty
string in order to boot the GC IPL without any game inserted.
(Not required anymore thanks to std::variant and std::optional.)
The motivation for this are multiple: cleaning up and being able to add
support for booting an installed NAND title. Without this change, it'd
be pretty much impossible to implement that.
Also, using std::visit with std::variant makes the compiler do
additional type checks: now we're guaranteed that the boot code will
handle all boot types and no invalid boot type will be possible.
