Hacker News new | ask | show | jobs
by esterly 3247 days ago
SQL Server source code originated on UNIX, ported to OS/2 then Windows. See the Sybase history https://en.wikipedia.org/wiki/Sybase
2 comments

SQL Server 7.0 was a complete rewrite (you will notice that the Sybase copyright notices disappeared around then).
A rewrite, or a "rewrite"? I've seen plenty of press articles about something MS "rewrote" from the ground up, including windows itself, and they are never true.

Unless they actually started from a blank source repository then it was not a rewrite.

i was there, from 1995 on. It was a real rewrite. sybase's optimizer was the biggest piece of shit ever. losing predicates, functions that called each other multiple times to rewrite the tree. We didn't have docs on the page formats, we have to reverse engineer it. The only piece not completely rewritten in the first release in 7.0 shipping in 1998 was the tree/algebraizer that was the input to the query processor. it was so messy and horrible even our team of champions couldn't do it in the first release.
It would seem a lot of the protocol was kept though, no? IIRC there wasn't much diff between the mssql 6.5 protocol and mssql 7 protocol. I had been working with the freetds project in 1999/2000 and spent way too much time learning about some of that, although... it was 17 years ago and details are fading!
Most of the new stuff was on ADO and ODBC drivers, if I recall correctly.

I only made use of TDS C library, because there were some DML features not yet exposed via ADO and ODBC.

I think it was backwards compat at the least but i didn't work on that area.
> sybase's optimizer was the biggest piece of shit ever

Sybase even in the 11.5 days was horrible. Even with updated stats, it would drop off the cliff and you would suddenly have queries that took less than a second go to multiple minutes. It was the database where I had to force a lot of indexes. It really got confused with simple reference tables. Temporary tables were just plain problematic unless you did the trick of declaring them in the outer procedure and then calling another stored procedure to actually use the temp table.

I suppose there may have been some old code in there to maintain backwards compatibility with e.g. the T-SQL parser, but it was C before and C++ after the "rewrite"...
A rewrite is a rewrite, even if it isn't 100% new code, check a dictionary.
I checked a few (https://en.wiktionary.org/wiki/rewrite) they all seem to indicate that it's writing something again. Some included revise as a synonym, but the parent said "complete rewrite" which would exclude that. Otherwise where is the cut off line? Can I rewrite 1% and call something a rewrite?

I never knew the definition of rewrite would be so controversial.

Write something down, cross it out, (re)write the same thing again

What you wrote is the same but will be a little different

Don't down vote him. More often than not those are just normal refactoring with PR attempts to get rid of old license info. See IE7, it got rid of Mosaic license info yet even IE11 and early Edge contains web render code and mouse behaviors that can be traced back to Mosaic web browser, where it forked off. The same is with game engines, Valve's Source engine 2 started as a fork of ID's Quake 1 engine and it's still evident even in 2017. Or Dunia engine from Ubisoft traces back to FarCry 1 engine from Crytek. Or Call of Duty engine originates in Quake 3 engine from ID. Or in WinWord 2010 originates in WinWord2 code from 1990, with code that predates threads and uses fibers (known as coroutines nowadays in other languages).
it was far from a simple refactoring. we wrote almost every piece of it new and from scratch.
I'm pretty skeptical that Edge ever contained any old Spyglass code. If they kept the licensing disclaimer in those early versions, I suspect it was because proving that none of the old code was there wasn't a priority for anyone.
Unless I stop understanding English, all those examples are still a rewrite, writing something anew, doesn't mean throwing 100% of the old stuff away.
And these can also be explained by unit tests .. you keep the old unit tests and rewrite everything so those tests pass. Sometimes that means getting some of the same weird quirks or gotchas, but hopefully refactored so they are all in one place and clearly documented.
IE4 was a rewrite, not a refactor job.
Sybase had a version running on Linux back in 2003. Used it for a big analytics project. It blew away SQL Server in term of reliabilty. No need for regular restarts.
If you need regular restarts of SQL Server then there's something really quite wrong with your setup.
SQL Server requires regular restarts?

I find this hard to believe.

I don't know which version the parent looked at, but we had a mix of SQL Server 6.5 and 2000 servers. Those on 6.5 suffered from all kinds of phantom errors which a regular restart schedule fixed. SQL Server 2000 on the other hand was solid.
similar experience - worked with 6, 6.5 and 7 on NT 3.5 and NT 4. 4 was better, but it often was 4 itself which ended up needing rebooting, vs SQL Server itself, but... when one's on the other, does it make much of a difference? There wasn't an option to run MSSQL 7 on anything else, IIRC.

I do remember 7 on 4 was much improved re: requiring reboots, and the projects I was on ended up doing it periodically more out of proactive concern re: NT4 than real demonstrated problems with MSSQL 7. 1999 project had 80 NT servers running IIS reboot on a schedule every few hours with a big load balancer in front. 70+ up at any one time, always a handful being reboot and coming in and out of the pool. If we didn't proactively do it, they'd just go down anyway. IIRC that spoke more to IIS than NT but again... how can you necessarily tell the difference? Not rhetorical, there were probably good ways to dig in and try to determine root causes (and I think some folks tried or did) but it didn't mean we could actually do anything about it (like patch and recompile the NT kernel).