[GEM Development] [GEM-DEV] GEM 32

[Peter R Green]

A couple of times in the past, I asked questions about what everyone saw 
as the purpose of GEM development: where should it go, and how might it 
best be used. I am not sure that we have made much progress along that 
path even now.

This is not to denigrate the work that many of the more technical people 
have done to refine the current form of GEM, and make it more robust and 
consistent.

I think it was 1992 when I first joined the group; Ben had just released 
a new desktop; Robert Avon had recently set up a website as a repository 
for everything Digital Research as had the chap from Scandinavia who 
died, and John was shovelling away in the GEM basement working on the 
underpinnings.

GEM has come a long way, and OpenGEM has moved on quite a bit since I 
last looked in at Shane's work.

But David's comments suggest that some of those basic philosophical 
questions still need to be addressed.

Personally, I used GEM for a short while as a DOS front end on a '386 I 
was using mainly for experimental purposes, and then tried it out 
briefly in conjunction with Desqview-X before other projects took up my 
attention. I also used ViewMAX as a file manager in OS/2 for most of the 
time I used that OS. I was always happier with it than with OS/2's 
native file manager. But both uses are a long way in the past now...

Peter

David Ormand wrote:
> I have been thinking about this for some time also.
>
> My interest is maintaining GEM as _the_ GUI for DOS.  Having GEM under 
> Linux is fine, and a great alternative to X, but not if it moves it 
> away from being useful under DOS.
>
> Now, seems to me if you move towards Linux, you are moving towards 
> using GCC.  We already have a GCC for DOS, namely, DJGPP.  Seems to me 
> the first step is "porting" GEM to compile using DJGPP.  From what 
> I've heard, this could be a bit of a challenge, since GEM/AES/VDI are 
> kind of a "mixed bag".  I've got the sources, but I haven't looked at 
> them carefully.  If GCC/DJGPP is too difficult, OpenWatcom can 
> generate 32-bit code for both DOS and Linux.  And Windows, like CygWin 
> or MinGW.  I don't think a 16-bit compiler like Borland is the right 
> path to 32 bits.
>
> A public-domain OS like MMURTL is interesting, but we already have 
> FreeDOS and Linux OSes (and BSDs), and anyways, it appears that MMURTL 
> involves the use of yet another non-standard (and apparently non-free) 
> compiler.
>
> Any of the old-timers, was there ever an attempt to "standardize" the 
> build environment on something up-to-date or in common use?
>
> Seems the next step then is taking advantage of the native 32-bit 
> video resources.  Under Linux, there are the wide array of device 
> drivers.  Under DOS, there are various graphics libraries, such as GRX 
> or MGRX, that already have DJGPP ports.
>
> I realize this hand-waving in ignorance is easy, but any project would 
> have a better chance of success of attracting participants with a 
> clear path and objective.  I know I would enjoy participating!
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> gem-dev mailing list
> gem-dev at simpits.org
> http://www.simpits.org/mailman/listinfo/gem-dev
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.698 / Virus Database: 270.14.54/2488 - Release Date: 11/08/09 10:52:00
>
>