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

Reply via email to