In other words, Microsoft’s SQL Server for Linux is really the Windows SQL Server executable with a small Windows 8 kernel glued underneath, all running in a normal Linux process.
…
The Register asked Microsoft to explain itself but has not heard back.
I didn’t really see the problem with this. This is roughly how Linux stuff is run inside of Windows, Solaris and FreeBSD, and people don’t seem upset about that.
It’s also hardly a new idea. Office 6 (I think?) for Mac basically bundled Windows 3.1, QuickTime ported most of the Mac toolbox, iTunes added Carbon to that, etc. Some of these had really bad UIs for their non-native platform, but all of them allowed quick and useful ports that would otherwise have been very difficult to pull off. I mean, hell, basically the entire Windows API is a shim at this point in the first place.
But… it’s such a massive hack. It’s not like Microsoft is making a compatibility layer - they’re just releasing a database which really ought to be properly ported (MySQL doesn’t run a Linux compatibility layer on Windows, same for SQLite or postgres). It just seems like unnecessary overhead because of laziness to me (then again, that’s the Microsoft way).
SQL Server is a massive product, if you want a native port that’s going to be a huge effort. But what is wrong with pushing the abstraction layer even further down? Is it unnecessary overhead? FreeBSD does this for Linux binaries and it is claimed that it can run some binaries faster than native Linux on equivalent hardware. Is there a reason to think that this is more overhead than any other library which abstracts the OS away?
to be a huge effort. But what is wrong with pushing the abstraction layer even further down? Is it unnecessary overhead? FreeBSD does this for Linux binaries and it is claimed that it can run some binaries faster than native Linux on equivalent hardware. Is there a reason to think that this is more overhead than any other library which abstracts the OS away?
I’m actually shocked they even tried to do this. SQL server is so integrated into the windows kernel API for performance reasons, it’s pretty amazing they ported it to another environment period as it’s effectively a light wrapper to the windows kernel in a lot of cases.
I’m curious what other programs could benefit from the linux <=> windows shim SQL server for linux uses.
Others had said NT’s direction was influenced by the needs of SQL Server, like with fibers. SQL Server also does a lot of things like scheduling inside of itself, which makes this all the more interesting.
I actually think it’s a neat solution to the problem, and I don’t see how it’s much different than using a framework like Qt or some other big shared library.
One advantage of doing it this way is that it keeps the SQL Server code “clean” in that it can use the same code base on Linux and WIndows without a bunch of #ifdef garbage or anything like that.
It also pushes the problem of semantic differences between Windows and Linux into a reusable library. Process creation, for example, is significantly different on the two systems, but using this technique means SQL Server doesn’t have to care as long as the “ NT kernel library” does the right thing.
And if done correctly, the kernel library is reusable for porting other applications.
Remember that Microsoft’s software has historically been built to be as hard to port as possible to increase lock-in. It took massive hacks to even open and render Word documents. I imagine SQL Server is also heavily tied to Windows in non-portable ways, maybe even with undocumented functions. A Windows compatibility layer that works for all of them is a one-time investment that would keep paying off. If it’s not open-source, it also avoids helping the competition port stuff they don’t want outside things like WINE.
I think it’s pretty cool. I mean, if I wanted to run SQL Server in production, I’d run it on Windows, but I could definitely see installing it locally to play around with. For a job interview last year I had to do some work on a SQL Server hosted DB, and it was a perfectly pleasant experience, which nobody has ever said about Oracle anything ever.
I didn’t really see the problem with this. This is roughly how Linux stuff is run inside of Windows, Solaris and FreeBSD, and people don’t seem upset about that.
It’s also hardly a new idea. Office 6 (I think?) for Mac basically bundled Windows 3.1, QuickTime ported most of the Mac toolbox, iTunes added Carbon to that, etc. Some of these had really bad UIs for their non-native platform, but all of them allowed quick and useful ports that would otherwise have been very difficult to pull off. I mean, hell, basically the entire Windows API is a shim at this point in the first place.
But… it’s such a massive hack. It’s not like Microsoft is making a compatibility layer - they’re just releasing a database which really ought to be properly ported (MySQL doesn’t run a Linux compatibility layer on Windows, same for SQLite or postgres). It just seems like unnecessary overhead because of laziness to me (then again, that’s the Microsoft way).
SQL Server is a massive product, if you want a native port that’s going to be a huge effort. But what is wrong with pushing the abstraction layer even further down? Is it unnecessary overhead? FreeBSD does this for Linux binaries and it is claimed that it can run some binaries faster than native Linux on equivalent hardware. Is there a reason to think that this is more overhead than any other library which abstracts the OS away?
I’m actually shocked they even tried to do this. SQL server is so integrated into the windows kernel API for performance reasons, it’s pretty amazing they ported it to another environment period as it’s effectively a light wrapper to the windows kernel in a lot of cases.
I’m curious what other programs could benefit from the linux <=> windows shim SQL server for linux uses.
Others had said NT’s direction was influenced by the needs of SQL Server, like with fibers. SQL Server also does a lot of things like scheduling inside of itself, which makes this all the more interesting.
I actually think it’s a neat solution to the problem, and I don’t see how it’s much different than using a framework like Qt or some other big shared library.
One advantage of doing it this way is that it keeps the SQL Server code “clean” in that it can use the same code base on Linux and WIndows without a bunch of #ifdef garbage or anything like that.
It also pushes the problem of semantic differences between Windows and Linux into a reusable library. Process creation, for example, is significantly different on the two systems, but using this technique means SQL Server doesn’t have to care as long as the “ NT kernel library” does the right thing.
And if done correctly, the kernel library is reusable for porting other applications.
Remember that Microsoft’s software has historically been built to be as hard to port as possible to increase lock-in. It took massive hacks to even open and render Word documents. I imagine SQL Server is also heavily tied to Windows in non-portable ways, maybe even with undocumented functions. A Windows compatibility layer that works for all of them is a one-time investment that would keep paying off. If it’s not open-source, it also avoids helping the competition port stuff they don’t want outside things like WINE.
I think it’s pretty cool. I mean, if I wanted to run SQL Server in production, I’d run it on Windows, but I could definitely see installing it locally to play around with. For a job interview last year I had to do some work on a SQL Server hosted DB, and it was a perfectly pleasant experience, which nobody has ever said about Oracle anything ever.