Add Samba share browse and load content

[cscd98]

Guidelines

1. Rebase before opening a pull request
2. If you are sending several unrelated fixes or features, use a branch and a separate pull request for each
3. If possible try squashing everything in a single commit. This is particularly beneficial in the case of feature merges since it allows easy bisecting when a problem arises

Description

Adds the ability to add act as a samba client. To do so there is new settings under System->Network->SMB Shares to specify IP address, share name, optional username and password etc.

It can connect to a single share, then the user can access that configured shared under "Load Content" to load their ROMs.

It may be needed to load the core first before all related files displayed (e.g. Quake 2 PAK do not get listed until loading core).

1. Adds libsmb2 as a new optional dependency
2. Builds RetroArch with libsmb2 by default if library found on build system (under Ubuntu this is libsmb2-dev), otherwise does not
3. Optionally build deps/libsmb2 per platform, Makefiles require HAVE_BUILTINSMBCLIENT = 1 set. This mode has been tested in 4 and 5. There is also -DHAVE_SMBCLIENT which uses system libs.
4. Tested as a client using Ubuntu
5. Tested as a client using webOS using HAVE_BUILTINSMBCLIENT
6. Tested as a client using Windows 11
7. Tested as a client on Android (works great as Windows 11 host smb, on Ubuntu 26.04 doesn't work that well)
8. Tested as a client using UWP on Windows 11

All tests done using a local workgroup, not tested under active directory environment. Tested using a Ubuntu server as well as Windows 11 server. By default guest access is disabled in Windows 11, so use a username/password combination.

All code should be protected by HAVE_SMBCLIENT so it should compile cleanly without affecting anything else if disabled.

Portable considerations:

In Makefile.common, I have set necessary CFLAGS for building smbclient.
That works for Linux and Windows (ming) but probably isn't very portable for other platforms.

Related Issues

#11773
#11518
#8653
#8173

Related Pull Requests

Reviewers

[Tony427]

@cscd98 Awesome !! I assume this will work on tvOS as well, right? Appreciate to your awesome work!! I hope this will release soon.

[cscd98]

@Tony427 I don't own a macbook which limits my ability to support that platform unfortunately. However, there is an unmerged PR in upstream libsmb2 which should make including it in RetroArch easier.

[warmenhoven]

There are no current plans to make this work on tvOS. There are a lot of steps that have to happen between here and there. I'm currently the only person working on tvOS and there have been other parts of the app I've been focused on instead. If someone else wants to pick this up I can tell them the exhaustive list of what needs to be done and in what order.

[joaodforce]

@warmenhoven if you can show me the ropes, i can work on it. I have a lot of objC/Swift development history for iOS, I've merely dabbled with tvOS before but I'm sure I can find my way around it.

[warmenhoven]

iOS and tvOS development are mostly the same; it's probably easiest to think of tvOS as a slightly defective version of iOS, most things will work just fine but occasionally you'll hit some weird bug or missing API.

The first thing that has to happen is libsmb2 has to be added to the frontend build. There are two paths here, either the version in deps/ has to be added to the build (strongly preferred) or the library has to be built and added to https://github.com/warmenhoven/retroarch-apple-deps.

Adding it to the build should not be done through modifying Xcode project files, it should be done through griffin.c. This has an uncomfortably high chance of driving you mildly insane. Please make sure to reuse the already-defined preprocessor macros HAVE_BUILTINSMBCLIENT and HAVE_SMBCLIENT. Further instructions can be intuited from Makefile.common.

If you've made it this far, congratulations, most cores that don't use the VFS themselves directly (and instead rely on the frontend to hand them the rom data in the game info) will probably mostly just work. You'll need to test them all to validate that they don't sneakily call standard file system APIs behind your back, but mostly it should be fine.

Most of the cores that do/can use VFS in some capacity, are not currently compiled that way for iOS/tvOS. So for each of those, you'll need to change their makefile or CMakeLists.txt (but mostly makefile) to enable that. This gets very core-specific pretty much immediately and I haven't done the full audit of exactly which cores do/don't.

There are currently 182 cores that compile for iOS and 180 for tvOS (only missing parallel_n64, which doesn't even work on iOS, and qemu). In order to get the app in the App Store I had to change a single compile flag (to set the minimum supported OS version) and test them all. It took me about two weeks, and that was for a change where I just had to make sure the core was able to be run.

[warmenhoven]

Oh, I should also say, the compilation guide is https://docs.libretro.com/development/retroarch/compilation/ios/, and I'm happy to answer questions, the easiest place to reach me is on the libretro discord.

[cscd98]

This the upstream PR sahlberg/libsmb2#450 which will make it easier to include it into RetroArch if the maintainer merges it. I looked into Apple platform, this seemed easier to do (without a device) and I don't fancy maintaining a fork of libsmb2 which is why Apple got delayed.

I already have an updated griffin that uses it (but not for Apple yet).

I could always PR the libsmb2 to RetroArch @warmenhoven if you're not concerned about upstream updates for now.

[warmenhoven]

Most of the deps in deps have been modified from upstream at some point. It makes updating to a newer version a major pain so it's a trade off. If it's small and likely to be approved by upstream anyway then it's probably worth it? Really up to you.