freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] FT_PtrDist is badly defined and should be abolished


From: Antoine Leca
Subject: Re: [Devel] FT_PtrDist is badly defined and should be abolished
Date: Fri, 15 Oct 2004 15:30:35 +0200

Hi Graham,

On Wednesday, October 13, 2004 08:43, Graham Asher va escriure:
>
<David>
>> This won't work on 64 bits systems, and these are becoming more
>> common, thanks to AMD and game developers :-)
>
> There are two points I'd like to make here. First, surely it *will*
> work on these systems, because 'long' would be 64 bits?

(Unfortunely) No. Microsoft did a (stupid) precedent by deciding for Win64
that int *and*long* will stay at 32 bits (certainly they have their reasosn,
such as too much code that assume that long is 32 bits: I remember seeing
_a_lot_ of APIs in Windows where the parameters were chosen as LONG when INT
would have been plain correct and even compatible bvetween Win16 and Win32;
certainly they do not want to burden their customers by requiring another
transition when the one between Win16 and Win32 were painful.)

The *nix guys, who did experiment (for a while) with 64-bit OS and
portability through the transition for a while, did conclude that the best
thing to do was to use 32-bit int and 64-bit long (the so-called LP64
model); this was clear by 1998, early 1999 (there are good reasons why I can
give such a date). Yet others believe they know better. And it happens that
these others own a good share of influency.


> Secondly, when I said "It is inconceivable that this code
> would ever have to handle pointer distances unrepresentable by a
> 'long' " I was thinking not of the full address range of the system,
> but of the size of Type 1 font files; I refuse to believe in a font
> file of any type as long as 2^32 bytes.

I agree with you on this second point. In other words, and when we refer to
current (hybrid 32/64-bit) architectures, anything that embeeds a font
engine and hence FreeType, can work very well with an (old-fashionned)
32-bit model.

Yet I suspect David is thinking about another class of devices (next
generation? I do not know this market, perhaps they are here right now),
which are full 64-bit, with no or poor support of 32-bit arithmetic. Such
devices may very well target the game industry (where 64-bit are common for
handling graphics). OTOH it is clear that such devices will have long (and
probably int as well) as 64-bit, so there is no problem, even if the
programming template is a reincarnation of DirectX.


Antoine






reply via email to

[Prev in Thread] Current Thread [Next in Thread]