3 ms·

That's an interesting point, and indeed NT has a curious history in that regard - Microsoft was originally planning an OS/2-based API as the dominant one, and i

That's an interesting point, and indeed NT has a curious history in that regard - Microsoft was originally planning an OS/2-based API as the dominant one, and it was only due to the success of Windows 3.0 that they ended up adapting the Windows API to 32 bits. Microsoft has always been dominated by backwards compatibility constraints so there probably wasn't much scope for a massive redesign of the API, as it was in their best commercial interests for 16 and 32 bit Windows APIs to match as closely as possible, to ease porting of third party software.

acdha 11y ago
Backwards compatibility was definitely a driving factor for a lot of bad decisions back then. Here's a great example of how they wanted to avoid breaking a few apps written for a Win95 beta build: http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532... That's a bit silly but it also meant things like dutifully porting the real-mode Windows messaging system's feature which allowed any app to execute code in any other app: http://en.wikipedia.org/wiki/Shatter_attack http://en.wikipedia.org/wiki/Shatter_attack Like, say, sending a message to the anti-virus software running as SYSTEM to get root… The most entertaining bug I found was one of the times they failed at portability: one of the Win32 APIs to enumerate the contents of a directory worked 100% of the time on the Windows NT systems our development team used but returned no results on Windows 95 unless you had enabled network sharing (you didn't even need to share something; just starting the service was enough). This manifested in a very confused user wondering why our open dialog showed C:\ as empty when Explorer showed their files were still there.

3 ms·

That's an interesting point, and indeed NT has a curious history in that regard - Microsoft was originally planning an OS/2-based API as the dominant one, and i

by geographomics 11y ago

acdha 11y ago
Backwards compatibility was definitely a driving factor for a lot of bad decisions back then. Here's a great example of how they wanted to avoid breaking a few apps written for a Win95 beta build: http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532... That's a bit silly but it also meant things like dutifully porting the real-mode Windows messaging system's feature which allowed any app to execute code in any other app: http://en.wikipedia.org/wiki/Shatter_attack http://en.wikipedia.org/wiki/Shatter_attack Like, say, sending a message to the anti-virus software running as SYSTEM to get root… The most entertaining bug I found was one of the times they failed at portability: one of the Win32 APIs to enumerate the contents of a directory worked 100% of the time on the Windows NT systems our development team used but returned no results on Windows 95 unless you had enabled network sharing (you didn't even need to share something; just starting the service was enough). This manifested in a very confused user wondering why our open dialog showed C:\ as empty when Explorer showed their files were still there.