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: Daniel Schuh who wrote (20687)	8/17/1998 4:26:00 AM
From: Daniel Schuh	Read Replies (1) \| Respond to of 24154

Secrecy of Software Code Creates Security Risk nytimes.com But a proprietary lock is a necessity in business, you know. "The problem is these gigantic, 10-megabyte Web browsers," said Mark Seiden, chief network consultant for Veriguard Inc., a computer-security concern in Menlo Park, Calif. "Nobody knows what flaws are in them. Nobody even knows, really, everything that they do." A Microsoft tradition, you might say. When you got 8500+ APIs floating around, it goes without saying it's all beyond the comprehension of mere mortals. Only Bill knows . . . Yet, he said, we install them without thinking. "Or worse," Seiden said, "you have no choice but to install them because, in the case of Internet Explorer, they're part of the operating system. Then there are all the things which are part of Windows which haven't been looked at, with an eye toward security, by anybody other than the vendor." They don't call it "Internet Exploder" for nothing. Embrace and Demolish! Any software company that develops software for Windows, for example, has to trust whatever security defaults Microsoft has chosen to use, yet "the developers have no idea what's in them," Seiden said. "There's no way to find out the Windows source code." Until a few months ago, the same was true of Netscape. But earlier this year, Netscape published its source code to encourage its use by third-party software developers. Apparently developers have not had sufficient time to discover all its flaws. They will, though. Bill, if you love something, set it free! Cheers, Dan.

To: Daniel Schuh who wrote (20687)	9/13/1998 12:17:00 PM
From: rudedog	Read Replies (1) \| Respond to of 24154

Dan - When did Microsoft actually ship a TCP/IP Winsock for Windows 3? In 1989, I was lead designer on a team building a complex retail system which had an IBM S/390 for core transactions, a set of Sun (later HP) Unix boxes for relational database work (Sybase) which managed support and tracking data as well as real-time business rules, and a client system running Windows. The windows boxes used both HALAPI (to do CICS to the mainframe) and TCP/IP to talk to the Unix boxes. We used a stack from FTP for the TCP/IP stuff. This was a large system both in physical and geographic terms (used a WAN for stores in several states). MSFT was very interested in various parts of the work and sent engineering teams in at various times to work with us, and to try alternate designs using all MSFT technology. They put up a parallel system using OS/2 SQL Server which was tested in 1990. It included a MSFT-written TCP/IP stack over NDIS. Performance of this system was not too bad given that it was running on a 486-based server and the 'real' system was on a Sun 690. It did not have enough headroom to support the real system but the MSFT TCP/IP stack worked quite well. The MSFT team also put up an OS/2 system which managed the CICS traffic through a consolidator - IBM also helped out with that. This approach would have been much less costly than putting the HALAPI boards in every client and doing two WANs, one for SNA and a second for TCP/IP. So at least as far back as 1990, there was significant interest at the engineering level in a TCP/IP stack for MSFT. That work later rolled into both Windows and NT, but not for many years. Watch out for that DNA retrovirus. You know what DNA stands for of course - National Dyslexia Association... <GG>

To: Daniel Schuh who wrote (20687)	9/13/1998 12:18:00 PM
From: rudedog	Read Replies (1) \| Respond to of 24154

Dan - When did Microsoft actually ship a TCP/IP Winsock for Windows 3? In 1989, I was lead designer on a team building a complex retail system which had an IBM S/390 for core transactions, a set of Sun (later HP) Unix boxes for relational database work (Sybase) which managed support and tracking data as well as real-time business rules, and a client system running Windows. The windows boxes used both HALAPI (to do CICS to the mainframe) and TCP/IP to talk to the Unix boxes. We used a stack from FTP for the TCP/IP stuff. This was a large system both in physical and geographic terms (used a WAN for stores in several states). MSFT was very interested in various parts of the work and sent engineering teams in at various times to work with us, and to try alternate designs using all MSFT technology. They put up a parallel system using OS/2 SQL Server which was tested in 1990. It included a MSFT-written TCP/IP stack over NDIS. Performance of this system was not too bad given that it was running on a 486-based server and the 'real' system was on a Sun 690. It did not have enough headroom to support the real system but the MSFT TCP/IP stack worked quite well. The MSFT team also put up an OS/2 system which managed the CICS traffic through a consolidator - IBM also helped out with that. This approach would have been much less costly than putting the HALAPI boards in every client and doing two WANs, one for SNA and a second for TCP/IP. So at least as far back as 1990, there was significant interest at the engineering level in a TCP/IP stack for MSFT. That work later rolled into both Windows and NT, but not for many years. Watch out for that DNA retrovirus. You know what DNA stands for of course - National Dyslexia Association... <GG>