Font_ApplyFields problem

[Tony van der Hoff]

On 7 Nov 2001, in message <620cccd54a.druck at druck.freeuk.net>,
David J. Ruck <druck at freeuk.com> wrote:

> Ah now that is a good point, I must say I hadn't considered. You usually
> expect 3rd party libraries to be self contained (or at the very most
> requiring linking against standard C lib stubs) and it may not be obvious
> it was only partially linked against OSLib, if you are also using OSLib.

I don't think I'd expect 3rd party libraries normally to be self-contained;
by definition, a library is only a collection of compiled objects, possibly
using another library's (probably stubs') headers; it can never be -partially
or otherwise- linked against anything. 

OSLib itself is, of course, self-contained; it sits at the bottom of the
dependency tree, like stubs. That is unusual, and most third-party libraries
will depend upon something else, as does, for instance, OSLibSupport, which
depends on both OSLib and stubs.

Such a library may, of course, be made self contained by embodying object
modules extracted from the libraries upon which they depend, such as OSLib,
but I've never heard of anyone doing that, and believe it would probably
contravene the GNU GPL to do so; I have never been asked for permission for
anyone to do such a thing, and am unaware of Jonathan having given such
permission before me. It would almost certainly contravene any commercial
license, such as that for stubs.

[snip]
> 
> Even though OSLib strives to be binary compatible, it would only take
> something line a fix to ensure return parameter is updated when previously
> it was not to break some code. 

Duh?

However, your warning is certainly appropriate, although I can't imagine,
under the proposed scheme, how things can be made to fail.

If a 3rd party library *internally* uses 8-bit handles, then it will continue
to link using os_f from OSLib, which is, until we turn it off, going to be an
8-bit function. You would call that library broken, and in the long term it
may fail. That, I'm afraid, is SEP.

If, on the other hand a 3rd party library exports an os-f in its interface,
then any module which is recompiled using its header will see it as an os_fw
due to the name translation. This will fail to link, as the 3rd party library
doesn't know about os_fw. The module in question must be recompiled with
OSLIB_F8 defined. 

There is the somewhat dodgy case, where a hacker has cast an os_f into a
byte, or worse, copied a byte into an os_f, which will both silently
compile, but quite honestly, I believe this is beyond the scope of OSLib's
responsibility.

I think first two are the only two cases where a problem may arise; if you
can think of others, please let us know. 

And so it came to pass that once again all was peaceful in OSLib land. All
differences were resolved, and everyone lived happily ever after... :-)

-- 
Tony van der Hoff         | MailTo:tony at mk-net.demon.co.uk
                          | MailTo:avanderhoff at iee.org
Buckinghamshire, England  | http:www.mk-net.demon.co.uk