30.05.2012 05:33, Bart Oldeman wrote:
>> What do you think about the MMAP_PAGE_ZERO personality
>> instead?
> It looks blocked (try setarch -Z dosemu.bin), otherwise it would be
> too easy to bypass :)
Hmm? Works perfectly for me, but doesn't do the trick
unless mmap_min_addr is set to zero or you
On 29 May 2012 15:42, Stas Sergeev wrote:
> 29.05.2012 07:01, Bart Oldeman wrote:
>>
>> machine in DOS days. And if you have an older computer, just use a 32
>> bit kernel and set mmap_min_addr to 0 and things still work (with a
>> security risk -- unplug the network if you're paranoid).
>
> What
29.05.2012 07:01, Bart Oldeman wrote:
> machine in DOS days. And if you have an older computer, just use a 32
> bit kernel and set mmap_min_addr to 0 and things still work (with a
> security risk -- unplug the network if you're paranoid).
What do you think about the MMAP_PAGE_ZERO personality
inste
29.05.2012 07:01, Bart Oldeman wrote:
> I now realise that the person who sent you the mail must have missed
> the message:
>
> Using CPU emulation because vm.mmap_min_addr > 0.
> For more information, see /home/bart/.dosemu/boot.log.
Wait, wait, haven't YOU changed this to warning, so that it
does
On 26 May 2012 09:25, Stas Sergeev wrote:
> 26.05.2012 16:48, Bart Oldeman wrote:
>>
>> On 26 May 2012 08:05, Stas Sergeev wrote:
>>>
>>> And I already have the mail like "why dosemu is running fast
>>> as root, and is slow running as user". I think this change should
>>> be undone. Yes, the non-ze
27.05.2012 15:08, Eric Auer wrote:
> A while ago, Ubuntu included a config snippet to
> set mmap_min_addr to 0 if Wine or Dosemu packages
> were installed, do other distros tend to do the
> same or do people often have to manually config?
Most distros do not include dosemu, and wine can
now use dos
Hi! Just a short comment: One of the cool things
about DOSEMU is that it lets you run DOS apps on
your real CPU without emulating the CPU, so I do
appreciate attempts to make users aware of how to
configure things to make that possible instead of
just falling back to virtual CPU mode :-)
Whe
26.05.2012 16:48, Bart Oldeman wrote:
> functions as follows:
>
> in prepare_ems_frame:
>
> static const u_short unmap[] = {0x, 0, 0x, 1, 0x, 2, 0x,
> 3};
> if (MSDOS_CLIENT.ems_map_buffer == NULL)
> MSDOS_CLIENT.ems_map_buffer = malloc(emm_get_size_for_page_map());
26.05.2012 16:48, Bart Oldeman wrote:
> On 26 May 2012 08:05, Stas Sergeev wrote:
>> And I already have the mail like "why dosemu is running fast
>> as root, and is slow running as user". I think this change should
>> be undone. Yes, the non-zero lowmem base is a great work,
>> cheers and regards,
On 26 May 2012 08:05, Stas Sergeev wrote:
> And I already have the mail like "why dosemu is running fast
> as root, and is slow running as user". I think this change should
> be undone. Yes, the non-zero lowmem base is a great work,
> cheers and regards, but, as long as it is hopelessly slower tha
14.04.2012 21:51, Bart Oldeman wrote:
>
>>> When mmap_min_addr>0,
>> ... or selinux is enabled.
>> You need to adjust an error message to take this into
>> account. I was very confused when set mmap_min_addr
>> to 0 yet still receiving the error from dosemu.
> OK. I also changed the error to be
17.04.2012 04:39, Bart Oldeman wrote:
> I put up a git repository that is a mirror of the svn:
> git clone git://dosemu.git.sourceforge.net/gitroot/dosemu/dosemu
Another small wish here: please, strip the trailing spaces! :)
-
21.04.2012 16:04, Eric W. Biederman wrote:
> Well you could always start a project to write native 16bit programs to
But the problem is with the 32bit programs, if they
happen to use the 16bit stack for some crazy reason.
> I thought it was an Intel bug?
The clever history books say that AMD once
Stas Sergeev writes:
> 19.04.2012 06:05, Eric W. Biederman wrote:
>> So let me point out that Andi is no longer the x86_64 maintainer,
>> and one of the big policy changes that happened with the turn over in
>> maintainership is that workarounds for weird cpus bugs (if the can be
>> implemented c
19.04.2012 06:05, Eric W. Biederman wrote:
> So let me point out that Andi is no longer the x86_64 maintainer,
> and one of the big policy changes that happened with the turn over in
> maintainership is that workarounds for weird cpus bugs (if the can be
> implemented cleanly) are now considered.
>
Bart Oldeman writes:
> On 16 April 2012 17:30, Stas Sergeevwrote:
>> Ah, that explains most of everything... :((
>> Have you considered the $_cpu_emu mode that will
>> emulate v86 and 32bit prot mode with 16bit stack, and
>> nothing more? My guess is that the app does'n work
>> too much with such
17.04.2012 16:23, Bart Oldeman wrote:
> On 14 April 2012 07:17, Stas Sergeev wrote:
>> I've just had a look into a possibility of using
>> LOWMEM() for the mappers, eliminating the
>> special meaning of MAPPING_LOWMEM and
>> MAPPING_HMA, which are adding lowmem_base
>> to the source. The mappers c
On 14 April 2012 07:17, Stas Sergeev wrote:
> I've just had a look into a possibility of using
> LOWMEM() for the mappers, eliminating the
> special meaning of MAPPING_LOWMEM and
> MAPPING_HMA, which are adding lowmem_base
> to the source. The mappers can use LOWMEM()
> explicitly, instead of usin
Hi,
17.04.2012 04:39, Bart Oldeman wrote:
> On 16 April 2012 17:30, Stas Sergeevwrote:
>> Ah, that explains most of everything... :((
>> Have you considered the $_cpu_emu mode that will
>> emulate v86 and 32bit prot mode with 16bit stack, and
>> nothing more? My guess is that the app does'n work
>
On 16 April 2012 17:30, Stas Sergeevwrote:
> Ah, that explains most of everything... :((
> Have you considered the $_cpu_emu mode that will
> emulate v86 and 32bit prot mode with 16bit stack, and
> nothing more? My guess is that the app does'n work
> too much with such a setup, so maybe the slowdow
16.04.2012 22:18, Bart Oldeman wrote:
> which saved value?
>
> Anyway there are a few issues for x86-64:
> - you can't sigreturn() to DPMI code (i.e., the indirect DPMI switch,
> "call sigreturn()" or dropping out of a signal handler), because that
> involves calling SYSCALL which destroys %ss. The
On 16/04/2012, Stas Sergeev wrote:
> Then maybe you should at least check whether the saved
> value was actually zero, and print an error if not.
which saved value?
Anyway there are a few issues for x86-64:
- you can't sigreturn() to DPMI code (i.e., the indirect DPMI switch,
"call sigreturn()" o
16.04.2012 16:31, Bart Oldeman wrote:
> For x86-64 dosemu jumps to DPMI code using the "iretl" instruction
> that is valid in userland and pops all of eip, cs, eflags, esp, and ss
> (that's its behaviour in long mode). However, if the popped cs is a
> selector to a 16-bit PM segment, the high 16 bi
16.04.2012 16:39, Bart Oldeman wrote:
> I'm not sure I like this approach. Now two handles are permanently
> allocated, visible by "mem/e", etc.
There is a functionality called "handle attributes", which is
basically not used.
If 2 visible handles are a big concern, we can invent some
clever attrib
16.04.2012 16:39, Bart Oldeman wrote:
> I'm not sure I like this approach. Now two handles are permanently
> allocated, visible by "mem/e", etc.
Well, I am afraid there are not too many ways around this.
You either permanently allocate (and how would one handle
be better than 2 handles with this re
On 16 April 2012 06:47, Stas Sergeev wrote:
> And you are working around of the lack of git: I would
> otherwise send it as a patch-set myself. :)
I've been playing with git, it will come ;)
> Fortunately, there is a better way of solving this, also japheth
> have suggested it in the past.
> With
On 16 April 2012 07:05, Stas Sergeev wrote:
> Oh, and while I was touching this part, could
> you please also explain how dpmi_setup() now works,
> I mean its mmap() looping. What is the magic here?
For x86-64 dosemu jumps to DPMI code using the "iretl" instruction
that is valid in userland and po
Oh, and while I was touching this part, could
you please also explain how dpmi_setup() now works,
I mean its mmap() looping. What is the magic here?
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to
Hi,
16.04.2012 02:52, Bart Oldeman wrote:
> I had a good look at your EMS patch and applied some of the more
> innocent portions
And you are working around of the lack of git: I would
otherwise send it as a patch-set myself. :)
> -- but there is something wrong with the changed
> msdos.c interfa
Hi Stas,
I had a good look at your EMS patch and applied some of the more
innocent portions -- but there is something wrong with the changed
msdos.c interface: from what I see:
before:
the EMS page frame was unmapped (mapped to lowram),
with your patch:
msdos.c reserves 4 EMS pages (=64k), and t
14.04.2012 21:51, Bart Oldeman написал:
> On 14 April 2012 04:27, Stas Sergeev wrote:
>> I was always subscribed there, I checked that many
>> times, and the mail delivery knob was set to enabled.
>> Yet you said I was somehow unsubscribed because
>> of the bounces, and that was true: delivery didn
On 14 April 2012 07:17, Stas Sergeev wrote:
> Would it be possible to remove an outdated flags,
> and use the new API instead? I.e. move the MAPPING_SCRATCH
> handling from mmap_mapping() to alloc_mapping(),
> use alias_mapping() instead of MAPPING_HMA|MAPPING_LOWMEM
> etc, so that mmap_mapping()
On 14 April 2012 04:27, Stas Sergeev wrote:
> I was always subscribed there, I checked that many
> times, and the mail delivery knob was set to enabled.
> Yet you said I was somehow unsubscribed because
> of the bounces, and that was true: delivery didn't work
> until I posted to the list.
I tried
14.04.2012 06:25, Bart Oldeman написал:
> well I agree things should be cleaned up for sure. As far as I can see
> LOWMEM() is only used in a few places -- it could be completely
> removed.
I've just had a look into a possibility of using
LOWMEM() for the mappers, eliminating the
special meaning of
14.04.2012 06:25, Bart Oldeman написал:
> you should be able to subscribe using
> https://lists.sourceforge.net/lists/listinfo/dosemu-cvs
I was always subscribed there, I checked that many
times, and the mail delivery knob was set to enabled.
Yet you said I was somehow unsubscribed because
of the
On 12 April 2012 16:09, Stas Sergeev wrote:
>
> I havent noticed: wasn't writing anything.
> Actually, I was unsubscribed from the list, as
> you explained, because of the bounces.
> Now obviously to re-subscribe the one only
> need to post to the list. After my today's post
> I started to receive
12.04.2012 20:34, Bart Oldeman написал:
> Hello Stas,
>
> First of all I'm sorry for my general non-responsiveness, I've just
> been busy in general.
I havent noticed: wasn't writing anything.
Actually, I was unsubscribed from the list, as
you explained, because of the bounces.
Now obviously to re-
Hello Stas,
First of all I'm sorry for my general non-responsiveness, I've just
been busy in general.
> 3. Make a fully functional dosaddr_to_unixaddr(), not just
> a quick hack it currently is. It should use the proper reverse-mapping
> maintained by mapping.c, instead of relying on a "map_char
Glad you got it to work then, all the legacy code still left must make
it hard to change anything without breaking something else.
On Thu, Apr 12, 2012 at 8:24 AM, Stas Sergeev wrote:
> Hello.
>
> I needed to run some commercial DOS-based multitasking
> environment recently, which doesn't work
Hello.
I needed to run some commercial DOS-based multitasking
environment recently, which doesn't work under dosbox.
It implements the memory context switching by the use of
EMS. dosemu doesn't support this, but it was easy to implement,
so the patch is attached.
There is still a problem with this
40 matches
Mail list logo
