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
