This changes the read request handler to work just like IOS:
* To make things clearer, we now return early from error conditions,
instead of having nested ifs.
* IOS does an additional check on the requested read length, and
substracts the current seek position from it, if the read would
cause IOS to read past the EOF (not sure what the purpose of this
check is, but IOS does it, so we should too).
* The most significant one: IOS does *not* return the requested read
length, or update the file seek position with it. Instead, it uses
the *actual* read length.
As a result of simply doing what IOS does, this fixes _Mushroom Men_.
The game creates a save file, reads 2560 bytes from it, then
immediately writes 16384 bytes to it. With IOS, the first read does not
change the seek position at all, so the save data is written at
offset 0, not 2560. With Dolphin, the read erroneously set the
seek position to 2560, which caused the data to be written at
the wrong location.
Behavior confirmed by comparing IPC replies with IOS LLE and by looking
at the FS module in IOS.
YYCJ is one of the last titles to be completely broken in Dolphin.
It would hang right after the Wii remote screen. Looking at the
game's debug messages reveals that it was failing to find some of
its files.
IOS LLE booted the game just fine, which confirmed that it was an issue
with IOS HLE.
By comparing the ioctlv requests and responses with IOS, it turns out
that one of the very first ES replies was different between IOS HLE and
IOS: there was a mismatch for the content fd returned by ES.
Changing the initial content FD to what IOS returns fixes the issue.
IOS
000000: 00 00 00 08 00 00 00 00 00 00 00 07 00 00 00 09 ................
000010: 00 00 00 01 00 00 00 00 01 38 66 f0 00 00 00 20 .........8f....
000020: 00 00 00 00 00 00 00 00 00 00 00 00 81 36 d3 18 .............6..
000030: 81 36 d3 18 00 00 ff ff ff ff ff ff ff ff ff ff .6..............
Dolphin
000000: 00 00 00 08 06 00 00 00 00 00 00 07 00 00 00 09 ................
000010: 00 00 00 01 00 00 00 00 01 38 66 f0 00 00 00 20 .........8f....
000020: 00 00 00 00 00 00 00 00 00 00 00 00 81 36 d3 18 .............6..
000030: 81 36 d3 18 00 00 ff ff ff ff ff ff ff ff ff ff .6..............
So where did 0x6000000 come from?
We (the Microsoft C++ team) use the dolphin project as part of our "Real world code" tests.
I noticed a few issues in windows specific code when building dolphin with the MSVC compiler
in its conformance mode (/permissive-). For more information on /permissive- see our blog
https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/.
These changes are to address 3 different types of issues:
1) Use of qualified names in member declarations
struct A {
void A::f() { } // error C4596: illegal qualified name in member declaration
// remove redundant 'A::' to fix
};
2) Binding a non-const reference to a temporary
struct S{};
// If arg is in 'in' parameter, then it should be made const.
void func(S& arg){}
int main() {
//error C2664: 'void func(S &)': cannot convert argument 1 from 'S' to 'S &'
//note: A non-const reference may only be bound to an lvalue
func( S() );
//Work around this by creating a local, and using it to call the function
S s;
func( s );
}
3) Add missing #include <intrin.h>
Because of the workaround you are using in the code you will need to include
this. This is because of changes in the libraries and not /permissive-
This adds memory values for IOS11, 20, 30, 50, 51, 52, 60 and 70.
Unfortunately, IOS40 (in its working version) is not present on NUS, so
constants for that one are still missing.
Mat M