Aminet 10

home *** CD-ROM | disk | FTP | other *** search

/ Aminet 10 / aminetcdnumber101996.iso / Aminet / docs / misc / Q_log.lha / q.log

Wrap

Text File | 1995-11-22 | 41.0 KB | 779 lines

Sch > I'd liek to introduce JeremyG to you all Sch > JeremyG say hi :) JeremyG > Hey all... Sch > Jeremy has been developing an OS for about 5 years now Sch > It was developed on the Amiga and is actually portable to other platforms Sch > It's hardware independent. Some of the features it has are Memory Protection, Retargetable graphics, AutoConfig Networking and much more Sch > Jeremy: Is there anything you want to say about the OS before we start? JeremyG > I've got a few paragraphs I can send if you want... Sch > Please do JeremyG > Q Operating System is the first fully hardware and interface independant operating system. This allows it to do some interesting things, such as DOOM on an Amiga, or an Amiga paint program on a 16 processor Cray YMP-C90. It is fully capable of "forcing" the issue, if the program JeremyG > doesn't want to cooperate. Impossible? It is, with current OS technology. That is why we've had to start from scratch, completely rebuilding the philosophy of OS design. No longer is the end user at the JeremyG > mercy of the applications programmers. Instead of lowering the system to match as many applications as possible, Q raises those applications to meet the system. This is retargetability at its ideal. JeremyG > At long last hardware designers will be free from compatibility worries, and applications programmers don't have to support all of the "standards" out there. In fact, they don't have to support any! JeremyG > The techniques we use to do what we do also offer many other advantages, such as some of those previously discussed. JeremyG > Because of the way it handles the applications, things such as crash proofing, resource management, auto-caching, virus resistance, JeremyG > full retargetability, and many other features become possible. Sch > Jeremy: When you're done, just let me know so I can give out the rules for the conference and people can have a little while to think of their questions :) Sch > Ok Sch > Ok folks: You will be /msging me with your questions Sch > I will be on as Schrade. Please send msgs to him and him ONLY Sch > Question asking is ONLY for the undernet side of the net due to the instability of EFFNet Sch > Ok..here we go Sch > First question from Dagorgil Sch > "How does this promotion of applications happen?" Sch > DO NOT MSG me as Sch. Send MSGS to Schrade ONLY JeremyG > The basic idea is that it reads the program, converts it to it's own language (called UML) and the converts that language back to the machine code needed to run JeremyG > on your machine. Obviously its much more complex than this, but basically that's how it works. It is a recompilation type metho JeremyG > GA Howard > Wont memory protect and crash-proofing cause the OS to slow dow drastically compared to the kickstart in use today? JeremyG > Nope, in fact it will operate considerably faster. Let me explain something that will give you a better idea JeremyG > of what kind of techniques are used. For starters an MMU is not used AT ALL. It is not needed. Virtual memory is a thing of the JeremyG > past. Memory protection has moved to higher planes. JeremyG > You have to pay for it of course. And it is done when you "prep" a program when it is first installed on your system. JeremyG > It could take several hours before that program is available to you, but once it's prepped, it will operate as fast or faster JeremyG > than under more primitive systems. In addition, each time you run a program it gets a little bit faster, optimizing itself to JeremyG > the peculiar ways that you use it. In fact, an assembly language programmer would have a difficult time coding tighter and more JeremyG > precisely than Q can. Later on as Q becomes more developed, we will actually hold contests, to see if assembly programmers can JeremyG > program more efficient code than Q can... I know this sounds like a tall order, but it's no longer just an idea on paper, JeremyG > it is a working product being put through the final stages of testing. JeremyG > GA Vicce > "I would like to know how he would market the OS." JeremyG > There are several different techniques being thrown around, and many of them will be employed. Make no mistake, Q JeremyG > will run on anything powered with a processor with 256k of RAM or more... That means that pretty much the entire computer JeremyG > industry is our market. As far as personal computers are concerned, the Amiga in particular, we have spoken with JeremyG > Amiga Technologies, and if they can get over their doubt and unbelief, we will demonstrate it to them as soon as they JeremyG > are willing. We would prefer to sell our product packaged with computers, and not to sell it on the open market directly. JeremyG > GA Zool > No offense, but is this real? I mean, it seems impossible: A programmer announces a new OS which he's been working on alone for 5 years, no one has ever heard of it, and it has features that make all other OS look hideous? Sounds too good to be true. JeremyG > Good question and completely understandable. JeremyG > If you think about it for a while, you might figure out why we keep it low-profile, at least up until now. JeremyG > Sorry for the vagaries, its a good question, I just can't answer without making a lot of people angry... JeremyG > GA oleg > "What language is the OS written in?" JeremyG > Q is written in Q... :) yes, Q is a programming language, and the only one powerful enough to pull off something like itself. JeremyG > Bootstrapping was the only way to get it to the public in less than a century. C++ programming is a ridiculously slow JeremyG > development process comparatively. The original "contrictor" is written in 68040 assembly language, and is the JeremyG > seed bootstrapping code for Q itself. But the vast bulk of Q is written in Q. JeremyG > Oh, by the way, I am not by any means the only one developing this, I am just the one who designed the core of Q. GA Frac_unet > "How did Q come about? Just a personal project? University or industry linked research?" JeremyG > It came about as a desparate programmers attempt to make programming an easier process. JeremyG > It started as small alterations of C++, and expanded to what we call a SuperCompiler. JeremyG > Then we realized that by running this supercompiler under most operating systems, it would be seriously inhibited. JeremyG > So we designed it AS an operating system. Because of its nature, it made a REAL NICE operating system, even though that JeremyG > wasn't the intention. It became an ideal development utility for us as we could code for several different platforms AT tHE JeremyG > SAME TIME. In other words, we could write a word processor in Q, and have it spit out executables for Amigas, Windows, JeremyG > Macs, etc. with almost no extra effort. GA gregh > "Availability? How much?" JeremyG > We are actually going to release an early version for Amigas as licenseware (completely free). JeremyG > That of course depends on several other factors, it may not happen. The money comes from extras that may be attached JeremyG > to the operating system, such as extra interfaces, hardware description modules, drivers, etc. There will be a develope JeremyG > version, but it will cost a lot, possibly over a grand... GA Robr > What is your URL address, and when can we see screen shots?" JeremyG > I am currently working on getting a web page up. No screen shots yet, for legal and logical reasons. JeremyG > Just to add something quickly to the last question, we're looking at 1st quarter of 96 for the free Amiga release. JeremyG > The logical reasons I am referring to consists of the simple fact that no two Q systems look alike. Being interface JeremyG > independant, and being more configurable than even the most flexible of interfacing programs, it JeremyG > ... ah you get the point. About the end of the year we will be permitted to show it off, and then I can upload some of my JeremyG > favorite interfaces. GA Cappy > "What background in programming Amiga and other platforms do you have?" JeremyG > Lets see... I have done database programming for a long distance company for a few years. I have a small amount of experience JeremyG > in the PC world, but much more in the Amiga world. Just private stuff though, nothing I have coded has ever been released. JeremyG > GA neyda > 1) Where does one buy this OS (answered) 2) Where does one get developer kits (please be specific) 3) Why haven't there been any demos or talk of or news about this OS? JeremyG > To answer question 2, you don't. Not yet. For one thing you don't need them, because all operating system programs will work, JeremyG > provided that they are properly described. There will be developer kits eventually, but we really don't have to JeremyG > go around to all the developers and beg for them to support us. JeremyG > To answer question 3 this is the first time that I was permitted to talk about it on the internet. This IS the talk JeremyG > and the news. Demos? Our first is in mid December and is open to anyone who wants to be there. In fact, I am trying to JeremyG > get our people to let me release betas to all of the people who come to the demo (after signing a form, of course). JeremyG > The details of the demo are being hammered out and I will post the results as soon as I get them. GA TaoTe > 1) Where does one buy this OS (answered) 2) Where does one get developer kits (please be specific) 3) Why haven't there been any demos or talk of or news about this OS? TaoTe > Also thrown in from TaoTe: Does Q support multithreading? and is there an FAQ? TaoTe > How well does Q work as a server, i.e. for SQL database processing? JeremyG > No FAQ yet, and yes it does support multi-threading, (and even a few new concepts) JeremyG > It works as well as the descriptors written for it. JeremyG > As a server it is a dream, fault tolerance, high performance operation, JeremyG > extremely easy to use, full multi-user support, and many others... JeremyG > GA doZE > "Have you taken your ideas from OS9?" JeremyG > What is OS9? GA Sch > OS9 is an OS that was popular on the tandy color computer :) Sch > not was, IS... it still exists Sch > It is now being used as an OS for CDi type components and also for Kiosks JeremyG > Okay, I guess the answer is no. Some stuff I would like to add to the networking questions... JeremyG > I will now elaborate a little on the networking side of it, I think it would answer many questions. JeremyG > Let me point out some attributes of it and you figure out how it works... For starters it is JeremyG > capable and in fact does create its own protocols over any piece of hardware if you give it the chance. JeremyG > This means that if I hooked up the parallel and serial ports as well as an ethernet connection between two computers, JeremyG > Q would automatically come up with a protocol to work most efficiently over the configuration. JeremyG > ALL resources are shared between the computers (user alterable of course). This includes processing power and RAM, and JeremyG > all IO resources. I.E. If I ran lightwave on an Amiga with a Pentium attached (however it is attached), if the task JeremyG > feels like it, and if there is free processor on the Pentium, the task will be completed by BOTH processors. I know that JeremyG > this sounds crazy, but parallel processing is Q's birthright. It is actually quite easy with the techniques it uses. I could JeremyG > write a lot more about this but I will stop for now. GA Frotz > Why on earth did start developing a replacement for AmigaDOS 5 years ago, and why hasn't ANYBODY seen this thing running? (partially answered) JeremyG > This is NOT a replacement for AmigaDOS. It is true that it does replace it, but that WASN'T the intention. JeremyG > We DIDN'T want people to know about this until we were about ready to release it. You see there are many companies JeremyG > out there would would much prefer that we never surface with a product. We have had to of necessity keep it quiet until we JeremyG > could better protect our investment. GA Trooper1 > Question: How can Amiga programs be memory protected, when sharing memory is hardly ever done explicitly on the Amiga?1 JeremyG > Could you rephrase the question? JeremyG > GA deltax > How big is the kernel? What kind of system resources does it need?" JeremyG > The kernal is relatively small, simply because most resources reside inside of classes and objects on the hard drive. JeremyG > The system resources it needs are remakably small, again because of the nature. It has been run under 256k of RAM. JeremyG > The more RAM you can give it though the faster it will go. In fact, running a program that normally requires 1 meg of ram JeremyG > (say a fractal program) in 100 megs of ram will INCREASE its speed considerably. Space-time conversions are part of the JeremyG > resource management subsystem. The actual Q on the hard drive may be anywhere from 10 megs to several Gigs depending on JeremyG > how you do it and what system it is run on, as well as which hardware descriptions you want, which interfaces, etc. JeremyG > GA Trooper1 > "When one allocates memeory in an Amiga program, this is almost never done using the MEMF_PUBLIC flag. Still, the allocated memory is used by several different programs. Trooper1 > How do you know that his is what happens, and that the other program is not violating the first?" JeremyG > Good question, and the answer is QUITE involved. Nor would I describe it, because that goes deep into the core. However, Sch > huh JeremyG > I will attempt to explain breifly what goes on concerning situations like this so that you can know that this is real. Cappy > hahaha JeremyG > Each time Q takes apart a program and attempts to figure out what's going on, it must perform a complex juggling act, JeremyG > one that isn't always completely successful, although it almost always comes up with SOME solution... JeremyG > The basic idea is the whole art of Q and that is attempting to match up what a program seems to do with what the JeremyG > programmer actually intended to happen. Don't worry though, if it works under the Amiga's OS it will work under Q. JeremyG > even if some settings need to be changed... Sorry, kinda vague, but that's the best I can do right now... GA Sch > Jeremy: Just a little note. We have seen wonderful promises from a gentleman named Jim Drew before. He promised lots but never delivered. Sch > When are you going to show some proof? Sch > (This is from me) JeremyG > I have already explained that there is a demonstration in mid December... It will be held in Mesa, Arizona, USA. Sch > OK. JeremyG > GA BloodHawk > "Will I be able to get 040 performance out of my 000 machine with Q-OS?" (uh.......huh huhh huhh) Sch > I think not. Sch > :) JeremyG > Nah. But on average things should move 20-50% faster. Even more so if you know what you're doing. GA Fastlane > Why do we all get the feeling that this is a total load of bullshit that you are spouting, and why are you obviously dodging questions? JeremyG > The difference is that Jim Drew wanted something from people... I am simply telling people that when this is available on the JeremyG > internet, give it a fair chance. I know this sounds insane, believe me, I am the one that has to speak with teh JeremyG > investors. They have brought in some of the most knowledgable of computer science, JeremyG > inevitably they come EXTREMELY skeptical. But after they've fired question after question (bound by a non-disclosure JeremyG > agreement, unlike this by the way) they almost always leave recommending it to those who would invest money. JeremyG > Some questions are dodged for OBVIOUS reasons I hope. I don't mean to be rude, but there is such a thing as not JeremyG > disclosing something because of legal purposes. If you think I am going to reveal in full detail all of the inner JeremyG > workings of Q, DREAM ON... GA Dagorgil > Since you claimed that memory protection works even on a machine with no MMU, would you explain what happens when you run a program that takes a pointer as input and does something with it? And with no VM, programs that do malloc(realmemsize+!) JeremyG > The program is processed before it ever runs. It is called a "prep" cycle, and could not possible conflict with other JeremyG > programs even if it was specifically designed to do so. In other words, I could write a program that would trash the JeremyG > hard drive, but as it is passed through the prepping cycle Q realizes that it goes outside of its specified domain and JeremyG > does one of many things: doesn't allow the program to be run at all, rewrites the program to run properly (if at all possible) JeremyG > , alert the user, etc. Good question though. GA W1zard > So if I plug my Amiga running Q-OS into a CRAY, then Q will immediately re-configure to make use of the extra CPU horsepower? JeremyG > If you have the proper description modules (i.e. the hardware and processor descriptions of the Cray), YES. JeremyG > Obviously you are limited by bottlenecks such as the network speed, etc. OF COURSE it is REQUIRED that Q be running on the JeremyG > Cray as well. GA TaoTe > "How does Q stack up against Windows NT? What about OLE and the Common Object Model? Does Q support virtual memory? Does it support a GUI like Intuition? TaoTe > What methods exist in Q, for interprocess communication and multiprocess cooperation?" JeremyG > As far as Windows NT, no comparison... Q uses it's own form of object orientedness and is incompatible with others UNLESS JeremyG > a description module is written. Virtual memory is obsolete with Q technology and is no longer needed. Because Q is able JeremyG > to manipulate programs in real time as resources are made available its natural resource management system replaces JeremyG > any need for virtual memory. The performance increase because of this alone is significant. As I have previously mentioned, JeremyG > it is interface independant and it has SEVERAL GUIs. By default, when installed, it will take on the form of your JeremyG > previous interface. In other words, installed on an Amiga, it will come up looking, and responding, very similar to JeremyG > intuition. This will probably make a few of you flip out, I'm sorry, that's simply how it works. JeremyG > Yes, that does mean if you have extra programs running such as Directory Opus or ToolManager, those interface alterations MrGandalf > "I think for people to get the idea that this might actually exist, spec sheets and snapshots should be made available as soon as possible." [I agree! -Sch] JeremyG > are ABSORBED as well... It can be changed easily, and each user may have his/her own interface. JeremyG > GA Cappy > I'd like more detail on this network thing with writing its own protocols. Will the networking support 802.2? JeremyG > I have no idea what 802.2 is. Again, if it has a descriptor, it is supported. Often, if possible it is auto-detected. JeremyG > For example, lets say that you have a network of non-Q systems, networked though Ethernet running a TCP-like protocol and JeremyG > you want to attach a Q system to it, if you have the TCP decsriptor, you need to give it some info and then you will be JeremyG > running along like any other networked computer. The real advantages come when you hook Q machines up. Then it has the freedom Cappy > "You obviously know nothing about networking standards" JeremyG > to change the protocol to match various conditions. If the data integrity of a connection suddenly drops, Q will alter the JeremyG > protocol to a more stable one. It is true that I know little about networking standards, but I don't have to. I am not the JeremyG > one writing those descriptors. My specialty is the core of Q. I have written only a few of the classes and one interface. JeremyG > All of the rest is done by other employees of Pure Logic Enterprises. GA Bloodhawk > "What WELL KNOWN Amiga users/developers are beta testing this?" (GOOD question! :) JeremyG > None. All beta testing up until now has been privately done for reasons already explained. This is not a normal product. JeremyG > Don't expect it to operate through methods that you are familiar with. It will be opened up for PUBLIC beta-testing at JeremyG > the demonstration in December. JeremyG > GA DoZE > "How many people have been working on this?" DoZE > add on to that "What have you successfully run on this system?" JeremyG > There is 3 working full time, and others we give projects to such as specialty hardware etc. We have tested JeremyG > several products from various sources and have not had any problems yet. We are going to have a DOOM demonstrated running JeremyG > on an Amiga 3000 with a graphics card in our demonstration if ID Software permits us to. The most difficult programs JeremyG > to get to work properly are Amiga games, as they are often far more complex than most system-friendly software. It is just JeremyG > as difficult for Q to run an Amiga game on an Amiga as it is to run an IBM game on an Amiga. Everything is foreign to Q. GA Sch > Note: if you can't get Id to let you demo it, try Rise of the Triad, Dark Forces, etc... don't just say "Oh screw it." Sch > Next Question from Cryo JeremyG > Oh, we intend to. There are several options that would be quite impressive if we could demo. Sch > "How much Amiga kernel source was used to create his new "OS?" [Cryo - wondered when you'd get here :) -Sch] JeremyG > None was needed. Current programmers are familiar with older style philosophies. With Q, JeremyG > all it needs is a description of what various routines are SUPPOSED to do, and it hums along fine. Sometimes we JeremyG > have serious problems, but we have invariably returned to find that our OS description modules weren't coded quite JeremyG > right (maybe we didn't understand ALL that the function was supposed to perform, and problems result). JeremyG > GA Fastlane > "What is your email address and usual IRC nick?" [And - do you plan to frequent the 'net/IRC at all? -Sch] JeremyG > I don't think that I want to give out my email address, I get too much as it is. I will probably be known in IRC JeremyG > as JeremyG, unless I embarass myself too badly and have to change it... :) JeremyG > GA Sch > err Sch > POAG JeremyG > No, that was a different person... sorry for the confusion. GA W1zard > "Will there be an entrance fee to see the demo in December? If so, how much?" JeremyG > No entrance fee. You are right, Fastlane, I am on POLT's computer right now, but I assure you that I've never been on JeremyG > IRC before, I usually mess around with more primitive users groups such as usenet. This IRC stuff is cool :) GA Wyrehead > "What support will there be for Gfx cards? Will Q be able to autodetect how to access them or will it just translate existing drivers...?" JeremyG > In some cases it can auto-detect, but more often than not it will "absorb" old device drivers. I know this sounds JeremyG > somewhat miraculous, but that's how it works... As Q classes are written for them, however, they will be better JeremyG > able to take advantage than even the previous drivers of the gfx/sound/etc. cards. We will either write them ourselves JeremyG > or get the hardware companies to make them, depending on how cooperative they are. GA Frac_unet > "Have you heard of TOAS, and are Q and TAOS in any way related (spiritually, in concept or do they share any code?)" Sch > I think thats TAOS or Taligent is what he refers to JeremyG > I have not heard of TAOS (what does it stand for?) GA JeremyG > I have heard of Taligent, but not much. If we are related it is because we are sick and tired of current operating JeremyG > systems and want to move on (maybe StarTrek's OS? ) GA Sch > It's a joint venture with Apple and some other company for a fully OO OS. Cappy > What is your full name and what is the name of the company you represent?" JeremyG > Jeremy Gurr, Pure Logic Enterprises, Inc. GA doZE > How about running something like Lightwave on this OS... does it do it? Please don't be brief. JeremyG > Of course, it runs great. In fact, believe it or not, it was one of the easier ones to get working. JeremyG > We have only tested a faulty 3.5 though, we are waiting to get our hands on a 4.0 GA WyreHead > Does this Q mean that that things like AGA Amiga games and demos will work on ECS machines with a Gfx card? JeremyG > Yes. GA Litz > I would like to know how it handles encrypted self modifying code... JeremyG > It handles it quite well, thank you. Excellent question. What would you do, if given hundreds of years and a chunk of SMC that JeremyG > was compressed and encrypted and told to re-write it for another computer? You would go through it, step by step, writing it JeremyG > down as you go. And then, after you understand FULLY what is going on you will re-write it for your target computer. JeremyG > Just because it has been impossible up until now, doesn't mean that new methods haven't been created to do so. JeremyG > I can elaborate further on this if you want... just keep the questions coming. JeremyG > GA Sch > >>> Cryo comment "It sounds lot like Jim Drew's supposed transcription routines." Sch > Jeremy: have you talked with Jim Drew at all? JeremyG > Nope, and it really isn't productive to talk about it now. I'm not here just to waste your's and my time, believe me Sch > OK. JeremyG > we are pressed tight for time as it is. GA Cryo > Umm, ok, you "absorb" drivers, which means you fuzzle interrupts along with those, and yet you claim no Amiga kernel source is used. I certainly would not want to see the overhead this extra level of indirection causes. It sounds like nothing more Cryo > than a warm, fuzzy layer written in C++. JeremyG > It is NOT a level of indirection, it is part of the prepping cycle that only happens once. After it is complete it is coded as JeremyG > if it was intended to run on that machine. GA SmknDHerb > How/Why are you getting "too much" email if you are just now revealing this project? JeremyG > We have a lot of intersted parties (again bound by non-disclosures) that want to work with us. We aren't really getting JeremyG > "too much", I just used that as an excuse. GA frac_unet > "Do you need the original sourcecode of an app in order to "translate" it to run on Q?" JeremyG > No we do not. That's the whole POINT of Q is that you run an app as if it was designed for you computer, even if it's not. GA Cappy > "Where is Pure Logic Enterprises, Inc. based?" JeremyG > Mesa, AZ GA Fastlane > "Aren't there legal issues relating to Reverse Engineering of code if you are translating other peoples' software? I'm sure they wouldn't be happy for you to be doing so." JeremyG > Yes, it's a big issue to. We may have to just restrict it to running PD code. We prefer to get with software companies and ask JeremyG > them to include in their license the ability to be run under a Q system. I can't see any reason why they wouldn't. GA Sch > Jeremy: restrict it in what way? Writing? Or encoded in the OS :) JeremyG > No way other than notifying the users to not run software that says that it can't be modified in this way. JeremyG > It's actually quite similar to an emulator, it just caches the results... JeremyG > GA NyxQ > Will I be able to run the 680x0 version of NeXTStep on my A3000 w/Gfx Card? And can it handle running apps for CPU architectures it's never seen before? JeremyG > YUP. GA Sch > uhmmm Sch > Can you expand upon that please. That almost sounds impossible JeremyG > Ok, explain how it is impossible and I'll explain how Q handles those "impossibilities". GA Sch > JeremyG: I'll let that one go. :| Litz > "How long would it take to "prep" IRIX to run flawlessly?" JeremyG > I've never tried it, but assuming its as complicated as I think it is, it could take a few days... GA amigama > "Does Pure Logic Ent, Inc have a phone we call reach for other info?" JeremyG > We would prefer that you use our web page when we get it up. I will have it posted as soon as it is available, and by that JeremyG > time I will be authorized to explain it (in the web page) in more depth. GA Nyx > What kind of OOP language features does Q support, and how does it compare to C++ and/or Objective-C? JeremyG > It is VERY different from C++, even though that is the base we started from. Basically EVERYTHING is an object, JeremyG > the keyboard, the monitor, etc. And they have operations that may be performed on them. Then you have a somewhat new JeremyG > concept that we call dependencies that make some otherwise complex programming quite a bit easier. For example, I could JeremyG > code a screen blanker, something that would alter a "screen" object after the "input" family of objects hasn't been altered for JeremyG > a period of time. The "dependency" that triggers the action is inactivity of the Input object for a period of time. JeremyG > There is a tight heirarchy of objects. For example the input object has the keyboard, the mouse, and the JeremyG > joystick objects as children. These children inherit all formal and informal attributes as well as all operations JeremyG > pertaining to the parents, allowing the children to further specify operations and attributes. JeremyG > I could go further on this if you want. GA TaoTe > What mechanisms does Q have to support inter-process communication and multi-applications cooperation? JeremyG > Interprocess communication has been raised to whole new levels with Q. Such a thing as message ports and arexx JeremyG > ports are no longer needed. Let me give an example that may illustrate this. Lets say that a term program wants to send JeremyG > a message to another term program, trying to find out whether it has taken control of a serial port or not, it JeremyG > simply refers to the other program by name and searches through it's heirarchy of resources. Sorry, sloppy example. JeremyG > I've got an idea, give me an example, and I'll explain how it would work with Q. GA RobB > Is "Q" going to be on a ROM or completely software based? JeremyG > It will at first be completely software based, although it would boot a bit quicker and use less space if it could be place JeremyG > d in ROMS. JeremyG > GA Cryo > "Show us some startup code" Sch > uhuh Sch > I don't think we have time for that.. ;) Sch > jeremy: how fast are you at typing example code out of your head? JeremyG > Not quite that fast... GA Litz > "What is IRIX?" [Addressed directly to you, Jeremy] JeremyG > Isn't it a UNIX derivative for a Silicon Graphics machine? If you want to know how little I know (or care) about JeremyG > other OSes, I just don't have time to analyse and study all of them, we've got others that work for us that are supposed JeremyG > to design the OS description modules, and later on we will probably even make one for IRIX. GA NyxQ > How about subclasses? Inheritance? What kind of method binding does it use? How does it NyxQ > figure out the details of a new CPU that it's never seen before? Does it just use osmosis to determine what each bit in an instruction uses? NyxQ > How does it know how long the instructions are?" JeremyG > First about CPUs it has never seen before. I am sorry if I seemed to imply that it can magically handle cpus it has never JeremyG > seen before, but as I have already explained, it requires a processor description module for each processor before it can JeremyG > do ANYTHING with that processor's code. JeremyG > About subclasses and inheritance, I'll give you a quick Q programming lesson. A Q class is actually an object possessing of JeremyG > certain attributes. If I want to make another object with similar attributes, I would create it with reference to the parent JeremyG > object. It may be composed of other objects in a wide variety of different ways. It has both Formal and Informal attributes. JeremyG > The formal attributes are those that specifically describe what an object is composed of. The informal attributes are JeremyG > those that are actually "contained" within the object, such as it's name, it's size, and other tagged attributes. For JeremyG > example, if I wanted to make a picture that only I had access to (without going through normal access methods) I would JeremyG > attach an informal attribute called "WhosAllowed" and set it equal to my user name. Then I would create a dependency that JeremyG > would only allow user's with my user name to access it. Yet this attribute isn't actually contained in the picture (it JeremyG > would mess up the format). I could go on... GA Ezy > "Do you really expect anyone to believe this code translation thing Ezy > out proof? -- Why are you on IRC talking about it Ezy > d not giving lectures at a CS composium?" JeremyG > It has been done before, just on a smaller scale. But that was back when computers weren't quite so powerful. There is no JeremyG > better proof that I can give than the actual thing, which won't be long before it's available, one way or another. GA Sch > Jeremy: When are you meeting with Amiga Tech? JeremyG > We were supposed to meet with them Saturday (tomorrow for us), but apparently that fell through. They said that it was hard JeremyG > to believe (understandable) but that they would be at COMDEX and could maybe stop by on the way home. Then they never got JeremyG > back with us... We will try and get with them again, but they are by no means the only ones we are interested in. GA RobR/Jacob > Will Q run MUI 3.0 and how does it handle bad programs like AMosaic? JeremyG > Q will run anything the Amiga does, and *SOMETIMES* more. At the very least, AMosaic won't take your system down. But it is JeremyG > possible that it will actually function with less problems, as Q does resource analysis. GA xterm > Just what makes you think that your nifty translation will work? If it's so cool, why haven't REAL OS-innovations xterm > (read: AT&T, IBM, USL/Unix, MicroSoft(yes), etc.) done this yet? And if you can do this, why start on the Amiga? Why not xterm > a platform where you'll sell a hell of a lot more copies of the OS? JeremyG > This "nifty translation" has been working for quite some time. It's just a matter of getting some of the more difficult JeremyG > bugs eliminated. Why start on the Amiga? We didn't START on anything. The Q code is completely independant of ANY machine. We JeremyG > wrote the Amiga hardware and processor descriptors first because not only are they readily available (to us) but they JeremyG > provide a great test for Q's abilities: a complex piece of hardware incompatible with about everything, even older versions JeremyG > of itself. Who could ask for a more ideal proving grounds? Why hasn't larger companies come up with it? That question has JeremyG > been asked throughout the ages everytime a new invention comes, as it so often does, from a small establishment when JeremyG > much larger ones have been working on those problems for years. GA Sch > Addendum to xterm's Question: Sch > The other OS authors have access to better hardware than the Amiga or PPC's... the could have easily done it there. JeremyG > If they dared challenge the current philosophies they would have long ago, but as is so often the case...GA Cyro > "Will Q run BeBox programs? It'd be way cool if it did." Cryo > :) JeremyG > As answered MANY TIMES before, if it is properly described, it will as much as your hardware is capable... No you can't run JeremyG > DOOM on a pocket calculator, but give it an Amiga 500, and it stands a chance (slow but possible). GA Litz > "So, if you can "prep" IRIX in a few days, why haven't we seen something useful yet? Like a PPC version of AmigaOS? Or perhaps a blender with the Q-OS?" JeremyG > Cuz yer not ALLOWED to see it yet... can't you guys realize that some things need some extra time to be properly protected, JeremyG > and that releasing stuff like that could seriously jeopardize it? Any patent attourneys on here? GA