Hi Thomas,<br><br>I owe you an apology as well - I didn't mean to go off on rant like that.<br><br>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).<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>So - to progress on more realistic terms I've decided on the following:<br><br>1/ Develop a library (including header and implementation) for VDI using Turbo C++ 1.01 (available as a legal free download from <a href="http://edn.embarcadero.com/museum">http://edn.embarcadero.com/museum</a> - was Borland, now sold off as a separate company).<br>
2/ This library will use the 'modernised' function names.<br>3/ Develop a set of test applications that exercise all known functions in the VDI.<br><br>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.<br>
<br>Regards,<br>Shane<br><br><div class="gmail_quote">On Sat, Nov 7, 2009 at 7:15 PM, Thomas Clayton <span dir="ltr"><<a href="mailto:topcatdrc@yahoo.com">topcatdrc@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Shane,<br>
<br>
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.<br>
<br>
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 :-) )<br>
and<br>
wouldn't it be "neato" for GEM to run in a manner that took "full advantage" of it (those).<br>
<br>
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.<br>
<br>
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_. ***<br>
Paper-bound copies ARE available FROM him (last I knew). (I own one.)<br>
<br>
<br>
Still, in more practical matters, I like(d) your idea of "objectifying"(?) GEM 16-bit code.<br>
<br>
<br>
Sincerely,<br>
<br>
Thomas Clayton<br>
<br>
<br>
--- On Thu, 11/5/09, Shane Gough <<a href="mailto:goughsw@gmail.com">goughsw@gmail.com</a>> wrote:<br>
<br>
> From: Shane Gough <<a href="mailto:goughsw@gmail.com">goughsw@gmail.com</a>><br>
> Subject: Re: [GEM Development] [GEM-DEV] GEM 32<br>
<div class="im">> To: "GEM Development" <<a href="mailto:gem-dev@simpits.org">gem-dev@simpits.org</a>><br>
</div>> Date: Thursday, November 5, 2009, 4:20 AM<br>
<div><div></div><div class="h5">> Hi Tom,<br>
><br>
> Pretty much - although I have some code snippets to prove<br>
> (or disprove) various ideas. Certainly nothing that could be<br>
> publicly released that would contribute anything.<br>
><br>
> In my defence I will argue that many systems started out<br>
> this way - the Linux kernel is a good example :P<br>
><br>
><br>
> I am certainly not promising anything - if you read that<br>
> from my emails I apologise. I'm simply interested in the<br>
> idea, believe I have the skills to implement it and (it<br>
> seems) others are interested as well. To me this is an<br>
> interesting intellectual problem (and I'd rather be<br>
> writing code than watching TV) - I don't get paid for<br>
> this, it's never going to make me any money and it's<br>
> a choice I make about how I choose to spend my spare time.<br>
><br>
><br>
> Sorry to seem like I'm ranting but this is the only<br>
> forum I get to discuss my ideas about this particular topic.<br>
> It doesn't really matter if I do something about them or<br>
> another reader does (or someone scanning the archives in a<br>
> couple of years time). At this stage it is little more than<br>
> an idea (in my minds eye as you say) and I've not<br>
> presented it in any other way.<br>
><br>
><br>
> Regards,<br>
> Shane<br><br>
</div></div></blockquote></div><br>