On Sun, Jun 19, 2016 at 3:44 AM, Eric Auer <e.a...@jpberlin.de> wrote:
> Hi Rugxulo, some CWSDPMI nitpicking and some memory limits coming ;-)
>> So DR-DOS 7.03 forcibly needed its own (weird, hybrid, bundled VxD or
>> whatever) EMM386, which had its own built-in XMS (so no separate HIMEM
>> needed) plus built-in DPMI (so no CWSDPMI needed).
> CWSDPMI is both a DPMI host and a DOS extender.
No, CWSDPMI is pure DPMI "only", roughly 0.9 with a very few 1.0
extensions. It is not a DOS "extender" at all because it doesn't
support any (non-standard, unofficial) int 21h extensions. So it
doesn't support Watcom apps (e.g. Doom).
> So if you run programs compiled to use it, but are in DR-DOS, you may still
> need CWSDPMI,
OpenDOS 7.01 allegedly had a buggy DPMI server, so you needed to
disable it and use CWSDPMI instead for your DJGPP apps. However, that
was later fixed in 7.02 or such.
With 7.03, you can NOT multitask if you don't enable their own
built-in DPMI host. (I don't think so-called "OpenDOS" ever had a full
release, so it probably didn't even officially have multitasking.)
> but that could rely on DR-EMM386 for the DPMI part of the work.
I think their built-in DPMI did support unofficial int 21h extensions
(same as Windows and a very few others), but it lacked virtual memory.
Sadly, GCC just eats up too much RAM, even in (nowadays considered)
"ancient" versions. So the whole multitasking advantage wasn't as good
as it sounded. Besides, you also probably wanted software cache and/or
RAM drive to speed things up (at least I did), and even those were of
limited use (due to hardcoded memory limits, again).
> The same thing happens when you run such a
> program inside Windows or a DOS window of Windows, which also
> provide DPMI already :-)
Which is why Vista's DPMI bug (memory limits again!) was all the more
painful. You couldn't override it with anything else (at least not
until SP1 via registry). For the company that actually invented DPMI,
they sure dropped the ball there. It's sad that DPMI was considered so
superior to every other scheme but eventually rejected, abandoned,
allowed to bitrot.
>> But it was allegedly limited to 64 MB per task, hardcoded, no matter
>> if you incorrectly tried to switch out the XMSv2 (e.g. trying to use
>> HIMEMX) or not.
> Interesting limitation. EMS, XMS2, XMS3, VCPI, DPMI all have limits,
> but if DR-EMM386 claims to support XMS3, it should support > 64MB...
But it didn't. It probably just faked the version number for
compatibility (dunno why) with unknown apps. Bad idea, I think, but I
don't know the details or why.
> EMS 3.2: Up to 8 MB, one 64 kB page frame with 4 pages of 16 kB
> EMS 4: Up to 32 MB? Maps 4 kB and 16 kB pages in your low 1 MB
> DPMI: Up to 4 GB, in theory, but see the XMS 3 limitations.
> VCPI: Up to 4 GB, in theory, but only up to 4 MB vm86 shared space?
EMS/VCPI were obsoleted by DPMI. Unlike VCPI, DPMI could run on a 286
and didn't always mandate (unsafe) ring 0.
> XMS 2: Up to 64 MB, in some cases limited to only 16 or 32 MB
> XMS 3: Up to 4 GB, in practice even only 2 or roughly 3 GB
Right, I get about 2.5 GB here locally with XMSv3 (HIMEMX). Not sure
about maximum allowed by CWSDPMI, it has some bugs. I don't push it
(or any extender) too hard, I'm not expert enough (or at all!) to do
> Background: VCPI helps you to take over protected mode for yourself
> without breaking too much of the current system state. This is why
> Windows does not allow VCPI software to run.
VCPI was basically an extension of EMS, and it was spearheaded (I
think??) by Desqview dudes.
> Windows itself used a special interface called GEMMIS to take over memory
> management for itself. In other words, it replaced HIMEM and EMM386 on the
> fly to
> have full control in 386 enhanced mode. Which is part of the reason
> why that mode has troubles with FreeDOS and non-commercial EMM386.
EMS and XMS were considered ugly hacks but unavoidable in the old
days. DPMI was considered the future. Too bad nobody kept it updated!
> Windows for Workgroups 3.11 always wants to run in enhanced mode,
> you can only run WfW 3.11 in a limited "safe mode" without that.
At that time you could still boot to pure DOS, but the goal was
(probably) to make that less necessary over time.
> Fun facts: Some games get confused if you have more than 16 or 32 MB
> of RAM reported to them and even Windows 3 has problems above 256 MB,
> although you can edit the config to get it working with at most 1 GB,
> where even the most modest possible swap calculation sign-overflows.
This is part of the reason why DOSBox doesn't support more than 64 MB max RAM.
> Also, DOS software only sees limited amounts of memory when you run it
> inside Windows 3, old 32 bit Windows versions or even in Vista NTVDM.
> Note that this is a per-task limit, so it is not that bad in the end.
I think there should be limits, of course, but it should be
configurable, certainly not hardcoded to 32 MB on literally "all"
machines! For pete's sake, that's 3% of my (then) laptop's RAM, and
no, it was NOT sufficient for most tasks (e.g. DJGPP).
> In theory, you could have XMS drivers or DPMI hosts for DOS which let
> your software use up to 4 GB per task from a total of more than 4 GB?
> I think there is some experimental CWSDPMI which tries to do that...?
No, I don't think he ever published any patches or betas for that. I
certainly never heard of any, but I didn't bug him too hard. I didn't
want to burden him. I get the feeling that he didn't want to waste his
time (which was always low).
Regardless, there are very few people skilled and interested enough to
care, so nobody every complained much. It's unfortunate, but that's
the way it is.
> Hehe... I have Scorpions' "You and I" on some "snuggle rock" sampler:
My local radio affiliate stopped carrying The House of Hair show (for
unknown reasons, after 10+ years), so I have to stream online from
some other station just to hear classic bands like this anymore. And
yes, that's tonight, 10pm! My fav!
>> we're just lucky anything works. Games are not high priority
> I think they are. I mean people still love their retro games,
> while they hopefully use software for multi tasking OS with
> network, multiple cores, GUI and 47 TB of RAM at work now ;-)
Yes, ReactOS NTVDM seems oriented towards games (e.g. Duke Nukem 3D).
I guess games have less direct alternatives than more mundate things
like compilers or archivers.
> I hope that my list of memory size limits above is roughly correct!
> Cheers, Eric
> PS: Cool that you have a 10 in 1 multi-tasker repair shampoo.
What's in it, nanobots? Ten little robots washing each of my hairs
individually? Pardon my skepticism, but I doubt it's really
multitasking. Heck, I'm the (only) one scrubbing my dumb head!
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
Freedos-user mailing list