Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Using Multiple CPU Cores in DOS? (Miscellaneous)

posted by Rugxulo Homepage, Usono, 13.09.2011, 02:27

(CAVEAT: this was not meant to be a long rant, sorry, and I hope it's not too off-topic or unhelpful, that wasn't my goal. Please keep this in mind.)

> > Or you couls maybe requiere loaded DPMI server, if it could help, of
> course.
>
> The problem is, DPMI isn't designed to be used with TSR's, and really
> doesn't help. That's why I'm investigating DPMS and JLM's.
Does DPMIONE has TSR support? (Hmmm, maybe not, I might be thinking of Flashtek X32.) But I guess you don't want to rely on a specific (abandoned?) implementation or two. I agree, of course, just saying ....

> If something like my suggestion is possible, it could increase system speed
> for nearly all applications that need PM (DPMI, EMS, XMS, etc.), not just
> USB or TSR's.
I'm vaguely thinking that some (semi-obscure) computers have supported this for years. Not home PCs, mind you, but others. I'd be very surprised if no one had tried this yet. I'm pretty sure somebody somewhere has a computer than can run two different chips running two different OSes at the same time.

It's an interesting idea, at least, but I suspect most people will say something (dumb? reasonable?) like, "Just use virtualization (VirtualPC, QEMU, VirtualBox, VMware)." Especially with things like AMD SVM (paged real mode) or VT-3x or whatever the hell they call the latest (Westmere? "unrestricted guest execution", real mode, big real mode), nested page tables, etc.

Okay, maybe that wouldn't help your USB for DOS cause specifically, but just in general, I mean, I think people (e.g. MS including Hyper-V in Win8 by default, even for home use) are starting to want people to use virtualization for any legacy concerns. Hence trying to run two OSes on the actual cores without an OS is probably less of a goal for them than running under modern virtualization. (Perhaps you can somehow write a very limited hypervisor and somehow use that to implement faster mode switching, I dunno. That's the only "real" reason, no pun intended, to bring this up, heh.)

> Also in DPMI/PM, most INT calls need to be reflected to real mode. In
> addition, I/O requests should usually be reflected to real mode (though
> they normally aren't by default), in case there is any I/O virtualization
> going on. Even in a "normal" system there may be a lot of mode switching
> going on, far more than I think most people realize.
It's odd that on the one hand, everybody wants ultra speed, but on the other hand they want ultra compatibility. I don't know if you can really have both. At least, the PC market has gotten incredibly fractured trying to chase these two goals (and fast hardware advancements, of course). I'm not complaining, but it does seem like we're suffering from the weight of it all. (And obviously I think throwing everything away and starting from scratch isn't even feasible, fun, or recommended. But no one can agree which part to preserve as everybody's usage is different.)

> Requiring a specific version of DOS (like a 32-bit one), or a specific
> version of EMM, or even requiring an EMM at all, isn't a viable
> alternative, IMO. USB needs to work no matter what, even if it works
> slowly.
As opposed to requiring latest Windows (which most developers do) or latest Linux .DEB or .RPM distro (if even) or latest Mac OS X upgrade? That's the way the world works: find one (obscure) solution, and force it down everyone's throat, esp. for money. It's annoying. I mean, I get it, it simplifies some things, but it's not a universal solution. That's why compatibility is important.

Honestly, it's kinda dopey that we don't have portable drivers or binaries for all these various x86 systems. Am I the only one who thinks it's dumb that x86 OS #1 can't run code from x86 OS #2 despite being written for the same language (e.g. C89)? At least FreeBSD partially got that right by emulating others. Maybe that's why Java is so popular for modern developers (allegedly #1 or #2 most popular programming language by far). But that seems too high-end, difficult, non-standard, and of course high requirements for my tastes. Meh, there is no good solution.

EDIT: Would the Rosetta OS group's framework sound interesting here?

I wonder sometimes if we'd be better off splitting the IBM PC line into "legacy" and "(modern) multimedia" and "server". Well, I guess that's what we did, almost, with Windows (legacy), Mac (multimedia), Linux (server). Unfortunately, Win64 isn't legacy at all anymore (unless you're one of the crazies who thinks 32-bit is deprecated and obsolete [yes, some people think that!]). It seems everybody nowadays wants to support multimedia, which needs tons of RAM, which needs 64-bit, which needs modern drivers, which needs money. And modern gaming needs 3D acceleration, video, sound, etc., basically high-end multimedia, which needs all of the above. And Windows is big in the gaming world. So even if servers and businesses and home users don't want it, they're stuck with the effects of that support and the lack of 16-bit (DOS) backwards compatibility due to 64-bit due to gaming and multimedia.

I guess in theory we should all switch to Linux/DOSEMU (somewhat buggy), eCS (OS/2, too expensive) or work on the FreeDOS kernel more (too difficult). And before you whine, DOS386, :-P I'm just saying, doing everything in pure DOS is infeasible, not the least because of lack of drivers and developers. Dual booting is fine (I'm doing it now), but it's not a perfect solution, nor is virtualization, nor is NTVDM or MDOS or DOSEMU or whatever, nor buying old (prone to failure) hardware.

Post reply
 

Complete thread:

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