Some large corporations have Win3.1 based vertical apps used in things like call centers. As they expand the operations, they buy more copies of Windows 3.1.
A rewrite would be expensive, and often these things run on custom network drivers etc that are incompatible with Win95+.
Until relatively recently, MS even made money from sales of OS/2 1.3, which is even older than Windows 3.1.
Well, one big problem with PGP is the lack of integration with mailers. SMIME capable mailer (like Netscape and Outlook/OE) generally automatically verify the signature and display the results to the person reading the message.
I have an older version of the PGP add-on for Outlook, and it doesn't automatically verify messages. I'd have to reach all the way up and push a toolbar button, an for most mailing list messages, I can't be bothered!
Perhaps this is because the SMIME is based around the 'trusted root' idea, where PGP can be used in a completely decentralized mode. (You wouldn't be able to verify my PGP sig because I'm not on any key servers, for example.)
No, Microsoft didn't understand what Netscape and Sun were up to, and that's what made them scared. The only thing they did know is that Netscape thought they could make Windows "irrelevant" and "a poorly debugged collection of device drivers", and anyone with balls huge enough to say that must be up to something good.
Now that they've killed Netscape and failed to kill Sun, they finally sat down and thought about it for a while. And what they came up with was.NET(work is the computer).
A lot of that probably has to do with BIOS implementations. For example, my IBM ThinkPad 600 is rock solid with suspend/hibernate under Win2000 -- I bring it down and up several times a day and it's never failed. On the otherhand, my IBM desktop claims to support it, but it refuses to 'wake up'.
No -- This is a reason to bitch about Microsoft. In 1995, some of their "Product Managers" came in to our company and promised us that NT 4.0 would support APM (and Plug'n'Pray) as part of a sell to get us to standardize on NTW clients.
They backed off on that promise, and punted the feature to NT5, which was going to ship in 1997 or 98 or 99, or last year. In the meanwhile, laptop vendors had to hack their own APM drivers, but desktop support hardly shipped. Bottom line is that there's 4 years worth of NT machines out there that can't even shut down the monitor when idle.
Not to mention that it's tradtional in NT networks to have lots of little print server boxes, usually on desktop-type machines. (The reason being because the print subsystem ran partially in kernel mode and was unstable until about NT4-SP4.)
Such boxes could easily 'go to sleep' if they haven't done anything in an hour without affecting people, if there was a way to wake them up with a network request. (I don't know if these new 'management NICs' can do that under Win2K -- I know they can boot the machine, but wake them up?)
As a side note, that was a problem with lots of MacSE's and for a long time Apple would give you a new drive if you had one of the affected models. Unfortuantely, Apple isn't handing out 40MB Seagates anymore.
There were also certain Sun workstations that had the same problem, and the 'official' fix was to drop it from a height of 8 inches during boot.
All this is silly. Think about it.
COM/acriveX is (was) supposed to be cross language what happened to that? Can't you write comm objects is c++ or VB and call them from perl and python? Why invent yet another thing to do the same?
Why communicate via http and XML with other windows machines when you can use DCOM or COM+ or whatever it is they are calling it these days.
It's actually the same idea. The problem with Windows RPC is two-fold: It runs on the NetBIOS ports (139 etc) and is firewalled by every corporation and ISP, and it is also totally unreliable over slow links (as years of trying to use the NT system tools have taught me...)
SOAP solves this problem by moving to HTTP/HTTPS which is more difficult to firewall and probably won't be (scary!), and is presumably better at handling the sorts of modem and ISDN connections that home users and back offices have.
Of course if they just grafted SOAP onto DCOM, everything would be hunky dory (why not, you can already do MTS/MSMQ over SMTP). But, nope, they have to invent a new component interface and throw in the CLR to confuse things. This effectively obsoletes the core technologies that they've been selling to developers for the last 5 years. Either a anti-antitrust strategy, or a total and complete admission that DCOM has been a commercial failure.
Actually, in my observations, most end users are much happier with a web application than they are with a VB/Java/PowerBuilder/Whatever client software. Probably because they associate WWW with Fun Porn Fun, but they hardly complain about the missing functionality (key shortcuts and the like), and were never that impressed with your cool grid control anyway. Not to mention the fact that web apps are about 200x cheaper to deploy and manage than the usual DLL Hell winclients.
Real big transaction environments users like call centers, might have a different attitude, but in that case a dumbterm is still often the fastest data entry solution.
They should have. Either that or support VB6 on future platforms until the end of time.
But, this would be to ignore one of Microsoft's biggest strategic advantage in their war with Java -- the hoard of lower-paid internal corporate VB developers. These are basically people that can't be converted to {C-style} syntax, or they would have been hacking at Java or J++ at least a long time ago. By giving them a BASIC with most of the features of Java, Microsoft can make a major appeal on cost and on the "do it internally versus hire it out" question.
Now if I was a person or corporation that had invested pretty heavily in VB6 and DCOM and all of that last year's stuff, I'd be pretty pissed that Microsoft is breaking my apps and pulling the rug out from under my standard technolgoy. But these folks are accustomed to doing what they're told, and most are busy downloading the.NET betas and boning up.
If MS were to be split up, it's not clear to me which side would get which components of the.NET architecture, though some guesses seem reasonable.
Read the trial documents. The interesting thing is that it does not that much about web browsers. Instead it generally classifies a whole bunch of software as "middleware" -- the accusation being that MS is using their OS monopoly to selectively take over middleware markets (browsers and Java to be specific).
So,.NET is carefully crafted to be middleware, which means it goes with the App Company in a breakup. This is unlike COM which is pretty clearly a API facility and therefore belongs to the OS Company (DCOM is arguable). Which gives them the right to control "the platform" for upcoming versions of MS Office etc., if they do happen to get broken up. Then the OS Company can go out of business for all the app company cares, because the can just move the.NET VM to Linux or OS/2 or whatever else.
And if they don't get broken up, they can use their OEM contracts to push.NET onto millions of machines and keep Java off them, just like they did with IE. Or at least until some judgement or settlement comes down.
don't think there will be any contest between the AMD x86-64 and the Intel IA-64 processors.
Is there really any fair comparision between the two?
Look at it from a major vendor's point of view (say Compaq): Itanium will be running in $15,000 "Professional Workstation" models running 64-bit Linux or Windows 2002 and only available through special distributors and support channels. Sledgehammer will be running in $2,000 "Presario" models running 32/16-bit Windows ME models (with maybe 64-bit optimized video drivers) that anyone can pick up at the local Best Buy or Radio Shack.
Which is not to say that someone won't put together a nice 64-bit Linux solution on Sledgehammer. But without broad OS support (Windows, Novell, etc), Sledgehammer isn't really in the same market as IA64, Alpha, and Sparc.
Microsoft Exchange was in development for 7 years at MS before shipping. And it still really hasn't stablized, despite the fact the core has really been significantly upgraded.
Lotus Domino has been on the market for about 14 years, and before that it was a university project.
Anyway, good luck to any open sourcers trying to reproduce this sort of groupware server, because it's a huge job.
A more fruitful approach might be to just tie together a LDAP/IMAP/NNTP server system with a unified install and admin interface (kinda like Netscape tried to do).
That having been said, a worm that targeted IIS4's FTP service and W2K's Print Server service, and had nothing to do with the usual Outlook/VBS/Desktop virus targets, would be treated to a 300 post flamefest on Slashdot, even if Microsoft had fixed the exploits months ago. Instead, we have 98 posts currently, most of them relatively demure.
I'm actually kinda surprised that "Red$at" is getting such kind treatment around here today.
Office for MacOS X, and pretty much every other MacOS X application are built on the proprietary Apple Carbon API and has nothing to do with MacOS X's BSD compatibility server.
But, if it was said on Slashdot (OS X == BSD), it must be true!
Three cheers to anyone who managed to get paid millions of dollars from what is essentially a clone shop. Thats alot of money for turning a few screws and installing Linux.
Most Win2K stability problems fall in that category. 2000 was not intended to run on all motherboards with all BIOSes - In fact the default-on ACPI stuff pretty much exists only to smoke out defective boards that mighta sorta worked in 98.
Linux can run on some of these "Win9x" systems, of course. But that's only because some poor guy spend umpteen unpaid hours sniffing around the hardware to figure out exactly what's defective or undocumented about it. Nobal effort, to be sure.
So, yeah, it sucks that Windows 2000 doesn't support every piece of junk hardware (and junk hardware includes some of the stuff that the hardware sites jizz over for quake numbers). But, at least the situation is better than NT4, which was better than NT3 and OS/2 (for which you pretty much had scope out a 'certified' system).
You make it sound as if all these Apple-Microsoft deals were seperate things. The fact is that they all happened at the same time and were probably negotiated together at the same table. I think Spindler's book discusses this, so look in your local rement bin.
+ Apple finds QuickTime code in Windows.
+ Apple finds a judge apparently willing to put an injunction down on shipping Windows if a settlement can't be reached.
+ Other, unspecified, Apple patent violations by Microsoft.
+ Time and negotiations pass.
+ Microsoft agrees to support Office and IE on Mac, at the same level as Windows, for a number of years.
+ Apple agrees to make IE the default web browser on MacOS and support Microsoft's Java flavor (the latter never happened, I think.)
+ Microsoft agrees to pay Apple a 'substantial' undisclosed sum and a $150M disclosed sum.
+ Apple wins that round, getting cash and critical software for their platform from their #1 ISV.
Sysadmin access is *not* a backdoor. It's a Front Door, dammit. (As in, every user should know that the company has access to their machine via the sysadmin.)
My datapoint is a book I found in a junk bin called "The Sony Vision" (Nick Lyons, 1976). It contains pictures of BetaMax units clearly designed for the US home market, including a combo TV-VCR unit. There is also a chapter which describes Beta as a cheaper and more convienient version of U-Matic scaled down for the consumer market. It doesn't discuss Beta as a professional format at all...
"It will be used by broadcasters though to store material"
Don't broadcasters already have 69 digital tape formats to choose from?
"VHS" says to me that it's a consumer format. Maybe you'll see adoption from people that do home/low-scale video editing on their firewire Macs, but I don't see the real pros using this. (For example, DigitalBetaCam has 95 Mbps and is backcompatible with their existing tapes.)
Slashdot Mirror
Traditionally HTML mail is sent in two parts, one text/html and one text/plain.
That Hotmail toolbar thing seems to only send text/html, which sucks because I occasionally have to check mail from an older version of pine.
I'm not against HTML mail, but breaking the convention of a plain text fallback is all wrong.
Some large corporations have Win3.1 based vertical apps used in things like call centers. As they expand the operations, they buy more copies of Windows 3.1.
A rewrite would be expensive, and often these things run on custom network drivers etc that are incompatible with Win95+.
Until relatively recently, MS even made money from sales of OS/2 1.3, which is even older than Windows 3.1.
Well, one big problem with PGP is the lack of integration with mailers. SMIME capable mailer (like Netscape and Outlook/OE) generally automatically verify the signature and display the results to the person reading the message.
I have an older version of the PGP add-on for Outlook, and it doesn't automatically verify messages. I'd have to reach all the way up and push a toolbar button, an for most mailing list messages, I can't be bothered!
Perhaps this is because the SMIME is based around the 'trusted root' idea, where PGP can be used in a completely decentralized mode. (You wouldn't be able to verify my PGP sig because I'm not on any key servers, for example.)
No, Microsoft didn't understand what Netscape and Sun were up to, and that's what made them scared. The only thing they did know is that Netscape thought they could make Windows "irrelevant" and "a poorly debugged collection of device drivers", and anyone with balls huge enough to say that must be up to something good.
.NET(work is the computer).
Now that they've killed Netscape and failed to kill Sun, they finally sat down and thought about it for a while. And what they came up with was
A lot of that probably has to do with BIOS implementations. For example, my IBM ThinkPad 600 is rock solid with suspend/hibernate under Win2000 -- I bring it down and up several times a day and it's never failed. On the otherhand, my IBM desktop claims to support it, but it refuses to 'wake up'.
No -- This is a reason to bitch about Microsoft. In 1995, some of their "Product Managers" came in to our company and promised us that NT 4.0 would support APM (and Plug'n'Pray) as part of a sell to get us to standardize on NTW clients.
They backed off on that promise, and punted the feature to NT5, which was going to ship in 1997 or 98 or 99, or last year. In the meanwhile, laptop vendors had to hack their own APM drivers, but desktop support hardly shipped. Bottom line is that there's 4 years worth of NT machines out there that can't even shut down the monitor when idle.
ACPI, on the other hand, is I believe mandatory for Intel SMP boxes. (At least the Configuration parts, can't say about the Power parts.)
APM is essentially a legacy spec.
Not to mention that it's tradtional in NT networks to have lots of little print server boxes, usually on desktop-type machines. (The reason being because the print subsystem ran partially in kernel mode and was unstable until about NT4-SP4.)
Such boxes could easily 'go to sleep' if they haven't done anything in an hour without affecting people, if there was a way to wake them up with a network request. (I don't know if these new 'management NICs' can do that under Win2K -- I know they can boot the machine, but wake them up?)
As a side note, that was a problem with lots of MacSE's and for a long time Apple would give you a new drive if you had one of the affected models. Unfortuantely, Apple isn't handing out 40MB Seagates anymore.
There were also certain Sun workstations that had the same problem, and the 'official' fix was to drop it from a height of 8 inches during boot.
All this is silly. Think about it.
COM/acriveX is (was) supposed to be cross language what happened to that? Can't you write comm objects is c++ or VB and call them from perl and python? Why invent yet another thing to do the same?
Why communicate via http and XML with other windows machines when you can use DCOM or COM+ or whatever it is they are calling it these days.
It's actually the same idea. The problem with Windows RPC is two-fold: It runs on the NetBIOS ports (139 etc) and is firewalled by every corporation and ISP, and it is also totally unreliable over slow links (as years of trying to use the NT system tools have taught me...)
SOAP solves this problem by moving to HTTP/HTTPS which is more difficult to firewall and probably won't be (scary!), and is presumably better at handling the sorts of modem and ISDN connections that home users and back offices have.
Of course if they just grafted SOAP onto DCOM, everything would be hunky dory (why not, you can already do MTS/MSMQ over SMTP). But, nope, they have to invent a new component interface and throw in the CLR to confuse things. This effectively obsoletes the core technologies that they've been selling to developers for the last 5 years. Either a anti-antitrust strategy, or a total and complete admission that DCOM has been a commercial failure.
Actually, in my observations, most end users are much happier with a web application than they are with a VB/Java/PowerBuilder/Whatever client software. Probably because they associate WWW with Fun Porn Fun, but they hardly complain about the missing functionality (key shortcuts and the like), and were never that impressed with your cool grid control anyway. Not to mention the fact that web apps are about 200x cheaper to deploy and manage than the usual DLL Hell winclients.
Real big transaction environments users like call centers, might have a different attitude, but in that case a dumbterm is still often the fastest data entry solution.
They should have left VB mostly the way it was.
.NET betas and boning up.
They should have. Either that or support VB6 on future platforms until the end of time.
But, this would be to ignore one of Microsoft's biggest strategic advantage in their war with Java -- the hoard of lower-paid internal corporate VB developers. These are basically people that can't be converted to {C-style} syntax, or they would have been hacking at Java or J++ at least a long time ago. By giving them a BASIC with most of the features of Java, Microsoft can make a major appeal on cost and on the "do it internally versus hire it out" question.
Now if I was a person or corporation that had invested pretty heavily in VB6 and DCOM and all of that last year's stuff, I'd be pretty pissed that Microsoft is breaking my apps and pulling the rug out from under my standard technolgoy. But these folks are accustomed to doing what they're told, and most are busy downloading the
If MS were to be split up, it's not clear to me which side would get which components of the .NET architecture, though some guesses seem reasonable.
.NET is carefully crafted to be middleware, which means it goes with the App Company in a breakup. This is unlike COM which is pretty clearly a API facility and therefore belongs to the OS Company (DCOM is arguable). Which gives them the right to control "the platform" for upcoming versions of MS Office etc., if they do happen to get broken up. Then the OS Company can go out of business for all the app company cares, because the can just move the .NET VM to Linux or OS/2 or whatever else.
.NET onto millions of machines and keep Java off them, just like they did with IE. Or at least until some judgement or settlement comes down.
Read the trial documents. The interesting thing is that it does not that much about web browsers. Instead it generally classifies a whole bunch of software as "middleware" -- the accusation being that MS is using their OS monopoly to selectively take over middleware markets (browsers and Java to be specific).
So,
And if they don't get broken up, they can use their OEM contracts to push
don't think there will be any contest between the AMD x86-64 and the Intel IA-64 processors.
Is there really any fair comparision between the two?
Look at it from a major vendor's point of view (say Compaq): Itanium will be running in $15,000 "Professional Workstation" models running 64-bit Linux or Windows 2002 and only available through special distributors and support channels. Sledgehammer will be running in $2,000 "Presario" models running 32/16-bit Windows ME models (with maybe 64-bit optimized video drivers) that anyone can pick up at the local Best Buy or Radio Shack.
Which is not to say that someone won't put together a nice 64-bit Linux solution on Sledgehammer. But without broad OS support (Windows, Novell, etc), Sledgehammer isn't really in the same market as IA64, Alpha, and Sparc.
Microsoft Exchange was in development for 7 years at MS before shipping. And it still really hasn't stablized, despite the fact the core has really been significantly upgraded.
Lotus Domino has been on the market for about 14 years, and before that it was a university project.
Anyway, good luck to any open sourcers trying to reproduce this sort of groupware server, because it's a huge job.
A more fruitful approach might be to just tie together a LDAP/IMAP/NNTP server system with a unified install and admin interface (kinda like Netscape tried to do).
Nice wagon circling -- you deserve the karma.
That having been said, a worm that targeted IIS4's FTP service and W2K's Print Server service, and had nothing to do with the usual Outlook/VBS/Desktop virus targets, would be treated to a 300 post flamefest on Slashdot, even if Microsoft had fixed the exploits months ago. Instead, we have 98 posts currently, most of them relatively demure.
I'm actually kinda surprised that "Red$at" is getting such kind treatment around here today.
Oops - proprietary Apple Carbon and Cocoa APIs
Office for MacOS X, and pretty much every other MacOS X application are built on the proprietary Apple Carbon API and has nothing to do with MacOS X's BSD compatibility server.
But, if it was said on Slashdot (OS X == BSD), it must be true!
Three cheers to anyone who managed to get paid millions of dollars from what is essentially a clone shop. Thats alot of money for turning a few screws and installing Linux.
How about (3) Your Hardware or Drivers Suck.
Most Win2K stability problems fall in that category. 2000 was not intended to run on all motherboards with all BIOSes - In fact the default-on ACPI stuff pretty much exists only to smoke out defective boards that mighta sorta worked in 98.
Linux can run on some of these "Win9x" systems, of course. But that's only because some poor guy spend umpteen unpaid hours sniffing around the hardware to figure out exactly what's defective or undocumented about it. Nobal effort, to be sure.
So, yeah, it sucks that Windows 2000 doesn't support every piece of junk hardware (and junk hardware includes some of the stuff that the hardware sites jizz over for quake numbers). But, at least the situation is better than NT4, which was better than NT3 and OS/2 (for which you pretty much had scope out a 'certified' system).
You make it sound as if all these Apple-Microsoft deals were seperate things. The fact is that they all happened at the same time and were probably negotiated together at the same table. I think Spindler's book discusses this, so look in your local rement bin.
+ Apple finds QuickTime code in Windows.
+ Apple finds a judge apparently willing to put an injunction down on shipping Windows if a settlement can't be reached.
+ Other, unspecified, Apple patent violations by Microsoft.
+ Time and negotiations pass.
+ Microsoft agrees to support Office and IE on Mac, at the same level as Windows, for a number of years.
+ Apple agrees to make IE the default web browser on MacOS and support Microsoft's Java flavor (the latter never happened, I think.)
+ Microsoft agrees to pay Apple a 'substantial' undisclosed sum and a $150M disclosed sum.
+ Apple wins that round, getting cash and critical software for their platform from their #1 ISV.
OK. Thanks for the historical information.
Sysadmin access is *not* a backdoor. It's a Front Door, dammit. (As in, every user should know that the company has access to their machine via the sysadmin.)
My datapoint is a book I found in a junk bin called "The Sony Vision" (Nick Lyons, 1976). It contains pictures of BetaMax units clearly designed for the US home market, including a combo TV-VCR unit. There is also a chapter which describes Beta as a cheaper and more convienient version of U-Matic scaled down for the consumer market. It doesn't discuss Beta as a professional format at all...
"It will be used by broadcasters though to store material"
Don't broadcasters already have 69 digital tape formats to choose from?
"VHS" says to me that it's a consumer format. Maybe you'll see adoption from people that do home/low-scale video editing on their firewire Macs, but I don't see the real pros using this. (For example, DigitalBetaCam has 95 Mbps and is backcompatible with their existing tapes.)