[gs-devel] display device on 64-bit platforms

[Stefan Kemper]

Hi Russell, 

On Wed, 2003-03-19 at 01:43, Russell Lang wrote:
> The display device has a parameter DisplayHandle which is passed 
> to callbacks.  This is set by the caller and allows the caller 
> to identify the ghostscript and display device instance.

I'm confused, why do you want/need a 64 bit identifier?  
Looks like you are really passing a 64bit void pointer.  

> DisplayHandle is currently set from display_get_params as a 
> long.  This means the caller usually sets it by
>   sprintf(buf, "-dDisplayHandle=%d", (long)ptr);
> This does not work on 64-bit platforms because PostScript 
> integers are only 32-bits long.  You also have to use a signed 
> value for a pointer which is confusing.

If you are passing something to the display device then the -d and -s
device parameter mechanisms are the method.  

Why must this be set before gsapi_init_with_args()?  
This implies that you have a coupling with the interpreter.  I'm not
fond of Set functions that have temporal restrictions.  Get/Set usually
imply restriction free functions.  Init is a better name for this kind
of function. 

In this case I would go with method 2.  The general contract for -s and
-d is that it shouldn't have temporal or external coupling issues.  
 
> Some possible fixes:
> 1. Add DisplayHandleHigh for the upper 32-bits.  Backward 
> compatible, but messy.

little endian, big endian, this isn't a good idea.

> 2. Add a new api 
> GSDLLEXPORT int GSDLLAPI
> gsapi_set_display(gs_main_instance *instance,
>     display_callback *callback, void *handle, 
>     unsigned int format);
> This will set the value for the handle before 
> gsapi_init_with_args.  Some code needs to be added to copy the 
> callback, handle and format when the display device is copied 
> from the static instance. This is not backwards compatible, but 
> is the method I used for my proposed GhostPCL changes.
> 3. Use method 2, but if DisplayHandle is ever set to non-zero, 
> use that in preference to the value from gsapi_set_display.  
> This an attempt at backward compatibility.


How about you use 2).  1 and 3 only work in a gs only environment, if
you want to have backward compatibility here then first check the
platform for 64 ptrs before allowing -dDisplayHandle to overwrite a null
gsapi_set_display() 

This seems like a hack.  For 32bit pointer systems running gs you can
use the old method, otherwise the new method must be used.

My choice is to break it. whats the cost to your customers?

> If we make some non-backward compatible changes, it might be a 
> good idea to fix another problem - the calling convention for 
> the display callbacks are C, rather than the more portable 
> GSDLLCALL (which is __stdcall in MSVC++). This sort of problem 
> makes it impossible to use the display device from VB.

Gag, you want to use pascal calling convention, and allow VB.  
You have offended the gods of unix :)

Seems like all the DLL functions and their callbacks should use the same
calling convention, now whats the hidden cost, I'm I going to see the
GSDLLCALL sprinkled throughout the code

> So my question are:
> Who would be affected by such a change?

No idea.

> Any particular preferences for the fixes, or other ideas?


How goes the linux display version?

-Stefan