Talk:Homebrew ABI: Difference between revisions

(4 intermediate revisions by 2 users not shown)

Line 67:

--[[User:Misson20000|Misson20000]] ([[User talk:Misson20000|talk]]) 00:27, 10 November 2018 (UTC)

Where does this "IFilesystem" come from? --[[User:Yellows8|Yellows8]] ([[User talk:Yellows8|talk]]) 01:47, 10 November 2018 (CET)

Doesn't much matter as far as the application is concerned. Could be some save data that the loader opened from FS, could be some BIS filesystem, or, in my case, a custom IFileSystem implementation that came from a custom service. Just as long as it implements the IFileSystem interface.

--[[User:Misson20000|Misson20000]] ([[User talk:Misson20000|talk]]) 00:57, 10 November 2018 (UTC)

Workarounds (which only exist for a debugger) don't belong in the HBABI. --[[User:Yellows8|Yellows8]] ([[User talk:Yellows8|talk]]) 19:17, 12 February 2019 (UTC)

Almost all of HBABI is workarounds to facilitate running homebrew applications in dirty environments:

- bad entrypoint arguments (MainThreadHandle)

- reusing the same process (OverrideHeap, Argv (can't use loader-args), AllocPages, LockRegion, RandomSeed)

- legacy exploits (OverrideService, AppletWorkaround)

- working around 0xffff8001 check in SVCs (ProcessHandle)

And although it's not specified in the HBABI, reading back argv[0] for ASET is also a way to work around not being installed as a real application and being able to access romfs like official applications do.

The only thing I'm working around here is the ASET workaround that needlessly ties homebrew to the SD card. Even if this is a workaround for a debugger, I don't think that's grounds for not belonging in the HBABI. It's not like Nintendo doesn't do anything similar ("Redirect*" commands in lr).

--[[User:Misson20000|Misson20000]] ([[User talk:Misson20000|talk]]) 21:42, 12 February 2019 (UTC)

Reusing the same process is the approach selected for nx-hbloader which is the standard way to load homebrew, and I see no reason why they would be labeled as "workarounds". AllocPages and LockRegion were unilaterally added by you several months ago and nx-hbloader has no use for them. OverrideService and AppletWorkaround are not presently used by anything and they were mostly added for future-proofing in case we need to support a more restrictive environment where we need to pass stolen service handles, they don't exist for "legacy" exploits.

I see no reason to add a romfs override key. If we want to support non-SD card paths, we will add other device name prefixes to argv[0] (such as host:/) and add support for these devices in libnx.

--[[User:Fincs|Fincs]] ([[User talk:Fincs|talk]]) 22:12, 12 February 2019 (UTC)

@@ Line 67: / Line 67: @@
 --[[User:Misson20000|Misson20000]] ([[User talk:Misson20000|talk]]) 00:27, 10 November 2018 (UTC)
+Where does this "IFilesystem" come from? --[[User:Yellows8|Yellows8]] ([[User talk:Yellows8|talk]]) 01:47, 10 November 2018 (CET)
+Doesn't much matter as far as the application is concerned. Could be some save data that the loader opened from FS, could be some BIS filesystem, or, in my case, a custom IFileSystem implementation that came from a custom service. Just as long as it implements the IFileSystem interface.
+--[[User:Misson20000|Misson20000]] ([[User talk:Misson20000|talk]]) 00:57, 10 November 2018 (UTC)
+Workarounds (which only exist for a debugger) don't belong in the HBABI. --[[User:Yellows8|Yellows8]] ([[User talk:Yellows8|talk]]) 19:17, 12 February 2019 (UTC)
+Almost all of HBABI is workarounds to facilitate running homebrew applications in dirty environments:
+  - bad entrypoint arguments (MainThreadHandle)
+  - reusing the same process (OverrideHeap, Argv (can't use loader-args), AllocPages, LockRegion, RandomSeed)
+  - legacy exploits (OverrideService, AppletWorkaround)
+  - working around 0xffff8001 check in SVCs (ProcessHandle)
+And although it's not specified in the HBABI, reading back argv[0] for ASET is also a way to work around not being installed as a real application and being able to access romfs like official applications do.
+The only thing I'm working around here is the ASET workaround that needlessly ties homebrew to the SD card. Even if this is a workaround for a debugger, I don't think that's grounds for not belonging in the HBABI. It's not like Nintendo doesn't do anything similar ("Redirect*" commands in lr).
+--[[User:Misson20000|Misson20000]] ([[User talk:Misson20000|talk]]) 21:42, 12 February 2019 (UTC)
+Reusing the same process is the approach selected for nx-hbloader which is the standard way to load homebrew, and I see no reason why they would be labeled as "workarounds". AllocPages and LockRegion were unilaterally added by you several months ago and nx-hbloader has no use for them. OverrideService and AppletWorkaround are not presently used by anything and they were mostly added for future-proofing in case we need to support a more restrictive environment where we need to pass stolen service handles, they don't exist for "legacy" exploits.
+I see no reason to add a romfs override key. If we want to support non-SD card paths, we will add other device name prefixes to argv[0] (such as host:/) and add support for these devices in libnx.
+--[[User:Fincs|Fincs]] ([[User talk:Fincs|talk]]) 22:12, 12 February 2019 (UTC)