4 ms·

Its kind of cool that you can abstract the operating system with only a 200-line long header file.

by rhelz 2y ago

lostmsu 2y ago
It is missing threading and networking. Also permissions.
asveikau 2y ago
This is the interface description. It's not the .c file that implements the abstraction. There is lots of code behind this, redundantly implementing the calls using either Win32 or POSIX.
- JaDogg 2y ago
  But you do not need to know about them if abstraction works, I assume it is sufficient for SQLite use case.
  - asveikau 2y ago
    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.
    - csense 2y ago
      Yeah, translating between Windows and POSIX paths is basically a one-liner: sed -e 's-/-\\-g' -e 's-^-C:-'
    - skissane 2y ago
      > 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
- rhelz 2y ago
  // This is the interface description // Yeah, but that is the abstraction. The associated .c files are not the abstraction, because they could be implemented any number of different ways, and it would still be the same abstraction. It's incredible that even the header file is around 200 LOC. For state-of-the-art, very performant database, I would have thought that all manner of Os-specific IO api's would have to be used.
  - asveikau 2y ago
    I don't find it that remarkable. They are function signatures for open, close, read, write, a few locking operations... The signatures for the same operations on both Win32 and POSIX look extremely similar to this. These are fairly "obvious", most multiplatform code written in C has something pretty close to this.
msla 2y ago
The dividends of damn near everyone who still matters copying Unix and developing similar ideas about subdirectories and filenames and so on. There's still differences between Windows and Everything Else, but it's easier to ignore them now that, for example, all of the old flat file systems with no directories (like on the original MacOS, CP/M, MS-DOS 1) are all comprehensively obsolete and ignored.
- skissane 2y ago
  > all of the old flat file systems with no directories (like on the original MacOS, CP/M, MS-DOS 1) are all comprehensively obsolete and ignored. not quite true. The classic flat OS/360 filesystem is still heavily used on IBM mainframes. Of course, probably your app will never run on a mainframe, and if it does, it will probably run either under z/Linux or the z/OS UNIX filesystem (zFS). But there is still a lot of actively supported in-production software which does, since born-on-the-mainframe apps mostly use the classic filesystem and the POSIX file API is mainly used by apps ported from elsewhere
01HNNWZ0MV43FF 2y ago
I can abstract the entire sun with a pair of sunglasses

Its kind of cool that you can abstract the operating system with only a 200-line long header file.

by rhelz 2y ago

Its kind of cool that you can abstract the operating system with only a 200-line long header file.

lostmsu 2y ago

It is missing threading and networking. Also permissions.

asveikau 2y ago

This is the interface description. It's not the .c file that implements the abstraction. There is lots of code behind this, redundantly implementing the calls using either Win32 or POSIX.

JaDogg 2y ago
But you do not need to know about them if abstraction works, I assume it is sufficient for SQLite use case.
- asveikau 2y ago
  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.
  - csense 2y ago
    Yeah, translating between Windows and POSIX paths is basically a one-liner: sed -e 's-/-\\-g' -e 's-^-C:-'
  - skissane 2y ago
    > 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
rhelz 2y ago
// This is the interface description // Yeah, but that is the abstraction. The associated .c files are not the abstraction, because they could be implemented any number of different ways, and it would still be the same abstraction. It's incredible that even the header file is around 200 LOC. For state-of-the-art, very performant database, I would have thought that all manner of Os-specific IO api's would have to be used.
- asveikau 2y ago
  I don't find it that remarkable. They are function signatures for open, close, read, write, a few locking operations... The signatures for the same operations on both Win32 and POSIX look extremely similar to this. These are fairly "obvious", most multiplatform code written in C has something pretty close to this.

msla 2y ago

The dividends of damn near everyone who still matters copying Unix and developing similar ideas about subdirectories and filenames and so on. There's still differences between Windows and Everything Else, but it's easier to ignore them now that, for example, all of the old flat file systems with no directories (like on the original MacOS, CP/M, MS-DOS 1) are all comprehensively obsolete and ignored.

skissane 2y ago
> all of the old flat file systems with no directories (like on the original MacOS, CP/M, MS-DOS 1) are all comprehensively obsolete and ignored. not quite true. The classic flat OS/360 filesystem is still heavily used on IBM mainframes. Of course, probably your app will never run on a mainframe, and if it does, it will probably run either under z/Linux or the z/OS UNIX filesystem (zFS). But there is still a lot of actively supported in-production software which does, since born-on-the-mainframe apps mostly use the classic filesystem and the POSIX file API is mainly used by apps ported from elsewhere

01HNNWZ0MV43FF 2y ago

I can abstract the entire sun with a pair of sunglasses