Op 16-3-2012 0:55, Rugxulo schreef: > stuff, esp. not DJGPP/DPMI things, so I would only do "JEMM386 LOAD" > and "UNLOAD" at runtime if needed (rarely).
The ability to dynamically load and unload JEMM386 is a nice benefit indeed. Indeed an XMS/HMA-only environment already provides a pretty decent start. > together, and you can't just load at runtime (if XMS already enabled) > because it only uses its own XMS manager built-in. So while it saves a > few kb of space by combining them, it's slightly less useful if you > don't want EMS or UMBs (and/or have a very rare app that refuses to > run under V86 mode). Also I very vaguely remember some apps in the old > days not working correctly with NOEMS. JEMMEX optionally acting as a 2-stage driver would be nice. Either load it as all-in-one, or starting as an XMS-driver and only allow itself as EMM386 driver, refusing all other UMB/EMS drivers. Then you get: [1]: DEVICE=JEMMEX.EXE NOEMS DOS=HIGH,UMB [2]: DEVICE=JEMMEX.EXE XMS DOS=HIGH [3]: DEVICE=JEMMEX.EXE XMS DEVICE=JEMMEX.EXE NOEMS DOS=HIGH,UMB [4]: DEVICE=JEMMEX.EXE XMS DOS=HIGH @echo off echo Loading EMS driver: jemmex.exe Some XMS managers are also dynamicly loadable, but that has more limited use as it won't enable HMA. Also, (primary) shells typically can't relocate themselves to XMS. ------------------------------------------------------------------------------ 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
