Building a RISC OS ROM

As I explained in a previous post, the SMB file sharing protocol originally created by IBM and popularized by Microsoft Windows is now an industry standard, including the SMB 2 and 3 extensions released with Windows Vista and later versions. Over the past few years, support for the original SMB 1 protocol has been removed from Windows, macOS, and Samba (Linux/UNIX), so there’s now a fairly respectable bounty to upgrade RISC OS’s “LanManFS” protocol handler to connect to SMB 2 and 3-only servers.

If I hadn’t spent several hours back in 2021 to figure out how to build a RISC OS “ROM” image for Raspberry Pi (it’s loaded from the SD Card by a bootloader but is functionally equivalent to a real ROM image) using the commercial Acorn C compiler that came with the RISC OS ePic card that I paid £50 for, then I’d be in real trouble because it’s not easy to build a ROM, even with instructions.

Sadly, my attempt to build the current beta version of RISC OS failed with compiler errors, so I suspect the Desktop Development Environment version that I have may be too old. Fortunately, the version of the source code that I downloaded in 2021 does still build, and I was able to substitute my work-in-progress “OmniLanManFS” directory and start working on upgrading it.

My first step was to remove the old NetBEUI protocol, which was a relatively simple matter of defining NO_NETBEUI in the Makefile and removing the c/NetBIOS source file from the build. RISC OS uses “.” as a directory separator, so “.” and “/” are typically swapped in filenames coming from other systems, and in the POSIX compatibility library, and the convention for source code is to put C source files in a directory named “c”, and C header files in a directory named “h”, with no filename extensions. This confuses VS Code and it can’t find the header files, but at least I can get syntax highlighting by manually changing the file type from “Plain text” to “C” when I open source files.

Here are the subtasks that I’m working on. I’ll update this post and cross them out as I complete them. My goal is to have everything finished by Sunday night, and to communicate my intention to collect the bounty to the bounty scheme administrators as soon as I’ve finished the first three items on the list and committed the changes to the jhamby_smb2 branch of my OmniLanManFS GitHub repo as proof of my seriousness and ability.

• Remove NetBEUI protocol code
• Add support for direct TCP on port 445 in preference to NetBIOS port 139
• Add support for DNS name resolution in preference to NetBIOS port 137
• Fix bugs in “Trans2 subcommands” discovered while testing SMB1
• Verify SMB1 code correctness, including module reload and debug version
• Add negotiation handshake for SMB 2.0.2 (Vista SP1) and SMB 2.1 servers
• Add code to handle all needed SMB 2.x message and response types
• Test with Windows, macOS, and Samba servers, including domain logins

Update: I finished adding direct TCP support, but it took me a while to figure out that my ROM version of the LanManFS module can be replaced with a relocatable module from the filesystem. There’s a version of the LanManFS module in the Apps.!Omni.RMStore directory (the leading “!” often indicates a RISC OS app folder, which works like a macOS app bundle directory, with double-left-click to open the app and shift+double-left-click to show the directory contents).

There are “Obey” scripts (similar to UNIX shell scripts) named !Boot and !Run (many Obey scripts also have a leading “!”) to load modules and perform other startup tasks when the parent folder of the app is opened (!Boot) and when the app is launched (!Run), and there are numerous other Obey scripts run at boot time.

The !Omni app is the GUI front-end, and its !Run script runs another Obey script named Startup in the Files directory inside of !Omni, which in turn loads the modules for the enabled protocols (which can be customized by setting variables at the top of the script to 1 or 0). It looks like the ROM module isn’t replaced unless it’s an older version.

If I manually double-click the LanManFS module file after building it, and before using the Omni app, then I get a RAM version of the module, and I can see that it’s using port 445 when I run *LMInfo from a task window. If I don’t do that, then I find that I’m connecting on port 139, which means I got an old version of the module from the ROM (*Modules shows me the starting address, which starts with FC for ROM modules and 20 for relocatable modules).

I thought maybe my problem was that I’ve been using the Desktop Settings -> Save option of the task manager window, which generates or updates a file named !Boot inside !Boot.Choices.Boot.Tasks that will (hopefully) recreate the currently open filer and app windows on subsequent boots. Sometimes that leads to problems, but that doesn’t seem to be the case here.

I finally built a RISC OS ROM with my updated module by ticking the “Clean” and “Clean all” build options in the !Builder GUI, in addition to “Export headers”, “Export libraries”, “Export resources”, “Make ROM”, “Install ROM”, and “Join ROM”. It appears that running the !MkClean script isn’t sufficient. I think I need to manually delete any old copies of LanManFS and LanManFS_sym in the Install.ROOL.BCM2835.Networking folder if I want to build a ROM with a newer version of the module without doing a full clean build.

At least this means that I can build and load test versions of LanManFS as relocatable modules instead of having to build a new ROM file every time.