I am happy with the first test - HIMEM+EMM386 also works with FDAPM for me.
Thank you! Bye Flo On Mon, 31 Jul 2006 09:00:52 +0200, Michael Devore <[EMAIL PROTECTED]> wrote: > Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files > emmx221.zip, EMM386 version 2.21 memory manager, mostly executable files; > and emms221.zip, source code files. > > This release of EMM386 has a few fixes and changes, mostly directed to > Qemu > and FDAPM users, although those modifications are untested for that > environment. It also fixes a problem with an advanced EMS handle name > set > function, EMS free page reporting when using the deprecated EMM= option, > and internal corrections that may affect a few people. If you are still > having problems with EMM386 2.20, version 2.21 is recommended. HIMEM is > unchanged. > > Once more unto the breach... > > EMS function 53h, subfunction 1, set name, was stuffing garbage in the > system handle name instead. Didn't break anything (the SYSTEM handle > name > is arbitrarily chosen), but it didn't work either. As with the other > advanced handle name functions recently fixed, this would probably affect > just a few EMS 4.0-based programs, but it should work now. > > When using EMM=xxx option, the EMS routines were double-counting the > previously allocated pages due to the tighter EMS/VCPI coupling change > recently made. You could allocate what was reported as remaining, so the > first allocation could pull the full amount of actual EMS pages, but any > allocation following that double-counted, so it would only take half of > what was really available. Anyway, although EMM=xxx is not recommended > for > general users, it should give a good EMS free page report now. > > The is-this-cpu-really-a-386-or-better-or-else-forget-it routine might > actually work now that I've made Arkady's change. Untested. > > A couple of internal VCPI allocator routines weren't always getting the > proper flag setting. Since the default conditions didn't trigger the > error, it usually didn't make a difference, but it under some conditions > (typically low memory or smaller than default-sized blocks, near as I can > tell), it could fail to properly allocate all free memory available and > return an out of memory condition on VCPI memory allocated. If you ran > out > of memory running a DOS-extended program and you don't think should have, > this fix is for you. One of those weird errors, you don't know why it > never come up before and if it ever happened in normal conditions. Me, > I'm > just glad it's gone, even if it never bit anybody. > > I eliminated some debug code that probably wasn't hurting anybody. It > just > wanted to live, but I killed it, because my blood runs thin and cold and > the goddess of mercy has never walked beside me. > > And what all the Qemu and FDAPM people have been waiting for, EMM386 now > keeps original flag values except carry flag (status code) on INT 13h, > INT > 40h, and (I added) VDS processing routines, per Japheth remarks on the > code > earlier. In other words, RETF 2 is dead, long live IRET. Don't know > whether this fixes the problems with Qemu et al, but I'm hopeful. > > Unfortunately, the IRET code changes are completely untested here, other > than to say they don't smoke my computer, and VPC 2004 is still happy. > If > you have had problems with Qemu, FDAPM, or VDS, please give it a try and > let me know what happens. Hey, that goes for everybody else > too. What? You need motivation and positive feedback? Okay, listen > up. Everyone one reading this message is the coolest, smartest, most > handsome, nicest, bestest person to ever walk, roll on, or crawl terra > firma. And because you are the coolest, smartest, most handsome, nicest, > bestest people to ever walk, roll on, or crawl terra firma, you're going > to > give me good feedback. Yes? Yes. Man, you are great. > > If someone knows an easy way to get Qemu and FreeDOS IMG files working > under XP without having to burn/rip ISO's a bunch, flip floppies, or > other > major fooling around, let me know and I'll try it out here. I am > incredibly lazy and need streamlined setups for testing, i.e. updating > the > IMG files with each new change shouldn't take more than a minute or two. > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel -- Florian Xaver Webdesign, Sword (DOS GUI): <http://www.flox.at.tf> oZone - desktop enviroment f. DOS, Win, Linux: <http://www.flox.at.tf> Dr-DOS Wiki: <http://www.drdos.org> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
