In the days of OS/2 1.2, when a new High Performance File System (HPFS) was created, a new mechanism needed to support custom file systems was created too. It was named the Installable File Systems (IFS) mechanism. It defines not only filesystem API but an infrastructure needed to successfully boot OS/2 from any filesystem, and utility routines which must be supplied with each IFS. In this section, the boot infrastructure is most important. The ifs.inf document from IBM defines that each bootable IFS must contain not only IFS driver itself, but two more small modules: A microfsd (uFSD), which is intended for a readonly filesystem access from os2ldr, and a minifsd (mFSD), which is intended for a readonly filesystem access from the OS/2 kernel, before the main IFS is loaded, base device drivers are loaded, and some initial structures are initialized.

An uFSD and a mFSD supplies a number of exported functions to its client (an OS/2 loader or OS/2 kernel, correspondingly). These functions hide a specific FS internals from the client. So, the kernel or OS/2 loader must not know these details, and handle each FS the same way.

The bootos2 OS/2 booter also consists from uFSD and mFSD (and the 3rd part which take an info from FreeLDR and places uFSD and mFSD at their intended positions. All these are contained in a single bootos2.mdl module). An uFSD and a mFSD are special kinds, so they get a Multiboot Info structure from a bootloader, along with system info and all pre-loaded files in the form of multiboot modules. Then the main bootos2 part relocates this info to safe place and moves uFSD, os2ldr and mFSD to their intended places and starts uFSD. The uFSD then starts os2ldr. The os2ldr loads a number of files, including os2krnl, to memory, performing fixups and using uFSD routines for that. The uFSD implements open, read, close and term functions by searching filenames in Multiboot info structure, then it finds these modules in memory and reads them from here, implementing read operations as a simple memmove(). So, all files are pre-loaded in memory and are retrieved from there using the usual open, read, close operations.

The same way, the rest of files is retrieved from in-memory structures, when a mFSD is used in OS/2 kernel environment. When the mFSD finishes, it passes control to a fully-functional IFS, it searches IFS module in memory, using program loader structures. It determines FS_MOUNT and FS_OPENCREATE IFS entry point addresses, then it calls FS_MOUNT first to remount a boot volume by IFS, and finally, reopens all the files which left open, by IFS FS_OPENCREATE function. If something goes wrong at this point, a panic (IPE) message is displayed (“Can't remount”, or “Cannot reopen” correspondingly). If all were OK, The mFSD finishes and the boot process begin using the IFS for file access. From this point, OS/2 boots as usual.