Another feature that would help is a Windows Installer package to make it easier to deploy to many machines on a Windows network. The provided installer is fine for single users, but it doesn't beat the ease of MSI packages for thousands of machines.
If Windows XP wasn't a nightmare running in limited mode, maybe they would've set it as the default.
And if developers didn't perpetuate the nightmare of having to run as Administrators, maybe we wouldn't have to run as admins. It seems to primarily be a problem with games and copy protection. Age of Mythology, for example, requires Administrator privileges to run due to its copy protection mechanism. Various other programs don't function well when run on a limited (regular Users) account, but I firmly believe it's a problem on the developer side. Hell, you can even debug programs using Visual Studio.NET as a regular user, as long as you add yourself to the Debuggers group.
Crap such as Winamp not working properly as non-admin (it seems to require writing to HKEY_LOCAL_MACHINE when HKEY_CLASSES_ROOT would suffice) shouldn't happen, and is what's preventing limited mode from being viable for most users.
If you're writing programs, PLEASE test it as a regular user!! Don't write to HKLM, don't write to Program Files, don't write to the Windows directory. Keep settings in HKEY_CURRENT_USER or in the Documents and Settings\Username\Application Data directory. Please.
I use wget all the time, even when I'm working with an X11 browser.
I use wget all the time, even though I mainly use Windows. It's a great as a quick and simple downloader. No dealing with clunky GUIs or "download accelerators". Just open a console and "wget url", or "wget -c url" to continue a file. You can get it as part of Windows ports for Unix utilities package.
Far too many Windows applications require that the user be logged in as Administrator. So many apps unreasonably require admin privledges that many users opt to be permanently logged in as Administrator. This in itself is a huge security hole.
And far too many apps require Administrator privileges for no good reason at all. Quite frankly, I put the blame on application developers. The Windows OS security structure is quite clear in what privileges are needed. Debugging an application? Either be Administrator or add yourself to the list of users/groups that are allowed to debug. A lot of other privileges are similar in that you get to control who gets what privileges. This allows for selective granting of privileges to users on a case-by-case basis.
It seems like a lot of the time when applications demand Administrator privileges, it's because developers were lazy and didn't bother doing privilege checks, and instead simply demand Administrator privileges even when it isn't required.
I sent my entire family Gmail invitations to their Hotmail address without problems, although one of my friends did have a problem with disappearing invites with Hotmail.
I seriously doubt IE7 will be compliant. It would be nice, for sure, but given Microsoft's history it's extremely unlikely.
Then again Visual C++ 6 had horrible C++ standards compliance, but Visual Studio.NET has improved considerably in that area. IE7 standards compliance might be unlikely, but I wouldn't consider it extremely unlikely.
Isn't all that impressive? Everytime I show it to people and show them all of the things it lets you do, they all start begging me for an invite. The Gmail interface is very utilitarian, much like their search interface. It also loads a *lot* faster than Yahoo!'s
I have yet to see Yahoo's interface, but Gmail sticks almost all page functionality into a Javascript file. The HTML page you download merely includes that script, and contains a script to populate the page with your emails and other account-specific data. The page elements are all generated on your own computer, precluding the need to transfer them over the Internet, and significantly increasing performance (for me at least).
I also have a GMail account, mainly because it was offered to me. While the idea of that much space is appealing, I don't like not being able to sort my mail.
Interesting point. I think the Gmail designers intended labels as a way to sort emails. If you don't know what they are, they behave like real labels; you can attach multiple labels to a single email, and then perform searches by labels. You can also automatically apply labels to incoming mail depending on a set of criteria.
The annoying part is that labels don't inherently provide hierarchy. You have to settle on a naming convention if you want hierarchy, and right now that's getting cumbersome for me. It'd be nicer if they had the concept of folders in addition to labels.
No...I don't think you are oing anything wrong. Since firefox is still under development, I am sure that some versions of Firefox are just better than others
Actually, I've seen sluggishness on those computers ever since version 0.6.0, so the code just might be slow in general. One part that bothers me is the use of custom widgets instead of the ones provided by Windows. It's great from a portability standpoint, but it does reduplicate functionality that already exists in Windows, as well as possibly implements it in a slower manner (which can't really be avoided since I'm sure Windows UI code is implemented in the kernel, and we don't want Firefox to come with a kernel driver).
Also, and very strange to me, FireFox is lo's - and I mean LOTS - more stable than IE 6 SP2. I ran crash tests on both and Firefox is clearly superior
Sure, in crash tests one browser might be superior, but in my own experience from daily usage, the two seem to be about the same. Some pages will crash IE, and some pages will crash Firefox. Overall, stability hasn't been a problem for me.
Windows 98 w/ 64 MB of Memory, an 800 MHz Intel Celeron all hooked to the net over 28.8 Lbps dial-up - again, the performance increase over IE 6 SP2 was dramatic.
Something makes me think you're referring to Internet speed. I doubt there's much of a difference between the two. The performance problems I'm having deal directly with the UI. Widgets and startup seem sluggish, the latter of which can be alleviated by leaving Firefox on all the time. Interesting how you ran Firefox on that computer. Too bad I don't have a system with similar specs to test it out on; I haven't touched a 9x system in years.
I'll take "Free existing cool service" over "Free theoretical awesome service" any day.
Ah but for some people Gmail has made the transition from the theoretical to the real;) I got a single invite from someone who works there, and now my entire family as well as a couple friends have Gmail accounts as a result of my own invites. Ask around; maybe someone you know has an account. Gmail seems to occasionally give people invites.
#8. Overall Speed!!!! This SOB Firefox is fast - Very Fast compared to IE
I just had to pick this one out from the rest. I reformatted a couple computers today to join them to a new Windows network I'm building, and one of the programs I automatically installed via MSI files was Firefox. (Note to Firefox developers: create MSI packages! People like me use them!) I've been using Firefox on my own computer for a while now without any performance problems, but it's quite sluggish on some of these 750 MHz boxes I'm installing them on, noticeably slower than IE.
Note that these are completely fresh installs of Windows, so I don't think it's something I'm doing wrong. Does anyone else have similar experiences with older computers?
Mozilla/Firefox will not have "won" the war until the majority of programmers under MS Windows, upon needing to add an HTML render widget, or HTTP downloader, or FTP downloader to their app, do so by invoking the appropriate DLL from Mozilla rather than the IE/Windows DLL.
I came across a Mozilla ActiveX Control that implements some of the web browser interfaces, including IWebBrowser. I have yet to try it and don't know how well it works, but perhaps this will suffice when all that is needed is an HTML widget. If you're not familiar with COM and IWebBrowser, an identical implementation of the interfaces would be extremely easy to use instead of the Microsoft-provided implementation. You basically change the ID of the interface implementation you want to create, which is essentially one important line of code, and the rest of the code stays the same.
As for HTTP and FTP downloading, Microsoft provides APIs for that, and quite frankly, they're easy enough to use that I doubt Mozilla/Firefox will be able to replace them. An HTML control replacement, however, would be nice, especially if it can be packaged into a single lightweight DLL.
You can't patch the stupid vulnerabilities in the OS if you aren't visiting on IE....
Take a look at the Microsoft Security Baseline Analyzer. It'll check for vulnerabilities and provide links to patches you can download and install manually.
Yeah there is. They can only force independent application developers to rewrite their apps so many times. They'll need this especially in the short to mid term as a newish technology looking to gain traction via mind share, competeing against the established Java community.
On the other hand, multiple versions of.NET can be installed and coexist, so old applications can continue using.NET version 1.0, for instance, while newer applications that want to take advantage of new features can be updated to use 2.0. You can't really avoid code changes if you want to use new features, but even when taking a look stuff like C# 2.0, most, if not all, of the changes are mere additions and extensions, not changes of existing features that would require an entire rewrite.
The only problem is when new APIs require a complete rewrite, but I have not experienced with any Microsoft API, including Direct3D, which required only simple modifications. Direct3D's variability is still an exception, however. All other APIs I've seen have been fairly stable across versions.
so now we've got a some free software that is causign MS to lose lots and lots of money (because maybe people will go with this rather then MS's SDK)...
I give this about 3 days before MS finds a way to shut it down...
MS releases virtually all of their SDKs for free, including those for mobile device development. They wouldn't lose money if people went for this, at least not directly.
That's interesting, but assumes installers don't clobber system DLLs with old versions, which was a problem in the past. Hopefully things have changed enough now that it isn't much of a problem anymore. Using a popular installer known to correctly replace files would also be good. I recommend InnoSetup, but use Windows Installer if you can so that I can replicate your programs across a network with a couple mouse clicks:)
The reason why forks are not dangerous is because people will still want to write "standard" Java code, no matter how many different strange Java-esque things there are.
There's a possibility "standard" Java will mean the most popular distribution of Java, and if popularity varies greatly with time problems might arise. A situation similar to IE and CSS might also develop, where a bad effective standard prevents the adoption of the proper standard.
Having created build scripts in FreeBSD, Gentoo, Sourcemage, and Arch Linux, I think the most important goal is to use/develop a script language that newbies find easy to use.
If you're developing a new distro, and you're concerned about giving users a reason to move, focus on making it easy for us to add to the distro!
For small programs, I can imagine an XML file that describes stuff like possible shortcuts to place on start menus and any file extensions that should be handled by the program. The installer can process that XML file and set up links and associations automatically. No need for a programming scripting language except in complex installation scenarios.
Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.
Most of the cruft Microsoft installs in C:\Windows are shared libraries such as msvcrt.dll and mfc42.dll. I agree that it's ugly but there's not really anywhere else they can go, especially since C:\Windows\System32 is on the path by default. Applications shouldn't even touch C:\Windows unless they're installing kernel drivers or providing system-level functionality. Any other behavior should be considered bad and unacceptable, and would be similar to Linux programs putting their program executables in/bin or/sbin.
An interesting thing I've noticed is this shift in some places to installing shared libraries such as mfc42.dll to the program's installation directory, eliminating the need to touch C:\Windows at all and avoiding DLL hell at the expense of file space. (IIRC, there are several variants of mfc42.dll.) Yes, this would be bad on older systems with limited hard drive space, but for future OS's like Longhorn I think this would be acceptable. Even my sister's computer has over 20 GB of space right now. Hopefully the view of C:\Windows as a shared dumping ground will go away.
The reason some programs stop working when you move them around is the storage of the program location in the registry. With.NET, Microsoft is encouraging the storage of program settings in an XML config file in the program's directory, and similar storage of user settings in their Documents and Settings folder is completely possible. I see a slow progression to Mac OS X's concept of self-contained applications.
MS needs to get this part right to satisfy customers running legacy third party applications developed under previous version of Windows. It's often been observed, and rightly so, that MS' biggest competitor is itself - old versions of its own software competing against its new offerings.
I know it's a bit late in replying, but Microsoft HAS maintained compatibility for the most part. The Win32 API is a derivative of the old Win16 API all the way from at least Windows 3.0. The code for a Windows 3.0 application will very likely compile and run on Windows XP. There might be minor application-breaking changes, but there aren't any major paradigm shifts that I'm aware of.
Longhorn will change this, but the old Win32 API will still be present. There's just too much legacy code to dump that API, and furthermore, some of the WinFX framework will actually use Win32 in its implementation, so Win32 isn't going away anytime soon.
As for the statement of Microsoft competing with itself, that's probably true for stuff like Windows 2000 to Windows XP, but Windows 3.1 to Windows 95 was a large jump, and I'm willing to bet Windows XP to Longhorn will be just as large with these new APIs and.NET.
I agree that it might be more prudent for MS to shift towards a business model in which they sell support, but do remember that MS is notorious for repackaging one of their current OSes with superficial or pointless alterations and selling it as a new, superior product. WinME is a prime example of this behavior.
Longhorn doesn't seem to be a superficial improvement over Windows XP, however. Sure, the new 3D-accelerated GUI may provide only eye candy, but the underlying APIs and technology involved are completely different from the old GUI API. The same applies with the WinFX framework, which will hopefully be a complete and modern replacement for the old Win32 API, which is quite ugly especially in the UI area.
Windows Me might've been pointless, but Longhorn provides some real improvements from a developer standpoint. It remains to be seen whether or not this will translate into improvements for the end-user, but I'm sure a lot of coders will be happier with Longhorn.
Then again, graphics used to be in the NT kernel and that's what made it appear fast, but lead to a lot of problems and crashes, so maybe the longer load time is worth the wait when compared to a reboot.
AFAIK, the graphics subsystem has been moved to the kernel to improve performance. One consequence of this, at least on older versions of Windows (2K or NT4, perhaps), is that a bad font can crash Windows.
Also, sometimes a shutdown complains about an application that won't respond even after you've closed everything. I think they're hoaxoring people to think they got a fast system, when they're really just robbing Peter to pay Paul.
In all cases I've seen this has been a result of hidden programs or bad programs that spawn other hidden programs that aren't closing properly. As an example, a Logitech MouseWare helper program sometimes refuses to die upon shutdown. Remember that there can exist non-visible programs, so what you see on the taskbar is not representative of all the programs you are running. Try the Task Manager for that (Ctrl+Shift+Esc).
With regards to the resource problem, it's entirely possible Windows has initialized or allocated some resource at the request of a program and hasn't released it. You can think of it as delayed initialization to speed up startup. As an example, instead of initializing the web browser control when you first log on, it can be initialized when it's first used instead.
Slashdot Mirror
Another feature that would help is a Windows Installer package to make it easier to deploy to many machines on a Windows network. The provided installer is fine for single users, but it doesn't beat the ease of MSI packages for thousands of machines.
If Windows XP wasn't a nightmare running in limited mode, maybe they would've set it as the default.
And if developers didn't perpetuate the nightmare of having to run as Administrators, maybe we wouldn't have to run as admins. It seems to primarily be a problem with games and copy protection. Age of Mythology, for example, requires Administrator privileges to run due to its copy protection mechanism. Various other programs don't function well when run on a limited (regular Users) account, but I firmly believe it's a problem on the developer side. Hell, you can even debug programs using Visual Studio.NET as a regular user, as long as you add yourself to the Debuggers group.
Crap such as Winamp not working properly as non-admin (it seems to require writing to HKEY_LOCAL_MACHINE when HKEY_CLASSES_ROOT would suffice) shouldn't happen, and is what's preventing limited mode from being viable for most users.
If you're writing programs, PLEASE test it as a regular user!! Don't write to HKLM, don't write to Program Files, don't write to the Windows directory. Keep settings in HKEY_CURRENT_USER or in the Documents and Settings\Username\Application Data directory. Please.
I use wget all the time, even when I'm working with an X11 browser.
I use wget all the time, even though I mainly use Windows. It's a great as a quick and simple downloader. No dealing with clunky GUIs or "download accelerators". Just open a console and "wget url", or "wget -c url" to continue a file. You can get it as part of Windows ports for Unix utilities package.
Far too many Windows applications require that the user be logged in as Administrator. So many apps unreasonably require admin privledges that many users opt to be permanently logged in as Administrator. This in itself is a huge security hole.
And far too many apps require Administrator privileges for no good reason at all. Quite frankly, I put the blame on application developers. The Windows OS security structure is quite clear in what privileges are needed. Debugging an application? Either be Administrator or add yourself to the list of users/groups that are allowed to debug. A lot of other privileges are similar in that you get to control who gets what privileges. This allows for selective granting of privileges to users on a case-by-case basis.
It seems like a lot of the time when applications demand Administrator privileges, it's because developers were lazy and didn't bother doing privilege checks, and instead simply demand Administrator privileges even when it isn't required.
One of the Apollo astronauts, IIRC, pulled out a sandwich during flight. Mission control was afraid of crumbs getting into the instrument panels.
I sent my entire family Gmail invitations to their Hotmail address without problems, although one of my friends did have a problem with disappearing invites with Hotmail.
I seriously doubt IE7 will be compliant. It would be nice, for sure, but given Microsoft's history it's extremely unlikely.
Then again Visual C++ 6 had horrible C++ standards compliance, but Visual Studio.NET has improved considerably in that area. IE7 standards compliance might be unlikely, but I wouldn't consider it extremely unlikely.
And themes
I'm actually against themes, and prefer that all my programs have the same general look.
Isn't all that impressive? Everytime I show it to people and show them all of the things it lets you do, they all start begging me for an invite. The Gmail interface is very utilitarian, much like their search interface. It also loads a *lot* faster than Yahoo!'s
I have yet to see Yahoo's interface, but Gmail sticks almost all page functionality into a Javascript file. The HTML page you download merely includes that script, and contains a script to populate the page with your emails and other account-specific data. The page elements are all generated on your own computer, precluding the need to transfer them over the Internet, and significantly increasing performance (for me at least).
I also have a GMail account, mainly because it was offered to me. While the idea of that much space is appealing, I don't like not being able to sort my mail.
Interesting point. I think the Gmail designers intended labels as a way to sort emails. If you don't know what they are, they behave like real labels; you can attach multiple labels to a single email, and then perform searches by labels. You can also automatically apply labels to incoming mail depending on a set of criteria.
The annoying part is that labels don't inherently provide hierarchy. You have to settle on a naming convention if you want hierarchy, and right now that's getting cumbersome for me. It'd be nicer if they had the concept of folders in addition to labels.
No...I don't think you are oing anything wrong. Since firefox is still under development, I am sure that some versions of Firefox are just better than others
Actually, I've seen sluggishness on those computers ever since version 0.6.0, so the code just might be slow in general. One part that bothers me is the use of custom widgets instead of the ones provided by Windows. It's great from a portability standpoint, but it does reduplicate functionality that already exists in Windows, as well as possibly implements it in a slower manner (which can't really be avoided since I'm sure Windows UI code is implemented in the kernel, and we don't want Firefox to come with a kernel driver).
Also, and very strange to me, FireFox is lo's - and I mean LOTS - more stable than IE 6 SP2. I ran crash tests on both and Firefox is clearly superior
Sure, in crash tests one browser might be superior, but in my own experience from daily usage, the two seem to be about the same. Some pages will crash IE, and some pages will crash Firefox. Overall, stability hasn't been a problem for me.
Windows 98 w/ 64 MB of Memory, an 800 MHz Intel Celeron all hooked to the net over 28.8 Lbps dial-up - again, the performance increase over IE 6 SP2 was dramatic.
Something makes me think you're referring to Internet speed. I doubt there's much of a difference between the two. The performance problems I'm having deal directly with the UI. Widgets and startup seem sluggish, the latter of which can be alleviated by leaving Firefox on all the time. Interesting how you ran Firefox on that computer. Too bad I don't have a system with similar specs to test it out on; I haven't touched a 9x system in years.
I'll take "Free existing cool service" over "Free theoretical awesome service" any day.
Ah but for some people Gmail has made the transition from the theoretical to the real ;) I got a single invite from someone who works there, and now my entire family as well as a couple friends have Gmail accounts as a result of my own invites. Ask around; maybe someone you know has an account. Gmail seems to occasionally give people invites.
#8. Overall Speed!!!! This SOB Firefox is fast - Very Fast compared to IE
I just had to pick this one out from the rest. I reformatted a couple computers today to join them to a new Windows network I'm building, and one of the programs I automatically installed via MSI files was Firefox. (Note to Firefox developers: create MSI packages! People like me use them!) I've been using Firefox on my own computer for a while now without any performance problems, but it's quite sluggish on some of these 750 MHz boxes I'm installing them on, noticeably slower than IE.
Note that these are completely fresh installs of Windows, so I don't think it's something I'm doing wrong. Does anyone else have similar experiences with older computers?
Mozilla/Firefox will not have "won" the war until the majority of programmers under MS Windows, upon needing to add an HTML render widget, or HTTP downloader, or FTP downloader to their app, do so by invoking the appropriate DLL from Mozilla rather than the IE/Windows DLL.
I came across a Mozilla ActiveX Control that implements some of the web browser interfaces, including IWebBrowser. I have yet to try it and don't know how well it works, but perhaps this will suffice when all that is needed is an HTML widget. If you're not familiar with COM and IWebBrowser, an identical implementation of the interfaces would be extremely easy to use instead of the Microsoft-provided implementation. You basically change the ID of the interface implementation you want to create, which is essentially one important line of code, and the rest of the code stays the same.
As for HTTP and FTP downloading, Microsoft provides APIs for that, and quite frankly, they're easy enough to use that I doubt Mozilla/Firefox will be able to replace them. An HTML control replacement, however, would be nice, especially if it can be packaged into a single lightweight DLL.
You can't patch the stupid vulnerabilities in the OS if you aren't visiting on IE....
Take a look at the Microsoft Security Baseline Analyzer. It'll check for vulnerabilities and provide links to patches you can download and install manually.
Yeah there is. They can only force independent application developers to rewrite their apps so many times. They'll need this especially in the short to mid term as a newish technology looking to gain traction via mind share, competeing against the established Java community.
On the other hand, multiple versions of .NET can be installed and coexist, so old applications can continue using .NET version 1.0, for instance, while newer applications that want to take advantage of new features can be updated to use 2.0. You can't really avoid code changes if you want to use new features, but even when taking a look stuff like C# 2.0, most, if not all, of the changes are mere additions and extensions, not changes of existing features that would require an entire rewrite.
The only problem is when new APIs require a complete rewrite, but I have not experienced with any Microsoft API, including Direct3D, which required only simple modifications. Direct3D's variability is still an exception, however. All other APIs I've seen have been fairly stable across versions.
so now we've got a some free software that is causign MS to lose lots and lots of money (because maybe people will go with this rather then MS's SDK)...
I give this about 3 days before MS finds a way to shut it down...
MS releases virtually all of their SDKs for free, including those for mobile device development. They wouldn't lose money if people went for this, at least not directly.
That's interesting, but assumes installers don't clobber system DLLs with old versions, which was a problem in the past. Hopefully things have changed enough now that it isn't much of a problem anymore. Using a popular installer known to correctly replace files would also be good. I recommend InnoSetup, but use Windows Installer if you can so that I can replicate your programs across a network with a couple mouse clicks :)
The reason why forks are not dangerous is because people will still want to write "standard" Java code, no matter how many different strange Java-esque things there are.
There's a possibility "standard" Java will mean the most popular distribution of Java, and if popularity varies greatly with time problems might arise. A situation similar to IE and CSS might also develop, where a bad effective standard prevents the adoption of the proper standard.
Having created build scripts in FreeBSD, Gentoo, Sourcemage, and Arch Linux, I think the most important goal is to use/develop a script language that newbies find easy to use.
If you're developing a new distro, and you're concerned about giving users a reason to move, focus on making it easy for us to add to the distro!
For small programs, I can imagine an XML file that describes stuff like possible shortcuts to place on start menus and any file extensions that should be handled by the program. The installer can process that XML file and set up links and associations automatically. No need for a programming scripting language except in complex installation scenarios.
Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.
Most of the cruft Microsoft installs in C:\Windows are shared libraries such as msvcrt.dll and mfc42.dll. I agree that it's ugly but there's not really anywhere else they can go, especially since C:\Windows\System32 is on the path by default. Applications shouldn't even touch C:\Windows unless they're installing kernel drivers or providing system-level functionality. Any other behavior should be considered bad and unacceptable, and would be similar to Linux programs putting their program executables in /bin or /sbin.
An interesting thing I've noticed is this shift in some places to installing shared libraries such as mfc42.dll to the program's installation directory, eliminating the need to touch C:\Windows at all and avoiding DLL hell at the expense of file space. (IIRC, there are several variants of mfc42.dll.) Yes, this would be bad on older systems with limited hard drive space, but for future OS's like Longhorn I think this would be acceptable. Even my sister's computer has over 20 GB of space right now. Hopefully the view of C:\Windows as a shared dumping ground will go away.
The reason some programs stop working when you move them around is the storage of the program location in the registry. With .NET, Microsoft is encouraging the storage of program settings in an XML config file in the program's directory, and similar storage of user settings in their Documents and Settings folder is completely possible. I see a slow progression to Mac OS X's concept of self-contained applications.
MS needs to get this part right to satisfy customers running legacy third party applications developed under previous version of Windows. It's often been observed, and rightly so, that MS' biggest competitor is itself - old versions of its own software competing against its new offerings.
I know it's a bit late in replying, but Microsoft HAS maintained compatibility for the most part. The Win32 API is a derivative of the old Win16 API all the way from at least Windows 3.0. The code for a Windows 3.0 application will very likely compile and run on Windows XP. There might be minor application-breaking changes, but there aren't any major paradigm shifts that I'm aware of.
Longhorn will change this, but the old Win32 API will still be present. There's just too much legacy code to dump that API, and furthermore, some of the WinFX framework will actually use Win32 in its implementation, so Win32 isn't going away anytime soon.
As for the statement of Microsoft competing with itself, that's probably true for stuff like Windows 2000 to Windows XP, but Windows 3.1 to Windows 95 was a large jump, and I'm willing to bet Windows XP to Longhorn will be just as large with these new APIs and .NET.
I agree that it might be more prudent for MS to shift towards a business model in which they sell support, but do remember that MS is notorious for repackaging one of their current OSes with superficial or pointless alterations and selling it as a new, superior product. WinME is a prime example of this behavior.
Longhorn doesn't seem to be a superficial improvement over Windows XP, however. Sure, the new 3D-accelerated GUI may provide only eye candy, but the underlying APIs and technology involved are completely different from the old GUI API. The same applies with the WinFX framework, which will hopefully be a complete and modern replacement for the old Win32 API, which is quite ugly especially in the UI area.
Windows Me might've been pointless, but Longhorn provides some real improvements from a developer standpoint. It remains to be seen whether or not this will translate into improvements for the end-user, but I'm sure a lot of coders will be happier with Longhorn.
Then again, graphics used to be in the NT kernel and that's what made it appear fast, but lead to a lot of problems and crashes, so maybe the longer load time is worth the wait when compared to a reboot.
AFAIK, the graphics subsystem has been moved to the kernel to improve performance. One consequence of this, at least on older versions of Windows (2K or NT4, perhaps), is that a bad font can crash Windows.
Also, sometimes a shutdown complains about an application that won't respond even after you've closed everything. I think they're hoaxoring people to think they got a fast system, when they're really just robbing Peter to pay Paul.
In all cases I've seen this has been a result of hidden programs or bad programs that spawn other hidden programs that aren't closing properly. As an example, a Logitech MouseWare helper program sometimes refuses to die upon shutdown. Remember that there can exist non-visible programs, so what you see on the taskbar is not representative of all the programs you are running. Try the Task Manager for that (Ctrl+Shift+Esc).
With regards to the resource problem, it's entirely possible Windows has initialized or allocated some resource at the request of a program and hasn't released it. You can think of it as delayed initialization to speed up startup. As an example, instead of initializing the web browser control when you first log on, it can be initialized when it's first used instead.