Thought DOS was DEAD??

Here's an article from last year to illustrate where our beloved OS is now residing...

http://www.zdnet.com/anchordesk/story/story_2324.html

[snip]

Examples include smart phones, set-top boxes, personal digital assistants, cash registers, factory automation, process control, avionics, handhelds, kiosks, pay-at-the-pump, airline entertainment, security panels, photocopiers, fax machines, game machines, calculators, medical and laboratory measurement, palmtops, organizers and network computers.

[end snip]

But is it Y2K COMPLIANT???

-- Forum Regular (Here@y2k.comx), November 08, 1999

Answers

I can second that. I did an embedded systems project for handheld last year that was DOS based. It didn't do much of anything date related though.

As a general principle, I still expect nearly all embedded systems to be either 1) not date dependent, 2) work after a reset if they have date rollover problems, 3) allow the date to be set back if they won't work with dates after 1/1/00.

Problems will be with systems that have dates in their memory or datebase, which prevent them from being rolled back, and systems that connect to larger systems that expect them to use the correct date. We'll just have to cross our fingers and hope there aren't many of these last two categories. Since no one is talking about actual remediation experiences, we're in the dark.

-- You Know... (notme@nothere.com), November 08, 1999.

My company uses both handhelds and an industrial entry station that are both running good ole 6.2 - we probably have a total of 800 of these things - the apps do not use dates - they are basically Clients talking to a compliant server (the server records the date and time of the xact) - these boxes will run, but the dates may not be correct, which will not matter, because I have yet to see one where the date was even close to right - I have suggested that we insert a line in the Autoexec or have the App set the date to something like 1990 each time the things are started up, but sofar no decision or action - if they fail, our help desk will just be busy telling the users how to set the date back.... We're a new SAP shop, like Hersey and others, sofar, we're still running along, but having to react almost daily...

-- BH (bh_slientvoice@hotmail.com), November 08, 1999.

What you have to remember is that most systems are driven by cost considerations. And DOS is certainly cheap.

-- just another (another@engineer.com), November 08, 1999.

DOS is dead only in the heart and mind of Microsoft. <:)=

-- Sysman (y2kboard@yahoo.com), November 09, 1999.

Here is a link on Y2K vs DOS Compatibility...

Link

-- John (jh@NotReal.ca), November 09, 1999.

Well, the real truth is that Win 95 and 98 are both based on DOS. Microsoft has said that they will proably release one more 'DOS based' version of Windows someitme in 2000 or 2001. Other than that, the other Windows products are NT (New Technologies) and Active Directory based.

DOS never went anywhere, and won't any time soon.

-- . (.@...), November 09, 1999.

I implemented a small embedded system that could read and write DOS disks. DOS 3.0 and later set aside 7 bits for the year starting with 1980 which means year rollover doesn't happen till 2108. Hopefully a better solution will have come along by then. As I recall, this was in excess of what VAX/VMS or Unix offered.

The IBM PC/AT introduced the battery backed up RTC that has a two digit year plus a 1 digit century. ie. 19 or 20. If the ROM BIOS has been written correctly, in theory there should be no problems until Y2K1 (2100).

So in fact, PCs & DOS system stuff is a bit better than what is usually portrayed in that they should be able to handle the turn of the century correctly. OTOH, applications either comply or don't when they use or compare dates. If they don't there's really no excuse for not having made it right. Hopefully, the apps can be fixed to take advantage of what the system provides.

-- Duane (dkucheran@creo.com), November 09, 1999.