Other answers already tell a great deal, I'll just add a bit more details to fill some gaps.
One of the question the author asks is:
If so, does this mean that outside of Windows, a filesystem isn't necessary to write to a hard drive?
Actually, you don't need it even inside Windows. But the devil is in the details:
At a low level, the hard drive is just a bunch of bytes that can be read and written. Each byte has a number - the 1st byte, the 2nd byte, etc. And... that's it. Just a bunch of numbered bytes. Note that there's no concept of a "file" or "directory" or "partition" or whatever. When an operating system wants to read or write to the drive, at the lowest level it just says to it "please give me bytes 123 to 456" or "please write this data into bytes 789 to 1234". Or something like that.
In fact, you can easily write a program like that too. If you're a programmer, all you need to do is open a special filename \\.\PhysicalDrive0
like a regular file and you get full access to ALL the bytes on the drive, just as they are written. (Note: this is under Windows. Under Linux you open one of the files under /dev
and other OSes might have other mechanisms still)
Mind you, you'll need admin privileges for that, since you do get access to all the sensitive information on the drive. But other than that, that's all there is to it. I've done it myself.
Now, actually, I've lied to you a bit. A little white lie. The drive doesn't actually deal in individual bytes. It reads and writes data in "sectors". That's just a fancy name for "a bunch of bytes at a time". For the "spinning rust" kind of drives, the sectors are usually 512 bytes large. So when you read or write to the drive, you need to do it in 512 byte large chunks. So, Windows actually tells the drive "get me sectors 1 to 5" or "write to sectors 6 to 8". But it doesn't really change the whole idea.
SSDs usually have larger sectors, and the sizes can vary between drives. Typically it's 4096 bytes, but there are drives with 2048 byte sectors, and probably other values too. Again - doesn't really matter, just something to keep in mind. The OS usually abstracts it away and allows you to read and write whatever, and then does a little extra work to make sure the result is what you expect it to be.
Next step are the "partition tables" that wallyk has nicely explained in his answer.
The partition tables aren't anything that the drive cares about - all it cares about is reading and writing sectors of bytes. But we, humans, would like to split the drive into "partitions" and that's where the partition tables come in. A partition table is, by convention, stored at the very start of the drive. It's probably documented in some standard somewhere too, so that all the tools and OSes have the same understanding of them.
The MBR (Master Boot Record) table is an older standard, there since 1982. Since at that time nobody had even dreamed of SSDs or sectors different than 512 bytes, the MBR was designed to take up exactly 1 sector (512 bytes) and had a bunch of other limitations, particularly relating to larger drive sizes.
Eventually the drives got large enough that MBR just wasn't enough, and GPT (GUID Partition Table) was introduced to get around those limits.
Now, whichever format you use, all that the partition table actually says is something along the lines of "The partion 1 exists on sectors 50 to 5000 and is formatted with the FAT32 filesystem; The partition 2 exists on sectors 5001 to 10000 and is formatted with the EXT4 filesystem" and so on.
From this the OS can find the actual partitions and parse the filesystems. And that's where you get files and folders and permissions and other stuff that the OS provides you with. This is all done in software.
And here's another thing to note - as I said, the partition tables are a convention, not a necessity. Hardware doesn't care about it, software does. So you can use a drive even without one. For example, this day and age, it's common practice to use LVM in Linux to manage your hard drives (it's a bit of a long story). And one possibility with that is to add a whole drive to the pool of devices managed by LVM. In this case, there will be no partition table on the drive - LVM will manage it instead.
7I don't know Windows well enough to answer this, still I have one observation: on certain level Windows likes (or used to like? – I'm not up to date with Windows) to treat partitions and filesystems almost as if they were one thing. In effect some Windows users tend to equate the two concepts. Technically these are different things. You can have partitions without filesystems; a filesystem without any partition; a filesystem smaller than its partition; a filesystem not corresponding with the partition type. This comment is to avoid confusion in case the simplified view meets the strict one. – Kamil Maciorowski – 2019-10-09T20:57:32.923
4Trivially, a swap partition doesn't have a filesystem and is written to on a hard drive, so that's the an example that answers your final question. Other examples are
fdisk
andmkfs
, which create partitions and filesystems - they wouldn't be able to work if there was no way to write to an unformatted disk! – Toby Speight – 2019-10-10T15:15:30.3531"does this mean that outside of Windows, a filesystem isn't necessary to write to a hard drive" – It's true inside of Windows as well. How do you think Windows writes a filesystem to a hard drive? – Jörg W Mittag – 2019-10-13T00:02:02.500