Re: SoundBlaster drivers

[Stas Sergeev]

28.01.2019 2:40, Brent Busby пишет:

SoundBlaster drivers bundled with Windows 3.1?

https://www.pcjs.org/disks/pcx86/windows/3.10/
Disk 3 contains
|SNDBLST DR_ 10122 03-10-92 3:10a |
|||SNDBLST2 DR_ 10445 03-10-92 3:10a|
|
||Google has all answers, try things out.
|

Re: SoundBlaster drivers

[Stas Sergeev]

27.01.2019 5:01, Brent Busby пишет:
That explains why MIDI seems to work in bare DOS -- because the 
BLASTER command from DOSEMU is providing everything needed for sound, 
at least for DOS. I thought I needed drivers though because Windows 
3.1 isn't seeing any sound or MIDI on its own though. So the BLASTER 
command should be making an emulated sound card available even to 
Windows? 

Windows has its own set of drivers, which
you can install in windows control panel.
Use the drivers from windows itself, rather
than from the sound blaster drivers disk.
I don't remember if the drivers from disk
work, but the ones that bundled with windows,
certainly do.

Re: SoundBlaster drivers

[Stas Sergeev]

27.01.2019 2:54, Brent Busby пишет:

I'm trying to install SoundBlaster drivers inside the DOSEMU emulation.

No, you don't need to install any drivers,
because the default autoexec.bat of dosemu
is doing all the needed work.
However, installing the drivers should be
possible, and if it hangs, please fill in the
bug report with the copy of drivers and
steps to reproduce.

Re: FW: DOSEMU

[Stas Sergeev]

21.12.2018 16:40, adrian wilkins пишет:
Multiple Windows-based terminals local area networked into a Linux 
file server running Samba.  All the above locking systems work OK. 
Multiple Windows-based terminals running PUTTY into multiple copies of 
DOSEMU on a Linux server. All the above locking systems work OK. A 
mixture of Windows-based terminals running PUTTY into DOSEMU on a 
Linux server AND Windows-based terminals accessing Samba directly.  
Locking fails. My tests reveal that it is DOSEMU that is maintaining 
lock tables rather than passing these through to the Operating System 
(whichever that is). Can you please confirm this? 

No, samba does this:
http://pig.made-it.com/samba-tdb.html
It has quite a lot of database tables with locking info.
dosemu2 passes locks down to OS.


The internet is awash with people complaining about these aspects.

People usually complain about your previous scenario
with multiple dosemu instances w/o samba. But luckily
it works for you correctly. This is the best we can offer.

I would like to contribute to the development of DOSEMU-2 by having 
these defects corrected. The obvious way is to allow the server O/S to 
handle record and file locking, in which case all DOSEMU-2 has to do 
is to pass these through to the O/S rather than handle them itself.

Maybe you can patch samba to stop using TDBs
for locking, but this is very unlikely. Or maybe you
can add a TDB support to dosemu. Unlikely.

Could someone in charge please advise me how to go about this:  which 
sources contain the locking code; how to build a test DOSEMU-2 for my 
own use; and where to go for help ? 

The locking code is in file mfs.c:
https://github.com/stsp/dosemu2/blob/devel/src/dosext/mfs/mfs.c#L2686
The build instructions are here:
https://github.com/stsp/dosemu2/blob/devel/INSTALL
You are welcome to experiment, but don't hold
your breath - a success in that task is very unlikely.
We do not support the mixed environment with samba.
If you are very motivated, full-time developer in this
area, maybe you will come up with some "bridge"
between dosemu2 and samba so that they can share
the locking info with each other - good luck.

Re: dosemu, Putty, ERROR: X

[Stas Sergeev]

19.10.2018 9:28, Alex пишет:
Dear all, I am just starting using dosemu. I have Debian 8 guest 
running in VirtualBox and am connecting to it using Putty on Windows7 
host. While trying to execute "dosemu remdir_c.bat" that calls DOS exe 
file I am getting following error: root@myhost:/home/user2/DOS/H# 
dosemu remdir_c.bat ERROR: X: Can't open display "10.0.2.1:10.0". 

Try
dosemu -t

Re: quick question about dosemu

[Stas Sergeev]

25.09.2018 1:49, David Henderson пишет:
Thanks for the tip Stuart, I'll see if I can touch base with the 
author(s)! 

What's the use of contacting the authors, instead
of trying things out on your own? This is the best
way of getting no help at all, unless you contact the
paid support, like doswin32 has.
And HX authors are especially difficult to contact.
Save other's time, and this will pay back.

Re: quick question about dosemu

[Stas Sergeev]

24.09.2018 23:01, David Henderson пишет:
So I have bad news... I tried both dosemu and wine, but neither will 
run chkdsk. I even tried using another wine binary called wineconsole 
- no go there either. This sucks!!! But at least there is confirmation 
that it will not work. 

Wine is not going to work because I don't think
it supports direct partitions. dosemu is your only
friend I suppose. Try ntfs4dos, there seems to be
some chkdsk included.
Try those 1024+ windows emulators for dos.
HX will probably not work with low-level filesystem
access, but doswin32, 32rtm, wdosx and all the
rest will give you some field for research.
doswin32 seems to be very active and has a
commercial support. So you can pay them money
if the functionality is missing. But you will also pay
them for dosemu support, as currently they only
support dosbox. Anyway, there are lots of things to try.

Re: quick question about dosemu

[Stas Sergeev]

20.09.2018 23:42, David Henderson пишет:
Good afternoon! I am working on a project that I would need to run 
some DOS executables from the Linux command line (e.g. chkdsk.exe). I 
briefly looked at DosBox, but it requires a GUI environment and is 
geared towards games. Does dosemu allow me to run something like 
chkdsk.exe on an NTFS partition from within Linux? 

Is there a chkdsk.exe for DOS that supports NTFS?
Anyway, partition access is supported but not well
tested. Try your things on a partition image in the
file first. If that works fine, then there are chances
that partition will also work.

announce: fdpp, a 64bit DOS in C++

[Stas Sergeev]

Hi all DOS fans!

After a year of development, I am glad to announce
the new 64bit DOS. But as we know, all new is well-forgotten old,
so this actually is a freedos kernel port to 64 bits.
Some of you have probably already heard about
this project, as it was pre-announced on fosdem-18,
but at that time it could barely display the copyright
msg. So I bet no one believed this is even possible. :)
And here we go:
https://github.com/stsp/fdpp

The description of the project and the usage
instructions are in the readme:
https://github.com/stsp/fdpp/blob/master/README.md

The current status is on the releases page:
https://github.com/stsp/fdpp/releases

This is going to be the primary DOS for dosemu2,
but I hope it will be useful for other projects too.
For example the freedos-32 project:
http://freedos-32.sourceforge.net/
can likely get a very good use of it.

I don't know if the main freedos project can be
interested in a 64bit port of it, but I think there
were some talks in the past, including Pat V himself,
which I unfortunately can't google out now. Let's
see what people think.

The next target is going to be a 64bit command.com.
While it is in some distant future, the 32bit command.com
is already here:
https://github.com/stsp/comcom32

So lets move on to 64bits! Happy DOSing. :)

announce: fdpp, a 64bit DOS in C++

[Stas Sergeev]

Hi all DOS fans!

After a year of development, I am glad to announce
the new 64bit DOS. But as we know, all new is well-forgotten old,
so this actually is a freedos kernel port to 64 bits.
Some of you have probably already heard about
this project, as it was pre-announced on fosdem-18,
but at that time it could barely display the copyright
msg. So I bet no one believed this is even possible. :)
And here we go:
https://github.com/stsp/fdpp

The description of the project and the usage
instructions are in the readme:
https://github.com/stsp/fdpp/blob/master/README.md

The current status is on the releases page:
https://github.com/stsp/fdpp/releases

This is going to be the primary DOS for dosemu2,
but I hope it will be useful for other projects too.
For example the freedos-32 project:
http://freedos-32.sourceforge.net/
can likely get a very good use of it.

I don't know if the main freedos project can be
interested in a 64bit port of it, but I think there
were some talks in the past, including Pat V himself,
which I unfortunately can't google out now. Let's
see what people think.

The next target is going to be a 64bit command.com.
While it is in some distant future, the 32bit command.com
is already here:
https://github.com/stsp/comcom32

So lets move on to 64bits! Happy DOSing. :)

Re: Setting up dosemu2 (from binary)

[Stas Sergeev]

26.06.2018 03:18, Richard White пишет:

Hi!

I have just joined github at Andrew Bird's suggestion because I need to run
legacy DOS software on a 64-bit system. I'm a relative newbie, but have been
very happily running dosemu2 for more than 1 year. Installed via deb created
from binaries.  (Thanks so much Andrew for helping me get going!)

I am now setting up new systems. (64-bit debian  8.10 and 9.4 with KDE) and
ran into a minor issue.

I have created the deb file and installed it. Dosemu starts, but complains
about missing freedos. I have experimented with placing freedos  pieces into
~/.dosemu/drive_c and got dosemu to boot, but it still does not find the
freedos support files. Perhaps I need the counterpart (for binaries) of the
INSTALL document, if it exists, or perhaps instructions for installing the
freedos binary? Or ... should I adjust dosemu.conf?

There was a patch yesterday that answers your
question:
https://github.com/stsp/dosemu2/pull/624/commits/bfe393c3ba1527e4a8d109221c8231538230e051
So you have to put freedos to dosemu2 dir
before building deb, or before doing
"sudo make install". It will then embed it into
an installation. Without doing this, you get a
dummy dosemu2.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FOSDEM talk next week

[Stas Sergeev]

28.01.2018 20:47, j...@astro.princeton.edu пишет:


Hi, Bart.

I have been using (and absolutely depending on) dosemu/freedos for
more than 15 years. I use a DOS CADD program called Generic Cadd
for the design of electronics and astronomical instruments, which
I started using probably 30 years ago. I now run 64-bit Fedora
or Ubuntu on all my machines, and run DosEmu on a 32-bit
Ubuntu virtual machine because I need the speed; the emulator
on 64-bit machines is just too slow,

Please re-check this.
Bart have contributed the KVM acceleration
to dosemu2, so this is no longer the way you describe.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

dosemu2 discussions

[Stas Sergeev]

Hello dosemu users & developers.

It looks like dosemu lists are pretty quiet
this days, albeit of a bit spamming from
linux-kernel development.
This is because dosemu1 development
have come to an end (AFAIK), and dosemu2
development/discussing all happens within
the github platform. There is probably no
need in an MLs any more, because the things
can be discussed directly in an issues tracker,
in a pull-requests tickets, in a comments to
patches, etc etc. There are plenty of possibilities
that guthub offers.

So I invite everyone interested in dosemu2
development to visit our github page:
https://github.com/stsp/dosemu2
click the "Watch" button and participate
in the discussions that are happening there.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 07/26] x86/insn-eval: Do not BUG on invalid register type

[Stas Sergeev]

Hi Ricardo, would you mind unsubscribing
linux-msdos@ from all your future mails on
this subject? Otherwise I am afraid there
would be no subscribers left when you are
finally done. :)
I think all non-kernel-dev MLs should be
treated with more care. Eg your initial
questions were certainly on-topic, but the
kernel patch-series (esp in such quantity)
are definitely not.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

04.04.2017 05:05, Ricardo Neri пишет:

On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote:

30.03.2017 08:14, Ricardo Neri пишет:

You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.

But emulation is still needed for SMSW, right?

Likely so.
If you want, I can enable the logging of this command
and see if it is used by some of the DOS programs I have.

It would be great if you could do that, if you don't mind.

OK, scheduled to the week-end.
I'll let you know.

Thanks!

OK, done the testing.
It appears smsw is used in v86 by windows-3.1 and dos4gw
at the very least, and these are the "major" apps. So doing
without a fixup in v86 will not go unnoticed. Unfortunately
this also means that KVM-vm86 should be properly tested.
I have also found a weird program that does SGDT under
v86. This causes "ERROR: SGDT not implemented" under
dosemu, but the prog still works fine as it obviously does
not care about the results. This app can easily be broken
of course, if that makes any sense (likely not).

Thanks for inputs! Then it seems that we will need emulation for sgdt
and smsw.

I wouldn't claim we need an emulation of sgdt. One
or 2 exotic apps do not count much, considering the
overall small usage of dosemu and an easiness of
re-adding them to dosemu itself.
So if it makes any sense to not add it for vm86, then
please leave it omitted. However it seems Andy wants
an overall completeness here, lot let me just say I'll be
fine with either option.


  Perhaps sidt?

If only for overall completeness.
If it makes any sense to, please leave it omitted.


  sldt and str will not need emulation in either
protected mode or virtual-8086 mode. At a later stage I can look into
working in the syscall as Andy proposes.

I will also look into the kvm-v86 path for dosemu2.

It seems we have an agreement :) Do we?

Yes, fine with me.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

30.03.2017 08:14, Ricardo Neri пишет:

You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.

But emulation is still needed for SMSW, right?

Likely so.
If you want, I can enable the logging of this command
and see if it is used by some of the DOS programs I have.

It would be great if you could do that, if you don't mind.

OK, scheduled to the week-end.
I'll let you know.

Thanks!

OK, done the testing.
It appears smsw is used in v86 by windows-3.1 and dos4gw
at the very least, and these are the "major" apps. So doing
without a fixup in v86 will not go unnoticed. Unfortunately
this also means that KVM-vm86 should be properly tested.
I have also found a weird program that does SGDT under
v86. This causes "ERROR: SGDT not implemented" under
dosemu, but the prog still works fine as it obviously does
not care about the results. This app can easily be broken
of course, if that makes any sense (likely not).
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

31.03.2017 17:11, Alexandre Julliard пишет:

In fact it would be nice to be able to make sidt/sgdt/etc. segfault
too. I know a new syscall is a pain,

Maybe arch_prctl() then?
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

30.03.2017 08:14, Ricardo Neri пишет:

But at least dosemu implements it, so probably it is needed.

Right.


Of course if it is used by one of 100 DOS progs, then there
is an option to just add its support to dosemu2 and pretend
the compatibility problems did not exist. :)

Do you mean relaying the GP fault to dosemu instead of trapping it and
emulating it in the kernel?

Yes, that would be optimal if this does not severely break
the current setups. If we can find out that smsw is not in
the real use, we can probably do exactly that.
But other
instructions are not in real use in v86 for sure, so I
wouldn't be adding the explicit test-cases to the kernel
that will make you depend on some particular behaviour
that no one may need.
My objection was that we shouldn't
write tests before we know exactly how we want this to work.

OK, if only SMSW is used then I'll keep the emulation for SMSW only.

In fact, smsw has an interesting property, which is that
no one will ever want to disable its in-kernel emulation
to provide its own.
So while I'll try to estimate its usage, emulating it in kernel
will not be that problematic in either case.
As for protected mode, if wine only needs sgdt/sidt, then
again, no one will want to disable its emulation. Not the
case with sldt, but AFAICS wine doesn't need sldt, and so
we can leave sldt without a fixups. Is my understanding
correct?
In this case, I suppose, we are very well on a way to avoid
the extra syscalls to toggle the emulation features.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

11.03.2017 02:59, Ricardo Neri пишет:

On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote:


Why would you need one?
Or do you really want to allow these instructions
in v86 by the means of emulation? If so - this wasn't
clearly stated in the patch description, neither it was
properly discussed, it seems.

It str and sldt can be emulated in vm86 but as Andy mention, the
behavior sould be the same with and without emulation.

Why would you do that?
I looked up the dosemu2 CPU simulator code that
is used under x86-64. It says this:
---
CODE_FLUSH();
if (REALMODE()) goto illegal_op;
PC += ModRMSim(PC+1, mode) + 1;
error("SLDT not implemented\n");
break;
case 1: /* STR */
/* Store Task Register */
CODE_FLUSH();
if (REALMODE()) goto illegal_op;
PC += ModRMSim(PC+1, mode) + 1;
error("STR not implemented\n");
break;
...
case 0: /* SGDT */
/* Store Global Descriptor Table 
Register */
PC++; PC += ModRM(opc, PC, 
mode|DATA16|MSTORE);

error("SGDT not implemented\n");
break;
case 1: /* SIDT */
/* Store Interrupt Descriptor Table 
Register */
PC++; PC += ModRM(opc, PC, 
mode|DATA16|MSTORE);

error("SIDT not implemented\n");
break;
---

It only implements smsw.
So maybe you can make your code much
simpler and remove the unneeded emulation?
Same is for prot mode. You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

29.03.2017 07:38, Ricardo Neri пишет:

Probably you could also remove
the sldt and str emulation for protected mode, because,
as I understand from this thread, wine does not
need those.

I see. I would lean on keeping the emulation because I already
implemented it :), for completeness, and because it is performed in a
single switch. The bulk of the emulation code deals with operands.

But this is not for free.
As Andy said, you will then need a syscall and
a feature mask to be able to disable this emulation.
And AFAIK you haven't implemented that yet, so
there is something to consider.


You know the wine's
requirements now - they are very small. And
dosemu doesn't need anything at all but smsw.
And even smsw is very rare.

But emulation is still needed for SMSW, right?

Likely so.
If you want, I can enable the logging of this command
and see if it is used by some of the DOS programs I have.

It would be great if you could do that, if you don't mind.

OK, scheduled to the week-end.
I'll let you know.


But at least dosemu implements it, so probably it is needed.

Right.


Of course if it is used by one of 100 DOS progs, then there
is an option to just add its support to dosemu2 and pretend
the compatibility problems did not exist. :)

Do you mean relaying the GP fault to dosemu instead of trapping it and
emulating it in the kernel?

Yes, that would be optimal if this does not severely break
the current setups. If we can find out that smsw is not in
the real use, we can probably do exactly that. But other
instructions are not in real use in v86 for sure, so I
wouldn't be adding the explicit test-cases to the kernel
that will make you depend on some particular behaviour
that no one may need. My objection was that we shouldn't
write tests before we know exactly how we want this to work.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

11.03.2017 02:47, Ricardo Neri пишет:



It doesn't need to be a matter of this particular
patch set, i.e. this proposal should not trigger a
v7 resend of all 21 patches. :) But it would be useful
for the future development of dosemu2.

Would dosemu2 use 32-bit processes in order to keep segmentation? If it
could use 64-bit processes, emulation is not used in this case and the
SIGSEGV is delivered to user space.

It does use the mix: 64bit process but some segments
are 32bit for DOS code.

Do you mean that dosemu2 will start as a 64-bit process and will jump to
32-bit code segments?

Yes, so the offending insns are executed only in 32bit
and 16bit segments, even if the process itself is 64bit.
I guess you handle 16bit segments same as 32bit ones.


  My emulation code should work in this case as it
will use segmentation in 32-bit code descriptors. Is there anything else
needed?

If I understand you correctly, you are saying that SLDT
executed in 64bit code segment, will inevitably segfault
to userspace. If this is the case and it makes your code
simpler, then its perfectly fine with me as dosemu does
not do this and the 64bit DOS progs are not anticipated.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

11.03.2017 00:04, Andy Lutomirski пишет:

On Fri, Mar 10, 2017 at 2:30 AM, Stas Sergeev <s...@list.ru> wrote:

10.03.2017 05:41, Andy Lutomirski пишет:


On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
<ricardo.neri-calde...@linux.intel.com> wrote:

On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:

08.03.2017 19:46, Andy Lutomirski пишет:

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.

I guess that the _UMIP_FIXUP part makes it clear that emulation, not
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
program.

Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
COMPAT_MASK0_X86_UMIP to disable UMIP make sense?

Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
purpose? Applications could simply use this compat mask to bypass UMIP
and gain access to the instructions it protects.


I was obviously extremely unclear.  The point of the proposed syscall
is to let programs opt out of legacy features.

I guess both "compat" and "legacy" are misleading
here. Maybe these are "x86-specific" or "hypervisor-specific",
but a mere enabling of UMIP doesn't immediately make
the use of SLDT instruction a legacy IMHO.

Sure it is. :)  Using SLDT from user mode is a legacy ability that
just happens to still work on existing CPUs and kernels.  Once UMIP
goes in, it will officially be obsolete

Yes, but the names you suggest, imply that "UMIP_FIXUP"
is legacy or compat, which I find misleading because it have
just appeared. Maybe something like "COMPAT_X86_UMIP_INSNS_EMU"?
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

10.03.2017 05:41, Andy Lutomirski пишет:

On Wed, Mar 8, 2017 at 5:11 PM, Ricardo Neri
<ricardo.neri-calde...@linux.intel.com> wrote:

On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:

08.03.2017 19:46, Andy Lutomirski пишет:

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.

I guess that the _UMIP_FIXUP part makes it clear that emulation, not
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
program.

Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
COMPAT_MASK0_X86_UMIP to disable UMIP make sense?

Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
purpose? Applications could simply use this compat mask to bypass UMIP
and gain access to the instructions it protects.


I was obviously extremely unclear.  The point of the proposed syscall
is to let programs opt out of legacy features.

I guess both "compat" and "legacy" are misleading
here. Maybe these are "x86-specific" or "hypervisor-specific",
but a mere enabling of UMIP doesn't immediately make
the use of SLDT instruction a legacy IMHO.


  I'll ponder this a bit more.

So if we are to invent something new, it would be nice to
also think up a clear terminology for it. Maybe something
like "X86_FEATURE_xxx_MASK" or alike.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

10.03.2017 05:39, Andy Lutomirski пишет:

On Thu, Mar 9, 2017 at 2:10 PM, Stas Sergeev <s...@list.ru> wrote:

09.03.2017 04:15, Ricardo Neri пишет:


On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:

On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <s...@list.ru> wrote:

08.03.2017 19:06, Andy Lutomirski пишет:

On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <s...@list.ru> wrote:

08.03.2017 03:32, Ricardo Neri пишет:

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

This patchset initially treated tasks running in virtual-8086

mode as a

special case. However, I received clarification that DOSEMU[8]

does not

support applications that use these instructions.

Can you remind me what was special about it?  It looks like you

still

emulate them in v8086 mode.

Indeed, sorry, I meant prot mode here. :)
So I wonder what was cited to be special about v86.

Initially my patches disabled UMIP on virtual-8086 instructions, without
regards of protected mode (i.e., UMIP was always enabled). I didn't have
emulation at the time. Then, I added emulation code that now covers
protected and virtual-8086 modes. I guess it is not special anymore.

But isn't SLDT just throw UD in v86?
How does UMIP affect this? How does your patch affect
this?

Er, right.  Ricardo, your code may need fixing.  But don't you have a
test case for this?

Why would you need one?
Or do you really want to allow these instructions
in v86 by the means of emulation? If so - this wasn't
clearly stated in the patch description, neither it was
properly discussed, it seems.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

09.03.2017 03:46, Ricardo Neri пишет:

On Wed, 2017-03-08 at 17:08 +0300, Stas Sergeev wrote:

08.03.2017 03:32, Ricardo Neri пишет:

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

This patchset initially treated tasks running in virtual-8086 mode as a
special case. However, I received clarification that DOSEMU[8] does not
support applications that use these instructions.

Yes, this is the case.
But at least in the past there was an attempt to
support SLDT as it is used by an ancient pharlap
DOS extender (currently unsupported by dosemu1/2).
So how difficult would it be to add an optional
possibility of delivering such SIGSEGV to userspace
so that the kernel's dummy emulation can be overridden?

I suppose a umip=noemulation kernel parameter could be added in this
case.

Why?
It doesn't need to be global: the app should be
able to change that on its own. Note that no app currently
requires this, so its just for the future, and in the
future the app can start using the new API for this,
if you provide one.



It doesn't need to be a matter of this particular
patch set, i.e. this proposal should not trigger a
v7 resend of all 21 patches. :) But it would be useful
for the future development of dosemu2.

Would dosemu2 use 32-bit processes in order to keep segmentation? If it
could use 64-bit processes, emulation is not used in this case and the
SIGSEGV is delivered to user space.

It does use the mix: 64bit process but some segments
are 32bit for DOS code.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

09.03.2017 04:15, Ricardo Neri пишет:

On Wed, 2017-03-08 at 08:46 -0800, Andy Lutomirski wrote:

On Wed, Mar 8, 2017 at 8:29 AM, Stas Sergeev <s...@list.ru> wrote:

08.03.2017 19:06, Andy Lutomirski пишет:

On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <s...@list.ru> wrote:

08.03.2017 03:32, Ricardo Neri пишет:

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

This patchset initially treated tasks running in virtual-8086

mode as a

special case. However, I received clarification that DOSEMU[8]

does not

support applications that use these instructions.

Can you remind me what was special about it?  It looks like you

still

emulate them in v8086 mode.

Indeed, sorry, I meant prot mode here. :)
So I wonder what was cited to be special about v86.

Initially my patches disabled UMIP on virtual-8086 instructions, without
regards of protected mode (i.e., UMIP was always enabled). I didn't have
emulation at the time. Then, I added emulation code that now covers
protected and virtual-8086 modes. I guess it is not special anymore.

But isn't SLDT just throw UD in v86?
How does UMIP affect this? How does your patch affect
this?
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

09.03.2017 04:11, Ricardo Neri пишет:

On Wed, 2017-03-08 at 19:53 +0300, Stas Sergeev wrote:

08.03.2017 19:46, Andy Lutomirski пишет:

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.

I guess that the _UMIP_FIXUP part makes it clear that emulation, not
UMIP is disabled, allowing the SIGSEGV be delivered to the user space
program.

Would having a COMPAT_MASK0_X86_UMIP_FIXUP to disable emulation and a
COMPAT_MASK0_X86_UMIP to disable UMIP make sense?

Also, wouldn't having a COMPAT_MASK0_X86_UMIP to disable UMIP defeat its
purpose? Applications could simply use this compat mask to bypass UMIP
and gain access to the instructions it protects.

I don't think someone will want to completely disable
UMIP, so why do you need such functionality?
My question was only what does "compat" mean
in "COMPAT_MASK0_X86_UMIP_FIXUP", compat with what.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

08.03.2017 19:06, Andy Lutomirski пишет:

On Wed, Mar 8, 2017 at 6:08 AM, Stas Sergeev <s...@list.ru> wrote:

08.03.2017 03:32, Ricardo Neri пишет:

These are the instructions covered by UMIP:
* SGDT - Store Global Descriptor Table
* SIDT - Store Interrupt Descriptor Table
* SLDT - Store Local Descriptor Table
* SMSW - Store Machine Status Word
* STR - Store Task Register

This patchset initially treated tasks running in virtual-8086 mode as a
special case. However, I received clarification that DOSEMU[8] does not
support applications that use these instructions.

Can you remind me what was special about it?  It looks like you still
emulate them in v8086 mode.

Indeed, sorry, I meant prot mode here. :)
So I wonder what was cited to be special about v86.


Yes, this is the case.
But at least in the past there was an attempt to
support SLDT as it is used by an ancient pharlap
DOS extender (currently unsupported by dosemu1/2).
So how difficult would it be to add an optional
possibility of delivering such SIGSEGV to userspace
so that the kernel's dummy emulation can be overridden?
It doesn't need to be a matter of this particular
patch set, i.e. this proposal should not trigger a
v7 resend of all 21 patches. :) But it would be useful
for the future development of dosemu2.

What I'd actually like to see is a totally separate patchset that adds
an inheritable (but reset on exec) per-task mask of legacy
compatibility features to disable.  Maybe:

sys_adjust_compat_mask(int op, int word, u32 mask);

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

[Stas Sergeev]

08.03.2017 19:46, Andy Lutomirski пишет:

No no, since I meant prot mode, this is not what I need.
I would never need to disable UMIP as to allow the
prot mode apps to do SLDT. Instead it would be good
to have an ability to provide a replacement for the dummy
emulation that is currently being proposed for kernel.
All is needed for this, is just to deliver a SIGSEGV.

That's what I meant.  Turning off FIXUP_UMIP would leave UMIP on but
turn off the fixup, so you'd get a SIGSEGV indicating #GP (or a vm86
GP exit).

But then I am confused with the word "compat" in
your "COMPAT_MASK0_X86_UMIP_FIXUP" and
"sys_adjust_compat_mask(int op, int word, u32 mask);"

Leaving UMIP on and only disabling a fixup doesn't
sound like a compat option to me. I would expect
compat to disable it completely.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: lag while printing and serial redirect

[Stas Sergeev]

25.12.2016 17:03, Jakub Klawiter пишет:

Hello!

2016-12-21 22:22 GMT+01:00 Stas Sergeev <s...@list.ru>:


1. My DOS program needs decimal point instead of decimal coma on
keypad. It should be easy to remap it, as it is used in wild countries
;-)
2. I also need there ctrl+enter to work „DOS way”. And I really have
no idea what code sends ctrl+enter in DOS, what I know that it is not
working when started under dosemu -dt

You mean -t.

I've been using -dt but ok … it looks the same so probably -d (in my
dosemu) does nothing ;-)

I never told  you to use -d. I told either -t or -td, but
not -d or -dt.


Anyway i'll probably try to fight with it after new year.

Key combos may be a problem, yes.
You can run "cat" and see what your key combos produce.
For example "Enter" and "Ctrl-Enter" produce the same newline,
which means making it to work the dos way is not trivial.

Yes in linux terminal both produces \x0a

anyway same dos exe i'm using is working fine with dosemu started with
-X so maybe it is possible.

Its certainly possible with -X, the problem exists only
with -t. So after you outlined it, I withdrawn my suggestion
about -t. -t is good to just run a bat file, which I thought
your use-case is. For interactive stuff it doesn't work well.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: lag while printing and serial redirect

[Stas Sergeev]

20.12.2016 23:37, Jakub Klawiter пишет:

Hello!

2016-12-20 1:19 GMT+01:00 Stas Sergeev <s...@list.ru>:

it's even better (larger) only problem that colors are little bit flat
this way... too flat :(
https://goo.gl/photos/WLLRvbkVGCkg9tyA6 (in front -X, back -dt) Is it
possible to change palette somewhere as it doesn't depend on my
terminal palette.

Ok i fount it in other place in my terminal. everything is great right
now. Thank you all for all your help!

Maybe you've found the palette config, but to make
the output independent of any config, one needs to add
the truecolor support (which is very new in slang library).

It's good enough for me ;-)

Anyway i've temporary switched back to -X because of kbd problems.

1. My DOS program needs decimal point instead of decimal coma on
keypad. It should be easy to remap it, as it is used in wild countries
;-)
2. I also need there ctrl+enter to work „DOS way”. And I really have
no idea what code sends ctrl+enter in DOS, what I know that it is not
working when started under dosemu -dt

You mean -t.


Anyway i'll probably try to fight with it after new year.

Key combos may be a problem, yes.
You can run "cat" and see what your key combos produce.
For example "Enter" and "Ctrl-Enter" produce the same newline,
which means making it to work the dos way is not trivial.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: lag while printing and serial redirect

[Stas Sergeev]

19.12.2016 16:53, Jakub Klawiter пишет:

Hello!

2016-12-19 14:34 GMT+01:00 Jakub Klawiter :


it's even better (larger) only problem that colors are little bit flat
this way... too flat :(
https://goo.gl/photos/WLLRvbkVGCkg9tyA6 (in front -X, back -dt) Is it
possible to change palette somewhere as it doesn't depend on my
terminal palette.

Ok i fount it in other place in my terminal. everything is great right
now. Thank you all for all your help!

Maybe you've found the palette config, but to make
the output independent of any config, one needs to add
the truecolor support (which is very new in slang library).
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: lag while printing and serial redirect

[Stas Sergeev]

19.12.2016 16:34, Jakub Klawiter пишет:

Hello!

2016-12-15 23:18 GMT+01:00 Stas Sergeev <s...@list.ru>:



There is absolutely nothing wrong about it except that it is
just usually not needed for text-mode non-interactive stuff,
and the advantage of not using it is that you'll have all the
text still on your terminal after dosemu closes. The output
of your .bat can be redirected to the file with simple bash
redirection etc - this is just a better integration with your
linux environment, but nothing very important.

leaving any output in terminal is not important here because my batch
file ends with exitemu ;-)

If you use '-dumb' or '-td' (depending on version), then the
DOS output will stay on your terminal even after exitemu.
Unfortunately is seems dumb is not an option for you as you
are using colors and ascii drawing.


Anyway it is possible to use it without -X and change font/wndow to
large one. My current .desktop file looks like:

Terminal=false
Icon[pl]=gnome-panel-launcher
Exec=gnome-terminal --profile TEST --hide-menubar --command
"/home/cartoon/skrypty/run-kantor-kasa.sh"

it's even better (larger) only problem that colors are little bit flat
this way... too flat :(
https://goo.gl/photos/WLLRvbkVGCkg9tyA6 (in front -X, back -dt) Is it
possible to change palette somewhere as it doesn't depend on my
terminal palette.

This is a work in progress:
http://lists.jedsoft.org/lists/slang-users/2015/020.html
They added such support into slang and mc, but its very new.
For example I have fedora-24 and it doesn't yet contain these
features.
You can fill the ticket in dosemu tracker and maybe someone
will find the time to look into this sometime in the future.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: lag while printing and serial redirect

[Stas Sergeev]

16.12.2016 01:10, Jakub Klawiter пишет:

It's not "just a bat". I mean it is starting executable programm which
need terminal to be 80x24.
the batch file is now rather simple (just cd to working directory, and
exe with it's parameters) but i'll leave it like this because... i did
it this way under DOS 6.22 than  windows 95 in other shop under
FreeDos-0.9, than 1.0 (yes i had at work real 386DX in XXI century :D)

I like to have it as large as possible, with -X i can set $_X_font =
"vga12x30" it's working.

Of course I can change font in my terminal, and set it to start 80x24
by default but... i don't want large fonts in every terminal I start.

You probably want some command that can enlarge and reduce
the font size on fly, that can work on various terminal emulators.
There seems to be no such command, even though google shows
there is a demand for it.

I can have few profiles in gnome-terminal but did not find any way to
change profile from desktop file i'm starting all that stuff. BTW
what's wrong with -X. Why should I try to not use it? Anyway of course

There is absolutely nothing wrong about it except that it is
just usually not needed for text-mode non-interactive stuff,
and the advantage of not using it is that you'll have all the
text still on your terminal after dosemu closes. The output
of your .bat can be redirected to the file with simple bash
redirection etc - this is just a better integration with your
linux environment, but nothing very important.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: lag while printing and serial redirect

[Stas Sergeev]

15.12.2016 19:18, Jakub Klawiter пишет:

Hello!


2016-12-14 21:00 GMT+01:00 Stas Sergeev <s...@list.ru>:

14.12.2016 17:32, Jakub Klawiter пишет:

Hmm… i was sure that timeout is about something else rather about
existance / being ready to print…

Perhaps it would be better to call something like "$_printout_delay",
but its probably too late to rename.

it is also not delay, i've changed it from 10 to 5, and the lag is
smaler but not by half.

This is a delay since the print data xfer ended, not started.
So the total_time_before_printout_starts=data_xfer_time+printout_delay.
If data_xfer_time is large enough, then reducing printout_delay
twice will result in some srink of total time but not twice.
Maybe you can reduce also the data_xfer_time, try
speed 0
in the beginning of your printing bat file.


dosemu -X -f "/home/cartoon/skrypty/dosemu-raporty.conf"  -E r.bat

Are you sure you need '-X' for running just the bat file?
Try -dumb or -td or -t depending on dosemu version.

I have dosemu-1.4.0.7 or 1.4.0.8 ... no idea why but ubuntu repo says
it's 1.4.0.7 and dosemu that it's 1.4.0.8 :> Anyway it's 1.4 :D

This is the last "stable" version, but its very very old unfortunately.


It's not "just a bat". I mean it is starting executable programm which
need terminal to be 80x24.
the batch file is now rather simple (just cd to working directory, and
exe with it's parameters) but i'll leave it like this because... i did
it this way under DOS 6.22 than  windows 95 in other shop under
FreeDos-0.9, than 1.0 (yes i had at work real 386DX in XXI century :D)

I like to have it as large as possible, with -X i can set $_X_font =
"vga12x30" it's working.

Of course I can change font in my terminal, and set it to start 80x24
by default but... i don't want large fonts in every terminal I start.

You probably want some command that can enlarge and reduce
the font size on fly, that can work on various terminal emulators.
There seems to be no such command, even though google shows
there is a demand for it.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: lag while printing and serial redirect

[Stas Sergeev]

13.12.2016 16:26, Jakub Klawiter пишет:

Hello!

i've got dosemu installed on ubuntu box. I've OKI dot matrix printer
connected to it via USB2parallel interface.

Now if i'll try e.g.

$ echo test | lpr -l
the printer starts to print immediately.

But from dosemu if i'll try:

C:>echo test > lpt1:

it's working but there is 3-4 seconds lag before it starts to print.
Where can i look to fix it?

my dosemu.conf part:

$_lpt1 = "lpr -l"
$_printer_timeout = (10)

So why dont you reduce the timeout then?


The second thing:

i like to have COM1 (serial) port transmission redirected to reglar
file. I tried something like:

$_com1 = "/tmp/com1.txt"

but it's not working. Is it possible to catch serial transmission to a file?

Yes, but not as simple. You need to establish the pty link
with 'socat' program. But this feature is quite simple to add.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DOSEmu2 question

[Stas Sergeev]

01.12.2016 08:21, Patrick McMunn пишет:
I didn't think my question was suitable for opening a bug and maybe 
not for the mailing list, so I just wanted to ask directly. Will 
DOSEmu2 be able to run on FreeBSD, or does it rely on Linux-only 
features that would prevent it from working on a BSD system?


Hi, lets actually add the ML to CC as the question
may be interesting for someone else.
dosemu2 has quite a few backends for CPU emulation.
Simulator, jit, kvm, vm86.
For example simulator should be easily portable.
So I think the basic v86 functionality should be
easily portable to FreeBSD. DPMI currently uses quite
a few linux kernel extensions, so this may be more
problematic. SDL frontend is very portable too.
Overall I think it is just a matter of demand: I haven't
heard a lot of demand about BSD ports. I suppose
dosbox already dominates the bsd market. Have you
tried dosbox for your needs?
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Stas Sergeev]

11.11.2016 07:14, Ricardo Neri пишет:

10.11.2016 09:46, Ricardo Neri пишет:

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1].

Indeed.
The code you've found, was copied from wine, because
dosemu supports windows-3.1. But sgdt is in win32s part
that is disabled in dosemu. It is however enabled in wine, or
at least it was when I ported the VxD code from there. So you
may want to ask wine devs if they still use sgdt and vm86.
In dosemu, if we ever enable win32s support, we won't rely
on sgdt. In fact, when some prot mode program under dosemu
uses GDT selectors, in a fault handler we replace them with
LDT selectors.

Actually, the SLDT instruction is also impacted by this feature. This

We do not support programs that do SLDT.
The "polite" programs use special DPMI API extension to get
the selector that covers LDT. That allows us to manage an "ldt
alias" - memory buffer where we emulate LDT by write-protecting it.
If we ever support SLDT, we would very much like to trap it
and provide the pointer to our alias. Some very old dos extenders
for 286 may start to work with such change, that are currently
unsupported.


feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
SMSW or STR are executed with CPL > 0. Would this be a problem for
dosemu?

I am only a bit unsure about SMSW; the rest should be safe.
Maybe some odd prog would use SMSW to check for FPU?
Or to check for v86 mode by checking the PE bit?
I am sure this is very uncommon, and if we find such prog, we
can add an emulation of that instruction. I am pretty sure no one
would get sufficiently hurt, but there will likely be 1-2 bug reports
in our tracker, because if something is possible, then some DOS
prog did that. :)


  The proposal now is to trap this GPU fault and give fake value
for these tables.

If this fake value will be cooked up by the kernel without delivering
the signal to dosemu process, then I don't see any problem at all.
Of course you can provide the sane value for smsw.
If that will go up to dosemu, then some coding may be needed
on the user-space side.


This is good news. This means that we could go ahead and give a fake
pointer to the GDT and the other impacted tables?

Definitely.
What these fake tables will look like, btw?
Will they somehow resemble the real ones?
Visible to user-space?
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Stas Sergeev]

Hi!

I don't know the context of that discussion, so I'll only
comment on the dosemu part.

10.11.2016 09:46, Ricardo Neri пишет:

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1].

Indeed.
The code you've found, was copied from wine, because
dosemu supports windows-3.1. But sgdt is in win32s part
that is disabled in dosemu. It is however enabled in wine, or
at least it was when I ported the VxD code from there. So you
may want to ask wine devs if they still use sgdt and vm86.
In dosemu, if we ever enable win32s support, we won't rely
on sgdt. In fact, when some prot mode program under dosemu
uses GDT selectors, in a fault handler we replace them with
LDT selectors.


  dosemu includes an i386
emulator that in some cases uses the actual instructions of the host
system.

In dosemu2 code, the places you've found, now contain this:
error("SGDT not implemented\n");
If we ever support SGDT, we'll use some emulation/fake values.

So overall, dosemu is not going to willingly use sgdt in any
near future. But the programs running under vm86 or in prot mode
may do so. This is very uncommon though, especially under dosemu,
because it supports only a "polite" programs - those that work
under win95's dos prompt. No one would get sufficiently hurt if
sgdt under vm86 will somehow change from its current behaviour.

You can ask wine people for their sgdt use in win32s subsystem.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Emulated PCI devices?

[Stas Sergeev]

22.10.2016 16:34, Mouse пишет:

Its just that usually when you have some expensive HW, emulating it
in software is not enough because the HW is usually doing something
useful, not just makes some program to work. :)  If you don't need
any functionality of that HW other than to make some DOS prog happy,

Sort of.  It's a (relatively-)high-speed input device, and we plan to
replace it with either a pre-canned data file or a network connection
as a data source.  But, even once the host machine has the data, we
have to get it into the program somehow.  I could replace all the
relevant hardware accesses with traps to the emulator, but I could also
simulate the hardware it's expecting.

I wonder if there is a big difference.
Any hardware access you don't have ioperm permissions to,
makes it into an emulator trap. So I very much suspect you are
talking differently about the same thing. If you patch every
in/out insn of your prog into hlt, nothing will really change other
than it will be more difficult to simulate.


then I am afraid dosemu is not prepared for that, and you'll need to
implement the PCI emulator (in which case you can try qemu).

OK, I'll talk with the other people invovled and we'll decide what tack
to take: hack on the program, add PCI emulation to dosemu, switch
emulators, whatever.

Since dosemu is really a virtual machine (not like ntvdm or wine,
for example dosemu can run real windows31), and so is qemu,
you can get most of everything you had with dosemu, with qemu
too. Its just that dosemu sets up many things for you automatically,
which makes people think of it as of wine or ntvdm, but its not.
With qemu you'll have to do a lot of manual setup to get the
host FS access for example, but at the end you can get the
same results.
OTOH adding the PCI emulator to dosemu is not exceptionally
difficult, provided that it already has the PCI bios and emulation
of the config space ports. Its not like implementing everything
from scratches because you likely only need to emulate the
device config space. I suppose the device emulation itself will
take much more time anyway, esp if it uses DMA.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Emulated PCI devices?

[Stas Sergeev]

19.10.2016 03:03, Mouse пишет:

I'm working with dosemu and would like to add an emulated PCI device
to the emulated DOS machine.  [...]
Is this something that's already got hooks supporting it, or am I
breaking new ground here?

There was never any need to emulate the PCI device for DOS.  There
are hardly too many DOS drivers for the PCI devices.

In general, perhaps not. :-)


Maybe you can instead emulate the ISA version of that device,

As far as I know, no ISA version has ever existed - and, indeed, the
particular device in question has just recently been EOLed by its
maker.


Or maybe you simply want to use qemu

It may come to that; I'm working with dosemu because that was the first
DOS emulator we tried that we could make the software run in.  And, in
some respects, I prefer the way dosemu emulates DOS in much the same
sense that wine emulates Windows, instead of emulating hardware proper

dosemu does emulate the HW and uses freedos (or any other
dos you ask it to boot).
You can look into dosbox that "emulates" dos.


and not caring what software is running on it.


because I can't think of the real use-cases where you want to emulate
some modern device under dosemu or dosbox.

Well, I daresay they are not common, but I've got one. :-)

I can't go into too much detail (NDAs and such), but it involves a
legacy application, running under DOS, which depends on a particular
(relatively rare and expensive) piece of hardware.

If you want the DOS driver to communicate to that hardware,
then dosemu is fully prepared to that, because no emulation is
needed then. If you want to emulate the "very expensive hw"
without actually using the real hw, then I wonder what's the point.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Emulated PCI devices?

[Stas Sergeev]

19.10.2016 00:45, Mouse пишет:

I'm working with dosemu and would like to add an emulated PCI device to
the emulated DOS machine.  Obviously, I know enough about the hardware
I want to emulate to believe I can write an emulation of it.

But I'm not sure where to hook it in.  (I'm working based on commit
18f6f5cdf1beceae8c7532718bfaf423e4a44f6a.)

Good luck.


   I found
src/base/async/pci_bios.c and src/base/dev/misc/pci.c, but they appear
to be all about giving the emulated machine access to real PCI hardware
on the real machine.  That's not what I want; I'm trying to supply the
emulated machine with hardware that is not actually present.

There is src/env/video/matrox.c, which appears to be monkeying with PCI
stuff, but even that checks the real machine's /proc/pci and doesn't
run unless there's real hardware backing it (see matroxProbe(), which
incidentally is incorrectly commented as being MGAProbe).

Is this something that's already got hooks supporting it, or am I
breaking new ground here?

There was never any need to emulate the PCI device
for DOS. There are hardly too many DOS drivers for the
PCI devices. Maybe you can instead emulate the ISA version
of that device, which should be much simpler than adding
the PCI bus emulator. Or maybe you simply want to use qemu
because I can't think of the real use-cases where you want
to emulate some modern device under dosemu or dosbox.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dosemu print serial problem

[Stas Sergeev]

07.10.2016 18:44, Winfried Münch пишет:

Hi,

I try to run a DOS program whith lpt Lizens Dongle and 3 Printers on
dosemu 1.4.0.8 on Debian.

Most works great since I changed from Ubuntu 16.05 to Debian 8. Perhaps
the older Linux Kernel.

All Printer are managed by cups and lpr -l -P printername works on Linux.

Problem is When I use direct port access to lpt1 the Dongle works great
but I can't print to a lpr printer. I work 2 Days for LPT4 Working , patch
the dosemu sources, but the drdos i found don't support lpt4. So no lpt4
on dosemu.

One of the Printers is on COM1. So I tryed to print direkt on this Printer
but I get somthing like this on debug:
SER1: INT14 0x3: Port Status, AH=0x0 AL=0xb0
SER1: INT14 0x1: Write char 0x6f
SER1: Transmit 0x6f
SER1: ERROR: TX overrun
SER1: Read LSR = 0x0
SER1: Read MSR = 0xb0
SER1: Read LSR = 0x0
SER1: Read MSR = 0xb0
SER1: INT14 0x3: Port Status, AH=0x0 AL=0xb0
SER1: INT14 0x1: Write char 0x6d
SER1: Transmit 0x6d
SER1: ERROR: TX overrun
SER1: Func transmit_engine requesting TX_INTR
SER1: Interrupt 11 (2) cannot be requested: enable=0 IER=0x0
SER1: Interrupt 11 (2) cannot be requested: enable=0 IER=0x0
SER1: Read LSR = 0x60
SER1: Read MSR = 0xb0
SER1: Read LSR = 0x60
SER1: Read MSR = 0xb0
SER1: INT14 0x3: Port Status, AH=0x60 AL=0xb0
SER1: INT14 0x1: Write char 0x20
SER1: Transmit 0x20
SER1: Func transmit_engine requesting TX_INTR

So I try different Things, use com2="/dev/ttyS1", also direct portaccess
with fast dosen't work.

So at last try with the speed and hogthreshold. No difference.

I won't try to work witch MSCLIENT and Network on DOS.

So is there a possibility to fix the serial problem.

Try dosemu2
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ubuntu debs?

[Stas Sergeev]

09.09.2016 17:16, Danil Smirnov пишет:

Are there any .debs of dosemu2 for Ubuntu?

Its now there.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ubuntu debs?

[Stas Sergeev]

09.09.2016 17:16, Danil Smirnov пишет:

Are there any .debs of dosemu2 for Ubuntu?

Not yet.
Perhaps I can create some with checkinstall.
You can fill in an issue ticket for this.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "EMS driver version mismatch: got 3, expected 5, disabling"

[Stas Sergeev]

03.09.2016 17:30, Mouse пишет:

Teal deer: I'm getting the message in the Subject:, but can't figure
out where to get an appropriate ems.sys.
[...]

Remove your ~/.dosemu/* (ems.sys is there)

Thank you very much!  This worked (as I'm sure does not surprise
anyone).

However, neither the old .dosemu nor the new (I didn't actually remove
~/.dosemu, just renamed it so dosemu wouldn't find it) contains
anything named EMS.SYS, nor ems.sys, nor any mix thereof.  So, as happy
as I am to have it fixed, I don't understand why this fixed it.

There can be symlinks to system-wide dirs that contain ems.sys.
Check ~/.dosemu/drives/d in particular.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "EMS driver version mismatch: got 3, expected 5, disabling"

[Stas Sergeev]

30.08.2016 20:59, Mouse пишет:

Okay, I was hoping to see a bit of list traffic before sending, but,
for whatever reason, I'm not seeing anything.  I hope it's not some
kind of filtering spazz - though I did get the list welcome mail, so
that seems unlikely.

Teal deer: I'm getting the message in the Subject:, but can't figure
out where to get an appropriate ems.sys.

In more detail

I'm trying to use dosemu on Linux (kernel 3.13.0-48-generic, on
x86_64).  The binary distribution had some X issues - but I know a bit
about X, so I cloned the git tree and started to fix them.  I think I
have succeeded in fixing the immediate problem there, but now I'm
having other trouble.

The binary distribution claims to be 1.4.0.1 (in that when I run
dosemu.bin --version, the first line printed is "dosemu-1.4.0.1"); as a
disambiguator, dosemu.bin's MD5 hash is
60bf29180c9270018f6ba8f246e57a41.  But when I base my stuff on commit
77c5e739bf5f128802ef55763909568008eac6f0 ("Tagging 1.4.0.1", the only
child of commit 74b00d8d5b46d20ce384ab64544ea41a389afe70, "DOSEMU
1.4.0.1"), all I ever get is segfaults on startup after a complaint
about how LOWMEM mmap is failing.  The binary distribution's dosemu.bin
does print

EXPERIMENTAL: using non-zero memory base address 0x11.

and strace leads me to think this is relevant (in that it's printed
immediately after the same mmaps fail, but then two more mmaps are done
with addr=0x11).  However, I can't find that anywhere in the
1.4.0.1 tree.

So I moved my work over to the apparent development tip, basing it at
commit 18f6f5cdf1beceae8c7532718bfaf423e4a44f6a instead.  It still
crashed, but now I could find hints in the source that turning on
EXPERIMENTAL would help.  It did; I then got something that would start
(and, yes, the X issue was fixed) and complain about missing DOS.  So I
fetched dosemu-freedos-1.0-bin, through the chain of redirections (the
first one coming from either http://www.dosemu.org/stable/ or
http://www.dosemu.org/bleeding/):

http://prdownloads.sourceforge.net/dosemu/dosemu-freedos-1.0-bin.tgz?download
http://downloads.sourceforge.net/project/dosemu/dosemu-freedos/1.0/dosemu-freedos-1.0-bin.tgz?download=
http://superb-sea2.dl.sourceforge.net/project/dosemu/dosemu-freedos/1.0/dosemu-freedos-1.0-bin.tgz

which last finally gave me the gzipped tarball.  I did a make install
with this in place as dosemu-freedos-bin.tgz and then it was willing to
start, but told me

| DOSEMU 1.4.0.8-762-g400b188 (2016-08-30), configured: 2016-08-30 12:32:33 
-0400
| Please test against a recent version before reporting bugs and problems.
| Submit Bugs & Patches to linux-msdos@vger.kernel.org or via http://dosemu.org.
| FreeDOS kernel build 2036 cvs [version Aug 18 2006 compiled Aug 18 2006]
| Kernel compatibility 7.10 - WATCOMC - 80386 CPU required - FAT32 support
|
| (C) Copyright 1995-2006 Pasquale J. Villani and The FreeDOS Project.
| All Rights Reserved. This is free software and comes with ABSOLUTELY NO
| WARRANTY; you can redistribute it and/or modify it under the terms of the
| GNU General Public License as published by the Free Software Foundation;
| either version 2, or (at your option) any later version.
| C: HD1, Pri[ 1], CHS=0-1-1, start= 0 MB, size=  2000 MB
| D: HD2, Pri[ 1], CHS=0-1-1, start= 0 MB, size=  2000 MB
|
| EMS driver version mismatch, disabling.
| Please update your ems.sys from the latest dosemu package.
|
| Press any key!

and I've been unable to find an ems.sys that works any better,
including the one generated from ems.S during the build.

Remove your ~/.dosemu/* (ems.sys is there)
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DOS exe not working in DOSEMU under Ubuntu 16.04

[Stas Sergeev]

09.08.2016 10:34, Gordon Hay пишет:
I've been using DOSEMU under various versions of Ubuntu for many 
years, and still rely on it.

You can try dosemu2 or dosbox.
Older dosemus are not supported by distros, but
should still work if you install all updates (most
importantly the kernel updates)
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ubuntu 16.04 on i386 has VM86 disabled again

[Stas Sergeev]

26.04.2016 13:09, Andrew Bird пишет:

The long term goal for the Kernel would be a new simplified vm86() call, but 
most likely this is not going to be backwardly compatible for existing apps to 
run unchanged.

This is not a problem: there are currently 2 vm86 syscalls:
vm86() and vm86old(). One can re-implement vm86old(),
leaving vm86() for compatibility with the current apps.


  A while ago I tested Bart's dosemu2 branch which implemented a kvm based 
mode. I found it to be almost identical for speed with vm86() on both floating 
point and integer based benchmarks on i386. If that can be made stable enough 
to use on i386 and x86_64, then I see no reason to implement a new vm86() 
purely for 32bit.

The problem is that kvm is unstable by itself:
https://lkml.org/lkml/2016/3/29/567
It reboots some old machines...
Also the way dosemu uses it, is a bit nasty and complex:
it sets up the full vm86 monitor in userspace. Bart initially tried
the clean implementation, but that required too much work
on both dosemu and kernel side, and may not be supported
on many CPUs. I still want to prepare dosemu for a clean
implementation, and make that optional. The branch "kvm"
is for that.


  Of course it's a question of developer resources, I for one am not capable of 
helping with either Kernel vm86() or to the stabilisation of kvm based dosemu, 
so I do what I can to preserve the ability to run with the old vm86() by 
pushing for runtime enablement in Ubuntu. I suspect this will only work for so 
long, and at some point it will be dropped. So I hope the kvm mode can be 
developed to the point where we no longer care about vm86() being available, as 
it's good enough to be the default and fast enough for those apps that need it.

Integrating kvm properly and cleanly, and fixing the kernel
to not reboot the older machines, is virtually an unlimited
amount of work, while re-implementing vm86() is a quite
small task. Of course if we accept enough of short-cuts,
then the proportions may change.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ubuntu 16.04 on i386 has VM86 disabled again

[Stas Sergeev]

26.04.2016 12:17, Paul Crawford пишет:

On 25/04/16 13:52, Stas Sergeev wrote:

That was the "right" thing to do. Or at least justified and discussed.
If we want vm86(), we need to re-implement it properly.
I have a word from top linux devs (including Linus himself)
that properly implemented vm86() will stay enabled.


This may seem like a strange question, but what is actually wrong with 
the current/past vm86() support?

The problems started to happen when vm86() was completely
broken for too long and no one have complained. So the kernel
devs decided to simply disable it, instead of fixing, assuming no
one uses it:
http://marc.info/?l=linux-kernel=143654248415764

Only then Andrew Bird have noticed that and raised
an issue. After a lot of pestering, I convinced them to actually fix it:
https://lkml.org/lkml/2015/10/31/7
but, since I am using the 64bit environment, I had the hard times
to even test the fix. So they left it disabled until someone can
provide a very simple, easy to audit implementation. This is not
difficult at all, BUT, this will require installing the 32bit OS somewhere,
a lot of time-wasting. :)

I was under the impression that for 32-bit CPU operation it was simply 
a call to the corresponding x86 instructions, so don't see what would 
be "wrong" 

You can see its sources and judge for yourself.
There are few problems. Firstly, it emulates VME in software
because of some horrible hacks that former dosemu developers
have pushed into kernel (grep for BIOSSEG in vm86_32.c).
Secondly it implements the horrible and completely unrelated
interfaces, also pushed by some dosemu devs in the darkest
past (VM86_REQUEST_IRQ and friends).
So while I was fighting the decision of disabling it, I'd be doing
the same thing if I were them. :)

with that beyond the obvious aspect that it can be abused by malware 
(much like anything else really) hence the idea of having it 
configurable at run-time so it defaults to being off but is only a 
(root) text edit away from being enabled for us who want it for odd 
cases like dosemu.

If it is properly implemented, then yes. And I have that "yes"
from Linus and Ingo personally.
But the current implementation does not deserve even the
run-time disabling. It should be completely compiled out,
unfortunately.
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ubuntu 16.04 on i386 has VM86 disabled again

[Stas Sergeev]

25.04.2016 15:16, Andrew Bird пишет:

Hi all,
Just a quick note to let people know that if you upgrade your i386 
Ubuntu to 16.04 LTS release, you'll find that you are only using cpu emulation 
again. I naively thought that fixing the problem for Wily HWE kernel would 
automatically mean that Xenial would come out with the fix. If this slow 
operation affects you, and you'd like it fixed, please visit the launchpad bug 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574602 and indicate that 
it affects you and its importance.

That was the "right" thing to do. Or at least justified and discussed.
If we want vm86(), we need to re-implement it properly.
I have a word from top linux devs (including Linus himself)
that properly implemented vm86() will stay enabled.
Or the one can use kvm, which can already be enabled
in dosemu config.
Currently there are no resources for either re-implementing
vm86() or fixing kvm support to the state when it can be
enabled by default. But feel free to contribute. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dosemu

[Stas Sergeev]

31.01.2016 03:16, Luca Rossi пишет:

hi, i'm Alex from sicily
i've found this interesting program for linux and apparently it's
capable of running my beloved videogame (carmageddon 1) on native HW,
i'd like to ask you if there is a simple solution for having an USB
drive with linux and dosemu, the actual question is... what linux
distro is best just for this pourpose?

dosemu needs a recent enough kernel (something like >= 4.1),
SDL2, not-so-recent fluidsynth (not from git) and ladspa (optional).
With these it will provide quite good sound/video capabilities.
See dosemu2.spec.in for a more complete list of dependencies.
Then you can check those with any distro you have.


  i've tried dosbox on windows
and it goes slow even on my "rig", with knoppix 7.4.2 it works, but no
sound (not with 7.6.1), even on a 2003 (A.C.) machine :)

dosbox has a good sound support too.
It is likely your fault that it doesn't work for you.
dosemu2 has the slightly more advanced sound stack (with microphone
support) but dosbox emulates more sound cards (dosemu2 is limited
to sb16).
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dosemu takes 99% of cpu

[Stas Sergeev]

Hello.

Fajar Priyanto wrote:

Is it normal that dosemu takes 99% of cpu?

That depends on the program that it runs,
and on dosemu version, which you, AFAICS,
haven't specified. 1.3.2 is known to be not
very good on that - try the CVS code.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: cp852 font - finally

[Stas Sergeev]

Hello.

Andrzej Kaczmarczyk wrote:

solution, for anyone else having the problem

Good explanation, but unless you'll find
a way to fit it into the dosemu docs (and
supply a patch), it will most likely get
lost.
Another point is that the dosemu config
should be pre-set for the like things, but
this is still under discussion for too long:(
Now it is apparently very important.


9. the next step depend on your graphics card
I have a SiS chipset PCI Card so
$_pci = (on)
$_chipset = sis

The problem is that this should not be
necessary. The error message that you sent
me privately (for which I proposed the
$_pci=(on) as a workaround), is most likely
a bug. And if it requires also $_chipset=sis
(does either change solve the problem, or
only both together?), then it is even more
buggy I think. Would be nice if you open a
bug entry for that, with the log and other
info I mentioned.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [SEAL] and xdosemu just work

[Stas Sergeev]

Hello.

Wesley Parish wrote:
SEAL works - somewhat.  Any other graphical environments for DOS I 
could try?

Try Windows 3.1 - works perfectly under
dosemu for those extreme-lovers:)

Are you making a list of the programs
that work under dosemu, or what? That
would be a huge list, beleive me. :)

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Syslog

[Stas Sergeev]

Hello.

Austin Morgan wrote:

If this is not currently possible is
it desireable enough for me to generate
a patch?

I think so, having such an option would
be nice. Will probably help those who
start dosemu from the desktop menus and
therefore do not see the error messages.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with settlers 1

[Stas Sergeev]

Hello.

Benjamin Schieder wrote:

Just another question: why did this work on the other machine (P4, 1GB
Ram, kernel 2.6.11.8) but not on the laptop (P-Mobile, 512 MB Ram, kernel 
2.6.10).

Maybe you have the
/proc/sys/vm/legacy_va_layout
enabled on the machine where it
works? I can't think of any other
reasons. It shouldn't work with
the flexmmap layout, so the
legacy layout might have been
enabled on that machine.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with settlers 1

[Stas Sergeev]

Hello.

Benjamin Schieder wrote:
xf) settlers 1 complains that it can't save. The game (not dosemu) 
gives the error filesystem full or write-protected.

This was fixed in 1.3.2 by
someone's request on BTS:
http://sourceforge.net/tracker/index.php?func=detailaid=1164054group_id=49784atid=457447
Wasn't this your own request by
any chance? If not - just upgrade
your dosemu and enjoy.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Instaling Xfont

[Stas Sergeev]

Hello.

Alain wrote:

Now the problem is: The cursor is still broken (is at 1/3 from the top)

This was fixed, upgrade from CVS.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sound support (2), using hardware directly

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
I have ran it succesfully on my AMD Athlon @ 1GHz, and I know there are 
softsynths that need much less, although not for Linux.

As I said, you can tune timidity++
to work even on 386, just disable
some effects processing.
There are also the alternative
synthesizers, like fluidsynth,
as someone pointed out to me, but
I am not sure if they work as an
alsa sequencer backend, or have
the server interface for midid.


running a softsynth inside Dosemu...

That is possible for FM synth, but
you really don't want to distribute
the instrument patchsets with dosemu.

Well, the problem seemed to be at the time that the (OPL3) driver from 
ALSA was conflicting with the OPL3 being accessed directly.

In this case simply not loading the
OPL3 driver from ALSA would help,
but IIRC it doesn't.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sound support (2), using hardware directly

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
Also not loading the OPL3 driver doesn't seem to be possible, since the 
plain sounddriver seems to have a dependency on the OPL3 driver.

But as a test, you can just not
load the sound drivers at all,
disable the SB emulation in dosemu,
open the Adlib ports, and see if
that works.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sound support (2), using hardware directly

[Stas Sergeev]

Hello.

John R. Sowden wrote:
Since this thread has worked it way to Dosemu talking directly to hardware, 
I am interested in using my linux/dosemu box to connect to a local area 
network that runs DOS only (we don't do windows).

This have nothing to do with
the direct hardware access.
Please refer to the dosemu
documentation to find out how
to set up the network access
under dosemu.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sound support (2), using hardware directly

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
Do you think it would be possible to allow complete direct access to 
the Sound Blaster card in Dosemu, so that I could set the mixer from 
Dosemu?

Yes, this must be possible.
You won't hear any sound in
most cases, but the mixer will
work, and so will the OPL3. Just
don't forget to tell your DOS
programs that it is the Adlib,
not SB, or the detection will fail.
Actually, even the sound will
work in some very old games like
Another World, which do not use
the DMA.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sound support (2), using hardware directly

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:

The current system seems to work pretty well for me

It doesn't even work with ALSA.
Also, your AWE probably have the
hardware mixing, but for those
with the cheap sound cards, it
is not possible to get the midi
together with sound (provided they
do not have the wave-table too).
I myself can't get this to work on
my pc-speaker, and that really annoyed
me enough to start writing the new
code. Now as for the DOS programs:
FT2 doesn't work, sound in DOOM
stutters, sound in Aladdin have a
big latencies, etc. It is not very
good.

While OPL3 emulation would be really nice, wouldn't it be better to 
implement support for real OPL3 chips and emulate and OPL3 at another 
level in the system if one isn't availlable?

Problematic. Access to the real OPL3
will require root or the kernel module.
And then you can just use $_ports to
get this working that way, no need to
write anything (yes, I know it doesn't
work for you right now, but thats a
different problem). So the real value
is to have the good OPL3 emulation.


Then also other
applications such as FreeSCI and
ScummVM would be able to make use of
it.

They all use the MAME OPL3 emulation
engine. I don't think they'll want
something else. And really, having
the OPL3 emulation system-wide doesn't
sound sane to me - this is too specific
to the old-PC emulators.

About the new system. If the new code isn't comparable to the current 
code yet, maybe release 1.4 of Dosemu should still contain the old 
code?

Noone knows when 1.4 will be released.


I'm really looking forward to the new stuff.

You will get it and the sound code
is not even the main part.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sound support (2), using hardware directly

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
Yes, I am aware of the MIDI support in Dosemu, but I thought it was 
only for General Midi compatibility.

No. On the software synth side, midid
have the -m option which will give you
some basic mt32 support.
As for the directly passing the midi
stream to the wavetable - this is also
possible and described, and will allow
you to use your AWE synth fully, provided
it all goes via the mpu-401 in a
pass-through mode (almost always this is
the case).
So you can try and see if there are any
differences with what you now have - there
shouldn't be, but you won't need root,
which is very important in some cases.


Sounds great! I'll watch the Dosemu
development and try things out when 
they get released :)

Well, the primary goal is to design the
very simple but robust sound subsystem
from zero, so that it won't depend on
OSS, but can work also with ALSA and
anything, and so that it can work with
many more DOS progs than the current one
does. But the OPL3, again, is not in the
list of the primary targets:)
Of course porting the MAME OPL3 emulator
to the planned sound system must be easy,
but we'll see where this all will end up.
It will probably take some time before
something can be released though - the
main problem is that the current code
also happened to work somehow, and the
replacement is possible only when the new
code matches the current one in the
functionality, which can take long enough.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sound support (2), using hardware directly

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:

Is anyone else using a similar setup?

No.


cards and it's wavetable for MIDI,
but is the way I described this the 
way to do it in this case?

In principle - not. MIDI can be achieved
by the more legitimate means.
sound-usage.txt describes many ways of
setting up midi under dosemu. That
includes the software synth and the
wavetable access ways, so you really
should have a look.


be near perfect, but I'm really
looking forward to have OPL3 support 
within Dosemu :)

I think it will soon be there. At
least a lot of work is being done
in the sound area right now.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DOSEMU CVS Crash With Kernel 2.6.12

[Stas Sergeev]

Hello.

T.P. Reitzel wrote:

Is anyone working on the source of this crash?

Not really. It doesn't look like
this problem is reproduceable, so,
as Bart already said, you should
move it to BTS.
I only committed the patch few days
ago that repairs the $_mapping option,
so that you can try $_mapping=mapfile
and $_mapping=mapashm and see if it
makes any difference, but this is
pretty much all that was done.

It looks like the kernel was not able
to commit the 1Mb of memory needed to
emulate the DOS address space, and sent
a SIGBUS to dosemu to notify about that.
This can happen if dosemu failed to
resize the backing-store, but it checks
the return value of ftruncate, so this
shouldn't be the case (or maybe it is
better to ftruncate() before unlink()?).
Or maybe you somehow ran OOM, make sure
the overcommit is disabled in
/proc/sys/vm/overcommit_memory
Or maybe it is a kernel bug - try -mm
patch then.
Anyway, this bug is not for the on-list
resolution.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dosemu 1.3.2 and linux 2.6.7 headers

[Stas Sergeev]

Hello.

Bart Oldeman wrote:

Maybe add the proper headers to the
dosemu source tree as we did before?

The question is which headers?

I think some of them can be located if
you symlink the kernel headers and try
to compile. Of course it is not guaranteed
to be all of them, but better than nothing.
The thing is that the source tree of dosemu
already contains a lot of the problematic
headers (you added most of them anyway:).
We can either keep adding to it, or remove
it entirely. Right now it is there, yet it
doesn't contain the sufficient amount of
headers to get the thing compiled on 2.6,
so basically it is useless. I still have
the hopes it can be entirely removed but...
not today:) (i.e. we really have to check
about the slackware, I guess)

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dosemu 1.3.2 and linux 2.6.7 headers

[Stas Sergeev]

Hello.

Hufnus wrote:

After some googling I think I finally found the
correct linux-libc-headers (as they are now called).
http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ 
http://ep09.pld-linux.org/%7Emmazur/linux-libc-headers/

Yes, that's the correct headers,
but unfortunately it doesn't save
the world. This project was rather
ambitious, but I am not sure it have
achieved all of its goals. The
intention was, AFAIK, to merge the
headers back to the kernel tree so
that the kernel folks to maintain
it - failed. The other intention
was to convince the distributors to
include it - I think this hasn't
happened too.
Now you are really supposed to use
the headers with which your glibc
was compiled! And even though the
headers you've found are the correct
ones, your glibc was not compiled with
those:( So the original suggestion
still stays - using the slackware
package of the 2.4 headers will work
the best:(
Note that compiling your software
with 2.4 headers doesn't mean that you
have to use the 2.4 kernel too. It
actually means nothing. You won't loose
any feature. Choosing the proper headers,
even if they are very old, will never
make your software any harm.


just now that they have an alternate 2.6 kernel in the
distribution and note that it is an alternate!

kernel is the one thing, glibc-kernheaders
is another. One have to understand that
the glibc-kernheaders are not the same
as those that come with the kernel. And
now slackware have the 2.6 set of the
glibc-kernheaders (or whatever they call it).
No matter what kernel you use, the software
(like dosemu) must compile with that headers
(if glibc was compiled with them, at least).
To the best of my knowledge, this is not the
case with the slackware. The problem with
pci.h, according to what I've heard, is
there in their sanitized set of 2.6 headers,
which is not good AFAICT. If you can verify
this - would be nice.


now I am going to switch to the libc headers or sanitized
kernel headers, since they seem robust enough and I am
now aware of them...

Not so fast - you need the headers your
glibc was compiled with - thats the problem.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dosemu 1.3.2 and linux 2.6.7 headers

[Stas Sergeev]

Hello.

Julius Schwartzenberg wrote:
The kernel header package that originally came 
with the version of Slackware I was using would always solve the 
problems for me.

That's true and that's the 2.4 headers,
but can you comment on this wrt compiling
dosemu:
ftp://ftp.slackware.com/pub/slackware/slackware-current/testing/packages/linux-2.6.11.11/kernel-headers-2.6.11.11-i386-1.tgz


-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dosemu 1.3.2 and linux 2.6.7 headers

[Stas Sergeev]

Bart Oldeman wrote:
This is not its default symbolic link. You must have created it 
yourself, manually.

Hi Bart, actually I've seen such
a problem with Slackware in many
different places, so I am starting
to beleive it really uses a symlink.
I remember Patrick Volkerding claimed
in that very list that Slackware doesn't
do this, but it looks like it was changed,
or at least there is some bug...
If some distro really does this, then
rooting out this tendency among users
is going to be really troublesome:(
And some people claim that even
installing the 2.6 headers from the
slackware package still gives an error!
And only that the 2.4 headers work
properly.

Maybe add the proper headers to the
dosemu source tree as we did before?
We can convince people to use the
proper headers by answering the same
question over and over again, but we
really can't change the distribution.

-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: slow printing

[Stas Sergeev]

Hello.
Attila Szabo wrote:
copy something to lpt: is take about half an hour...
What can I do to speed it up ?
Try $_hogthreshold=(0) in dosemu.conf.
Or upgrade from CVS.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Signaling dosemu application to kill itself from Linux

[Stas Sergeev]

Hello.
[EMAIL PROTECTED] wrote:
handles the I/O to 378h and 3f8h.  Since
he was not using INT 14h, I didnt realize
that your dosemu abstraction (emulation)
would filter both port and IRQ I/O!
Thats actually a common problem here.
People assume that something doesn't
work without even trying it (even after
they were suggested to try), and the
serial ports is a most frequent casuality
of such a self-delusion.
But when I was able to fire it up, the screen during
dosemu kill was NO LONGER HANGING Linux. And the restarts
occurred fine.
Good that is now works. But it would
be nice to understand where the problem
was, so that we can fix it. Your config
looks mostly safe, but there are still
those dangerous things like the hardware
ram and irqpassing (and I really think
that the hardware_ram thing was not
tested here for about something like 5
years or more, so it can easily be broken).
It would be nice if you try the things
as root again, but with the fresh dosemu.conf,
the one with everything is commented out,
and see whether it still hurts the linux
box or not. If it works without the
lookups/rebootes, then you can easily
locate an option of dosemu.conf that
made the problem for you. And it should
be the latest CVS code of dosemu to
make the testing more valueable.
This might have also solved the PIT emulation
going crazy, but wont know for 3 or 4 weeks.
This is very unlikely, but keep us
informed.
The idea was
to reset dosemu every week, to avoid the problem.
Quite pity that such a hacks are
still needed. Apparently dosemu was
never tested for such a long uptimes.
 if you need an LPT too, then that's
 a problem.
I knew that wasnt emulated from some posts.
So how at the end you got the LPTs to
work without a root? To the best of
my knowledge, it is not possible right
now, unless you implemented the missing
emulation yourself. (I don't mean the
printing-only mode, which is how the
LPT emulation is implemented right now)
We are not using INT 1A
OK, then please refresh my memory on
what you actually use and I'll take
another look at that code.
I would add code to the TSR
instead of having to do a dosemu kill and restart!
Yes, that should work.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Signaling dosemu application to kill itself from Linux

[Stas Sergeev]

Hello.
[EMAIL PROTECTED]
Negatory on that, no raw kbd or strange stuff,
all vanilla...
Yes, your config looks pretty save.
Note: you don't need to uncomment
the options unless you are going to
change them.
Why are you using the direct access
to the serial ports? The emulated
access of the CVS dosemu is nearly
as fast as the real one.
I'd like you to revoke the root
privs from a dosemu process before
the further experementations, but
if you need an LPT too, then that's
a problem.
Advantek i486 Cytrix tiny mobo.  I do have
a serial port, can try logging on a getty
there.
Yes, please do this and produce a
stack trace with gdb when dosemu is
hanging.
Alternatively, send a SIGSEGV to
dosemu when it is hanging, and it
will dump a stack trace into a log.
just spinning.  There is an assembly language
TSR that is running that I bet is holding
the dosemu thread active or hung.
No DOS program should hold a dosemu
when it gets a SIGTERM, or it is a
bug. The stack trace can help.
Also, how exactly are you killing
it? SIGKILL can help too:)
Is there a way (INT 1Ah?) to force dosemu to reset its time to
Linux's, on request?
The mentioned patch was just reading
a linux time directly, so with the
$_timemode=linux you don't need to
reset anything at all.
I am sure however your problem is not
related to RTC, it is a problem of the
PIT most likely. The patch won't help.
You'll have to dig a PIT code, which
is just a big mess :( It boils down to
the cputime.c at one point, but the
parts of it are all around the sources.
You'll certainly have fun tracking it.
One thing to try is $_rdtsc=on/off
(don't remember if I told you that
already)
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Signaling dosemu application to kill itself from Linux

[Stas Sergeev]

Hello.
Andrew Brooks wrote:
Not disappeared at all, still lurking.  But our patch was broken
up when applied to CVS and we haven't found the time yet to work
out which bits were applied, which changed and which left out :-(
What's the problem with that exactly?
I already pointed you the particular
commits. Now you only have to set up
the CVS tree before that commit and
apply your patch to it. Then setup
another tree, right after the commit
was done. Diffing these two trees
will immediately reveal what's missing.
10 minutes of work at most, I'd say.
Actually I've got a patch for the patch; you should change
I haven't applied that part at all.
It needs a further review with some
kind of a bi-directional communication
with the authors, which so far wasn't
set up properly:)
But sure enough I fixed other bugs
of your patch in the parts that were
applied. In case you are wondering:
http://cvs.sourceforge.net/viewcvs.py/dosemu/dosemu/src/base/dev/misc/rtc.c?r1=1.6r2=1.7diff_format=u
http://cvs.sourceforge.net/viewcvs.py/dosemu/dosemu/src/base/dev/misc/rtc.c?r1=1.5r2=1.6diff_format=u
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Signaling dosemu application to kill itself from Linux

[Stas Sergeev]

Hello.
[EMAIL PROTECTED] wrote:
The problem is that if dosemu is killed from Linux (crond), and
the dosemu console is in focus, the screen/kbd could cause Linux
to reboot
No! It can't! If it does this,
then it is a misconfiguration/
bug/outdated kernel/outdated dosemu/
dosemu with root privs/ or whatever,
but not the supposed behaviour.
With the sane setup such a things
simply cannot happen. Please explain
your problem in *much* more details.
because they were left in a bad state by a dos tsr.
You can extend the dosemu startup
script, or start it from another
script, which, after dosemu exits,
will restore the keyboard and the
console state. But no, this have
nothing to do with rebootes etc,
so please explain your problem in
details.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Signaling dosemu application to kill itself from Linux

[Stas Sergeev]

Hello.
[EMAIL PROTECTED] wrote:
the screen is ok (the shell's) but the kbd is
in echo strange characters mode and not passing to the original
shell.
strange character mode is probably
the raw mode. You probably set
$_rawkeyboard=(1) in your dosemu.conf.
I suspect you also did some other
unsafe changes in dosemu.conf, which,
only coupled with the root privs,
causes a reboot. (without the root
privs the reboot is not possible by
any means)
To get out of the raw mode you can
use either the kbd_mode command (which
you have to put in your script), or the
Alt-PrtSc-r keycombo.
dosemu is not restarted
That's strange. I think this means that
it is not really killed, and the process
is still spinning. You can ssh to your
PC and see what's going on in ps.
however, if I switch to a 2nd tty and run top, I see dosemu.bin
being restarted every 10min (for this test) and all is good!
You can also try xdosemu (if possible)
where all the like problems do not
exist.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Signaling dosemu application to kill itself from Linux

[Stas Sergeev]

Hello.
Gene Heskett wrote:
Mmm, what is this time patch, and where can it be obtained?
Here:
http://sourceforge.net/tracker/index.php?func=detailaid=1034800group_id=49784atid=457449
But I won't count too much on it,
as the guys who submitted it,
disappeared.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dosemu vs Xdosemu... font and Vga...

[Stas Sergeev]

Hello.
jb wrote:
On Xdosemu : - Font are ... ugly. - 
http://astrosurf.com/djibb/divers/xdosemu.png
Looks like a bug. Try bug-reporting it.
But (by blind way) I can display VGA drawings (font are always ugly)
Any tips ?
Set $_X_font=vga in your dosemu.conf
and try xdosemu again.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [DOSEMU / Linux]how to directly start a DOS app without goign through DOSEmu window

[Stas Sergeev]

Hello.
Daniel Moyne wrote:
With Linux I have a DOS app that I want to directly start without doing 
:
D:
cd generelt
demgene.exe
in the DOS window launched by xdosemu.
generelt directory is in my $HOME directory
xdosemu $HOME/generelt/demgene.exe
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [DOSEMU / Linux]how to directly start a DOS app without goign through DOSEmu window

[Stas Sergeev]

Hello.
Daniel Moyne wrote:
xdosemu $HOME/generelt/demgene.exe
Thanks this works fine but the ultimate idea is to move the DOS app 
demgene.exe in /usr/local/DOS/Generel for all users to access and keep 
$HOME/generelt just to access data ; in this case :
Move the main executable to /usr/local/DOS/Generel
but still have the symlinks to it from all the
home dirs?
$ xdosemu /usr/local/DOS/Generel/demgene.exe
This opens the app but has no $HOME/generelt definition for accessing data.
What else to do ?
If you can tell your demgene.exe to search
for its data on another logical DOS drive, then
you can make that another drive to be the
$HOME/generelt on a per-user basis. Search
for the Re: commandline switch for changing $_hdimage settings?
topic on that list to see how.
If this is not possible and you don't like the
idea with symlinks too, then I think you are
out of luck.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port Access slow

[Stas Sergeev]

Hello.
Pande Gede S wrote:
I want direct access,
No, you don't. Please justify that intention.
Also please read this thread:
https://sourceforge.net/tracker/?func=detailatid=457447aid=1166288group_id=49784
how to disable $_com1 and use 
Comment it out.
device /dev/null
Write that to $_ports string instead of
/dev/ttyS0.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Port Access slow

[Stas Sergeev]

Hello.
Pande Gede S wrote:
I use dosemu-1.2.2-1, I have serial printer with foxpro apllication.
How to speed up printing?
Try upgrading dosemu from CVS, its
serial code should be much faster.
I have added $ ports = device /dev/ttyS0
You don't have to set $_ports, you
should use $_com1 instead. Well, if
you want a direct access, you have
to disable $_com1 and use
device /dev/null, that option basically
does nothing.
fast ox03f8
That should be 0x3f8, not ox03f8
And you normally should not use $_ports
at all.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CD image

[Stas Sergeev]

Hello.
C. D. Logan wrote:
Is it possible to use a CD-Rom image (iso) on the Linux system and have 
it available under dosemu as a CD-Rom drive?
Please refer to this thread:
http://sourceforge.net/tracker/?group_id=49784atid=457447func=detailaid=1044528
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Switching consolle

[Stas Sergeev]

Hello.
Lars Bjørndal wrote:
What's BTS? Should I mail the result to the list?
The BTS (Bug Tracking System) for dosemu is
here:
http://sourceforge.net/tracker/?group_id=49784atid=457447
You may want to register yourself there before
opening a report - this will allow multiple
attachments and e-mail notifications about
your bug.
It is much better to report the bugs there
(if the query on list doesn't provide any help)
because:
1. The bug will not be forgotten.
2. You can do the large attachments there
without annoying the list subscribers.
3. It is just much quicker to add a comments
there, so if you haven't provided all the
necessary info about your problem, someone
can give you a quick hint, while on the list
this is less likely and usually gets ignored.
Whoever have any bugs that failed to find
the resolution on list, should fill in the
bug report. Some problems cannot be resolved
without the one. Of course filling the report
guarantees nothing, but the chances are higher.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Switching consolle

[Stas Sergeev]

Hello.
Lars Bjrndal wrote:
swithes consolle with ctrl-alt-fX, dosemu exits with an error message.
Is this a known problem?
You forgot to write down that error
message, didn't you?
Also, please try the CVS code, it may
do better for console.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usage with libgpm

[Stas Sergeev]

Hello.
Ryan Underwood wrote:
Ok, that's good to know.  Why
is it that libgpm is not available as
root console?
It still can be used, but you have to
set $_graphics=(0) then.
man gpm:
---
  While  the  current  console  is in graphic mode, gpm sleeps until text
  mode is back (unless -R is used). Thus, it wont reply to clients.
---
But the root-console with $_graphics=(0)
gives the corrupted national characters
to me, so I don't know how usefull it is.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sound support

[Stas Sergeev]

Hello.
Ryan Underwood wrote:
limited. Well, not our problems at all.
I mean, tell ALSA developers why dmix
is useless for this application
and suggest how it can be improved.
No-no, there is nothing with that
particular application (dosemu), as
soon as we are going to use the sound
server, not an ALSA directly. My
comments on dmix are unrelated to
dosemu. It is just that I had problems
with it.
I have the pc-speaker, it does 5-6bit
output only. And dmix doesn't support
8bit streams, so I have to mix the
16bit streams and add the code to the
driver to convert it back to 8bit. With
that configuration even 2 streams are
not practicle, i.e. I can't use dmix
at all.
Another problem I had is that it is not
possible to connect dmix to any plugin
other then hw.
On a generic hardware its limitation
may not be too noticeable (unless you
mix a lot of streams so that the
saturation makes the problems), but
for the small things like the pc-speaker
it was a disaster.
OK, I understand this.  JACK does have a
callback for when the sample
rate changes, so it would get that information.
No, it is not that. It is that the
rate of the output device and the
rate of the dosemu DMA are driven
by the different time sources, which
means they may sometimes get out of
sync (dosemu timing is not perfect
anyway). So when the buffers are getting
low, we have to find that out and speed
up our transfer a bit. If we are doing
writes ourselves, before every write we
could query the buffer and see if it is
low or not. But with the callback model
it is assumed that we can provide the
necessary amount of data at any time.
Server may want to fill up its buffers
at one point, and so it may call us up
to provide the amount of data we don't
have yet. Server is driving, not we.
So with the callback model, implementing
our own rate control is difficult.
work. Of course the most frightening
part is to put the stuff into a separate
thread.
Yes, but for SB this doesn't really make
sense, does it?
It does. Consider we are doing the 44100Hz
output. With the scheduler frequency of
1Khz, we'll have to transfer roughly 44
bytes per the timeslice. This is already
too much - the DOS prog will see the jumps
of the DMA registers by the value of 44,
while under the real hardware it can see
the transfer of every single byte.
But the dosemu clocks are set to 100Hz
for SIGALRM, so with that rate we'll have
to do the transfer of 440bytes per burst,
which is not much better than what we have
now. Increasing the rate of the SIGALRM is
really ineffective and will cause the
slowdown. And also the dosemu main thread
can sleep, which will cause underruns.
So moving the SB to another thread makes
sense, as far as I can see.
I think FreeBSD removed their v86 syscall now.
How can they run the VESA XFree server
then? With emulator?
What about x86emu from X.Org?
Might be something to take a look into,
but I think it is not as fast as qemu.
I don't know - so many people complaing
about the speed of DosBox even
on 2GHz machines.  I don't know
if it is with real-mode or p-mode code
though.
Well, when the simx86 was functional,
dosemu powered by it, was still way
faster than the dosbox is. I don't
know what the problems the dosbox have
with the performance, but there might
be few:) Well, dosbox didn't have the
dynamic translator back then, and the
simx86 no longer exist, so the fair
comparision is not possible, but for
the real mode simx86 was really very
usable, actually it was even fast, and
that is on my ancient 700MHz CPU.
to be able to run the windows kernel in
protected mode without too much of a
redesign.
Why didn't they just used VCPI?
They could use VCPI for their ring0
startup code (which is the DPMI server
itself), though they opted to implement
another quick hack called GEMMIS.
Thats probably because the VCPI was too
386-oriented (paging), while they needed
the stuff to work also on 286.
For the ring3 code they needed another
protocol, the one that will allow to
run the old winkernel and the DOS
programs concurrently. That became a
DPMI. And to not rewrite the winkernel
to be a DPMI client, they built the DOS
extender into their DPMI server, but
never documented that fact.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.
Julius Schwartzenberg wrote:
Any idea why it is only 'half' working?
I can think of 2 things: either it is
a conflict with the linux driver, or
with dosemu. You can isolate the both
possibilities.
1. Disable sound in dosemu config.
Then dosemu will not even try to grab
an OPL ports. Yes, SB won't work, but
Wolf might still be able to see Adlib,
and you'll be able to tell if it works
any better.
2. Disable all the sound drivers in
linux and reboot the machine just in
case. Make sure they are still not
loaded after reboot. Maybe they configure
your card somehow that the DOS prog
starts having problems.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.
Julius Schwartzenberg wrote:
I already tried this, but it
doesn't seem to make any difference.
But dosemu stops complaining about the
port conflicts, right?
I just tried it. Wolfenstein 3-D now is able to detect the OPL3 chip, 
but I can't hear anything (probably because the mixer isn't set).
In Wacky Wheels, I also can't hear anything.
Hmm, would it be possible then to boot
into DOS, set the mixer volumes, then
reboot back to linux (but with the hot
reboot, not with the reset button), and
then, if you don't load any ALSA module,
I think the volume will stick.
Another thing to try is to open also all
the SB ports to the DOS prog. Then you'll
probably be able to use mixer, and it
is also possible to use the SB ports
for the OPL access.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sound support

[Stas Sergeev]

Hello.
Ryan Underwood wrote:
Yeah, that is a big problem because
everyone is using a callback model
these days
I am not sure we can't try to use the
callback model, it may just be inefficient.
That also depends on how's the server
reacts on the partially satisfied
request (i.e. it asked for XXX bytes,
but we only give it a half of the size
or so). If the server have no problem
with that, we might still be able to
calculate how we have to speed the DMA
up or down.
It just sums the values of the streams.
I don't know how good it mixes more than
2 streams.
I know this is false because I have played
What exactly of the above, on your
opinion, is false, btw? The it just
sums the values..., or the I don't
know how... statement?
Or do you think just summing the values
will produce the good results for many
streams? Here's the quote:
---
The resolution for 32-bit mixing is only 24-bit. The low significant
byte is filled with zeros. The extra 8 bits are used for the saturation.
---
For the 16bit streams there might be
all the 16bits for saturation, but
with more than 2 streams the losses
are unavoidable, and consider that the
physical output is usually only 16bit,
not 32.
way dmix is implemented, its use is very
limited. Well, not our problems at all.
It might be a good question for the ALSA list.
It is not a question, this all is
even documented.
Isn't it what's the O_NONBLOCK for?
Here is Takashis' reply to a Linus rant:
Wow, amazing! O_NONBLOCK is not for that,
now I see. I wasn't aware such a seemingly
obvious things of the standard can sound
so different when Linus explains it:)
There is disagreement, but most kernel developers who responded thought
that O_NONBLOCK to avoid hanging the app was silly.  If the app wanted
to wait for the sound device to become available, it makes more sense 
to loop until not errno==EBUSY.
I don't think they (Linus mainly) offer
such a silly thing. His point it that the
synchronization on the sound device is
silly and must not be done (no sane
program should lock up and wait for the
device to free, as this may take from
seconds to years). And
---
If you actually think this is a useful
feature, I would suggest trying to 
key it off O_EXCL or a new flag.
---
Actually reading that discussion was
both informative and fun. Yes, I find
it funny to see how easily Linus beats
his opponents even on the things that
initially look obviously not on his
side, and how easily he proves what
initially looks obviously wrong. That's
something;)

Ok, so what you mean is that we must
have precise, low latency control
over what is written to the buffer.
No, what I mean is that we have to try
to advance the emulated DMA with the
constant speed. That means we shouldn't
do the callbacks to it and request the
data from it to fill the buffer. Instead
we'll have to do the buffering on an SB
side (SB have the FIFO actually), and
SB needs to have the information to be
able to adjust the speed of the emulated
DMA to match the speed of the real output.
It is probably more difficult to implement
with callbacks, but it may be possible.
The DOS program must see the DMA to
advance smoothly, but we can still do
some buffering on an SB side.
The good thing is that the current DMA
implementation will work, it is only
the SB layer that will require some
work. Of course the most frightening
part is to put the stuff into a separate
thread.
Isn't it possible for a BSD port too?
It might be (it was done in the past),
but it may be feature-less and difficult
to maintain. Linux kernel have a lot of
dosemu-related patches in it, dated from
the beginning of the project to nowadays.
And I personally (which may be totally
wrong) don't see a lot of demand for that.
Linux is always the primary market,
but perhaps the windows port will have
some market too. Not sure, but it worth
to try imo.
dosbox and qemu and
complaining about the speed
Is qemu still slow, even with its new
proprietary virtualization technology
(or whatever that kqemu is)? From what
I've heard (not too much), it may be
faster than dosemu.
are is much appreciated. x86_64 port is
probably more difficult, but can and must
be done.
By this you mean using a CPU emulator
For realmode only. Not a big deal.
We could even use simx86, but unfortunately
it broke.
In this case we are losing the
speed of native CPU, native IO, VESA
console (vs vgaemu).  I'm not sure
how it would turn out.
On 64bit machines? It might be very fast.
Emulating realmode code is not a big
deal *at all*. And even the protected
mode user-space code is not much of a
slowdown when translation is used, I
beleive. The real problem is with the
ring0/system code, which we always can
avoid to execute.
qemu-user development, and qemu-user no
longer runs dosemu (while it used to do
Have you mailed him with that problem?
Yes, long ago. He said he isn't going to
invest any more time in the qemu-user
development.
Well, we are running protected mode OS too,
as long as there is a DPMI
interface and we can find 

sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.
Ryan Underwood wrote:
Problem right now is that JACK only supports ALSA as a
That depends on how much we beleive
into it. The faq says:
---
a JACK backend to PortAudio
is under construction that would allow PortAudio apps to connect to JACK
ports.
---
Can we trust that? No idea.
What about
PortAudio?  It uses the callback based model like JACK but with many
more back-ends besides ALSA.
From a quick glance to the PortAudio
docs (which are in a chaos, as far as
I can tell), it is not an abstraction
layer, but rather an I/O library that
provides an access to the different
sound systems, and that access is not
unified. This is probably not the level
we have to use directly. JACK can get
use of it instead.
Also, a callback-based model, I hate to
say that, but looks like not the best
choise for us:( That may be fine for
Adlib, but for DMA sound this is a
problem. As I said already, we have to
do the smooth DMA transfers. Callback
API is chunk-oriented by design, which
is not good. We can accumulate the data
on an SB side and feed it to the callback
routine, but even then we won't have
enough info to control the DMA speed.
I.e. how do we know when the next
callback is to happen, and is the
current speed enough to supply the
necessary amount of data when the
callback happens? VDMSound uses the
on-fly DMA speed adjusting, which is
what we probably have to do as well,
and that doesn't work with the callback
model as far as I can tell. This is a
big problem.
There is the problem still of cards
which do not support hardware mixing.
That must be the headache for the mixing
layer, not ours.
First, dmix
will be a default plughw device configuration, so users will not have
problems with this.
That's not directly related to our
problems, but dmix is capable to mix
only two streams of the same rate.
It just sums the values of the streams.
I don't know how good it mixes more than
2 streams. It doesn't support 8bit
streams. If you want to use it with the
streams of a different rate, you'll likely
to have to route them via plug first,
but then there is no way to mmap the
card's buffer, and there are latencies
too. And you can't connect dmix to something
else than the hw. etc etc. Well, the
way dmix is implemented, its use is very
limited. Well, not our problems at all.
Also, ALSA semantics should be changed to return
-EBUSY instead of blocking when a sound device is opened
Isn't it what's the O_NONBLOCK for?
problem I don't know enough about is
what control over the audio stream
we get when dmix is in use.
Unless we use ALSA directly, not our
problem at all.
Additional problem of using JACK is that it doesn't work with dmix, so
it would block the card on a device which only supports one stream.
Do you mean it opens the hw instead
of the default output? That may be
for reason - if JACK does any mixing
itself (does it?), it might be doing
it better than dmix. Just a wild guess.
is full. Some DOS progs controls the
DMA registers during the sound output,
and that's why we have to guarantee the
smooth transfer and the accurate timing
ourself.
Does this imply we must mmap the sound buffer?
No, that means exactly the opposite.
mmapping the buffer is a dead end.
We will then have to do the mixing
and resampling ourselves, and we'll
not allow the other apps to use the
card with us, unless there is a hw
mixing I guess, and you can't mmap
unless you use the ALSA/OSS directly,
and even then you don't know what
you have mmapped, as the DMA organisation
can be different on the different cards.
And when the things like plug/dmix are
in use, I don't know what you'll mmap
in fact. No, we aint gonna mmap the
cards buffers. That was used by the
direct-SB patch:
http://www.geocities.com/SiliconValley/Circuit/5426/dosemu.html
something we don't want to have.
code waits for the OSS buffer to became
empty, resets the sound card, sets the
new parameters, and resumes the transfer.
Yes, this is completely stupid.
thanks... :)
Well, this may have been sufficient
at the time, since we had not even
Yes, exactly. That was quite sufficint
because it was a vast improvement over
the existing code, but it turned out
to be not future-proof. That's why the
new startups are achieving most of the
dosemu functionality within a *much*
smaller time-frame - they are not bound
to the ancient code and they do not
have to re-evaluate all those ancient
ideas behind that code etc.
idea that e.g. VESA, DPMI, WfW support
would become so good.
No-no, VGA/VESA emulation state internally
is not much better than the one of the sound.
Even the Windows VESA drivers that Japheth
wrote for us, are still not adopted.
DPMI state is now rather good indeed, but
that took years of (very slow) work.
WfW support is also not bad - that's because
finally we have the Windows expert who made
this possible. But there are still no
Windows experts on a FreeDOS side, so
FreeDOS is still not good for running
windows, which is bad also for dosemu.
SB support is the worst part about trying

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.
Julius Schwartzenberg wrote:
http://www.geocities.com/SiliconValley/Circuit/5426/dosemu.html
something we don't want to have.
This patch seems pretty neat.
Please note: this patch includes the
linux kernel module, not only the
dosemu modifications. This is needed
to drive the DMA controller directly.
You won't get it included into an
official kernel - people from XFree
tried that many times, this fails.
Linus doesn't want to provide the
DMA control to userspace I think,
or maybe there wasn't a good
implementation.
But people never give up:
http://www.ussg.iu.edu/hypermail/linux/kernel/0311.2/0107.html
http://www.bennee.com/~alex/software/kernel/index.php
The DMA access might be usefull for
dosemu, but not for sound. It is
good for driving some legacy hardware.
Is there any chance that at least OPL3
support could be added in such a way to Dosemu?
OPL3 doesn't need DMA. It doesn't actually
even need an interrupts. I see no reasons
why the one can't simply open an access
to the OPL3 ports for dosemu and it wont
work. Have you tried?
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sound support (Re: XMS problem with Aladdin demo)

[Stas Sergeev]

Hello.
Bernhard Bialas wrote:
However, a liitle bit more -compared
to now-marketing would be very usefull.
Comparing with what? It is probably
only dosbox that is close enough
with the goals to dosemu, but the
fair comparison between these two
is very unlikely. It will heavily
depend of who's comparing:) I think
it is better to not, or there can
be some flame. I've seen the dosbox
vs dosemu wars on a dosbox forums
sometimes, it is better to not have
the like things also on that side;)
As such marketing I would see
a list of applications which has been 
tested and works and also show
these one which are problematic.
Yes, that list would be very usefull
to have. I was trying to do something
like that in EMUfailures.txt, but of
course the real database will be much,
much better.
If I remember right, Ryan has a
plan to realize such list.
Yes, for many years now:)
Setting the wiki page might be very
interesting. Will probably help to
update the docs a little and gather
all those writings about dosemu,
like dosemu for dummies and others.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: XMS problem with Aladdin demo

[Stas Sergeev]

Hello.
Ryan Underwood wrote:
What are the requirements of a new
sound system, from your experience
with the current one?
The main requirement is that it must
not access the OS sound driver (OSS
or ALSA) directly, like it does now.
There must be mid-layers in-between,
like at least resampling and mixing.
This may be done by the use of some
sound server, but most low-end sound
servers do not support the variable
sampling rate, i.e. you can't change
the rate without re-connecting to the
server. Other servers have the
unacceptable latencies.
There are now appearing those modern
sound servers like JACK, which probably
can satisfy our needs, but I haven't
looked into that.
Now that SDL is usually linked in to
dosemu, we can do the mixing/resampling
ourselves as well, and send the output
to SDL too. But SDL doesn't even
provide the ability to query the output
buffer status (the last time I looked),
which is not very good. Though using
SDL for sound looks attractive.
Another thing that have to be changed,
is that the SB emulator have to control
the rate itself, not like it does now -
write to the device until the buffer
is full. Some DOS progs controls the
DMA registers during the sound output,
and that's why we have to guarantee the
smooth transfer and the accurate timing
ourself. For that matter it will probably
be necessary to put the SB and DMA into
a separate thread. But then we also need
a mechanism to make sure our timing is
not out of sync with the underlying device,
and so we have to query the state of the
output buffer and adjust our speed according
to its state. It is probably not easy
to provide an accurate info about the
state of the buffers for the output
software that does the stream mixing,
like SDL, so AFAIK SDL doesn't provide
that info at all.
This all will also require a major
changes in the SB and DMA emulators, as
now they are too OSS-oriented. For example,
to change the speed, currently the sound
code waits for the OSS buffer to became
empty, resets the sound card, sets the
new parameters, and resumes the transfer.
It is obvious to see how difficult and
ineffective it is, and it is really a
big surprise that it works out right most
of the time. Well, thats because I added
a tons of heuristic about choosing an
optimal buffer sizes, tuned it separately
to a hundreds of games, etc. What a
silly timewasting it was, but at the time
of doing this, dosemu was not compatible
with pthreads, and the good enough
sound servers were not even on a horizon
(or at least I wasn't able to find them).
And I also followed the old code that
was there since 1995, instead of just
rewrite everything.
Now it may be wise to finally rewrite
everything from scratch, rather than
hacking with the current code. The fact
that it actually happens to work, must
not confuse anyone.
It may not be difficult to implement,
but only if the architecture is properly
designed. Otherwise it will be just
another time-wasting. That's why
noone even dare to start the work:)
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ide-scsi

[Stas Sergeev]

Hello.
Lars Bjrndal wrote:
How can I use the ide cd-writer as a scsi drive under dosemu?
See README.txt:2.1.8 about how to
configure dosemu for that.
But I am sure noone did that for the
last 5 years or so, so feel free to
let us know how it works, when you are
done:)
Who have the SCSI devices with the
DOS drivers nowadays? Not too many,
I am afraid (may be wrong though).
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commandline switch for changing $_hdimage settings?

[Stas Sergeev]

Hello.
Christian Fischer wrote:
# dosemu -I 'disk { something /path/to/drives/c }'
don't work because of missing the right key for something in the 
global.conf doc.
something should be a directory in
your case. Can also be hdimage,
partition and wholedisk.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: XMS problem with Aladdin demo

[Stas Sergeev]

Hello.
Julius Schwartzenberg wrote:
The (working) version on my laptop seems to be from 26-12-2004.
Oh, that's strange.
Is there anything special I need to do to disable Dosemu's XMS support 
(using the default configuration)?
How one is supposed to disable/enable
something without changing the config? :)
You'll have to alter it by setting
$_xms=(off). Don't forget to also update
your ems.sys and see what diagnostic it
prints on startup. Then update your
config.sys to load himem.sys before ems.sys.
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: XMS problem with Aladdin demo

[Stas Sergeev]

Hello.
Julius Schwartzenberg wrote:
I've already got it working on my laptop in an older CVS version, but 
on my main workstation it quits everytime with an XMS error.
When exactly it stopped to work?
I think it doesn't work also on 1.2.2,
so it is not something recent.
Has much been changed to these sections in Dosemu lately?
Yes. But when and why that game stopped
working noone knows (noone cares either
I think, well, it you can say when it
started to fail, this may still be
somewhat interesting).
What kind things I should try to get this game to work properly?
Disable dosemu's XMS support, use the
native himem.sys...
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DOS's hotkeys and KDE

[Stas Sergeev]

Hello.
Ralph Alvy wrote:
Ctrl-Alt-Home disables the mouse, once it move into the xdosemu window. 
But the KDE keybindings are still in effect.
Does Ctrl-Alt-Home work any better if
you first change the
#undef ENABLE_KEYBOARD_GRAB
to
#define ENABLE_KEYBOARD_GRAB 1
in X.c of dosemu sources and
recompile?
Another thing to try is Ctrl-Alt-f
which will make dosemu to enter
fullscreen mode, where the KDE
keybindings should not be in effect
(no KDE here to try myself, sorry).
-
To unsubscribe from this list: send the line unsubscribe linux-msdos in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html