Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
Norman Dunbar wrote: On 27/01/11 15:48, gdgqler wrote: Of course. but why at runtime? Code reuse and/or share-ability. If you have 10 applications running and each one needs the same library code, isn't it much better to have one copy used by all, rather than running the system with 10 copies of the same code? That way, the space hogged by the 9 duplicates can be used to run another application? I dont get you. Whats wrong with toolkits and Things? They work like dlls. If the punter doesnt have loaded what you need you can always load it from the program's home directory. Per ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
On Thu, Jan 27, 2011 at 5:51 AM, Norman Dunbar nor...@dunbar-it.co.ukwrote: I may regret starting this, but as the subject says, what would you like to see in QDOSMSQ given that we were starting from scratch with the intention of writing a completely new OS? I'd like to see: A block sound driver, so we can do interesting and useful things with standard sounds. A windowing system that isn't just easy and cosmetically pretty for application users to understand, but that's also easy to code with. A new OS-supported distribution/save format that permanently resolves the stripped headers issue. A HAL - Hardware Abstraction Layer - to make the OS less dependent on specific elements of the hardware that have held us back for some time. A new boot option to allow us to configure behavior of the system, eg: installed RAM without dropping to a host OS (if emulating) or on genuine Moto hardware so all functions pertaining to configuring hardware are consistent parts of the OS, not variable of assorted emulators. Proper networking. Treating sockets with device independence too, so OPEN #5,tcp_192,168,0,17p80 is valid. Font improvements. Start by calling them fonts - but also by having a choice of bitmapped or outlined fonts with anti-aliasing. Remote desktop. Standard encryption/decryption. Something modern. Unix-style users. It's a multi-tasking OS. If people can never log into it from elsewhere and have it recognize users and privileges, there's only so much it will ever be able to do in the future. Some IO functions. QDOS makes a good RTOS for IO function, data logging etc - everything is there in the OS except good IO and logging functions. It would make a great robotics OS. A group of people to come together to help write drivers for things. There are many hardware projects stalled simply for lack of drivers. People with those skills need to communicate, and take requests for help, then divide and conquer. There are, that I know of, at least two stalled projects now because of these types of issues. OS-driven speech. USB drivers and drivers for certain classes of standard devices like UVC webcams, TWAIN scanners, PCL5 printers, etc. In fact, a whole new printing system, like CUPS, would be nice. Dave ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
On 27 Jan 2011, at 16:07, Norman Dunbar wrote: Of course. but why at runtime? Code reuse and/or share-ability. If you have 10 applications running and each one needs the same library code, isn't it much better to have one copy used by all, rather than running the system with 10 copies of the same code? That way, the space hogged by the 9 duplicates can be used to run another application? It would normally seem better to have just one copy of a routine rather than several. I think I misunderstood what was meant by at runtime. Both QLIB and TURBO allow extensions to be included in a program. This can be useful when the program is to be run on many machines some of which will not have the required extensions loaded. This gives easier use of the program at the expense of duplication. Compilation by TURBO allows solution of another problem which how to use another routine if the one you want is not loaded on your machine. It seems dangerous to me to rely on a routine which might have changed since the last time you looked at it. How can you know that the next time your program runs it won't produce different or faulty results because the DLL now contains something different? Works fine for Linux, HP-UX, Windows etc! The usual (Unix) case is that when version 6 of a library comes out, a link to the new *.so file is created, and you get an *.so.6 created. This is what your program is looking for. Other programs may be looking for *.so.5 = so they find that their link, created when release 5 went in, is still pointing at the *.so file, even though it is now the *.so from release 6. The versions are backwards compatible in that features in .5 are still there in .6. The same is true, of course, if an extension used by a program is updated. This should be OK if backward compatibility holds. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
On 27 Jan 2011, at 17:23, Norman Dunbar wrote: One thing I would like to see in SMSQ is the correct MC680xx vector table at the start of the OS. Is this because some of the space is taken up with QDOS vectors thus covering up some of the Motorola exception vectors? The solution is to use the VBR to relocate the exception vectors (possible with 68020+). George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
On Fri, Jan 28, 2011 at 5:08 AM, gdgqler gdgq...@gmail.com wrote: Compilation by TURBO allows solution of another problem which how to use another routine if the one you want is not loaded on your machine. Apologies for the off-topicness, but one thing I'd like to see from Turbo or other compilers is a command maker that can take a PROCedure or FuNction, compile it, and package it up so it can be loaded to extend BASIC. I think this would result in a mini-renaissance of keyword development, which could act as a suggestion line for additions to SuperBASIC and, more broadly, QDOSMSQ. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
Hi George, Is this because some of the space is taken up with QDOS vectors thus covering up some of the Motorola exception vectors? The solution is to use the VBR to relocate the exception vectors (possible with 68020+). Yes indeed, this is why. However, the solution still doesn't allow everything to be used. Only a number of the exception handlers and the traps from 5 to 15. I was meaning I'd like the standard features of the processor to be completely available in the ideal 680xx OS. Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
In message 4d415c3e.2020...@dunbar-it.co.uk, Norman Dunbar nor...@dunbar-it.co.uk writes Hi Norman, Something for everyone ... :-) All of the things that you list are quite technical considerations. Most users you want something that does something very well without them having to bother too much about it. Hence the embedded capabilities being shown by mobile phones and ipads, etc. The new way or working is moving towards being a more intuitive interaction between human and machine - hence hand movement and touch, etc. So, a new OS would have to be a new paradigm, in the first place. I may regret starting this, but as the subject says, what would you like to see in QDOSMSQ given that we were starting from scratch with the intention of writing a completely new OS? Disclaimer: No, I'm NOT thinking of writing one! For me, the following: * Ability to hook into the OS from any language, Basic, Assembler, C, whatever. * A windowing system that is simple to use. From any language. * Libraries that applications can link to at run time, as opposed to static linking at compile time. * Multitasking, obviously! * A file system that is not restricted to 36 characters. See http://qdosmsq.dunbar-it.co.uk/blog/2009/05/whats-wrong-with-this-file-system/ for a pseudo-rant on the matter. * Industry standard floating point format. * Industry standard graphics format(s) - PNG, for example. JPG if we must! SVG would be nice. * Speed and efficiency! ;-) Cheers, Norman. -- Malcolm Cadman ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
[Ql-Users] What would you most like to see in a new version of QDOSMSQ?
I may regret starting this, but as the subject says, what would you like to see in QDOSMSQ given that we were starting from scratch with the intention of writing a completely new OS? Disclaimer: No, I'm NOT thinking of writing one! For me, the following: * Ability to hook into the OS from any language, Basic, Assembler, C, whatever. * A windowing system that is simple to use. From any language. * Libraries that applications can link to at run time, as opposed to static linking at compile time. * Multitasking, obviously! * A file system that is not restricted to 36 characters. See http://qdosmsq.dunbar-it.co.uk/blog/2009/05/whats-wrong-with-this-file-system/ for a pseudo-rant on the matter. * Industry standard floating point format. * Industry standard graphics format(s) - PNG, for example. JPG if we must! SVG would be nice. * Speed and efficiency! ;-) Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
On 27 Jan 2011, at 11:51, Norman Dunbar wrote: I may regret starting this, but as the subject says, what would you like to see in QDOSMSQ given that we were starting from scratch with the intention of writing a completely new OS? Disclaimer: No, I'm NOT thinking of writing one! For me, the following: * Ability to hook into the OS from any language, Basic, Assembler, C, whatever. That's true of SMSQE * A windowing system that is simple to use. From any language. This also is true of SMSQE * Libraries that applications can link to at run time, as opposed to static linking at compile time. How would that work? If I write a program I like to know in advance what it will contain * Multitasking, obviously! True of SNSQE * A file system that is not restricted to 36 characters. See http://qdosmsq.dunbar-it.co.uk/blog/2009/05/whats-wrong-with-this-file-system/ for a pseudo-rant on the matter. Well - that's not in SMSQE. * Industry standard floating point format. OK for Q40/60 FPU * Industry standard graphics format(s) - PNG, for example. JPG if we must! SVG would be nice. Photon displays JPEG on a QL * Speed and efficiency! ;-) QPC2 is rather faster, with SMSQE, than even Q40/60. So, presumably, SMSQE is more than half way there? George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
Hi George, * A windowing system that is simple to use. From any language. This also is true of SMSQE Is it? * Libraries that applications can link to at run time, as opposed to static linking at compile time. How would that work? If I write a program I like to know in advance what it will contain True, but lets say you have a graphics application that needs to display an SVG graphic. Would you write an SVG decoder routine? No, you'd use the one built in to the OS as a library (dll on windows, so (shared object) file in Linux for example). The distributed application would not need to distribute the library as it is there on all computers running the OS in question. Your application is less resource intensive and downloads faster - ok, I realise the Windows apps are still available on two DVDs for an install! There's nothing to stop you statically linking the library to your application, of course, that way you know that the version you wrote it to work with is always available regardless of what version of the OS or library in question is built in to the customer's computer. * A file system that is not restricted to 36 characters. See http://qdosmsq.dunbar-it.co.uk/blog/2009/05/whats-wrong-with-this-file-system/ for a pseudo-rant on the matter. Well - that's not in SMSQE. I know! ;-) * Industry standard graphics format(s) - PNG, for example. JPG if we must! SVG would be nice. Photon displays JPEG on a QL Yes, photon does. But does anything else which has not been especially written to do so? Nope. So, this belongs in a graphics layer on top of (perhaps?) the OS. So, presumably, SMSQE is more than half way there? I think you may have taken me up wrong. I'm not complaining that QDOSMSQ is not good enough, I was asking what we would like to see in an ideal OS. SMSQ is pretty well there, I disagree that the windowing system is easy to code - the more I look into it for QL Toady, the more I find myself wondering why TT wrote stuff the way he did. Until I finally decoded EasyPTR3 many years ago, I had great difficulties getting anything pointer driven to work. It's only now I'm even attempting to look at it (the PE) from an assembly viewpoint! SMSQ has lots of colours now and bigger screen resolution etc which is a great improvement over the old days of 512*256 and 8 colours, but that was 1984. The sound system is still pretty lacking though Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
On 27 Jan 2011, at 15:18, Norman Dunbar wrote: * Libraries that applications can link to at run time, as opposed to static linking at compile time. How would that work? If I write a program I like to know in advance what it will contain True, but lets say you have a graphics application that needs to display an SVG graphic. Would you write an SVG decoder routine? No, you'd use the one built in to the OS as a library (dll on windows, so (shared object) file in Linux for example). Of course. but why at runtime? The distributed application would not need to distribute the library as it is there on all computers running the OS in question. Your application is less resource intensive and downloads faster - ok, I realise the Windows apps are still available on two DVDs for an install! There's nothing to stop you statically linking the library to your application, of course, that way you know that the version you wrote it to work with is always available regardless of what version of the OS or library in question is built in to the customer's computer. It seems dangerous to me to rely on a routine which might have changed since the last time you looked at it. How can you know that the next time your program runs it won't produce different or faulty results because the DLL now contains something different? George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
On 27/01/11 15:48, gdgqler wrote: Of course. but why at runtime? Code reuse and/or share-ability. If you have 10 applications running and each one needs the same library code, isn't it much better to have one copy used by all, rather than running the system with 10 copies of the same code? That way, the space hogged by the 9 duplicates can be used to run another application? It seems dangerous to me to rely on a routine which might have changed since the last time you looked at it. How can you know that the next time your program runs it won't produce different or faulty results because the DLL now contains something different? Works fine for Linux, HP-UX, Windows etc! The usual (Unix) case is that when version 6 of a library comes out, a link to the new *.so file is created, and you get an *.so.6 created. This is what your program is looking for. Other programs may be looking for *.so.5 = so they find that their link, created when release 5 went in, is still pointing at the *.so file, even though it is now the *.so from release 6. The versions are backwards compatible in that features in .5 are still there in .6. Easy. On QDOSMSQ the similar thing would be things I suspect, They are shared - the Menu Thing that Jochen produces is shared and usable by all sorts of programs, and only one version has to be in RAM at the time. Cheers, Norman. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] What would you most like to see in a new version of QDOSMSQ?
One thing I would like to see in SMSQ is the correct MC680xx vector table at the start of the OS. :-) -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
