Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Compatibility woes / deprecation (Miscellaneous)

posted by marcov, 18.02.2009, 23:08

> > > Itanium 2 can only run x86 in software emulation now.
> >
> > Compatible to their own lines, even though the lines were in heavy
> > decline.
> > Not everything is about x86.
>
> Yes it is (almost), for good or bad.

Afaik, there are more ARMs and MIPS sell bigger numbers than x86s :-) (*)

(*) though the revenue might be /slightly/ larger on the x86s :-)

> The only reason for Itanium 2's
> lacking support is that it was faster in software anyways, so they decided
> to scrap the hardware compatibility aspect.
Afaik the reason was that they had given up hope attracting the x86 hordes, and focussed on some high-end businesses that came mostly from HPUX (HP being the major Itanium vendor) and some highend computing (FPU throughput was quite nice for before Opteron times)

> > The problem with multicore is the apps, not the OS.
>
> I know, but the OS does do some things itself, so speeding itself up
> doesn't hurt.
Well, I assume it the same what the *nixes are doing, improving the granularities of kernel locking to avoid all-core stalls, as well as better supporting NUMA architectures. But that is only for scalability of server apps. Doubt it matters much for home use.

> > SSE5 has some minor checksumming/compression and encryption primitives
> > only afaik.
>
> AMD does claim much improved (30%?) single thread speedups.
If I add all the claims over all new technologies over the years together, I would have a 20 times the machine now. I can imagine this for maybe an ideal compression/checksumming/encryption scenario. But not for avg singlethread performance. I think 5% (from SSE5 alone) will be optimistic.

> > Don't know. Afaik the devels that mostly did that partially went to the
> > native OS/2 port. And while still alive (as in devels are on the list)
> > the mutation rate there is not that high either :-)
>
> I think the README.TXT still incorrectly mentions the EMX port as if still
> available, but the FTP /snapshots/ shows an empty i386-emx/ dir for both
> v22 and v23. I'm not surprised, esp. since EMX isn't actively maintained,
> AFAICT.
Yes, formally removing them from the list is a big step, and therefore always done late. (typical scenario: devel 1 says "we should delist this port". Devel 2: "but I just spent some time on it to get it releasalbe again" ... deadline passes. Devel 1: "where is the release for xx". Devel 2: "Sorry, something came up, didn't have time".

Note that this is not a accusation. It is simply how it works, and I myself am also guilty of this, many times (for instance, freebsd 64-bit support)

> I can't force and am not trying to, obviously. I just don't understand the
> rationale for dropping everything that was acceptable before.
Nobody was there to maintain it anymore. They just put out the light in the factory, but the factory was already empty. But the light going out is the thing that is visible from a distance, not the factory going slowly bankrupt and less busy over the years.

> > And old things lie on the ground, rot away and become fossils. Like Dos
> > and Dinosaurs.
>
> It's just frustrating: invest all your time and energy into this ... oh
> wait, we've moved onto something else. Try again!
IMHO if you are fair, subtract all your time invested after say 95-96. Because by then you should have been able to see it coming. If you invested the bulk of that time after that, you must have known it was a dying platform.

> DPMI is a standard, MS was very important to its creation.

Yes. And a standard is a document. Not software.

> It was published by a 12-member committee. Ignoring all the real-world reasons
> why they can't, I'm wondering, why wouldn't they want to be
> more compatible by running more apps??

Oldest rule of marketplaces:
Costs money/effort etc, and not enough demand.

> All their anti-MS b.s. and yet they do the same damn
> thing, spit on the little guy.

Well, IMHO the problem IS the little guy. Most of them run around like chicken without heads. Dos got killed off so quickly because in those times the number of computer users became 20-40 times as big, and the people that never knew it, never understood it.

The Office franchise has been based on the fact that employees would install an illegal version of the latest and greatest at home. And half an year later, some manager would solve the "problems" by "unifying" the company on the latest and greatest.

It may be strange to hear me say this in a thread were I argue against stagnation, but I'm a realistic, and while IMHO Dos was a goner in say 1997, the software deprecation tempo is too fast.

> It's all politics instead of "hey, how do I
> get my app to run best?"

An element of fashion has entered the computing scene, which is worse than politics because there is no responsibility feedback loop at all.

> > > Lousy DOS support.
> >
> > Feature not regression.
>
> BTW, DOSEMU claims to work (non-gfx) on NetBSD and "maybe FreeBSD", ever
> tried? Or would that make *BSD less appealing?
I haven't used dosemu in ages. Actually I have run w9x more recently than that.

> > > detract from SP2/SP3 for Vista (which does indeed need it).
> >
> > As far as I heard, Win7 is a dolled up Vista.
>
> 2k3 kernel = Vista pre-SP1 (NT 6.0)
> 2k7 kernel = Vista SP1 (NT 6.0.0001)
> ? = Windows 7 (NT 6.1)
Well, versioning can be manipulated out of marketing concerns. But all there seems to be is some minor makeup, introduction of old bugs (the @$*@($*&( slow USB disk problem that plagued preSP1 Vista too) and some damage control on UAC which they are already partially reverting because it created gigantic security holes.

> Progress doesn't have to kill everything that came before it. We are not
> praying mantises.
Good point there. Progress doesn't actually kill. It just competes for resources. Like that modern humans slowly made the Neanderthaler extinct by more adept competing for resources.

See Dos as a Neanderthaler (pun intended)

> > > Change is good, but
> > > change that breaks compatibility for no good reason (without good
> > > workaround) is bad.
> >
> > First, there can be good reasons that don't have workaround. Nobody is
> > obliged to actually keep compatibility.
>
> Just as nobody is obliged to keep diplomatic relations with foreign
> countries?
Bad analogy. Diplomatic relations only work efficient if there is mutual benefit. Which is exactly the problem. There is not enough incentive for devels to support those targets that users have abandoned in droves.

Post reply
 

Complete thread:

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