Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <34504EBC.200@rug.ac.be>
Date: Fri, 24 Oct 1997 09:31:08 +0200
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: DJ Delorie <dj AT delorie DOT com>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: proposal: movedata, dosmemget, etc. replacement
References: <199710232248 DOT SAA06508 AT delorie DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

DJ Delorie wrote:
> 
> > I assume that was caused by the fact that those functions were not
> > implemented at the same time and by different people.
> 
> No, most of them need to be compatible with other implementations.

Sorry, I'm unaware of those. djgpp is for me the only DOS c-compiler. I
don't want to use that commercial stuff because if something is wrong or
buggy, you can't even verify that or correct it.
Why do some software houses make such decision for not adapting the
standard order. We shouldn't make this mistake too.

> Besides, the non-standard ones were all done by me.  

So it seems to me that I called you a nut-case. Sorry about that.

>                                                     So many people
> use the existing order that changing it is no longer an option.

But I think that adding a set of similar functions is not entirely
excluded by this argument. The way of introducing that I proposed give
people the time to update their programs and even later they still only
would have to add an include line in order to have their programs run as
before.

> > Note the unusual order of offset and segment.
> 
> This is an argument against your changes.

You shouldn't put this argument on top of all changes. It is only part
of the changes. If we would agree that (o, s) is not acceptable because
people got too much used to (s: o), this were also acceptable.
Also one LDS or LES instructions could be used which is some cycles
less.

> I think that, overall, we shouldn't add these functions.  All they'll
> do is add yet another set of functions that don't match the other
> functions.  

Thats the most important argument I can find against these changes. And
that's also why I would disable the old ones after some time, like I
suggested.

>                             I'd rather not make significant changes
> to djgpp's core library like these.  Note that the functions you
> suggest replacing have been around for many years, and a *lot* of
> people use them.

The other pro's you didn't mention:
- no cast from ptr -> int. I really hate this! *Very* ugly. Bad, bad,
bad.
- no use of _my_ds ()
- one reload of a segment register less in most cases (memory copy
functions are used a lot)

Of course, I can live with the idea of not changing these functions, but
I think more people should give their opinion, because there are not so
many con's and I presented you a lot of pro's.

May I assume that because you didn't say anything about the selectors
for some area's that this is an appealing idea to you?

Most sincerely, and have a fine day.

-- 
+----------------+
| Vik Heyndrickx |
+----------------+