[GEM Development] [GEM-DEV] GEM 32

Sat Nov 7 17:29:21 PST 2009

Hi guys,

I do want to apologize Shane because I did think the OpenGem was your
project. Most of my ideas was that way.

However, OpenGEM does provide a platform which is what's needed in any
project. For instance if I wrote a program and the libraries it used was
automatically included in OpenGEM, that makes it easier for consumers. It
just burns me that even using apt-get, there could be some dependency
issues.

BTW, I have used PC-BSD on my laptop. That was a whole lot easier with their
.pbi installers than using Linux.

On Sat, Nov 7, 2009 at 9:33 AM, Shane Gough <goughsw at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> gem-dev mailing list
> gem-dev at simpits.org
> http://www.simpits.org/mailman/listinfo/gem-dev
>
>

-- 
Bro. Michael Henry
Associate Pastor
Monticello Christian Church

1 Timothy 1:15  "This is a faithful saying, and worthy of all acceptation,
that Christ Jesus came into the world to save sinners; of whom I am chief."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.simpits.org/pipermail/gem-dev/attachments/20091107/b845fd08/attachment-0001.html 