Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Vista (Announce)

posted by sol, 22.11.2007, 19:43

> Was it Win2000 or some other that dropped support for OS/2 1.x text apps?
> I mean, I never needed to run an OS/2 1.x app, but surely who would
> complain if Windows supported it? Seriously, why is backwards
> compatibility considered so evil?!
 ------------------------------------
> If MS would have done it if they could, then they didn't because they
> couldn't. So the question would be, why couldn't they? Other OSes have
> multiple access layers that some programmers, somewhere, knew how to write.
I really don't understand why everyone has so much trouble with understanding the problem of backwards compatibility. Poor planning is a big part of this, but sometimes things simply need to be deprecated.

DOS is an especially nasty specimen because "backwards compatibility" meant having lots of applications that assume that we're dealing with a single tasking OS with no security. What's this mean?

1) Direct attempts to read/write to the hard disk whether by interrupt or direct access (as in anti-virus, disk scanning, caching, etc)

2) More broadly; attempts at direct hardware access (video, drivers, serial/parallel ports, network devices, etc)

3) Simultaneous file read/writes by multiple applications

Answer to 1:
------------
(A) You could allow direct read/write to hard disk...but if you changed the FAT while the OS has its own cached copy...what happens? Which copy is correct? This would cause corruption/crashing. (B) You could disable direct hardware access and hook all interrupt calls and disallow them from writing to very sensitive areas. This would slow hard disk access quite a bit. This would also break compatibility with applications trying to write to those areas...they could cause worse problems since they might not handle the unexpected errors. (C) Disallow all calls - 100% breaking compatibility. Win9x did this.

Answer to 2:
------------
Direct attempts at hardware will change the state of the hardware if it's allowed. (A) You could constantly set it to a known state before working with it, but this wouldn't help if there's simultaneous access to prevent the system from crashing. It would also slow all operations involving the hardware. (B) You could stop the applications from direct access...this is what Win9x did. This breaks backwards compatibility.

Answer to 3:
------------
Multiple applications writing to one file is obviously never going to work, but why can't we have one application read and another write? Several reading? (A) You could use 'file locking', and have calls to open files request what they want to do (read/write/etc)...but the API doesn't support this. Breaks compatibility. (B) Add file locking APIs, but still support the old ones...except error out (Sharing Violation) when an app tries to write to a file currently being written. Will cause the app to crash, not too big of a deal (Win9x does this).

So basically, we're already breaking compatibility. Most apps were just updated after windows was released. Except, now we've got some issues:
- A pile of APIs that don't make any %*$#ing sense in a multitasking OS to add to the pile of APIs that do, and also perform the same tasks.
- Hooks of all kinds of interrupts that need to interact with the OS that should've been disabled
- Allowing of old interrupts/calls that can cause crashing
- Lots of extra code executing doing checks it shouldn't have to do

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 430 users online (0 registered, 430 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum