> I'm building a driver (for DOS) that's supposed to have several > functions hooked at an interrupt. When applications call these > functions, the driver should load and unload some tables or > activate/deactivate them somehow. Because these tables are big, I don't > want to keep them in conventional memory with the driver code > altogether, but instead prefer them to by dynamic. > The problem is as follows. If I want to have the tables in files, > then loading them in and unloading them from conventional memory will > cause several problems, which include slowdowns, risk of instability > because of hard-drive access and a big amount of conventional memory > still occupied while the tables are in use. I want, therefore, have the > tables permanently loaded in high, extended or expanded memory while the > driver is running.
I'd disregard EMS (expanded memory), or at least depending on EMS. It's supported when installing an EMM386 (+HIMEM) only, and if the user switched it on. If you still want to use EMS, write your program so that it doesn't need a page frame if running under the correct EMM. > But.... this means that the driver will have to do different things to > get to the tables depending on whether HIMEM, or EMM386, or both, or > none of them are currently there. Your program can't check for EMM386 or HIMEM, it can only check whether XMS or EMS is available. > I am really not very experienced with high memory, but I understand > that, even without HIMEM or EMM386, I can access high memory by setting > up real-flat mode. You're talking about extended memory. High memory is a 64 KiB (- 16 byte) area behind the real mode memory (1 MiB). High memory is available in normal real mode if the A20 line is switched on. HIMEM provides an interface for switching the A20 line. > Also, if HIMEM only is there, this mode is already available and I can > easily access the tables without having to move memory (that is, using > 32bit pointers in real mode instead of calling HIMEM functions to copy > data). Not necessarily. HIMEM isn't restricted to this method, and even if your HIMEM uses it, you'd still have to set up your own "flat real mode". > I need help understanding how these two drivers work, as well as what > happens in real-flat and virtual-86 modes. I'd disregard using "flat real mode" at all. > I also need to know how I can make my interrupt functions flexible > enough so that they can work no matter which HIMEM/EMM386 is currently > working and, if possible, I would like my functions to also be > compatible with protected mode (DPMI) applications calling them, because > the functions have to access memory and return pointers What does your interface look like? Does it return a pointer to the table? Then the table has to stay in the memory addressable in real mode, i.e. 1088 KiB (including the high memory area). Otherwise, not only your driver but any application which calls it would have to switch into the "flat real mode" on itself. With XMS (extended memory), your applications either would have to switch into "flat real mode" or some sort of protected mode (set up by itself, VCPI or DPMI) to access the table directly as well. XMS move requests would allow parts of the table (or the full table) to be read into real mode memory allocated by the application. > and therefore, might not work by using real-mode-interrupt calling > functions of the DPMI. Any memory accessible from real mode is accessible by DPMI applications as well. Just make sure to retrieve the correct segment and pointer registers from the real mode call structure, and to convert the passed real mode segment to a selector correctly. Regards, Christian ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
