Hi! >>>> - Xtree Pro >> >>> Do both run if you do not load any EMM driver at all? >> >> when using XMGR or no EMS/XMS at all they run both.
I vaguely remember Xtree using breakpoint ints and other weird things, alledgedly as anti reverse engineering code? Those might cause problems in combination with "virtual" environments, even "weakly virtual" ones such as JEMMEX, or stronger cases such as a whole virtual PC. I think of things such as "modify opcodes short after IP & check if the CPU 'properly misses' changes in already queued ops". >> Xtree complains after a minute: >> device: AUX, Cannot write data. >> what about the AUX device in Freedos? AUX should be a synonym for your first COM device, in other words the first RS232 serial port... >> Mode doesn't know about it? Call it by the other name then, COM1 probably? ;-) >> 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". Are you sure? What do the jemmex docs say about novme? >> why does MEM report EMS when JEMMEX option says NOEMS? Because NOEMS only means "do not reserve 64 kB of space for the EMS 3.2 page frame". Without a page frame, you have more UMB space, but only EMS 4 compatible software can use EMS, because EMS 4 can use any location to map EMS pages, not limited to a fixed location frame area, although addresses of course still must be page-aligned. It makes a big difference whether you run with JEMMEX, EMM386, JEMM386 or similar or without: In the "with" case, you may have UMB and your DOS runs in a "vm8086" task where some things can be virtualized. Without any such driver, you could only have hardware UMB (with eg UMBPCI driver) but all hard- and software stays "real" which can be good (faster, more realistic) or bad - if any hardware has compatibility issues that would be in a way hidden by JEMMEX et al making things more virtual. Also, if you use any UMB at all (DOS=UMB...) then you are at risk of using areas for UMB purposes that break something else (e.g. BIOS, network / sound / disk DMA buffer, MMIO) in some silly way because that something failed to properly reserve the area in question to keep DOS from using it. Which is why "X=a000-ffff" is useful as an experiment: If you eXclude all normal UMB areas, conflicts are avoided, but you still have JEMMEX active so you can notice whether it was some UMB conflict or JEMMEX itself which caused a problem... Note that USB drivers, both BIOS built-in and Bret's or Georg's loadable-for-DOS styles, can involve some heavy background activities (USB is complex, a complete layer based "network and plug and play" style architecture). They can also involve making things virtual, such as in the way that makes you believe that USB mouse / keyboard devices "feel" like PS/2 for DOS and other software but in fact are not connected to your actual PS/2 ports. >> btw. I still have some problems with XKEYB and other programs while >> JEMMEX is loaded > > XKEYB is deprecated. Try Aitor's latest KEYB 2.01 bugfix instead, if > possible, it is preferred. Or even mKEYB if your needs are minimal. Note that MKEYB is mostly BIOS int 15.4f based (plus a bit of 40:xx and int 16 for certain things) while XKEYB worked much closer to the hardware, which is alledgedly annoying for USB drivers to "fake". I do not know what design KEYB uses, but I would like to remind you in a related issue that EDIT 0.9 has a regression "bug": While EDIT 0.7 behaved nicely "idle" while you were not typing, 0.9 keeps your CPU busy all the time, wasting battery / hogging CPU if you run DOS in a virtual machine on a PC which also does other things / creating heat. Maybe some expert could check what broke in 0.9 that worked in 0.7? Eric ------------------------------------------------------------------------------ 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