Hi Arkady, > device? = c:\temp\emm386.exe ram i=b000-b7ff > smartdrv 8192 64
Microsoft would tell you that you have to try with x=a000-ffff or other "no UMB at all" style options. You should at least avoid shaky things like i=b000-b7fff ram for the test. Smartdrv also has options to force LOW memory usage. You might need the double buffer option for SMARTDRV, and/or the VDS option for our EMM386. Read the manuals for more details. > Forget to mention: your EMM386 outputs help screen to stderr (very > bad) and complains for /? option. This is indeed annoying. I tracked that one down to the prf.c variant used for EMM386 and HIMEM: For some very strange reason, the int 21 output is only used in EXE mode, while the SYS mode (loaded as driver) uses int 10.e style BIOS TTY output. This should NOT be needed, because DOS console int 21 services are already available in config sys. However, there is some evil compiler dependency: Depending on whether you compile with Turbo C or not, either int 21.2 (write char to stdout) or int 21.e (plain wrong) will be used. In other words, put_console() of prf.c of EMM386 fails if you do not compile with Turbo C. Oops. Anyway, suggested solution is: Remove the compile time decision between BIOS TTY and DOS CONSOLE output from prf.c, always use DOS CONSOLE. Your MEM and MFT tests are interesting... First, our EMM386 is pretty fast, but close-handle has bigger overhead (while MS EMM386 has small overhead but consumes more time for bigger handles) and restore page frame is slower. Overall speed is impressive :-). MS has EMS/XMS memory pool sharing. It seems to use the start of the UMB area for own stuff, so actual UMBs start later with MS EMM386, which is also 1k bigger than our EMM386 in low RAM. One actual PROBLEM with free EMM386: Why is our system (backfill) EMS handle "0 pages" in size? For MS, it is just one handle of 384k, which corresponds to the 4000:0-9fff:0 mappable range (which we do not support, our EMM386 can only map inside the EMS 3.x page frame). For free EMM386, there are one or more OTHER handles, which correspond to the UMB areas. As the UMB areas contain no other mappable ranges, it might be useful to HIDE those extra handles (16+144k in your case). Not sure if there should be support for 4000:0-9fff:0 mappable range and/or if there should be a nonzero-sized handle 0, though. ... I take back the "problem", it only seems to be a cosmetical one, unless 0-sized handles are a problem. As apps are not supposed to play with handles which they do not own, the UMB area alias handles are just funny in MEM output but otherwise harmless. Eric ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
