>> JEMMEX/JEMM386 also allow VCPI/DPMI to be used, > > VCPI, yes, but not DPMI, you don't (necessarily) need EMM386 for that.
Same for VCPI, I suppose -- There are "subroutine packages" that set up VCPI for a user application, if needed. >> 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. But, there are a LOT of us who do not use DJGPP and yet COULD use a bit more UMB space, to load more/bigger drivers etc. >> 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. Nor do I use JEMM386 in everyday work, as I run a "pure" V6.22 MS-DOS and do not need the extra features. I am only saying that you ought not so-quickly "dismiss" the idea of using an "EMM" driver. They DO have their uses! >> 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). Thus far, I have been absolutely UNABLE to "break into" a V86 system, which I might LIKE to do, so UIDE/UIDE2 are a bit faster from needing NO "Int 15h Ah=87h" XMS move "traps" when V86 is active. The level of protection provided by "V86 mode" sure looks SOLID enough, to me! > 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. I must DISAGREE: EMM386 may have been written for "EMS" memory but it EVOLVED into Microsoft's protected-mode provider and was NEVER merely a "backwards compatibility" EMS handler! >> In 16-bit "real mode" i.e. true DOS, you can "play whatever games" you >> like ... 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 command >> 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.) ONly a FEW factors, since a "protection trap" is a "PROTECTION TRAP!" for any AMD CPU as well as for Intel CPUs! All vendors "watch" this type of compatibility VERY closely, which is why I have NO qualms re: buying an AMD CPU. They are usually less expensive and WORTHWHILE!! >> 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 ... Glad to hear THAT!! > 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. I don't think it is as NECESSARY at you think! Back in 1988, I saw an MS-DOS V3.3 system running EIGHT tasks using an old Quarterdeck type of multi-tasking, and that was on a VERY-old 80386! DOS could still WORK for people (quite-well using drivers like UIDE as Lucho confirmed to me in 2008) if only they USE it properly, and aren't "Sold down the river" by Intel and Microsoft into buying "new" systems! I began my software career in 1966 at The Bank of California in San Francisco, who had only 2 IBM 1460s and one 1401, each with only TAPES (no disks!) and only 16K of memory! Yes, I meant 16,000 7-bit bytes, since memory was TERRIBLY expensive in 1966! Any you know what?? Those "poor old" 16K systems did a LOT more work than my current 1-GB system will EVER do! We need NO more "hardware", CERTAINLY NOT any damned 64-bitters having 64-GB of memory, when in fact Intel/Microsoft never REALLY learned to use 32-bit or even 16-bit systems all that well! Same for DOS -- USE IT a little BETTER, and maybe it CAN do the job, EXACTLY as it is now!! ------------------------------------------------------------------------------ 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
