Hi, On Sat, Jun 9, 2012 at 4:40 AM, JPT <j.p...@gmx.net> wrote: >>> Xtree complains after a minute: >>> device: AUX, Cannot write data. >> >> Dunno, would only make a horrible suggestion to use a different file >> manager, e.g. DJGPP-built Ytree. > > good hint, found FM which has exactly the same problems with JEMMEX as > BP has. Difference is, it does not run in any config. > If no EMS or XMS available I get Runtime error 200, else I get 000E.
Doesn't make sense, but a lot of bugs and conflicts don't. ;-) ftp://ftp.sac.sk/pub/sac/utilprog/r200fix.zip > the only ytree binary i was able to find is for Windows. ;( > > FM second one: > ytree 5.: > http://www.xtreefanpage.org/lowres/x60softw.htm I meant compile from scratch with DJGPP (and yes I actually built this like a week ago): http://www.han.de/~werner/ytree.html >> (Without further knowledge, it's very >> difficult, esp. since I don't have Xtree. But I honestly hate the idea >> of giving up or "don't use it" as worthwhile advice.) > > ;) > any clone would be ok. > XT has got a feature my father uses often, NC and clones dont have it. > and he is used to XT. iBiblio has a few file managers, e.g. at least three DOS Navigator derivatives. You could also try Doszip, but (naively) perhaps Ytree (clone) is more apt? Dunno. And there are dozens of other DOS file managers out there. http://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/ If that doesn't help ... what specific feature does he need / want so badly? >>> BP IDE starts fine, did not try further yet. >>> >>> current JEMMEX config is >>> DEVICE=C:\DOS\BIN\JEMMEX.EXE NOEMS X=TEST NOVME NOINVLPG >> >> Wait, are you running inside a VM? There's almost no other explanation >> for using "NOVME". > > no idea. this is what the freedos installer installed ;) > havent thought about it yet. > removing NOVME did not change anything. Well, no, it probably wouldn't, but I see no reason for disabling it except in rare cases. >> Dunno, no reason it should be using so much or even both XMS plus EMS at >> the same time. Might be some configuration setting (env. var.?) for that >> somewhere. Or it could just be the extender's bug. Try HDPMI16 or >> DPMIONE instead. > > mh, DPMIONE + FM did not work in any memory config. That's somewhat surprising, but I guess nobody's perfect. > HDPMI i did not try yet, since it comes with a huge DOS extender package. I just meant try "hdpmi16 -r", and see what happens. It should be okay (famous last words). You probably? don't need the other stuff. At least, HXRT.ZIP is probably enough. > its hard to remember. its soooo long ago since I dealt with DPMI etc. > so DPMI gets on top of any XMS manager? The DPMI client grabs what it can, either from DPMI host, VCPI, XMS, or raw. Depending on various factors, of course. > If I remember/understand correctly, XMS is provided by: > himem.sys, jemmex, xmgr, emm386 etc. HIMEM.SYS is the typical one, yes, but FreeDOS uses HIMEMX.EXE these days. XMGR.SYS is Jack's alternative. Jemmex is Jemm386 + HimemX bundled together. EMM386 traditionally doesn't have XMS built in (but DR-DOS' one does). >>> why does MEM report EMS when JEMMEX option says NOEMS? >> >> MEM isn't always reliable, > > there is no other solution? Mem isn't accurate in weird cases, things are complicated. I wouldn't worry about that specifically. As has been proven in buggy NTVDM, you don't have to report accurate numbers for things to (mostly) work. > I tried JEMMEX VERBOSE and it reports 8 MB EMS with NOEMS option. > strange. will check if there is a newer version... > http://www.japheth.de/Jemm.html Yes, there's a very slightly newer version, but I seriously don't recommend JEMM386 "NOEMS". It might work, but I ran into several bugs / errors / incompatibilities with a few extenders (DOS/32A, D3X), so I wouldn't totally recommend that setup. Easier to use JEMM386 LOAD sporadically if EMS is needed. >> It's hard for some extenders to work in all circumstances, esp. modern >> machines. Clearly they weren't fully tested, and they make some weird >> assumptions, probably because it mostly worked fine in common cases >> (e.g. legacy Win9x). 16-bit DPMI was always quirky, says CWS, because it >> was always relying on non-standard, undocumented int 21h extensions. > > well, the P3 is a good choice I think. Yes. > has a lot of modern interfaces, but is not that different from the old > hardware as really modern PCs. Right. But even a P3 might have issues (e.g. soundcard). > I do not want to know the problems one > has with UEFI BIOSes. ;) Me either, but I doubt we can hold off forever. http://board.flatassembler.net/topic.php?p=145154#145154 >> XKEYB is deprecated. Try Aitor's latest KEYB 2.01 bugfix instead, if >> possible, it is preferred. > does not work with USBDOS. No idea, just saying that "nobody" (heh) uses XKEYB, and Aitor's KEYB is heavily preferred. Whether that fixes anything or works better for you, dunno, but it's by far the recommended util for i18n keyboard input (also thanks to Henrique). I just threw tom's mKEYB out there just in case its minimalism worked where none others did (worth a shot). ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
