Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : MSFT Internet Explorer vs. NSCP Navigator -- Ignore unavailable to you. Want to Upgrade?

To: Dinesh who wrote (22027)	12/8/1998 8:57:00 AM
From: Justin Banks	Respond to of 24154

Why would SunOS's sprintf() return a value different from AT&T's ? 'Cause it deviated from the standard (though I think they've changed that now)? BTW, would that constitute a modification to "C" No, that meant that it wasn't ANSI standard C, but then again during that time period, I don't think Sun's c compiler even accepted function prototypes, being rather too k&r'ish for my tastes. -justinb

To: Dinesh who wrote (22027)	12/8/1998 7:55:00 PM
From: Charles Hughes	Respond to of 24154

>>> Why would SunOS's sprintf() return a value different from AT&T's ? BTW, would that constitute a modification to "C" ? After all, stdio is just as vital as awt or whathaveyou. <<< C, including the standard library, was standardized during the C++ effort. So what you describe is a violation of the public standard for the library. So compiler makers no longer do that, because it is known to screw up the developers and raise costs and lower reliability. Exactly the same point as with the OS. (MSFT in fact did screw around with the C standard lib calls when they were trying to eliminate their competition in C compilers some years ago. Same old MSFT.) Windows internal calls were already an incredible mish-mash of overlapping sets of partially obsolete API calls without the IE debacle. This kind of thing keeps me in work, but really, I would prefer to be working full time on something more productive than figuring out the psychotic windows programming architecture for people. Think about wasting maybe a quarter of the time of a million programmers a year with an average cost of maybe 125k per, just to reorganize around MSFTs various foolishnesses. 31 billion a year. And that's not even talking about the lost opportunity cost, the companies destroyed, the technologies never invented. The Aegis destroyers that can't keep their systems running when NT crashes. The price of monopoly and lack of public standards in the computer field is staggering. Eventually we are talking about hundreds of billions to trillions. Not to mention, as any reader of RISKS knows, computer screwups now kill and maim lots of people every year. >>> Of course there is always more than one way of doing stuff. Yeah, but MSFT was saying about a range of issues that they had to take the solution they did, for technical reasons. Which always seemed to be the one solution most inconvenient for their competitors. Or so it is alleged. The point here is that the ground is being laid to demolish the MSFT argument that it's actions were based on technical considerations. Having taken care of that you just need to look at the anticompetitive effect, because since the laws exist, you are supposed to be aware of this and avoid any unnecessary anticompetitive effect if you have a monopoly, just as you are supposed to be aware of any laws to which you are subject. Chaz P.S. I've been an NT developer for some time. I am perfectly aware of the upsides and downsides to that OS. Go Linux!