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 : Wind River going up, up, up! -- Ignore unavailable to you. Want to Upgrade?

To: Ramsey Su who wrote (3042)	4/17/1998 8:14:00 AM
From: w2j2	Read Replies (1) \| Respond to of 10309

Try these: exchange2000.com exchange2000.com wj

To: Ramsey Su who wrote (3042)	4/17/1998 11:18:00 AM
From: Snowshoe	Respond to of 10309

Ramsey, I am surprised that Microsoft is so far behind in the real-time arena. In fall 1996 I mentioned on this thread that MSFT was working on a couple of real-time projects code-named "Rialto" and "Mimosa", so I figured they would be farther along. Even though they are so late, I expect MSFT will have some success with new types of consumer end-products such as wireless handsets that benefit from the cachet of the "Windows CE" brand-name, and also need an RTOS. But will we ever see Windows CE used in deeply-embedded RTOS environments like telecommunications, aviation, and automotive applications? Before they would consider it, I think the development engineers would want to see a considerable track record of proven reliability that will take years to develop. As for the legal question you raise, I think it's important but I don't have the answer. Does anyone on the thread know how the typical RTOS warranty compares to Microsoft's standard "shrink-wrap" warranty?

To: Ramsey Su who wrote (3042)	4/17/1998 11:50:00 PM
From: Allen Benn	Read Replies (3) \| Respond to of 10309

>Can the RTOS world handle the flaws of the typical MSFT 1.0 releases and >worry about fixing the bugs later? The software industry ingeniously avoids most product liabilities. This is done not just by explicitly limiting liability in the fine print of licensing agreements, but by openly acknowledging the fallibility of their products. The software industry exposed, and then educated, the world of developers and end-users to the notion of software "bugs". By claiming, and constantly proving, that software bugs can rarely be eradicated, users had little choice but to accept the pervasiveness of software bugs. The most successful of all software companies, Microsoft, has built an empire on the notion that to err is human. Microsoft's patented rapid prototype initiating a continuous spiral of fleshing out functionality, is anathema to elegant design and operational robustness. Certainly Microsoft has learned that humans are particularly adept and forgiving about bugs that surface in complex human machine interfaces. Once they understand the Ctrl-Alt-Del sequence, they seem to accept any amount of buggy behavior. The ultimate in fleshing out a prototype is the laundry list of add-ons Microsoft intends to include in the next version of Windows CE. What must the operating system gurus at all the RTOS companies be thinking about this novel approach to operating system design and implementation? The theory behind the acceptable software bug is that software is incredibly complex, and rarely can be shown to the bug-free. Lacking the ability to prove correctness, the software industry has convinced customers to hold them blameless. If this makes sense to you, then why do we hold other manufacturers of complex products liable for their mistakes? Are all other products relatively simple in comparison to software? Of course not. This flexibility for passing the buck is not found in embedded systems. First, the interface may not be complex, or may even be non-existent. Indeed, few users may even be aware of the existence of software in a failed product. This means the software component of many embedded systems is not automatically given special treatment. Second, embedded systems often are deployed in mission critical, even life threatening situations, in which unwarranted product failures will not be forgiven or ignored. Reliability is but one of many tests Windows CE will have to pass to be considered seriously for most deeply embedded applications. When the Microsoft representative indicated to the Wall Street Journal that Windows CE would be appropriate for the AutoPC, but not process controls in automobiles, I suspect he really meant something much stronger. I doubt that Microsoft's lawyers would allow Windows CE to be used to control automobile processes, because of obvious difficulties shielding the company from expected product liability suits. Consider another example. The FAA permits software that is used to manage flow of aircraft to be written in any language without regard to any standard. Data flowing throughout the system not only is filled with omissions and commissions, but by design (or lack of design) much of it is incompatible or contradictory. But by definition, aircraft never crash from bad flow control, so there is no possibility of anyone being held liable for buggy management software or data. However, aircraft are dependent on air traffic control, involving hardware, software and human controllers. The software governing air traffic control is limited to specific languages with certified compilers, thoroughly documented and subject to exacting standards. A rough estimate for the cost of one line of assembly code used in air traffic control software is $100. In the late 1980s, the FAA migrated air traffic control software to updated IBM mainframes at the 20 en route control centers. To keep it simple and affordable, the migration avoided any upgrades in functionality, and still cost hundreds of millions in software alone. Microsoft wants to borrow the FAA's sloppy management software approach for use in the entertainment portion of the automobile, while carefully sidestepping all the serious, deeply embedded process controls like what is used to control aircraft. Allen