Hacker News new | past | comments | ask | show | jobs | submit login

The filesystem APIs for Windows and POSIX have extremely similar semantics when you bridge their superficial differences. I don't think this is as huge an achievement as suggested. Many multiplatform projects have similar wrapper layers. Indeed the FILE* abstraction in the C standard does some of it. (But not sufficient for the functionality that sqlite needs, hence the need for another wrapper.)

That's not a knock on sqlite, I consider it well implemented and one of my favorite libraries I've ever seen, used and studied.




> The filesystem APIs for Windows and POSIX have extremely similar semantics when you bridge their superficial differences.

This is in part because Windows and POSIX are relatives. Windows is (partly) descended from DOS, and DOS 2 deliberately borrowed a lot of ideas from Xenix (Microsoft’s Unix port). And Windows has continued to borrow ideas from POSIX since, e.g. Winsock is heavily based on Berkeley Sockets.

Compare DOS 2+ handle-based IO to CP/M: CP/M treats files as fixed length 128 byte records instead of bytes, you can only read or write a whole record at a time, and a file’s size on disk must be a whole multiple of 128 [0] - that has more in common with mainframe/minicomputer record-oriented IO than Unix-style byte-oriented filesystems

[0] later on, CP/M added an attribute in the directory entry to store how many bytes were valid in the last record of a file; but it wasn’t actually enforced by the filesystem, apps had to set/get the attribute using a separate API, a lot of apps just ignored it, and even for those who did try to use it, two completely opposite conventions of how to use it coexisted


Yeah, translating between Windows and POSIX paths is basically a one-liner:

   sed -e 's-/-\\-g' -e 's-^-C:-'




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: