Well, this has certainly got discussion going at least :)<br><br>@All<br><br>Apologies for any confusion, I didn't get a choice in my name (in fact, it was very nearly Michael so I may have been confused with you Brother Michael rather than Shane of GEM fame :P). If it helps refer to me as ShaneG or ShaneNotGEM :)<br>
<br>@David<br><br>For portability support GCC/GAS is almost a must. Between them they cover almost all available OS's and platforms. DJGPP comes with a DOS extender (is it GO32 or something similar? I don't recall off the top of my head). In any case, support for DJGPP will restrict the PC processor to a 386 or better - maintaining support for previous processors (at the VDI/AES level at least) would be difficult. This would mean a new implementation of VDI and AES that is fully 32 bit and protected mode aware. You could use 'thunking' (the way WIN32 was supported on Win31) but it would add a lot of complexity which would be better to avoid. How would existing (binary only) GEM applications run on top of this?<br>
<br>As for video support - on DOS the VESA interface would probably be easiest (there are third party TSR's that provide additional support for Non-VESA or Minimal-VESA cards). On Linux the standard Framebuffer interface would work reasonably well. As I mentioned in an earlier email - 2D accelleration would be up to the VESA implementation and 3D accelleration would be non-existant.<br>
<br>@Ben<br><br>I was wondering about the Atari GEM implementation as well. Ideally it should be supported as part of any standard API (from the documents I have read there is little functional difference between the TOS/DOS implementations of the GEM API). I don't know enough about it to say how easy it would be to port applications from Atari GEM to other GEM - from what I gather the TOS API is not exactly POSIX like (neither is DOS for that matter). Is there the equivelant of GCC (and it's standard C library) for TOS? If that's the case it should simplify things (excluding those applications that make explicit use of Atari only hardware functions). I haven't found a reasonable Atari emulator and development tools to do any testing on yet (I haven't looked that hard either though). I do have an Atari 520ST stashed away in the cupboard though - apart from playing a couple of games on it I haven't done much else.<br>
<br>@Peter<br><br>GEM (specifically OpenGEM) as it stands is great on legacy PC hardware (which is becoming more difficult to find). It's fun for those who are interested in nostalgia when running on DosBOX or something similar. But as a day to day platform for any purpose it is not really much use (yes, I know there are web browsers, news readers etc available - a lot of people have done a lot of work). But is GEM of any use in the long run on non-PC (or non-Atari) hardware? I work with embedded hardware (both commercially and for fun) and there are times when I would like a nice simple UI to plug in which doesn't have a large memory or disk footprint, is simple to program and provides a reasonably pretty interface - I think GEM would fulfill that goal.<br>
<br>@All<br><br>Anyway - as I have stated previously I have created the 'gemapi' and 'gemix' projects on SourceForge. I'm happy to hand over control of the 'gemapi' project to those with more of a history (and more experience) with GEM. I intend to continue with the 'gemix' project as a 'GEM like' (at the very least) implementation of the GEM API for the Linux kernel (initially, ideally it should work on any POSIX compliant system that someone can provide a VDI implementation for). SourceForge does provide for webspace as well so maybe the 'gemapi' project would be a reasonable place for a documentation Wiki and other developer style information?<br>
<br>What does everyone think?<br><br>