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 to subscribe you to dosemu-cvs now under your list.ru address.
>> 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 a warning for the default config.
> Is this because something is not properly implemented?
> I mean, the properly_implemented_e_invalidate(addr, len)
> should see if that range should be invalidated, and if not -
> just do not do anything at all. Not even unprotect. With
> the proterly_written_dosaddr_to_unixaddr() you will not
> get trapped, no matter what. So that's how I see it, or am
> I expecting too much from the current code? :)
OK. I think I understand what you mean. I'll change e_invalidate to
have addr as a DOS address (i.e. unsigned int), and then it can do the
right thing.
> If we are talking about hundreds or thousands, then yes,
> this was the only way to go... But if there are just a few, why
> not to fix them?
That's indeed the case, there were too many, and a few conversions got
me tangled up and then I just ran out of time, and wanted to get
things working first. So this, as you could call it "ugly transitional
helper code" is still there.
>> One problem is that there are still quite a few places that don't use
>> the READ_BYTE (etc) macros, and take pointers directly into DOS space
>
> That's horrible... how much of them are still in?
Too many.. Do a grep for MK_FP32 and Addr (an older alias for
MK_FP32). These macros are the main culprits for the &mem_base[xxx]
pointers. Note: when MK_FP32 does the right thing we'll also need to
change FP_OFF32 and FP_SEG32!
> Yes, you would first need to adjust them to be integers instead of
> pointers, but I guess, as a quick hack, you can just implement
> lowmemp() as follows:
> char *lowmemp(void *fuckedup_dos_addr)
> {
> return dosaddr_to_unixaddr((int)fuckedup_dos_addr);
> }
that would be dosaddr_to_unixaddr(fuckedup_dos_addr-mem_base) -- but I
get your point.
Then it's basically the same thing as the
LINEAR2UNIX(fuckedup_dos_addr-mem_base) that I mentioned a few emails
ago.
> Great! Good that an app can't get a base directly, like it can
> get the limit with lsl.
Yes, exactly, that's why the trick works.
Bart
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Dosemu-devel mailing list
Dosemu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dosemu-devel
