[GEM Development] [GEM-DEV] GEM 32

Mon Nov 9 08:42:53 PST 2009

AEEeeehh! (faint)

Oh. There ARE _TWO_ Shanes on this list. (very embarrassed emoticon).

I'd write more but
i) I need to recover
and
ii) it's going to be 70ish (here in Chicago this Sat.) SO I'm getting OUT!

Tom C

--- On Sat, 11/7/09, Shane Gough <goughsw at gmail.com> wrote:

> From: Shane Gough <goughsw at gmail.com>
> Subject: Re: [GEM Development] [GEM-DEV] GEM 32
> To: "GEM Development" <gem-dev at simpits.org>
> Date: Saturday, November 7, 2009, 9:33 AM
> Hi Thomas,
> 
> I owe you an apology as well - I didn't mean to go off
> on rant like that.
> 
> There seems to be a little confusion (mainly because of my
> name I guess) - I am NOT the same Shane that is responsible
> for ShaneLand OpenGEM. My net contribution to GEM (both
> commercial and open source) is limited to the posts I have
> made on this list. I have a handful of sample code I've
> written to test various ideas but none of it has ever been
> made public. So as you originally said all of this is in my
> minds eye - I just wanted to point out that I did not
> indicate anything else (the coincidence of my name and that
> of a major GEM contributor being the same has only just
> clicked).
> 
> 
> In terms of project I was not thinking of creating a new OS
> - my idea was to make a version of GEM that ran on a
> different OS (it already runs on two - DOS for IBM style
> machines and TOS for Atari's). The UI is not really tied
> to the underlying OS services (even Windows has a limited
> level of separation that can be replaced - that's how
> some 'skins' are implemented). Linux (or Unix based
> systems in general) are more flexible in that regard (and
> being open source - a lot easier to figure out how to do
> it). I did some research into the MMURTL stuff you mentioned
> (and it does look good - for anyone interested in
> implementing their own OS it would be a great start). The
> Linux kernel makes sense to me because there is hardware
> support for most of the devices I need as well as the
> underlying OS type stuff (threads, filesystems, networking,
> etc) so I can just concentrate on the UI stuff.
> 
> 
> The 'objectifying' stage was an idea to modernise
> GEM applications and ease porting. Basically if I could take
> existing code for a current application, convert it to use
> an OO framework and still have it work under
> 'classic' GEM then it should be a lot easier to
> convert that to a 32 bit version of GEM. There are a lot of
> assumptions in the GEM programs I have read through though -
> GEM Paint for example will crash if the active video mode is
> more thank 64K (in terms of width * height * bytes per
> pixel) - it assumes that 64K is the biggest chunk of memory
> that can be dealt with.
> 
> 
> A downside to many experienced GEM developers is that I
> would like to change the names of many functions (for
> example: The VDI function for 'Open Workstation' -
> op code #1 - would become vdiOpenWorkstation() as opposed to
> the recommended v_opnwk() - a lot easier to read and
> understand what it's doing).Most modern compilers (even
> the freebie ones available for DOS) are no longer limited to
> 8 character unique identifiers so there is no longer any
> need to truncate or abbreviate as much. As I am converting
> the function names I am also working on an automated
> translation script (using awk mostly) to help in the process
> if converting existing code.
> 
> 
> So - to progress on more realistic terms I've decided
> on the following:
> 
> 1/ Develop a library (including header and implementation)
> for VDI using Turbo C++ 1.01 (available as a legal free
> download from http://edn.embarcadero.com/museum
> - was Borland, now sold off as a separate company).
> 
> 2/ This library will use the 'modernised' function
> names.
> 3/ Develop a set of test applications that exercise all
> known functions in the VDI.
> 
> The code and documentation for this library shall be
> available on the SourceForge site for the 'gemapi'
> project. Help at this stage will probably be best given as
> discussions and criticisms. If you would like to become part
> of the project please create a SourceForge account and
> contact me via that method. I have not set any time period
> for the project so please don't start holding your
> breath :) Once this is basically working I'll start work
> on the AES functions. After that - well, it depends on what
> everyone says.
> 
> 
> Regards,
> Shane
> 
> On Sat, Nov 7, 2009 at 7:15 PM,
> Thomas Clayton <topcatdrc at yahoo.com>
> wrote:
> 
> Shane,
> 
> 
> 
> First and FOREMOST: I, in NO way meant ANY criticism of
> you. I hadn't noticed / realized Bro. Henry had
> mentioned you. If I had, I'd have written more for
> clarifications sake. You have made many good contributions.
> GEM development isn't  - and shouldn't be - ALL on
> your shoulders.
> 
> 
> 
> 
> Second, I was thinking about US as a group. Yeah. There is
> 32-bit processor (an 80386? ;-)  ) available (quite a few
> others, in fact, now  :-)  )
> 
>  and
> 
> wouldn't it be "neato" for GEM to run in a
> manner that took "full advantage" of it (those).
> 
> 
> 
> As a starting point for the 32-bit dream, I'd recommend
> everyone look up "MMURTL". An individual, named
> Richard Burgess, wrote his own 32-bit OpSys back in the
> '90s. It - and its source code! - is (are) now available
> as 'public domain' Sw.
> 
> 
> 
> 
> In the early "00"'s, I went looking for the
> book I'd seen (he wrote about HOW he made his design
> decisions) and couldn't find it till HE re-published it,
> himself. ***If you find "copies" of the book (in
> PDF); they are NOT "Public Domain" but (quite
> correctly) copyrighted by Richard Burgess. He DESERVES the
> compensation / remuneration _for the book_. ***
> 
> 
> Paper-bound copies ARE available FROM him (last I knew). (I
> own one.)
> 
> 
> 
> 
> 
> Still, in more practical matters, I like(d) your idea of
> "objectifying"(?) GEM 16-bit code.
> 
> 
> 
> 
> 
> Sincerely,
> 
> 
> 
> Thomas Clayton
> 
> 
> 
> 
> 
> --- On Thu, 11/5/09, Shane Gough <goughsw at gmail.com>
> wrote:
> 
> 
> 
> > From: Shane Gough <goughsw at gmail.com>
> 
> > Subject: Re: [GEM Development] [GEM-DEV] GEM 32
> 
> > To: "GEM Development" <gem-dev at simpits.org>
> 
> > Date: Thursday, November 5, 2009, 4:20 AM
> 
> > Hi Tom,
> 
> >
> 
> > Pretty much - although I have some code snippets to
> prove
> 
> > (or disprove) various ideas. Certainly nothing that
> could be
> 
> > publicly released that would contribute anything.
> 
> >
> 
> > In my defence I will argue that many systems started
> out
> 
> > this way - the Linux kernel is a good example :P
> 
> >
> 
> >
> 
> > I am certainly not promising anything - if you read
> that
> 
> > from my emails I apologise. I'm simply interested
> in the
> 
> > idea, believe I have the skills to implement it and
> (it
> 
> > seems) others are interested as well. To me this is
> an
> 
> > interesting intellectual problem (and I'd rather
> be
> 
> > writing code than watching TV) - I don't get paid
> for
> 
> > this, it's never going to make me any money and
> it's
> 
> > a choice I make about how I choose to spend my spare
> time.
> 
> >
> 
> >
> 
> > Sorry to seem like I'm ranting but this is the
> only
> 
> > forum I get to discuss my ideas about this particular
> topic.
> 
> > It doesn't really matter if I do something about
> them or
> 
> > another reader does (or someone scanning the archives
> in a
> 
> > couple of years time). At this stage it is little more
> than
> 
> > an idea (in my minds eye as you say) and I've not
> 
> > presented it in any other way.
> 
> >
> 
> >
> 
> > Regards,
> 
> > Shane
> 
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> gem-dev mailing list
> gem-dev at simpits.org
> http://www.simpits.org/mailman/listinfo/gem-dev
> 