Linked by Adam S on Sun 29th Jun 2008 16:10 UTC
Windows "Microsoft Windows has put on a lot of weight over the years" writs Randall Stross in a recent New York Times blog entry on Windows' legacy code. "Beginning as a thin veneer for older software code," he continues, "it has become an obese monolith built on an ancient frame. Adding features, plugging security holes, fixing bugs, fixing the fixes that never worked properly, all while maintaining compatibility with older software and hardware -- is there anything Windows doesn't try to do?" Does Microsoft have the business savvy or guts to rewrite Windows?
Thread beginning with comment 320681
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: No
by TemporalBeing on Mon 30th Jun 2008 14:07 UTC in reply to "RE: No"
TemporalBeing
Member since:
2007-08-22

This jihad to blame WOW(WOW16/WOW64) or backwards compatibility is subterfuge for horrible feature creep and horrible design. The NT kernel is the most understood, tested and architected kernel in the world, surround by heaps of cruft, .NET, a "bad java," and a ton of win32 bad crud. I'd like to see one day a "gentoo" or "debian" for NT kernel, you might be surprised if you built a sane userland around the NT kernel it wouldn't be a bad thing.

Blaming Windows 3.1/win32s/Windows 95 compatibility for the sorry state of affairs in Vista is complete folderol.


The NT kernel itself is quite good. However, what kills Windows is (a) 3rd party drivers (e.g. non-Microsoft provided drivers) for hardware such as video cards, sound cards, NICs, and various chipsets - yep, about the whole system; if you have good hardware with good drivers you're fine - and usually the Microsoft Certified drivers are good drivers - in terms of being friendly with the OS and not crashing the thing. (Keyword: usually)

(b) The Win32 API. As far as security goes - it's just horrid. For example, any application can modify any other application's GUI interface without necessarily having permission from the originating application. (Don't that before to get passwords; a little harder now since they did fix that by using encrypted text for the text box when its designated as a password text box; but it can still be captured without permission.)

Honestly, they need to get take the whole Win32 API and deprecate it; and start a new API that has security as its foundation. Keep it around for legacy support; put it in a sandbox even so it can't harm newer applications. And they could do that. (And no, the .NET API does not qualify since it basically calls back to Win32 to begin with.) The required functionality is already a center piece to the NT kernel since the Win32 API is one of a number of APIs (including a POSIX specific API) that the NT kernel supports natively through a DLL extension. There's nothing saying they couldn't create a WinNG (Next-Generation) API and support it alongside (at the same level) as the Win32 API; and move developers over to it - leaving the Win32 API there for legacy and basically unchanged. Developers will move; even if forced.

The likelihood of Microsoft doing that - near zilch.

Reply Parent Score: 1

RE[3]: No
by google_ninja on Mon 30th Jun 2008 15:19 in reply to "RE[2]: No"
google_ninja Member since:
2006-02-05

(And no, the .NET API does not qualify since it basically calls back to Win32 to begin with.)


It doesn't have to (as the mono guys have proven).

Reply Parent Score: 2

RE[4]: No
by TemporalBeing on Mon 30th Jun 2008 15:27 in reply to "RE[3]: No"
TemporalBeing Member since:
2007-08-22

"(And no, the .NET API does not qualify since it basically calls back to Win32 to begin with.)


It doesn't have to (as the mono guys have proven).
"

True, but that's basically what it does on Windows. It's doesn't call down to the NT Kernel API for everything - it uses Win32 where it can. Thus it won't work for what I said. And, not everyone is or will ever use .NET for everything. C/C++ and other languages will be needed for applications that will work outside the .NET framework, so they still need another API in addition to .NET even if they ported .NET to using just the NT kernel API.

Reply Parent Score: 1

RE[3]: No
by luzr on Mon 30th Jun 2008 16:06 in reply to "RE[2]: No"
luzr Member since:
2005-11-20


(b) The Win32 API. As far as security goes - it's just horrid.


BTW, GUI alternatives are no better. E.g. it is way too easy for one X11 app to crash the whole sessions (in fact, much easier than to crash WinXP GUI).

I am not sure about MacOS X here, but since it follows basically same coding paradigms, I would not be surprised it shares same problems.

In reality, I believe that bad security of GUIs is somehow caused by its very purpose:

Advanced GUI is about sharing between applications (mouse, keyboard, clipboard, objects etc...). Wherever is sharing, there is insecurity. Security is about isolation - but not many users would welcome "isolated" GUI....

Reply Parent Score: 1

RE[4]: No
by TemporalBeing on Mon 30th Jun 2008 17:11 in reply to "RE[3]: No"
TemporalBeing Member since:
2007-08-22

"
(b) The Win32 API. As far as security goes - it's just horrid.


BTW, GUI alternatives are no better. E.g. it is way too easy for one X11 app to crash the whole sessions (in fact, much easier than to crash WinXP GUI).

I am not sure about MacOS X here, but since it follows basically same coding paradigms, I would not be surprised it shares same problems.

In reality, I believe that bad security of GUIs is somehow caused by its very purpose:

Advanced GUI is about sharing between applications (mouse, keyboard, clipboard, objects etc...). Wherever is sharing, there is insecurity. Security is about isolation - but not many users would welcome "isolated" GUI....
"

I don't think it's so much that issue. Sure, applications can share data. However, to do so they need to do it over approved channels and every application should have to approve what from itself can be shared. The one thing you can't get around is sharing with the kernel - but that typically happens by request of the application so that's not really an issue.

But when another application wants to get data from the application, there should be a function that application (or even the kernel) calls into the application its trying to get data from and say 'hey, i'd like this access, can I have it?' with a default of denying access (for applications that don't code the function - default to secure) - threads and processes spun off from the application would be a challenge to answer for (likely default of approve for threads and deny for processes). And that would have to go for everything the application controls (e.g has opened, creates, etc.).

It's practical and it would work. And the security it would provide would work wonders - though not seen by the average user. You'd be able to quickly eliminate a lot of bad software (virii, trojans, keyloggers, etc.) as they would have to (a) break into the API to get what they currently get and (b) they'd be denied outright by the security.

Sure there would be some challenges with getting it working right, and developers would have to learn some new tricks too. But in the end, it would provide a security that is very well needed.

Additionally, the simple fact that an application is getting data from another application (e.g. keystrokes, etc.) does not prohibit this. Your base layer (e.g. the GUI API) would be able to get the application approved to receive that data from the OS/App providing it. The application would be able to act just as it does not, except with the security. Copy/Paste would be one bit that would likely have to be approved when going from one application (e.g. Notepad) to another (e.g. Wordpad, Vi, Emacs, etc.), but not within itself - the same instance of the program.

Reply Parent Score: 2

RE[3]: No
by luzr on Mon 30th Jun 2008 16:11 in reply to "RE[2]: No"
luzr Member since:
2005-11-20


Honestly, they need to get take the whole Win32 API and deprecate it; and start a new API that has security as its foundation.


So, do suggest that all Windows software, including e.g. OpenOffice or FireFox, is to be rewritten?

Can you imagine the real impact of obsoleting Win32?

And, BTW, Win32 has security in its foundation. Maybe later, to allow users to do what they need to do (like sharing clipboard etc...) they have softened the approach.

Reply Parent Score: 1

RE[4]: No
by TemporalBeing on Mon 30th Jun 2008 17:22 in reply to "RE[3]: No"
TemporalBeing Member since:
2007-08-22

"
Honestly, they need to get take the whole Win32 API and deprecate it; and start a new API that has security as its foundation.


So, do suggest that all Windows software, including e.g. OpenOffice or FireFox, is to be rewritten?

And, BTW, Win32 has security in its foundation. Maybe later, to allow users to do what they need to do (like sharing clipboard etc...) they have softened the approach.
"


Win32 has only as much security in it as the NT kernel forces it to have. That security is primarily related to user or system related tasks (e.g. files, permissions, etc.). It has nothing to do with application to application security, which is what is heavily needed - especially in Windows. If Microsoft really wanted to clean up the security of applications - they'd start there. It'd go a long way to eliminating virii, trojans, keyloggers, etc. (Phishing probably wouldn't be destroyed since that's a different attack angle.)

As I said in the GP - they could keep Win32 around for legacy or even sandbox it to protect the apps. Developers could, over time, update to the new APIs.

Can you imagine the real impact of obsoleting Win32?


Yes, I can. Yes, a lot of apps would need to be updated - if the companies/projects were going to continue releasing new versions. Yes, there would be tremendous opportunity for new work, rework, etc.

But think of this - wouldn't the security for end-users be work it? For your application even?

It could potentially make a lot of current virii obsolete since it would eliminate entire attack vectors - e.g. keyloggers, API generated buffer overflows, etc.

(By API generated buffer overflow, I'm referring to situations where a program has set a dialog control to be an exact size - e.g. 10 characters - and a third party program changes it, and then stuffs data at the end. The originating program should expect that the control won't change its size unless it itself changed the size.)

Reply Parent Score: 2

RE[4]: No
by apoclypse on Mon 30th Jun 2008 19:36 in reply to "RE[3]: No"
apoclypse Member since:
2007-02-17

The power of OSS is that they can probably move to whatever new api comes out without much issue. Firefox and OpenOffice are cross platform, they have no issues running without win32 now why would they have issues in the future. Developers will move to whatever they see fit to get their applications running on the platform, I really doubt an api change will deter them for long. The real issue are devs like Adobe, they are now stuck porting Photoshop to cocoa to get 64-bit support despite the countless warnings by Apple that cocoa was the way to go. Of course Adobe is getting their ass in gear now, and they would do the same on the windows platform if push came to shove. They aren't going to do it if they don't have to though. This is what scares MS though, things like what happened with Adobe may force adobe to look into a cross-platform solution or toolkit to avoid the same issue in the future, the easier it is for adobe to port their application with little expense the better the chances are that Adobe will start to get friendly with other OS's out there, because it would be easy and cost effective to do.

Reply Parent Score: 3