[GEM Development] GEM not going forward... Comments?

[Olivier Landemarre]

Shane Gough a écrit :
> Hi Michael,
>
>   
>> I think, it should not be impossible to build a 32-bit GEM. Pointers
>> used in the API are pointer to a typedef struct. eg:
>>
>> EXTERN WORD appl_find( CONST BYTE FAR *ap_fname );
>>
>> The same ist with the VDI. From the view of the application, it should
>> bo no problem and the Atari GEM proves this.
>>     
>
> In PC-GEM at least the VDI parameters are treated as an array of WORD
> values and the corresponding C structures are all aligned on WORD
> boundaries. Is this the same on Atari GEM? For some 32 bit processors
> this is non-optimal and a portable 32 bit GEM would have to take that
> into account.
>   
At my know, this is not a problem.

One important diffrence you can have trouble, is probably with RSC 
files, XaAES or MyAES as I know (for MyAES I'm sure), not support little 
endian RSC format (if you know how I could know, how recognize little to 
big endian RSC file I'm interesting, I could add this in MyAES)

>   
>> I am afraid, a GEM for Linux will come a little bit late. Yes, it can
>> be a nice lightweight GUI. But most small Linux systems with GUI have
>> enoughr power for X and use X with a toolkit.
>>     
>
> X is still fairly heavyweight. One application I thought of was a VDI
> driver that used a VNC framebuffer to provide a remote GUI on small
> systems that have no local display.
>   
Yes It's what I wan't to do, today problem is VDI that is not easy to 
write, if someone have already done this, please contact me!

> Regards,
> Shane
> _______________________________________________
> gem-dev mailing list
> gem-dev at simpits.org
> http://www.simpits.org/mailman/listinfo/gem-dev
>
>   

Olivier