[GUI] Re: HToolkit binary compatibility

[Wolfgang Jeltsch]

On Sunday, 2003-08-10, 08:58, CEST, Krasimir Angelov wrote:
> Hello Wolfgang
>
> --- Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
> > at the moment, the different C backends of HToolkit use different types
> > for, e.g., windows handles. In my opinion it would be better if the same
> > type (e.g. char *) would be used with all backends and conversions betw=
een
> > the common type (char *) and the native type (e.g., GtkWidget * or HWND)
> > would be made internally.
>
> The HWND type is defined as (void *) in the windef.h header. Is there any
> hardware platform where different pointer types have different internal
> representations?

Hello Krasimir,

there was a little discussion about this topic some time ago (but I don't=20
remember if it was on the GUI list).

I think, the different pointer types will be handled the same on most=20
platforms but I suppose that there is no guarantee for this behaviour. In o=
ld=20
times when we used MS-DOS we had severeal memory models (or whatever they=20
were called). In the small model, for example, one had several code segment=
s=20
but only one data segment. In this model, pointers to functions were 32 bit=
=20
wide (16 bit for the segment address, 16 for the offset address) while=20
pointers to variables were only 16 bit wide (just 16 bit for the offset=20
address)=B9). If void * was realized such that function pointers as well as=
=20
data pointers could be safely cast to void * and back=B2) then the size of =
void=20
* had to be at least 32 bit. So void * and char *, for instance, didn't hav=
e=20
the same representation.

> Krasimir

Wolfgang

=B9) This assumes that the stack, the global data and the heap all resided =
in=20
the data segment. I'm not completely sure if this was the case in the small=
=20
model.
=B2) Again, I don't know exactly if this was the case. I used to think so b=
ut in=20
the last discussion on this topic someone told me that this is, at least, n=
ot=20
enforced by ANSI C.