Sad thing is, if MS were to come out with channels and active desktop today, they would probably actually be used. Holy fish, was MS actually ahead of the curve on channels?
"Active Desktop" is still part of Windows (and has been for every version since Windows 98), it's just not turned on by default.
I guess my friend was dreaming the broken leg he got snowboarding then. I'm sure he'll be pleased to hear it.
I like nipping down the Thredbo for the odd weekend during winter just as much as the next bloke, but Australia's skifields aren't even playing the same game as "the worlds best snow country", let alone in the same ballpark.
For those unfamiliar with skiing in Australia, we get about 3 months worth of skiable snow a year, with maybe 6 weeks of that involving snow that could be deemed 'powder'. The highest lifted point is about 2000m (~6500'), the biggest vertical drop is about 700m (~2200') and the longest trail is about 5.5km (~3.4 miles). They also rely *heavily* on artificial snowmaking for consistent cover and outside of peak season, it's not unusual to find the bottom ~20% of the mountain (well, hill;) ) with very little natural snow at all.
(With NZ offering such consistently better snow for only marginally higher cost, it surprises me the Australian fields can even stay in business. All the following is IMHO, of course...)
The best skiing in Australasia is Mt Ruapehu on New Zealand's North Island. Unfortunately, it also has the worst weather, so if you wanted to get 3 days of skiing, you'd be best planning on being there 4-5 days. It also has the novelty of being located on the side of an active volcano that's "due" for an eruption;). For a good tradeoff of quality snow vs consistent weather, head to Cardrona on New Zealand's South Island. The raw stats are similar to Australia in terms of elevation, etc (minus the reliance on artifical snow), but because of geography and weather, the snow is much better and more consistent. Mt Hutt near Christchurch is also quite good, although a bit "bare". Avoid the major resorts around Queenstown, IMHO they're not as good skiing-wise (that said, the apres-ski aspect of Queenstown is much better than anywhere else, if that's something you look for).
As a serious question though, who's going to be doing renders and such where dual cores really shine, on a laptop?
Dual cores (like dual processors) start to shine as soon as you're doing any sort of interactive multitasking. For people using their laptop as a full time machine, that's important.
Everyone that writes and says their time is too valuable to build a machine (which let's face it, it takes only a couple of hours to assemble the parts) [...]
True. It does, however, take several solid days of research (if you don't keep up to date with hardware as a matter of course) to figure out what parts you should be assembling.
the whole thing is MS's fault. not the users. The app developers have secondary responsibility but MS caused the problem in the first place.
No, it's solely the application developers' fault. Microsoft have been recommending, and providing the necessary resources, to write LUA-friendly applications for a decade or so. It's part of the "Made for Windows XP" sticker requirements.
Their developer resources promote doing all kinds of bogus things in their apps. For years MSDN has gone out of its way to promote all the OS level hooks that are available to developers, many of which only work as admin.
And, of course, if they didn't, you'd be screaming about "undocumented APIs" or "Microsoft won't let us control our own computers".
It's no more Microsoft's fault that developer's write applications requiring admin access than it would be Linus's fault if I wrote an application that only ran as root.
MS aren't exactly standing on the moral superiority high ground here (I skimmed the article), how can they expect programmers to implement this with their programs when by default everyone is a local admin in windows and so far the only program which is supposed to use LUA is IE7 which isn't even released yet?
Microsoft have been giving developers the necessary information and tools to write "LUA-friendly" applications for about ten years now. Why is it their fault if application developers ignore it ? Is it Linus's fault if idiot Linux developers write apps that can only run as root ?
This is what amazes me about these discussions: they hired Cutler, the architect of a very successful OS, that had all of the necessary security features. They updated and reimplemented his architecture for modern PC hardware. They then mangled it beyond all recognition by insisting that programs written for Win 3.1 and later Win95 run under NT/2K/XP as if they were still on single-user, no priv separation, versions, and we're still living with that behaviour today.
No they didn't. Microsoft have been telling developers to write applications so they worked in regular user accounts for a decade.
Hell, the even implemented many of the "multiuser" features like per-user registries, home directories, etc on their single-user OS (Windows 9x) to make it easier for developers to write software that would run equally well as a regular user on NT as it did in Windows 9x.
Ok, that was obnoxious but my point was setting up a chroot jail is easier with command-line utilities.
Only if the GUI sucks.
If you don't know of anything that's easier with a command line tool, then you haven't done everything yet.
I know of a few things that are "easier" with a commandline (and many, many things that are "quicker"). However, 90% of them are only "easier" because a GUI interface either doesn't exist, or is extremely poorly designed.
When win9x went away in favour of a Windows NT kernel and environment, the multi-user environment was a completely new concept to hundreds of inexperienced programmers.
It's worth pointing out that NT has been around since 1993 and even Windows 9x has supported APIs and similar (eg: per user registries, per-user home directories/profiles, etc) to develop "multiuser friendly" applications since Windows 95 OSR2 (ca. 1996 - 97).
Software developers have had everything they need for around a decade to create Windows applications that don't needlessly require Administrator privileges. Those that haven't have no excuse.
To this day, several commonly-used programs still depend on Administrator access due to its development under an originally single-user environment or out of plain ignorance/stupidity.
Even today, supposedly top-notch developers are releasing software with needlessly idiotic implementations that "require" administrator privileges to run (I'm looking at you, id software).
That doesn't make it based on DOS any more than ndiswrapper makes Linux based on Windows.
I can only urge you to read a book like Inside Windows 95.
Windows 95 most certainly did use DOS calls, with the degree depending on how much 32 bit "code" was available. It was possible to *transparently* use Windows 95 with hardware that had no native Windows 95 drivers at all. It was not as simple as "DOS was a bootloader" although, likewise, it was also nowhere near as simple as "Windows is just a GUI on DOS".
This was a pretty incredible thing to do - quite frankly it's amazing Windows 95 worked at all, let alone as well as it did.
No. It was a lazy way to do backwards compatibility:)
Not in the slightest. Microsoft spend ~4 years developing Windows 95, they weren't "lazy" about it at all.
Windows 95 had 4 "essential" design requirements. It had to run DOS software (including drivers). It had to run Win16 software (including drivers). It had to run Win32 software (obviously) and it had to do for first two no slower than DOS and/or Windows 3.11 would on a 386 with 4M of RAM.
The hardware grunt simply didn't exist (in the consumer market) ca. 1994 to do the type of virtualisation you're talking about. Remember, a 386 was the typical machine, a 486 was fast and a Pentium was cutting edge. Which is why they didn't do it with virtualisation like NT or OS X does.
OS/2 and Windows NT can also run Win16 programs, but they do it right by using virtual environments.
OS/2 and Windows NT (NT in particular) also have higher hardware requirements and don't run anything like the range of software Windows 95 does. Additionally, you most certainly can't use DOS drivers to access hardware in either of them.
Microsoft could have reimplemented all the code it took from Windows 3.1 in 32-bit mode and run Windows 3.1 programs by mapping the 16-bit calls to their 32-bit counterparts. This would have made it so that Win16 programs could only bring down other Win16 programs rather than the whole system, and 32-bit programs couldn't bring down anyone but themselves.
And by doing so would have broken two of their primary design constraints, and simply ended up with the OS they already had (NT). Why would they have done that ?
This is, incidentally, what Windows XP still does.
Windows XP is Windows NT 5.1. It uses the same virtualisation methods for legacy support that every earlier version of Windows NT has (with improvements, obviously). This is why XP doesn't run all DOS and Win16 software DOS-based Windows does and can't leverage DOS drivers.
Instead, MS decided to reuse Windows 3.1 code. Thus, a large number of the 32-bit calls in Windows 95 (including most of USER32.DLL) were simply thunks to Win16. This meant that any unstable program, 16-bit or 32-bit, could potentially bring down the system, since a hung program might tie up the single Win16Mutex(), causing any program that makes Win16 calls or Win32 calls that thunk to Win16 to hang as well.
Firstly, I think you'll find the thunking only happened for Win16 apps (although it's been a very long time since I read Inside Windows 95, so I could be remembering wrong. Secondly, this 16/32 bit hybridiations was the sacrifice that had to be made for backwards compatibility. That's why anyone - particularly business customers - who *didn't* have any need for the additional legacy support Windows 9x offered, should have been running Windows NT. There was no reason whatsoever to run WIndows 95 if you didn't need it for DOS or Win16 support.
The entire 9x line didn't use DOS for anything other than a boot loader.
That's not strictly true. 95 could fall back to using DOS (ie: the BIOS) for hardware access in the absence of proper WIndows 95 drivers.
If your software and hardware was 100% Windows 95 compatible, DOS was pretty much irrelevant past boot. If it wasn't, DOS was used.
9x still sucked, but that was from a combination of sloppy programming and the fact that they were lazy and reused a whole bunch of 16-bit code through thunking. This had to be managed with Win16Mutex(), and when a program crashed during a 16-bit call the entire system would slowly lock up: other programs would make calls that had to be handled with 16-bit code, and these would stall since the mutex was waiting on the crashed program to return.
This was due to backwards compatibility requirements, not laziness.
The whole *point* of Windows 95 was to be a DOS/Win16/Win32 hybrid kludge. To say that it was like that because of laziness kind of ignores the main reason it was written in the first place.
I just loved NT 4.. man i didn't have keyboards or mouses attached because well you all know hold a key down.. hold the mouse button down and *BAM* 100% CPU usage until you let up.. someone lays a book down on it and the server stops responding
AFAIC, this deserves a +5 Informative if for nothing else than to offer a reminder that the basic truth underlying all these discussions is that Windows simply cannot be installed, managed or administered to any effective degree without resorting to a GUI. And no, an MMC snap-in for this or that feature, or using any of the one-off utilities found in the Resource Kit or elsewhere doesn't count.
And the only people who care about this are hardcore old-skool Unix nerds who get palpitations whenever something that isn't 7-bit ASCII text appears on their screen (and the horde of wannabe Slashbot fanbois who revere them).
A commandline is not a requirement for remote administration.
A commandline is not a requirement for automation.
A GUI is not an impediment to efficient systems administration.
So why didn't it look or act anything like MacOS ?
Moving the GUI into the kernel was a poorly thought out premature optimization.
How do you figure that ? Or are we forgetting that back when the decision was made a 66Mhz Pentium with a 33Mhz/32bit PCI video card was bleeding edge ?
Microsoft is doing the right thing by changing that.
Yes, I can't imagine at all how 10+ years of advancing technology could change the reasoning behind a kernel-mode graphical layer.
Acutally, you should want that. Let's say HR sends you a list of 100 new employees, along with user IDs. Do you really want to have to type each of those in (or cut and paste each one) and click on all the settings for each user?
Try and think outside the unix square for a few minutes. "Automation" and "command line" are not synonyms.
Maybe things have changed since I last had to admin Windows networks, but that's what you had to do.
Slashdot Mirror
Your point is wrong.
"Active Desktop" is still part of Windows (and has been for every version since Windows 98), it's just not turned on by default.
I like nipping down the Thredbo for the odd weekend during winter just as much as the next bloke, but Australia's skifields aren't even playing the same game as "the worlds best snow country", let alone in the same ballpark.
For those unfamiliar with skiing in Australia, we get about 3 months worth of skiable snow a year, with maybe 6 weeks of that involving snow that could be deemed 'powder'. The highest lifted point is about 2000m (~6500'), the biggest vertical drop is about 700m (~2200') and the longest trail is about 5.5km (~3.4 miles). They also rely *heavily* on artificial snowmaking for consistent cover and outside of peak season, it's not unusual to find the bottom ~20% of the mountain (well, hill ;) ) with very little natural snow at all.
(With NZ offering such consistently better snow for only marginally higher cost, it surprises me the Australian fields can even stay in business. All the following is IMHO, of course...)
The best skiing in Australasia is Mt Ruapehu on New Zealand's North Island. Unfortunately, it also has the worst weather, so if you wanted to get 3 days of skiing, you'd be best planning on being there 4-5 days. It also has the novelty of being located on the side of an active volcano that's "due" for an eruption ;). For a good tradeoff of quality snow vs consistent weather, head to Cardrona on New Zealand's South Island. The raw stats are similar to Australia in terms of elevation, etc (minus the reliance on artifical snow), but because of geography and weather, the snow is much better and more consistent. Mt Hutt near Christchurch is also quite good, although a bit "bare". Avoid the major resorts around Queenstown, IMHO they're not as good skiing-wise (that said, the apres-ski aspect of Queenstown is much better than anywhere else, if that's something you look for).
Yer dreamin'.
It does ?
The idea of binary *patches*, is bordering on blasphemous.
/Hyperbole
//But only just
Dual cores (like dual processors) start to shine as soon as you're doing any sort of interactive multitasking. For people using their laptop as a full time machine, that's important.
True. It does, however, take several solid days of research (if you don't keep up to date with hardware as a matter of course) to figure out what parts you should be assembling.
No, it's solely the application developers' fault. Microsoft have been recommending, and providing the necessary resources, to write LUA-friendly applications for a decade or so. It's part of the "Made for Windows XP" sticker requirements.
Their developer resources promote doing all kinds of bogus things in their apps. For years MSDN has gone out of its way to promote all the OS level hooks that are available to developers, many of which only work as admin.
And, of course, if they didn't, you'd be screaming about "undocumented APIs" or "Microsoft won't let us control our own computers".
It's no more Microsoft's fault that developer's write applications requiring admin access than it would be Linus's fault if I wrote an application that only ran as root.
Microsoft have been giving developers the necessary information and tools to write "LUA-friendly" applications for about ten years now. Why is it their fault if application developers ignore it ? Is it Linus's fault if idiot Linux developers write apps that can only run as root ?
There is a vast gulf of difference between "having local administrator rights" and "running as administrator all the time".
No they didn't. Microsoft have been telling developers to write applications so they worked in regular user accounts for a decade.
Hell, the even implemented many of the "multiuser" features like per-user registries, home directories, etc on their single-user OS (Windows 9x) to make it easier for developers to write software that would run equally well as a regular user on NT as it did in Windows 9x.
Only if the GUI sucks.
If you don't know of anything that's easier with a command line tool, then you haven't done everything yet.
I know of a few things that are "easier" with a commandline (and many, many things that are "quicker"). However, 90% of them are only "easier" because a GUI interface either doesn't exist, or is extremely poorly designed.
It's worth pointing out that NT has been around since 1993 and even Windows 9x has supported APIs and similar (eg: per user registries, per-user home directories/profiles, etc) to develop "multiuser friendly" applications since Windows 95 OSR2 (ca. 1996 - 97).
Software developers have had everything they need for around a decade to create Windows applications that don't needlessly require Administrator privileges. Those that haven't have no excuse.
To this day, several commonly-used programs still depend on Administrator access due to its development under an originally single-user environment or out of plain ignorance/stupidity.
Even today, supposedly top-notch developers are releasing software with needlessly idiotic implementations that "require" administrator privileges to run (I'm looking at you, id software).
I can only urge you to read a book like Inside Windows 95.
Windows 95 most certainly did use DOS calls, with the degree depending on how much 32 bit "code" was available. It was possible to *transparently* use Windows 95 with hardware that had no native Windows 95 drivers at all. It was not as simple as "DOS was a bootloader" although, likewise, it was also nowhere near as simple as "Windows is just a GUI on DOS".
This was a pretty incredible thing to do - quite frankly it's amazing Windows 95 worked at all, let alone as well as it did.
No. It was a lazy way to do backwards compatibility :)
Not in the slightest. Microsoft spend ~4 years developing Windows 95, they weren't "lazy" about it at all.
Windows 95 had 4 "essential" design requirements. It had to run DOS software (including drivers). It had to run Win16 software (including drivers). It had to run Win32 software (obviously) and it had to do for first two no slower than DOS and/or Windows 3.11 would on a 386 with 4M of RAM.
The hardware grunt simply didn't exist (in the consumer market) ca. 1994 to do the type of virtualisation you're talking about. Remember, a 386 was the typical machine, a 486 was fast and a Pentium was cutting edge. Which is why they didn't do it with virtualisation like NT or OS X does.
OS/2 and Windows NT can also run Win16 programs, but they do it right by using virtual environments.
OS/2 and Windows NT (NT in particular) also have higher hardware requirements and don't run anything like the range of software Windows 95 does. Additionally, you most certainly can't use DOS drivers to access hardware in either of them.
Microsoft could have reimplemented all the code it took from Windows 3.1 in 32-bit mode and run Windows 3.1 programs by mapping the 16-bit calls to their 32-bit counterparts. This would have made it so that Win16 programs could only bring down other Win16 programs rather than the whole system, and 32-bit programs couldn't bring down anyone but themselves.
And by doing so would have broken two of their primary design constraints, and simply ended up with the OS they already had (NT). Why would they have done that ?
This is, incidentally, what Windows XP still does.
Windows XP is Windows NT 5.1. It uses the same virtualisation methods for legacy support that every earlier version of Windows NT has (with improvements, obviously). This is why XP doesn't run all DOS and Win16 software DOS-based Windows does and can't leverage DOS drivers.
Instead, MS decided to reuse Windows 3.1 code. Thus, a large number of the 32-bit calls in Windows 95 (including most of USER32.DLL) were simply thunks to Win16. This meant that any unstable program, 16-bit or 32-bit, could potentially bring down the system, since a hung program might tie up the single Win16Mutex(), causing any program that makes Win16 calls or Win32 calls that thunk to Win16 to hang as well.
Firstly, I think you'll find the thunking only happened for Win16 apps (although it's been a very long time since I read Inside Windows 95, so I could be remembering wrong. Secondly, this 16/32 bit hybridiations was the sacrifice that had to be made for backwards compatibility. That's why anyone - particularly business customers - who *didn't* have any need for the additional legacy support Windows 9x offered, should have been running Windows NT. There was no reason whatsoever to run WIndows 95 if you didn't need it for DOS or Win16 support.
No, they use common dialogs that look and behave like explorer. There's a rather fundamental difference between those two things.
You'll find common dialogs in just about every GUI environment ever made. Haven't you ever fired up a GNOME app under KDE (or vice versa) ?
Much like, say, Redhat needs to find a way to separate glibc from RH Linux ?
That's not strictly true. 95 could fall back to using DOS (ie: the BIOS) for hardware access in the absence of proper WIndows 95 drivers.
If your software and hardware was 100% Windows 95 compatible, DOS was pretty much irrelevant past boot. If it wasn't, DOS was used.
9x still sucked, but that was from a combination of sloppy programming and the fact that they were lazy and reused a whole bunch of 16-bit code through thunking. This had to be managed with Win16Mutex(), and when a program crashed during a 16-bit call the entire system would slowly lock up: other programs would make calls that had to be handled with 16-bit code, and these would stall since the mutex was waiting on the crashed program to return.
This was due to backwards compatibility requirements, not laziness.
The whole *point* of Windows 95 was to be a DOS/Win16/Win32 hybrid kludge. To say that it was like that because of laziness kind of ignores the main reason it was written in the first place.
NTFS was a journalling filesystem around the same time Linus was first annoucing Linux.
Bullshit.
Most of which aren't actually in the kernel.
And the only people who care about this are hardcore old-skool Unix nerds who get palpitations whenever something that isn't 7-bit ASCII text appears on their screen (and the horde of wannabe Slashbot fanbois who revere them).
A commandline is not a requirement for remote administration.
A commandline is not a requirement for automation.
A GUI is not an impediment to efficient systems administration.
No. The point of Windows 95 was to offer a transitional platform from 16 bit DOS-based Windows to 32 bit NT-based Windows.
So why didn't it look or act anything like MacOS ?
Moving the GUI into the kernel was a poorly thought out premature optimization.
How do you figure that ? Or are we forgetting that back when the decision was made a 66Mhz Pentium with a 33Mhz/32bit PCI video card was bleeding edge ?
Microsoft is doing the right thing by changing that.
Yes, I can't imagine at all how 10+ years of advancing technology could change the reasoning behind a kernel-mode graphical layer.
Try and think outside the unix square for a few minutes. "Automation" and "command line" are not synonyms.
Maybe things have changed since I last had to admin Windows networks, but that's what you had to do.
No you didn't.