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: Bald Eagle who wrote (6088)	8/15/1999 2:48:00 PM
From: Chinacat	Read Replies (1) \| Respond to of 10309

B E In general, chips on their own don't realy "comply" or "non-comply" with Y2K type issues. In my opinion, Y2K in the embedded world has two facets: 1. The system clock that is being run usually just ticks. That is to say, it has some sort of "start date" and the clock just advances forward in time from there onwards. In some applications, there will be a "calender" that may or may not have been designed to comply with Y2K issues. However, this tends to have little connection with the supplier of the RTOS or the Chip. 2. File Systems. This is a pretty serious head-ache. Most RTOSes have an option to support DOS file systems. In most of these OSes, they've supported this feature from way back in the late 80's / early 90's, and comply with DOS 5.x or so, which means that the filenames are not long-file-names and don't comply with the Win32 FAT. The issue here is that the files created and managed under this DOS file system will have serious problems (I think that the earlier DOS filesystems can't name files after 12/31/1999, or will create files that have funny dates like 01/01/1900) and this will screw up the whole application. That being said, I think that there will be some acceleration in business once the Y2K scare is over, just like in the Database, Enterprise, and ERP world. cheers!