Disclaimer

InferenceOS is an operating system (MVP) philosophy which has its roots in two of the world'd most prominent operating system philosophies as far as file system is concerned, namely Microsoft Windows and Linux. There is no intention to infringe on intellectual property and/or copyrights, goodwill of these operating systems.

Git Repository: https://github.com/kontacthimanshu/InferenceOS

Readily Usable Hyper-V VM

• Readily usable Hyper-V VM of this operating system is inside the folder:

  ./ReadilyUsableHyperV-VM

• Just import the VM and keep all the virtual machine related files in one folder.

Steps to import VM

• Clone this repository.

• Ensure that no HyperV virtual machine is selected inside Virtual Machines pane. This is to ensure that "Action" menu item does not trim/hide the "Import Virtual Machine" menu option.

• Click on the menu option "Import Virtual Machine".

• Click the "Browse" button in the diaglog box's right side pane to locate the cloned repositories' folder where VMs are kept. That folder is "ReadilyUsableHyperV-VM", which is also mentioned above.

• Inside this folder locate another folder at following path:

C:\Users<user_name>\source\repos\InferenceOS\ReadilyUsableHyperV-VM\Virtual Machines

• In the above path the <user_name> is the name of the user's home folder which Windows created automatically. So you have to locate the above path inside your local user folder if you had cloned the repository there. Otherwise locate the "Virtual Machines" folder in the path where you have cloned the repo, whatever it is.

• After selecting the "Virtual Machines" folder click "Next" button at the bottom of the dialog.

• The next dialog pane will show you a virtual machine titled as "InferenceOS-HyperV", already selected and highlighted in blue background. If it is not selected for some reason, then select it.

• Click Next.

• In the next dialog you have three options and you have to select the third option which is "Copy the virtual machine".

• Now click Next again.

• Next dialog asks you the location where you want to store the virtual machine files. Create a folder at such a location in your system where the access to hard disk is not blocked by any administrative security policy (local or group policy). This is because the current MVP is built to work in such a manner that it needs all the files in one folder.

• So click on the check box titled as "Store the virtual machine in a different location.

• In all three text boxes keep the same path which you created in previous step.

• In the next dialog you will be asked to choose the location of virtual disk.

• In this text box also, you put the same path you put in last three text boxes on previous dialog page.

• Click Next and in the next dialog click Finish button.

• Your InferenceOS VM will be live in a few seconds.

• The VM will be in off state, you right click on the VM and click the menu item "Start" from the dropdown context menu.

• InferenceOS will boot and land on a command prompt like this "InferenceOS>".

• To test the main feature you have to try some commands which are listed in a tabular format at the bottom of this ReadMe file.

• Important commands to try are:

• create - You will use this command to create a file with a three character extension for example, "resume.doc"

• dir - This command will list the file(s) you just created with above command, but the output will not show the extension. That means the OS is hiding the extension. This is the crux. Rest is explained below.

• gui - This command takes you to graphical user interface of the MVP OS.

InferenceOS

InferenceOS is an experimental, open-source x86-64 operating-system which moves file-type knowledge away from the filename into an operating-system-controlled metadata and routing layer.

The defining experiment keeps an authoritative extension in each internal primary directory record and stores a separate extension-hash companion record. Ordinary CUI, GUI, and application views hide both values (file type extention and file type extension hash); privileged diagnostics and raw-disk analysis can reveal them.

Traditional operating systems commonly allow file-type information to become part of the filename or application-visible naming convention. In Windows, a filename such as report.docx explicitly carries its extension, and that extension participates heavily in application association. Windows Explorer may hide known extensions from the user, but the extension remains part of the filename and is readily available to applications.

Linux takes a more flexible approach. The Linux kernel does not fundamentally require filename extensions to determine what a file is. However, desktop environments and applications commonly rely on filename suffixes, MIME databases, file signatures, or combinations of these mechanisms to infer how a file should be handled.

InferenceOS takes a different architectural approach.

A file's type information remains internal to the operating system and InferenceOS-File System (hereinafter called InferenceOS-FS), rather than forming part of the ordinary application-visible identity of the file. InferenceOS will never even expose the file's extension through its official OS level API which lets people make applications and platforms such as .NET in case of Windows or Shell in case of Linux. This is because official API of different applications/software/platforms will be used by custom programs/applications to work on the file type extension they create/support, for example Microsoft Office's official graph API or Openpyxl is used to work on excel files. But in binary mode the InferenceOS' official OS level API will allow to work on any file in binary mode as this does not expose the format of the file. The file system approach that InferenceOS is offering can be adopted in the kernels of any existing operating system such as Windows and Linux (Ubuntu).

In InferenceOS Character User Interface or File Exploer the user may see a file simply as:

REPORT

while InferenceOS internally retains its authoritative extension and the corresponding extension-hash companion metadata.

Applications therefore do not need to ask:

Does this filename end with .DOC?

or:

Give me every file matching *.DOC.

Applications just ask for any particular file using its extensionless name and InferenceOS returns the file. If the file happnes to be in a format which the application software can work upon then it is fine, normal execution of the application software would follow. Otherwise there will be an application error stating "Unexpected file format", or whatever suitable user friendly error message the application software wants to gracefully degrade with.

This architecture can provide a narrower and more controlled security boundary.

An ordinary application does not need unrestricted access to the internal extension or extension hash. It receives files through operating-system-mediation which is a system call.

Consequently, applications have less opportunity to independently reinterpret filenames, incorrectly parse extensions, or make conflicting decisions about file type.

The approach also reduces the importance of filename-based deception. Names containing misleading combinations such as multiple extensions cannot be relied upon by applications as the authoritative declaration of file type, because InferenceOS would itself own the type association if implemented as formal industry recognized operating system.

The extension hash provides additional derived metadata that the operating system can use for efficient classification or very fast lookup.

InferenceOS does not attempt to secure file types merely by hiding extensions. It secures the file-type relationship by placing interpretation, validation, and application routing behind an operating-system-controlled boundary.

The distinction can be summarized as:

Windows: filename → extension → application association

Typical Linux desktop: filename/content → MIME/type inference → application

InferenceOS: file → OS-controlled type metadata → validated application capability → opaque file access

Security

Hiding extensions and using hash-based type lookup can reduce some attack surfaces, but it does not prevent hacking in general. Its value comes from changing who is allowed to know and interpret file type.

The strongest security benefit comes with this rule:

Applications do not inspect extensions themselves. They ask the OS for files they are permitted or designed to handle, and the OS performs type resolution internally.

For Example:

An application like Microsoft Word which for example can operate on or work on/with, file type extensions like: *.doc, *.docx, *.jpg, *.img, *.pdf etc etc.

Now since Microsoft Word knows that these are the file extensions it needs to work properly, it would only ask for files having these extensions from InferenceOS but scoped to a folder not for the entire hard disk. And InferenceOS will search the InferenceOS-FS FAT file system by converting the file extensions requested into a hash and search the InferenceOS file system with some very fast hashing based searching algorithm rather than doing just string comparison in a loop. This brings performance gain. The performance gain has to be measured in different forms of computing servers based on InferenceOS would support.

To illustrate this InferenceOS has two small applications called Doc Files and TXT Files which just show the files types they work on in their window. They are not yet ready to render file content. Notice the images below to see how file extension hiding takes place in CUI and GUI:

CUI Mode

1. It reduces filename-based deception

In conventional systems, users and applications frequently reason from names such as:

• invoice.pdf

• photo.jpg

• report.docx

Attackers can exploit that expectation with deceptive names:

• invoice.pdf.exe
• invoice.pdf.scr
• report.docx.exe

or with Unicode/look-alike tricks.

In InferenceOS, the ordinary user might simply see:

• Invoice

while internally the OS knows:

Internal extension: EXE

Extension hash: 6584638

Application class: Executable

The user-facing filename therefore cannot falsely advertise itself as .PDF, because the extension is not part of the presentation contract.

The OS determines the actual type.

This can eliminate an entire class of extension-spoofing social engineering.

Malware cannot simply enumerate *.DOC, *.XLS, etc.

Consider malicious software trying to find valuable files. On a conventional system, it might conceptually do:

• find *.docx
• find *.xlsx
• find *.pdf
• find *.key

3. Applications cannot arbitrarily ask for every interesting extension

Instead of allowing an application:

Give me all *.DOC files

InferenceOS could require:

Give application X the files it is registered to handle or it is asking for. Keeping a registry of application to extension mapping is optional and left open for pondering to OS implmenters.

Application

    |
    | "Give me my supported files"
    v

InferenceOS

    |
    +--> verifies application identity
    |
    +--> determines permitted file types
    |
    +--> searches internally
    |
    v

Opaque file handles

So malicious program MALWARE cannot simply request:

• *.DOC
• *.XLS
• *.PDF

because it never gets an API taking those extensions or enumerate filenames and inspect suffixes.

It could reduce ransomware reconnaissance

Imagine ransomware trying to locate valuable files. Typical targets might include:

• .doc
• .docx
• .xls
• .xlsx
• .pdf
• .jpg
• .sql
• .db

Traditional ransomware can enumerate files and rank them immediately from their extensions.

On InferenceOS an unprivileged malicious application might instead see:

• Q4 Results
• Family Photos
• Customer Data
• Research

without extension/type metadata.

More importantly, InferenceOS enforces/limits that to work on a certain file type use the official API provided by the application software that creates that type of file. For example, use official OpenOffice API to work on *.docx, *.pptx, *.csv, *.xslx. This would be the approach taken by any custom application software or program for example: custom tools users have to develop in day to day office work.

It can make application impersonation harder

Suppose a malicious application says:

“I support Excel documents. Give me every Excel file.”

InferenceOS does not have to trust that statement (when application to extention registry has been implemented).

Instead:

Application identity

        |
        v

Trusted application registry

        |
        +--> permitted TypeToken 14
        +--> permitted TypeToken 21
        |
        v

OS-controlled file enumeration

Demonstrated scope

• CUI and GUI views over the same VFS namespace, including File Explorer and filtered type viewers (DOC Files, TXT Files); the command prompt remains in the standalone CUI rather than opening automatically in GUI mode.
• A distinct InferenceOS-FS volume with a sparse 64 GiB reference disk, durable save ordering, metadata validation, and reboot-persistence workflows.
• Shell-mediated, opaque application file services that do not expose raw extensions or hashes.
• Reproducible freestanding C17 builds with pinned GCC and Clang profiles.
• An optional Extension Registry research path that always falls back to authoritative directory metadata.

The Extension Registry is disabled by default. Benchmark evidence may make an implementation proposal-eligible, but this README claims no performance improvement or default enablement.

InferenceOS is not production-ready, hardened, multi-user, network-complete, POSIX-compatible, or a general-purpose replacement for an established operating system. InferenceOS-FS is not FAT32-compatible.

Build and validation

Start with docs/build.md and the feature quickstart. The exact supported boundary and deferred capabilities are documented in docs/limitations.md. The final constitutional and release-claim disposition is recorded in docs/validation/constitution-check.md.

InferenceOS is licensed under the MIT License.

Quick Virtual Machine Creation in Hyper-V

Clone the repository. Open an elevated PowerShell window. Run from elevated PowerShell:

Set-Location C:\Users\konta\source\repos\InferenceOS

& .\tools\image\recreate_hyperv_vm.ps1 -Force -Confirm:$false ` -Start

Mandatory File System Mounting

• After the InferenceOS has booted up and command prompt is visible. Run following commands to mount the InferenceOS-FS FAT disk.

format disk0

mount disk0 /

Command and Feature Illustration Commands

The following commands are available at the InferenceOS> prompt. Arguments in angle brackets are required, while arguments in square brackets are optional. Commands that use a displayed path expect the extension-hidden name shown by dir. Diagnostic commands require the kernel-provided diagnostic capability described in the CUI documentation.

Command	Brief Description	Few Examples
help [command]	Lists every registered command, or shows the exact syntax and summary for one command.	help help write help diskinfo
version	Displays the current InferenceOS version.	version
clear	Clears the active text console.	clear
gui	Starts the graphical desktop; a startup failure leaves the CUI available.	gui
devices	Lists registered block devices and their status, sector geometry, and capacity.	devices
diskinfo <diskN>	Shows a block device's geometry, detected filesystem, classification, and mount state.	diskinfo disk0 diskinfo disk1
format <diskN>	Creates an InferenceOS-FS filesystem on an eligible unmounted device. This erases that device's existing filesystem data.	format disk0 format disk1
mount <diskN> /	Probes and mounts an InferenceOS-FS device as the VFS root.	mount disk0 / mount disk1 /
unmount /	Flushes storage and unmounts the VFS root when no operation is active.	unmount /
fsinfo	Displays mounted-filesystem identity, capacity, geometry, free-space, hash, and registry information.	fsinfo
sync	Persists filesystem and cache state, then flushes the device.	sync
reboot	Synchronizes required storage state and requests a restart.	reboot
shutdown	Synchronizes required storage state and requests a halt or power-off.	shutdown
create <path>	Creates an empty regular file at a canonical typed path.	create /DOCS/REPORT.TXT create NOTES.TXT create /IMAGES/LOGO.BMP
write <display-path> "<text>"	Creates an extensionless text file, or initializes an existing empty file, using its displayed path.	write NOTE "Hello" write /DOCS/REPORT "persistent data" write "/DOCS/REPORT (2)" "second copy"
append <display-path> "<text>"	Appends supported text to an empty or content-validated text file.	append NOTE " world" append /DOCS/REPORT " and more"
type <path>	Displays file content addressed by its canonical typed path.	type /DOCS/REPORT.TXT type NOTES.TXT
cat <display-path>	Validates a complete file as supported text and displays it using its extension-hidden path.	cat NOTE cat /DOCS/REPORT cat "/DOCS/REPORT (2)"
rename <display-source> <display-destination>	Renames or moves a displayed regular file while preserving its hidden authoritative extension.	rename NOTE MEMO rename /DOCS/REPORT /DOCS/SUMMARY rename /DOCS/NOTE /ARCHIVE/NOTE
delete <display-path>	Deletes the exact regular file selected by its displayed path.	delete NOTE delete /DOCS/REPORT delete "/DOCS/REPORT (2)"
search <extension>	Recursively finds files with an exact extension and prints extension-hidden absolute paths.	search DOC search .TXT search JPG
dir [path]	Lists display-safe entries in the current directory or a supplied directory.	dir dir /DOCS dir .
cd <path>	Changes the calling console's current directory.	cd /DOCS cd .. cd /
pwd	Prints the current directory.	pwd
mkdir <path>	Creates a directory.	mkdir /DOCS mkdir ARCHIVE mkdir /IMAGES
rmdir <path>	Removes an empty directory.	rmdir EMPTY rmdir /DOCS/OLD
fileinfo <display-path>	Shows privileged internal metadata for a file selected by its displayed path.	fileinfo REPORT fileinfo /DOCS/REPORT fileinfo "/DOCS/REPORT (2)"
hashinfo <display-or-canonical-path>	Shows privileged extension-hash values and companion-record validation state.	hashinfo REPORT hashinfo /DOCS/REPORT hashinfo /DOCS/REPORT.TXT
fatinfo <display-or-canonical-path>	Shows a privileged, bounded, validated cluster chain for a file.	fatinfo REPORT fatinfo /DOCS/REPORT fatinfo /DOCS/REPORT.TXT