Re: HToolkit binary compatibility

Wolfgang Jeltsch <[email protected]>
Newsgroups gmane.comp.lang.haskell.gui
Message-ID <[email protected]>
On Sunday, 2003-08-10, 08:58, CEST, Krasimir Angelov wrote:
> Hello Wolfgang
>
> --- Wolfgang Jeltsch <[email protected]> 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 between
> > 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 
remember if it was on the GUI list).

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

> Krasimir

Wolfgang

¹) This assumes that the stack, the global data and the heap all resided in 
the data segment. I'm not completely sure if this was the case in the small 
model.
²) Again, I don't know exactly if this was the case. I used to think so but in 
the last discussion on this topic someone told me that this is, at least, not 
enforced by ANSI C.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.