Hi,

On Thu, Mar 15, 2012 at 6:04 PM, Jack <gykazequ...@earthlink.net> wrote:
>
>> Unless you need EMS, you don't truly need JEMMEX itself ...
>
> JEMMEX/JEMM386 also allow VCPI/DPMI to be used,

VCPI, yes, but not DPMI, you don't (necessarily) need EMM386 for that.

> they allow "mapping" of
> upper-memory addresses into UMBs that UMBPCI cannot do (e.g. B000-B7FF)

Yes, if you can use it or "need" it. However, a 32-bit DJGPP app or
pure real mode "conventional memory only" usually doesn't.

> and they can be the "one provider" of upper-memory required by FreeDOS,
> which does NOT add-up the memory found by both UMBPCI and HIMEMX/JEMMEX
> (MS-DOS V6.22 and V7.10 WILL do this).   Many other reasons, I am sure,
> for using JEMMEX/JEMM386.

FASTBOOT and VME are good reasons, but I don't run a lot of EMS-based
software these days, so I don't enable EMM386 by default anymore. If I
need it or want to test under it, I just do "JEMM386 LOAD" (another
cool feature, despite disregarding UMBs). But keep in mind that
"JEMMEX LOAD" [sic] won't work if XMGR is already loaded, so I can't
use that.

>> ... Last I checked, I don't think it would let you run XMS only unless
>> you did "NOEMS", and even that still left you in V86 mode ...
>
> ANY usage of JEMMEX/JEMM386 is GOING to "leave you in V86 mode", since
> by definition THAT is the "protected mode" used by any "EMM" driver to
> protect the system from errant DOS programs!

Not much protection. DPMI is (usually but not always) ring 3, which is
better than ring 0 VCPI. Sure, DJGPP is rock solid (thanks to good
work by CWS), but other stuff isn't so kind, hence EMM386 rarely helps
there (in my limited experience).

> Actual "protected mode"
> is much less restricted, and that is NOT what an "EMM" driver uses nor
> what Intel INTENDED them to use when handling 16-bit DOS applications!

EMM386 only exists for backwards compatibility with EMS-using
software, and it was easier to implement due to the 386's MMU (or
whatever, I don't understand the details). Sure, EMM286 exists in rare
cases, but it's not as good.

> In 16-bit "real mode" i.e. true DOS, you can "play whatever games" you
> like.    In 32-bit "protected mode", you can "play games" only in YOUR
> program areas.   In "V86 mode" as when an "EMM" driver runs an old DOS
> program, you will "TRAP" real QUICK to the "EMM" driver" on almost ALL
> instruction sequences EXCEPT commands "legitimate" for up to an 80386+
> CPU to execute "on its own"!

It depends on a billion factors. Cpus these days are very complex.
(Don't take this the wrong way, I know way less than you do, just
saying, it's a mess.)

>> Nowadays, it does seem most DOS software is either real-mode or 32-bit
>> DPMI, though some XMS creeps in too ...
>
> Use of XMS is irrelevant, 32-bit DPMI is also irrelevant.   WHO CARES,
> since using or not-using an "EMM" driver in fact gives you exactly TWO
> choices for running a DOS system:  16-bit "real mode", or "V86" mode!!

In theory everything is fine, and usually it is, but there are weird
corner cases. I'm not saying EMM386 is bad or unstable, I've used it
(them?) a lot in the past. But the advantages aren't so irreplaceable.

>>> DOS also retains its single-sector directory handling, designed back in
>>> the early 1980s, when memory was EXPENSIVE and buffers were kept
>>> small.
>>
>> Two of the biggest hurdles to using DOS software often seem to be
>> memory management and file system quirks. I know there are other minor
>> things too, but those are the ones that seem to come up a lot. But
>> with DPMI and FAT32, that's fairly moot, thankfully.
>
> How do either DPMI or FAT32 "affect" single-sector directory handling
> by DOS??   Do they "magically" RE-program DOS to handle more than ONE
> directory sector at a time??   I think NOT!!   Until someone DOES so,
> DOS directory handling will still use SLOW "1981 style" single-sector
> I-O, and only a cache like LBAcache or UIDE/UIDE2 will help!

Well, that's basically what I meant. Newer "modern" OSes use fancier
schemes and have more uniform (forced one-size-fits-all) memory
management and file systems. Well, less so on the latter, Linux has
like 45+ file systems (and we don't, sniff). And people always whine
about DOS memory management bugs, quirks, workarounds. Same with FAT,
they hate it (but no one has replaced it yet, esp. not with open
source TSR or device driver). I just meant that in a perfect world
we'd already have ext2 or HPFS support and/or better memory management
across the board, not just lots of tiny bits and pieces and hacks.

In a way, it's a great idea (and one that PatV often mentioned) to
bring DOS into the 21st century, but it basically means rewriting
everything, which is very very unlikely to happen. (Kickstarter,
anyone?) Tons could be improved (and I'd expect compatibility to be a
top goal, too). However, I know I'm dreaming here, it won't happen.

Not a big deal either, I'm (semi-)content with the status quo ... but
the damn hardware keeps changing and breaking things ad nauseum,
thanks to rapid development of other "modern" things, hence UEFI kills
BIOS, GPT eats MBR, AMD64 kills V86, etc. There's only so many losses
you can take before the war is lost.   :-(     I don't want to be
pessimistic, and sure we have DOSBox, DOSEMU, VirtualBox (+ VT/X), but
it does seem more likely that the x86 "IBM PC clone" hardware market
will phase out DOS support totally before we ever get a grasp on even
planning such a rewrite. (I don't know what it is that makes new stuff
claim to be worth 10x more than old, established stuff. Silly
marketing or vanity, I guess.)

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to