4 ms·
Your application crashes. DOS does not.
by bonzini 6y ago
Your application crashes. DOS does not.
- pjmlp 6y agoI guess you never wrote DOS applications, nor used it on its prime days.
- bonzini 6y agoI did; I mean that if the system crashes it's your application's fault, not DOS's.
- pjmlp 6y agoHow can you prove that?
- neverartful 6y agoI suspect that they're alluding to the fact that DOS was more of a program loader than an OS and that once it loaded your program it was your program that was in the driver's seat. BUT there are subtle issues with drivers and networking still.
- pjmlp 6y agoI know that, but unless you can 100% guarantee that the application was clean from any kind of DOS interrupt calls, there are zero guarantees that it wasn't DOS, one of the drivers or the pseudo multitasking TSRs that were the culprit, there is no way to assert that the application was the one at fault.
- bonzini 6y agoDOS was simple enough that it can be considered essentially bug free. And in an embedded setting there are not going to be TSRs (you just boot directly into the application) and probably no DOS calls during the runtime. You would only use disks for special operations such as software updates.
- pjmlp 6y agoAh such a lucky one, never crashing DOS code, I guess you never used MS-DOS 4, nor had the experience of porting code across PC-DOS, MS-DOS and DR-DOS.
- bonzini 6y agoSome DOS versions were better than others. But often the cause was non portable code on the applications. That wouldn't apply if the DOS version is frozen.
- mikewarot 6y agoAmen! I never had a problem that wasn't bad hardware or my fault. All MS-DOS did was manage the disk, and keep track of time. There wasn't much to go wrong.