[japheth]

Hi,

currently most (or all) borland 32-bit dpmi clients -
which use 32RTM.EXE dont execute in DOSEMU. One reason
for this seems to be that interrupt 67h is zero in
DOSEMU. 32rtm.exe (at least the version coming with
BC4) checks if cpu is in protected mode (with SMSW
instruction) and if yes, if firmly assumes that int 67h
is set and executes this int, causing DOSEMU to terminate.

I wrote a simple tsr which sets this vector. after
executing this app I'm able to run TASM32.EXE V5 (this
is valid only for the current developer version of
DOSEMU!!!!). Other tools like TLINK32.EXE or BCC32.EXE
still dont work, but they no longer terminate DOSEMU.

Of course it would be much better to set this vector in
DOSEMU itself and so to avoid wasting memory with a
silly TSR - thats the request finally :-)

Japheth

[Stas Sergeev]

Logged In: YES
user_id=501371

int 67h is a EMS interrupt, it is NULL only as long as the
ems.sys in not loaded.
I have ems.sys loaded, int 67h is not NULL for me, and
tasm32 still doesn't work.
There might be something wrong here. Please clarify.

[japheth]

Logged In: YES
user_id=982058

this is a very interesting problem.
- as already mentionedi I use tasm32 V5 and 32rtm.exe from BC4
- it works with freedos and msdos 7.1
- I restored msdos.c throwing away my modifications - still
works
- changed dpmi memory from 0x20000 (128 MB) back to 0x5000
MB - still works (in case youre wondering: bcc32.exe
allocates that much of (uncommitted) memory)

But: if I execute FTE.EXE (a DJGPP application), then TASM32
crashes
Some RE shows: at least this version of 32RTM.EXE expects
HIWORD of edx, ebx, esi and edi to be cleared at program
entry. Since DOS doesnt change this, it may depend on the
programs executed earlier.

I wrote a small tool with debug to clear hiwords. So I would
suggest to execute it just before running tasm32. It may help

Japheth

[Stas Sergeev]

Logged In: YES
user_id=501371

I also have tasm32 V5.0 and 32rtm V1.5
Your prog doesn't help in my case.
Note that tasm32 never crashed dosemu for me, neither
does any other 32rtm-based app. It just doesn't work,
just exits immediately.

(in case youre wondering: bcc32.exe
allocates that much of (uncommitted) memory)
In case you are wondering, the amount of an uncommitted
memory is not limited by $_dpmi setting. Actually even
the committed memory that was allocated as uncommited is
not accounted, so you can commit any amount of
memory and effectively bypass the $_dpmi restriction.
So $_dpmi only limits the amount of the committed memory
you can allocate, and nothing more.

[Nobody/Anonymous]

Logged In: NO

I also have tasm32 V5.0 and 32rtm V1.5
Note that tasm32 never crashed dosemu for me, neither
does any other 32rtm-based app. It just doesn't work,
just exits immediately.

Ok, I tested with rtm32 V1.0. This version terminates
dosemu if vector int 67 is NULL

---

Your prog doesn't help in my case.

yes, it only may help for 32rtm.exe v1.0

---

I've got 32rtm.exe V1.5 now and tested it. TASM32 works,
but only with the already mentioned patch of clearing
HIWORD(eax) in post_extender for functions 0x3F and 0x40,
something like:

if (DPMI_CLIENT.is_32)
DPMI_CLIENT.stack_frame.eax =
DPMI_CLIENT.stack_frame.eax & 0xFFFF;

---

In case you are wondering, the amount of an uncommitted
memory is not limited by $_dpmi setting.

Hmm, are you sure? I really doubt it. BCC32 doesnt run with
20 (or 64) MB dpmi memory setting. And it mostly allocates
uncommitted memory. BTW, if you want to test it, you can
use this PE loader I mentioned here and there. Download it
from http://www.japheth.de/download/dpmildxx.zip.
extract it to a directory in your path and execute:

DPMILD32 BCC32 -c xxxx.c

Japheth

[Nobody/Anonymous]

Logged In: NO

I also have tasm32 V5.0 and 32rtm V1.5
Note that tasm32 never crashed dosemu for me, neither
does any other 32rtm-based app. It just doesn't work,
just exits immediately.

Ok, I tested with rtm32 V1.0. This version terminates
dosemu if vector int 67 is NULL

---

Your prog doesn't help in my case.

yes, it only may help for 32rtm.exe v1.0

---

I've got 32rtm.exe V1.5 now and tested it. TASM32 works,
but only with the already mentioned patch of clearing
HIWORD(eax) in post_extender for functions 0x3F and 0x40,
something like:

if (DPMI_CLIENT.is_32)
DPMI_CLIENT.stack_frame.eax =
DPMI_CLIENT.stack_frame.eax & 0xFFFF;

---

In case you are wondering, the amount of an uncommitted
memory is not limited by $_dpmi setting.

Hmm, are you sure? I really doubt it. BCC32 doesnt run with
20 (or 64) MB dpmi memory setting. And it mostly allocates
uncommitted memory. BTW, if you want to test it, you can
use this PE loader I mentioned here and there. Download it
from http://www.japheth.de/download/dpmildxx.zip.
extract it to a directory in your path and execute:

DPMILD32 BCC32 -c xxxx.c

Japheth

[Stas Sergeev]

Logged In: YES
user_id=501371

Hello.

There were many problems with my patch that as a side-effect
made the "alloc linear mem at fixed addr" working, it
appeared to have much more side effects than I expected.
Now with the collective efforts everything seems to be
rectified.

I implemented the 32bit wrappers around DOS read/write
and tasm32 now works indeed - thanks for your bug-hunting!
Perhaps now you can remove the dosemu-specific code from
your extender?

yes, it only may help for 32rtm.exe v1.0
Does the 32rtm 1.0 work with out-of-the-box dosemu now?

Hmm, are you sure? I really doubt it. BCC32 doesnt run
with 20 (or 64) MB dpmi memory setting.
OK, yes, you were right. This was changed as yet another
side-effect of the aforementioned patch.
This is now fixed, only the committed mem is accounted, and
is accounted properly, i.e. when you commit a previously
uncommitted memory, it is also accounted, so committing
can fail if the limit is reached.

[Stas Sergeev]

Logged In: YES
user_id=501371

Lets convert this thread to the "Windows support" discussion.

[Stas Sergeev]

Logged In: YES
user_id=501371

FYI, Bart made the VGA emulator compatible with your
VESA driver for Win3.1 - this all now in CVS.

[japheth]

Logged In: YES
user_id=982058

Thanks for the info. BTW, it is not "my" driver, it is
copyright MS.

Another BTW: It took me quite a while until "make" was
willing to create the x plugin, I had to add manually
"plugin/x" in line PLUGINSUBDIRS= in file Makefile.conf. Is
this normal or what am I doing wrong?

[japheth]

Logged In: YES
user_id=982058

Hello,

I added some features for my hx dos extender and it is now
able to run Quake 2 (Win32) in dosemu. But it seems there is
a bug in FreeDOS, MSDOS has to be used.

the hx binaries required are:

http://www.japheth.de/Download/HXRT.zip
http://www.japheth.de/Download/HXGUI.zip

SB16 sound works with Q2, but network still is todo!

---

Another extension to HX is SDL support. Some SDL apps I
tested successfully in DOS, but none works in dosemu.
I suspect the hx thread implementation not being compatible
with dosemu. Possibly one could extend dosemu's dpmi host a
bit? The one thing to do is, if a client is on the locked
stack and sets the trace flags in the IRET stack frame, this
flag should be copied to the application stack (and cause an
exception 01 then).

[Stas Sergeev]

Logged In: YES
user_id=501371

with dosemu. Possibly one could extend dosemu's dpmi host
A test-case please.

[japheth]

Logged In: YES
user_id=982058

A test-case please.

real-life test cases: many SDL apps (i.e. QEMU,
Blobwars,...) ;-)

or just try the attached one. It's a win32 console app,
creates 2 threads and should display 3 lines in a blue
rectangle. on dosemu, just 1 line (the main thread) is
displayed.

[Stas Sergeev]

Logged In: YES
user_id=501371

I fixed that bug in CVS (and of course Bart uploaded
1.3.3 5 minutes earlier, as usual:)
I also played with your stuff a little, looks promising.
Have you considered stealing the Wine code btw? Their
widgets look somewhat better than yours. :))
There seem to be some bugs though:
- Mouse movements work, but the mouse clicks are ignored
(under dosemu)
- The video mode is not restored on exit - very bad.
- Some problems with LFNs it seems. When it comes to
loading the msys-1.0.dll, it complains that it is not
found, although it is there and according to dosemu
log, it even being opened.

Btw, since you have implemented threading (vwin32-
compatible?), I wonder (again) are there any hopes
that the Win95 kernel will ever run on that stuff?

[japheth]

Logged In: YES
user_id=982058

I fixed that bug in CVS

Thanks! Some SDL apps now work (but QEMU still do not).

Have you considered stealing the Wine code btw? Their
widgets look somewhat better than yours. :))

No. I find they look "honest" :-)
And it's just the Win32 "MessageBox" function which is
implemented.

The video mode is not restored on exit - very bad.

It is, but possibly doesn't work for all cards. There's
an option in hxguihlp.ini to not use the VESA save/restore
functions.

Some problems with LFNs it seems. When it comes to
loading the msys-1.0.dll, it complains that it is not

There is a special version of dpmild32.exe which should
understand LFN, but I haven't tested it in dosemu yet.

Btw, since you have implemented threading (vwin32-
compatible?)

Don't know if it is "vwin32-compatible". It surely is
implemented differently and one cannot use the win95
kernel32.dll.

btw: I want to improve the sound code in the extender so it
accepts a SB Pro, not just a SB 16+. Can dosemu's SB
emulation be changed to just emulate a SB Pro?

[Stas Sergeev]

Logged In: YES
user_id=501371

btw: I want to improve the sound code in the extender so it
accepts a SB Pro, not just a SB 16+. Can dosemu's SB
emulation be changed to just emulate a SB Pro?
What exactly do you want to have changed? SB16 is mostly
backward-compatible with SB-pro, so you probably need to
only change the identification (0xe0, 0xe1, 0xe2) commands,
or what? Setting the SB-pro in games almost always work on
SB16, so I am not sure what exactly you need. There are
more commands and more mixer registers, but if you want
SB-pro, just don't use that additional features, I'd say.

[japheth]

Logged In: YES
user_id=982058

so I am not sure what exactly you need. There are
more commands and more mixer registers, but if you want
SB-pro, just don't use that additional features, I'd say.

Yes, sure. I expressed myself unclear. I was asking if
dosemu has an option to make it emulate a SB Pro only. But
thinking about it again it now seems pretty useless to me
from the dosemu perspective - because, as you told - a SB16
is almost 100% backward compatible.

From a developer' view such an option would be not totally
useless, if he has no SB Pro hardware available and just
wants a platform to test some code. Many SB compatible cards
just emulate a SB Pro.

[Stas Sergeev]

Logged In: YES
user_id=501371

thinking about it again it now seems pretty useless to me
from the dosemu perspective - because, as you told - a
SB16 is almost 100% backward compatible.
Exactly, and thats why my new sound code
http://dosemu.sourceforge.net/stas/
(unfortunately stalled right now) is designed with only
the SB16 in mind.

From a developer' view such an option would be not totally
useless, if he has no SB Pro hardware available and just
wants a platform to test some code.
I still dont see the point. What this option will do?
1. Change the identification commands
2. Restrict an access to some mixer registers
3. Disallow several SB16-specific commands
4. Enable a couple of the (mostly useless, undocumented)
SB-pro-specific commands
5. Change a few obscure corner cases in a behaveour
Which of the above are important enough to add an option?
Which ones will make any problems developing the software
for SB-pro? People have no problems developing on SB16 the
software that is intended to work on SB-pro too.

[Stas Sergeev]

Logged In: YES
user_id=501371

The video mode is not restored on exit - very bad.
It is, but possibly doesn't work for all cards.
There's
an option in hxguihlp.ini to not use the VESA save/restore
functions.
What exactly does it save/restore? dosemu restores both
the registers (using VBE functions) and the video memory,
and there are no problems on the same machines your
program locks up. Yes, it took quite a few efforts to
get the thing working on all machines, but at the end
it wasn't all that difficult.

[japheth]

Logged In: YES
user_id=982058

I still dont see the point. What this option will do?
...
Which of the above are important enough to add an option?

None!

It was just that I recalled that when I implemented the SB16
code I would have liked to have a SB Pro available to
implement and test 8 bit stereo output on that device.

What exactly does it save/restore? dosemu restores both
the registers (using VBE functions) and the video memory,

It saves/restores both the registers (with int 10, ax=4f04,
cx=000f) and video memory.

About sound again: it seems that the sb16 emulation returns
0 for the mixer master volume (index 22h). Is this by design?

[Stas Sergeev]

Logged In: YES
user_id=501371

code I would have liked to have a SB Pro available to
implement and test 8 bit stereo output on that device.
The question is why not to test that on SB16. IIRC
the SB-pro way of setting stereo (via mixer regs) is
supported by sb16, although is not recommended because
of the resulting downsampling.

It saves/restores both the registers (with int 10,
ax=4f04, cx=000f) and video memory.
Same as with dosemu.

About sound again: it seems that the sb16 emulation
returns 0 for the mixer master volume (index 22h). Is
this by design?
Havent touched that code for ages (and it is really a
piece of crap), but I think setting $_sb_mixer="/dev/mixer"
may solve the problem.

Attached is the rar archiever (win32 version) that
gives the exception 0Eh with HX. Any ideas why?

[Stas Sergeev]

rar

[japheth]

Logged In: YES
user_id=982058

Attached is the rar archiever (win32 version) that
gives the exception 0Eh with HX. Any ideas why?

Hm, image size in the PE header is 0x51000, but the last
section starts at offset 0x51000, with another virtual size
0x1000, so the real size of the image is 0x52000. Most
likely this is a bug in the exe-packer, but windows
obviously doesn't complain.

Woraround: patch the image size field in PE header.

[japheth]

Logged In: YES
user_id=982058

I possibly found the reason why many win32 SDL apps still
don't work in dosemu. There is a problem with the emulation
of the RTC timer. As default this timer has a frequency of
1024 and thus allows very short intervals. That's why it is
used by hx to emulate the win32 "CreateWaitableTimer" API.
On dosemu it simply doesn't create any interrupts.

I have attached a very simple test-case, which should
display an increasing number on the upper right corner of
the screen whenever interrupt 70h is called. On dosemu it
remains 0. On hx, win9x dos boxes and even winXP dos
boxes!!! this program works fine.

[japheth]

test case for IRQ 8 emulation

[japheth]

Logged In: YES
user_id=982058

Some of the issues are possibly solved now in hx

• Mouse movements work, but the mouse clicks are ignored
• The video mode is not restored on exit - very bad.

About the RTC timer: I've read somewhere - don't remember
how long this is ago - that linux is unable to supply timer
events at a rate of 1024 Hz, the best to achieve would be
about 100 Hz. Is this info still valid?