Lesson 1: Operating System Families, Filesystems, and Lifecycle

A technician sees a laptop that cannot open a file.

What is the first command?

Wrong question.

First ask:

• Which operating system is this?
• Which filesystem is involved?
• Is the file local, removable, or synchronized?
• Is the application supported on this platform?
• Is the operating system still supported by its vendor?

The support path starts with identifying the system you actually have.

Operating systems solve similar jobs with different designs

Desktop and mobile operating systems all coordinate hardware, applications, files, identities, networking, and user interaction.

They do not expose those responsibilities in the same way.

Windows

Common across consumer, education, and enterprise PCs. Windows support often involves editions, NTFS volumes, drivers, services, Registry or policy state, Microsoft management tools, and a broad application ecosystem.

macOS

Apple's desktop operating system is tightly integrated with supported Apple hardware and services. Support commonly involves APFS, application bundles/packages, Finder, Disk Utility, Keychain, FileVault, Time Machine, Apple services, and organization management policy.

Linux

Linux appears through many distributions rather than one vendor desktop product. The kernel is shared across the family, but package managers, release models, desktop environments, service tooling, and configuration conventions can differ.

"This is Linux" is sometimes only the start of identification.

ChromeOS

ChromeOS emphasizes browser and web applications, cloud services, managed-device workflows, and a more appliance-like desktop model on supported Chromebook-style systems.

A traditional Windows .exe package is not automatically useful there.

iOS and iPadOS

Apple mobile platforms emphasize application-store or managed deployment, permissions, synchronization, device policy, and tight hardware integration.

Android

Android runs across a broad mobile-device ecosystem with vendor variation, app-store or managed deployment, permissions, account synchronization, and device-management considerations.

Mobile support is not desktop support with a smaller screen.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

Cross-platform evidence

Same diagnostic method, platform-specific tools

Ask the same boundary questions while collecting evidence with the operating system's native tools.

1. 01
   Windows

   NTFS/FAT/exFAT plus Disk Management, Event Viewer, services, and PowerShell.

2. 02
   macOS

   APFS/HFS+ plus Disk Utility, Console, launch services, and system settings.

3. 03
   Linux

   ext4/XFS/Btrfs and others plus lsblk, mount, journalctl, systemd, and permissions.

4. 04
   Method

   Baseline → evidence → narrow theory → controlled action → original-function verification.

The filesystem is part of the platform contract

A filesystem determines how storage is organized and can affect:

• file naming;
• permissions;
• metadata;
• journaling and resilience;
• volume size;
• file-size limits;
• cross-platform compatibility.

A healthy drive can still be unusable for the required workflow because the receiving platform does not support the filesystem the way you expect.

NTFS

NTFS is the common Windows filesystem for system and data volumes.

It supports Windows features such as access-control permissions, large files and volumes, journaling, and metadata used by Windows services.

If a removable NTFS drive connects to another operating system, do not assume identical read/write behavior simply because the USB device is detected.

Hardware detection and filesystem compatibility are different layers.

ReFS

ReFS is a Microsoft filesystem designed for supported resilience and data-integrity workloads.

It is not simply "NTFS 2" and should not be treated as a universal replacement for normal Windows client volumes.

The use case decides whether it belongs.

FAT32

FAT32 is widely recognized across platforms and devices.

That compatibility comes with older limits, including a well-known per-file size ceiling compared with modern filesystems.

A large video failing to copy to a FAT32 device may be a filesystem-limit problem even when plenty of total free space remains.

That is stronger evidence than "the USB drive is bad."

exFAT

exFAT is commonly used on removable media that needs broad cross-platform support and larger-file capability than FAT32.

That makes it useful in some shared Windows/macOS workflows.

It still does not provide every feature of NTFS, APFS, or Linux-native filesystems.

Compatibility always has a tradeoff.

ext4 and XFS

ext4 is common across Linux systems and works well as a general-purpose filesystem.

XFS is also widely used, especially in enterprise and server Linux workloads.

A Windows workstation seeing the physical disk does not mean Windows natively understands an ext4 or XFS volume for normal client use.

Again:

physical device detected
        ≠
filesystem supported for required use

APFS

APFS is Apple's modern filesystem family across current Apple platforms.

A disk formatted as APFS may be perfectly healthy while another platform cannot use it natively as required.

Do not erase the disk to "fix compatibility" before protecting the data and understanding the workflow.

Worked case: the same drive behaves differently on two computers

Evidence:

external SSD hardware: detected on both systems
macOS: mounts volume and reads data
Windows: detects USB storage device but cannot use current filesystem normally
filesystem: APFS

What failed?

Not necessarily the cable.

Not necessarily the SSD.

The compatibility boundary is between the filesystem and the receiving operating system.

A strong service record says that.

A weak one says:

Drive only works on Mac.

That describes the symptom without explaining the mechanism.

Lifecycle is another compatibility boundary

An operating system can keep booting long after normal vendor support ends.

End of life or end of support can mean:

• security updates stop;
• application vendors stop supporting the release;
• browsers and drivers stop updating;
• management platforms drop support;
• new hardware becomes incompatible.

"It still turns on" proves very little about whether the platform remains appropriate for managed use.

Worked case: legacy application on an unsupported OS

Evidence:

old OS: boots
legacy application: works
vendor security support: ended
modern replacement: not yet available

There are two requirements in tension:

• preserve the application function;
• reduce the risk of an unsupported platform.

Possible architecture decisions might include application migration, replacement software, isolated virtualization, restricted network access, or planned retirement.

Virtualization may preserve compatibility.

It does not turn an unsupported OS into a supported one.

Application compatibility follows the platform

A Windows .exe, macOS .app or .pkg, Linux package, mobile app, or browser-based application may require completely different deployment paths.

Do not start with:

How do I force this installer to run?

Start with:

Is this application actually supported on this OS and architecture?

That question prevents a lot of wasted effort.

Compare platforms by support questions

For each supplied system, identify:

OS family
workstation or mobile
filesystem in use
application distribution model
update / lifecycle owner
management / identity consideration
one cross-platform compatibility risk
one piece of evidence to inspect before changing anything

Use Windows, macOS, Linux, ChromeOS, iOS/iPadOS, and Android examples.

Then classify NTFS, ReFS, FAT32, exFAT, ext4, XFS, and APFS by likely platform/use and one compatibility concern.

Before you move on

Cross-platform support is not about memorizing seven operating systems independently.

Keep the durable questions:

what platform?
what filesystem?
what application model?
who owns updates and policy?
what is supported?
what data must survive?

Then use the platform's own tools.

Next we do exactly that with macOS.