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.