Windows 7

[SezMe]

All in all, I'll be switching over to Windows 7 because it'll better suit my home computing habits and because it's a viable upgrade to the systems I manage at work.

Geeeze, I'm gonna go rob a bank. Sounds like you guys at Folsom are better set up than I am.

 

[Alareth]

I've been hearing good things about it running on netbooks so I may repartition the drive on my Aspire One and dual boot

 

[GreNME]

Geeeze, I'm gonna go rob a bank. Sounds like you guys at Folsom are better set up than I am.

I live on the Isle of Dallas/Ft. Worth in the Christian Republic of Texas. It just feels like prison to me.

 

[jsiv]

NT is absolutely written from the ground up. MS brought Dave Cutler, the father of VMS from Digital and he was the architect of this Brand New operating system. Windows NT was written new from scratch.

Code wise NT was mostly written from the ground up, yes. However, most of the APIs were ported from Windows. This means that it's hardly a "completely new operating system." In fact, like GrenME points out, it even inherited design flaws and outright bugs (that can't be fixed for compatibility reasons) from Windows.

Most of Win32 still resides in User land, not the kernel.

No. The only thing that really remains in the subsystem server is process/thread creation and the console (command line) environment. The reason it was moved into the kernel is to avoid all the threading and context switching that would otherwise be needed and that substantially impacted performance. This was not part of the original NT design so you probably won't see it in historical documentation.

Not in Vista and Win 7. The DWM, which is the new compositing engine is the base graphical engine. If you are not running Aero, then you revert to GDI+, however that is no longer a hardware driven process, but emulated in software. The DWM makes use of the hardware, which is why Vista and Win 7 require a DirectX 9 capable video card.

No, the DWM is an extension to the old window manager (which, incidentally, runs in kernel mode). It's optional and if it's disabled the standard window manager will do everything instead.

Programs still use plain old GDI, but what happens is that the resulting GDI bitmap is handed off to the DWM which converts it into a Direct3D texture. With DWM the whole desktop is a Direct3D surface and each window a texture quad. DWM draws the window borders itself and uses the bitmap from GDI to draw the client area.

In other words GDI is still responsible for all the actual work of creating the bitmap. GDI+ isn't really relevant in this context as it is just a utility library with convenience functions (all implemented in software with no acceleration) that eventually end up calling GDI.

The Windows controls themselves are implemented solely with GDI. It's very difficult to do anything about that because they are so old and fragile (they predate NT) and any little change (both internally and in APIs) made risks breaking thousands of programs. The whole thing is so dated that the only real option is a completely new framework.

 

[jsiv]

Now it looks like they're attempting to do more in the realm of redesigning, but it looks like they're now taking small steps instead of a complete framework redesign. Considering the resounding (lack of) success Vista had, it's not unrealistic to see why they're not eager to change too much at a time.

In my not so humble opinion the lack of new (native) frameworks is because Microsoft invested far too much in .NET at the expense of native development, hoping that it would become the preferred platform for all software (and not just business solutions).

 

[jeremyp]

NT was not a "completely new operating system." It was designed to be a high-end workstation and server OS based around 32-bit Windows APIs (also known as Win32, and based on the earlier 16-bit APIs),

An API is not code, it is an interface specification. The code in Windows NT was written from the ground up and one of its external interfaces is Win32.

You might think so, but no, GDI is part of Win32 and still forms the basis of everything graphical on Windows (with the exception of things running on Direct3D).

That is false. The Win 1.0 GDI was 16 bit code and it was built to implement the Win16 API. There's no 16 bit code in the Win32 implementation of Windows NT. The Win32 implementation of Windows 95 was what is called a "thunking layer" to convert the 32 bit Win32 calls into 16 bit Win16 calls. There's no way to directly implement a 32 bit API in 16 bit code.

 

[jsiv]

An API is not code, it is an interface specification. The code in Windows NT was written from the ground up and one of its external interfaces is Win32.

The only thing you can claim was unique in NT is the native NT API, which is internal and undocumented and only called by the various APIs that actually make up the OS (and that came from Windows).

That is false. The Win 1.0 GDI was 16 bit code and it was built to implement the Win16 API. There's no 16 bit code in the Win32 implementation of Windows NT.

Uh, no one has claimed there is. What I said in my original post was that the graphics API (GDI) hails from Windows 1. Where you get "code" from I have no idea.

You seem to be of the belief that GDI in NT is somehow completely unrelated to GDI in Windows 1. It isn't. Win32 is based on Win16, and inherits its design and APIs from it. This was intentional so developers wouldn't have to learn completely new APIs and could port their applications to 32-bit with as little trouble as possible (Win32 in fact even includes wrappers for 16-bit functions that don't exist in the 32-bit version to make this easier).

 

[jeremyp]

The only thing you can claim was unique in NT is the native NT API, which is internal and undocumented and only called by the various APIs that actually make up the OS (and that came from Windows).

The Win32 API first appeared in Windows NT. It was unique to Win NT until it was backported to the consumer operating systems (Win95, 98, Me).

Uh, no one has claimed there is. What I said in my original post was that the graphics API (GDI) hails from Windows 1. Where you get "code" from I have no idea.

You used the abbreviation "GDI" which I took to mean the GDI subsystem (which was common usage in my days as a Windows programmer), not just its API.

Win32 is based on Win16, and inherits its design and APIs from it.

The API is just a piece of paper - a contract - that defines how a subsystem interacts with other pieces of software. What counts is the software that implements the API. Mac OS X implements the POSIX API as does Solaris, but underneath you'll find no code in common.

Windows 7 has to implement the Win32 API or 32 bit Windows applications won't run on it. How well those apps run depends on the implementation, not the API.

 

[Zygar]

Server 2008 and Vista SP1 are identical, but that's not really relevant.

This right here is where I utterly began ignoring your posts in this thread. You're obviously getting your data from an invalid source if you think this is true.

Sure, they have a similar kernel, and many UI similarities, but Windows 2008 is significantly different and actually benchmarks faster than Vista SP1.

 

[PhreePhly]

The only thing you can claim was unique in NT is the native NT API, which is internal and undocumented and only called by the various APIs that actually make up the OS (and that came from Windows).

NT was unique from the ground up. NT was written from scratch. MS and IBM were working together on OS/2. MS wanted to build a competitor to Unix, so they brought in Dave Cutler from Digital and he began the implementation of a brand new multi-user server OS. However, when Bill Gates saw how well Windows 3.0 was received by the public, he decided to stop with the OS/2 joint venture and build a workstation class OS that could also function as a server. NT was never supposed to have the GUI during Cutler's initial design, but due to Gates' pressure, he was forced to implement it so that NT would have a Program Manager like Windows 3.1.

In order to do this, the WIN32 API was developed. In order to maintain compatibility it was based on the Win16 API. Win95 wasn't in development. Win32 was solely developed for NT. A follow on api, Win32s was provided for the "thunking" layer in Win95 to deal with 16-bit code.

Uh, no one has claimed there is. What I said in my original post was that the graphics API (GDI) hails from Windows 1. Where you get "code" from I have no idea.

You seem to be of the belief that GDI in NT is somehow completely unrelated to GDI in Windows 1. It isn't. Win32 is based on Win16, and inherits its design and APIs from it. This was intentional so developers wouldn't have to learn completely new APIs and could port their applications to 32-bit with as little trouble as possible (Win32 in fact even includes wrappers for 16-bit functions that don't exist in the 32-bit version to make this easier).

The GDI in NT is releated to the old GDI, only in the sense that it performs basically the same function. The graphics subsytem has gone through many changes during the course of NT's evolution. In NT 3.1 through 3.51, the graphics subsystem sat in User land. In NT 4.0, inorder to increase performance, the graphics subsystem was moved to the kernel. It stayed that way for win2000 and XP. In Vista, the graphic subsystem has once again been placed outside the kernel. GDI is now a software based emulation that speaks only to the DirectX API. It is only used if the program requires it, however as more programs are built with Windows Presentation Foundation, the GDI will also be completely bypassed.

PhreePhly

 

[PhreePhly]

This right here is where I utterly began ignoring your posts in this thread. You're obviously getting your data from an invalid source if you think this is true.

Sure, they have a similar kernel, and many UI similarities, but Windows 2008 is significantly different and actually benchmarks faster than Vista SP1.

No, jsiv is correct. The Vista SP1 kernel and Server 2008 kernel are exactly the same. The only difference between the two OS's is the services that are running. While there have been some benchmarks early on that claimed Server was faster, once the same services are turned on, the difference is negligible.

PhreePhly

 

[jsiv]

The Win32 API first appeared in Windows NT. It was unique to Win NT until it was backported to the consumer operating systems (Win95, 98, Me).

Win32 was a port of Win16 with some changes and additions here and there. It was not something brand new. Its history goes all the way back to the dawn of Windows, and this is important to understand. You cannot just pretend that one started with blank sheets on NT.

You used the abbreviation "GDI" which I took to mean the GDI subsystem (which was common usage in my days as a Windows programmer), not just its API.

In the context of what "subsystem" means on Windows, GDI is not one. GDI is a graphics API that was originally part of the Win32 subsystem but that is now implemented as a kernel-mode driver.

The API is just a piece of paper - a contract - that defines how a subsystem interacts with other pieces of software. What counts is the software that implements the API. Mac OS X implements the POSIX API as does Solaris, but underneath you'll find no code in common.

It's even worse on Windows. Not even the implementations can be changed much because thousands of programs depend on undocumented behavior and go snooping in private data.

How well those apps run depends on the implementation, not the API.

It's not about "how well" they run, it's about the very design of the API being outdated and cumbersome, and lacking features. You can't polish a turd. This goes for both GDI and the windowing API. Something completely new has to be introduced. Why do you think half of the time Windows itself doesn't even use the standard controls that everyone else is expected to use? It's because they're ****.

DirectX 11 does actually introduce a new graphics API (Direct2D) based on Direct3D, but it's brand new and untested. Nothing in Windows uses it, and there is no GUI framework to go with it.

 

[jsiv]

This right here is where I utterly began ignoring your posts in this thread. You're obviously getting your data from an invalid source if you think this is true.

Sure, they have a similar kernel, and many UI similarities, but Windows 2008 is significantly different and actually benchmarks faster than Vista SP1.

As PhreePhly points out, you are wrong. 2008 and Vista SP1 are binary identical and come from the same code base. The only difference is what tools and services are included, and that 2008's configuration is optimized for background services rather than interactive applications. It also lacks certain consumer features.

 

[jsiv]

The GDI in NT is releated to the old GDI, only in the sense that it performs basically the same function.

It's based on the same design and the same API. It's simply an updated version adapted for the 32-bit world. That's all I'm trying to get at.

The graphics subsytem has gone through many changes during the course of NT's evolution. In NT 3.1 through 3.51, the graphics subsystem sat in User land. In NT 4.0, inorder to increase performance, the graphics subsystem was moved to the kernel. It stayed that way for win2000 and XP. In Vista, the graphic subsystem has once again been placed outside the kernel.

GDI runs in kernel mode in Vista and 7 as well. It hasn't changed. There's no real benefit in moving it back into the subsystem other than making it slower, so it stays where it is.

GDI is now a software based emulation that speaks only to the DirectX API. It is only used if the program requires it, however as more programs are built with Windows Presentation Foundation, the GDI will also be completely bypassed.

GDI and Direct3D are completely separate (and incompatible) APIs that have nothing to do with each other. GDI does not sit on top of Direct3D. Doing that would be a pointless excercise that would make lots of programs break while offering no real advantage at all.

WPF is indeed a replacement for both GDI and User from a developer's perspective, however it is a managed API and is not usable by native applications (which is 99.7% of Windows software). This goes back to my earlier reply to GreNME where I say that Microsoft has unfortunately invested far too much in .NET.

 

[GreNME]

In my not so humble opinion the lack of new (native) frameworks is because Microsoft invested far too much in .NET at the expense of native development, hoping that it would become the preferred platform for all software (and not just business solutions).

I think you may be on to something with your opinion, but I'm not completely sure it's a bad idea on their part. Of course, I'm biased because I have to support business environments, and standards like those in .Net make it easier. Ultimately, though, I don't care if it's .Net or some other standard, so I'm not married to the idea that their investment in .Net is valid in any large respect-- I'm not a developer, so I don't care.

-----

Server 2008 and Vista SP1 are identical, but that's not really relevant.

This right here is where I utterly began ignoring your posts in this thread. You're obviously getting your data from an invalid source if you think this is true.

Sure, they have a similar kernel, and many UI similarities, but Windows 2008 is significantly different and actually benchmarks faster than Vista SP1.

As PhreePhly points out, you are wrong. 2008 and Vista SP1 are binary identical and come from the same code base. The only difference is what tools and services are included, and that 2008's configuration is optimized for background services rather than interactive applications. It also lacks certain consumer features.

Indeed, and this has been the main gist of the fork between their client and server operating systems for a while now. It's also why there's a notable element of power users who attempt to turn the server builds into desktop operating systems-- something I'm not a huge fan of, but have seen grow in popularity since Server 2003 (though it began before that).

 

[jsiv]

I think you may be on to something with your opinion, but I'm not completely sure it's a bad idea on their part. Of course, I'm biased because I have to support business environments, and standards like those in .Net make it easier. Ultimately, though, I don't care if it's .Net or some other standard, so I'm not married to the idea that their investment in .Net is valid in any large respect-- I'm not a developer, so I don't care.

-----
Well, I actually think that .NET is a great product. However, there's no getting ar ound the fact that it has higher resource requirements, requires an extremely large download (developers always want to use a more recent version than is bundled with the OS), and so is more suited for a controlled environment (such as in businesses). There's also the issue of most of the software on the market being written in C or some other unmanaged language. It's hard to not feel that the native side has been neglected.

Indeed, and this has been the main gist of the fork between their client and server operating systems for a while now. It's also why there's a notable element of power users who attempt to turn the server builds into desktop operating systems-- something I'm not a huge fan of, but have seen grow in popularity since Server 2003 (though it began before that).

An amusing piece of trivia resulting from this is that 2008 identifies itself as "SP1" (to match Vista) and that the first service pack for it will actually be SP2.

Or is that so that those who hold out for Service Pack 1 before upgrading won't have an excuse?

 

[GreNME]

Well, I actually think that .NET is a great product. However, there's no getting ar ound the fact that it has higher resource requirements, requires an extremely large download (developers always want to use a more recent version than is bundled with the OS), and so is more suited for a controlled environment (such as in businesses). There's also the issue of most of the software on the market being written in C or some other unmanaged language. It's hard to not feel that the native side has been neglected.

Microsoft has a long history of setting forth standards, and the market has a long history of often ignoring them. I blame it on the DOS/9x operating systems being supported too long.

An amusing piece of trivia resulting from this is that 2008 identifies itself as "SP1" (to match Vista) and that the first service pack for it will actually be SP2.

Or is that so that those who hold out for Service Pack 1 before upgrading won't have an excuse?

It's a conspiracy!

 

[PhreePhly]

It's based on the same design and the same API. It's simply an updated version adapted for the 32-bit world. That's all I'm trying to get at.


GDI runs in kernel mode in Vista and 7 as well. It hasn't changed. There's no real benefit in moving it back into the subsystem other than making it slower, so it stays where it is.


GDI and Direct3D are completely separate (and incompatible) APIs that have nothing to do with each other. GDI does not sit on top of Direct3D. Doing that would be a pointless excercise that would make lots of programs break while offering no real advantage at all.

Attached are two graphical descriptions of the graphics API's from XP and Vista. These are from the latest MSDN library.

GDI now sits on top of DirectX.

PhreePhly

 

[jsiv]

Yes, that is the DWM setup I described earlier which takes a GDI bitmap and applies it as a texture on a quad. I guess technically I'm wrong and you can call that "sitting on top of D3D," you're right about that.

In any case it doesn't solve any problems and offers no benefits to developers. It's simply an internal implementation detail, you're still stuck with the same old API with the exact same restrictions.

 

[PhreePhly]

Yes, that is the DWM setup I described earlier which takes a GDI bitmap and applies it as a texture on a quad. I guess technically I'm wrong and you can call that "sitting on top of D3D," you're right about that.

In any case it doesn't solve any problems and offers no benefits to developers. It's simply an internal implementation detail, you're still stuck with the same old API with the exact same restrictions.

What restrictions? Also, note that the driver is now hybrid with viddeo both in user mode and in kernel mode. If your video driver crashes, Vista will just reboot the subsytem and the user will get a notification that the driver has reset. No more BSOD.

PhreePhly