X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1567357830;
	bh=MdQwq4lFDW49RBkVM2UMSVkZsoK6L1vrCokQqvbZ0wk=;
	h=In-Reply-To:From:Date:References:To:Subject:Message-ID;
	b=V9DECDDg+rRzA6Mb62IFWamXjOMtO0jD0Wxw+7FPiTf+LqN8q6AXU1B3DdfWcI1T2
	yeF3DIsxgOZD9MiL04iLiKaC5GOEkWPcJyL3PrzOvujFT5JSYm4syk6wBpBCOmb/n+
	D8/mb4g/8Yu/Ak71vFM33S/z1nd2w+UkajxsiCsA=
Authentication-Results:	mxback20g.mail.yandex.net; dkim=pass header.i=@yandex.ru
Subject:	Re: cwsdpmi borland compatible? possible! (Re: [PATCH] exec: fix
	inversions in leak detection logic)
To:	djgpp AT delorie DOT com
References:	<964e3268-2f75-ee73-ab5a-b01bf1aadb98 AT yandex DOT ru>
	<qjb14m$1kqj$1 AT gioia DOT aioe DOT org>
	<7209026e-1f1b-e590-00a3-4ed1a424cc0d AT yandex DOT ru>
	<qjfkbp$1o2c$1 AT gioia DOT aioe DOT org>
	<bd347f78-b176-6992-291c-2e542241efa1 AT yandex DOT ru>
	<d97686df-50ba-5210-519a-abd80f2d190f AT yandex DOT ru> <838sr87yty DOT fsf AT gnu DOT org>
From:	"stsp (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Message-ID:	<3b801070-ac73-11a5-9053-905e906bc533@yandex.ru>
Date:	Sun, 1 Sep 2019 20:10:29 +0300
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Thunderbird/60.7.0
MIME-Version:	1.0
In-Reply-To:	<838sr87yty.fsf@gnu.org>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id x81HB8cb003691
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

01.09.2019 19:42, Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com] 
пишет:
>> From: "stsp (stsp2 AT yandex DOT ru) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
>> Date: Sun, 1 Sep 2019 19:07:49 +0300
>>
>> Now the question is: does anyone here think it would
>> be a good idea to make cwsdpmi borland-compatible?
>> (and MS-compatible, and whatever else)
> Are there any downsides?
>
> Also, how large would the changes be?

You mean, of implementing 0xc00 and 0xc01?
These are the functions from DPMI-1.0 spec and
I don't expect any downsides at all. Besides them,
I also need a very small extenstion that allows the
16bit clients (most borland clients are 16bit) to
access the 32bit DPMI API if code segment is 32bit.
There should be no downsides too as my program
explicitly queries for that extension (I called it
"THUNK_16_32") and it should be enabled only
after the query.
The changes of implementing the above should
be minimal (but of course only Charles may know
for sure).

If you ask for the downsides of the borland support
itself - well, bugs may create many downsides, and
they will. But no one is forced to run my program.
If they want the borland compatibility, then they run it.
Its not a part of cwsdpmi binary. Its a djgpp-compiled
app. You can compile it and run even now, but under
cwsdpmi it will complain for the unimplemented funcs,
and just exit. If missing funcs are added (for no downsides),
I can continue to work on it. In fact I can continue
even now, under different DPMI hosts, but w/o any
confidence that this will later work under cwsdpmi,
I don't see the point. "Different DPMI hosts" are already
borland-compatible, so for them I do nothing good,
and in fact the hdpmi author was not very pleased
by the fact I even write that, as this could suddenly
make the simple dpmi hosts like cwsdpmi just as
capable as his own. :)

- Raw text -