SQLServer is super Win32 specific, even to the extent of using undocumented Windows APIs (I think the canonical example is NtReadFileScatter and NtWriteFileScatter, which are more flexible than the documented ReadFileScatter and WriteFileScatter wrappers; I wouldn't be surprised if it uses many more undocumented calls).

SQLOS isn't an abstraction layer over the operating system necessarily. It's more of an abstraction over the _machine_ that allows scaling between 8GB and 512+GB of RAM, 4 to 64+ cores, etc.

That said, since SQLOS does handle all memory management and file I/O for SQLServer, it probably did make porting slightly easier.

Actually, "fibers" are a custom abstraction that can be used instead of threads, but SQL Server uses the threading model by default.

So you're right, I do think it will be an engineering challenge, but as parent mentioned, the fact that SQL Server kind of treats the OS itself as abstract means I think they might have a path forward. Otherwise, I don't think they would have announced this.

Another way of thinking about this is, maybe the low-level refactoring necessary to make this run on Linux will actually be good for the SQL Server engine, although it will most likely go through a period of serious instability while they figure out how!