RE: [ql-users] Virus alert (No, not a hoax !)
-Original Message- From: Tony Firshman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 10:51 PM To: [EMAIL PROTECTED] Subject: Re: [ql-users] Virus alert (No, not a hoax !) I don't run M$ mail programs - that is the reason I don't spread them! At work, I have no option - Outlook 2000 but seriously protected on the email server and on individual PCs with Macafee - which is probably the best AV on the go at the moment. At home, I use Opera and my wife uses Netscape. I would love to run a QL mail program - not least because it would simplify mailing lists. That would be nice :o) Norm. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com
RE: [ql-users] Re: Q40/Q60 device drivers
-Original Message- From: Dave Walker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 6:06 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] Re: Q40/Q60 device drivers I would be more than happy to make the DiscOVER sources available Nice one Dave, I'd like to see the sources please. although whether anyone else could fathom their way around them ... Aha, a challenge ! I like those :o) Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com
Re: [ql-users] Digital Precision Collection
On Tue, 26 Jun 2001 at 21:15:15, you wrote: (ref: [EMAIL PROTECTED]) At 12:02 AM 6/28/2001 -0500, you wrote: Maybe Simon (N) Goodwin or Chas Dillon can shed some light into this? They should know the status. I believe that most of the programs had a time clause to them and are now owned by the original authors. Now the problem might be tracking down the authors, or they could be considered abandonware. There's been a lot of discussion about abandonware on comp.sys.sinclair, dealing with old spectrum games. Remember, copyright infringement is only illegal if the copyright owner sues you. A city or government can't sue on behalf of the copyright owner. So, you take your chances. ... and Freddy Vachha is very good at suing. I would tread carefully. -- QBBS (QL fido BBS 2:257/67) +44(0)1442-828255 mailto:[EMAIL PROTECTED] http://www.firshman.demon.co.uk Voice: +44(0)1442-828254 Fax: +44(0)1442-828255 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
[ql-users] Digital Precision collection
Hi All, I would concur with Tony - Freddy would certainly sue, all depends on if he still actually owns the copyright or not, or they were indeed time limited and have reverted to Simon et al as the authors. Simon doesn't subscribe to this list, but I have forwarded this email to him for comment - I'm sure he'll know the score and I'll pass on his response. He is busy doing a regular contribution to Linux Format magazine now among many other Amiga related things. Cheers, Darren. [EMAIL PROTECTED] P.S. I am delighted to see work has begun on a CD device driver. Simon has been trying to get Frank Swift (a brother of Marks) to write a CD driver in C to read QXL.WIN's on any platform (inc. Amigas etc.) for some time - I set him QXL.WIN samples from my CD collection that I sell but never got a response from him, that was only a few weeks ago though. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify us immediately at [EMAIL PROTECTED] and delete this E-mail from your system. Thank you. It is possible for data transmitted by email to be deliberately or accidentally corrupted or intercepted. For this reason, where the communication is by email, the Bank of Ireland Group does not accept any responsibility for any breach of confidence which may arise through the use of this medium. This footnote also confirms that this email message has been swept for the presence of known computer viruses.
RE: [ql-users] Re: Q40/Q60 device drivers
Ahem, I *think I understood that :o) Norman. Norman Dunbar EMail: [EMAIL PROTECTED] Database/Unix administrator Phone: 0113 289 6265 Lynx Financial Systems Ltd. Fax:0113 201 7265 URL:http://www.LynxFinancialSystems.com -Original Message- From: Thierry Godefroy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 10:44 AM To: [EMAIL PROTECTED] Subject: Re: [ql-users] Re: Q40/Q60 device drivers VERY LARGE INFORMATIVE SNIP
[ql-users] unsubscribe
Re: Q40/Q60 device drivers (was: Re: [ql-users] Derek Stewart BB)
On Tue, Jun 26, 2001 at 05:42:26PM +0100, [EMAIL PROTECTED] wrote: I was going to suggest accessing unsupported filesystems by reading the device as a stream, but seem to recall trying something similar in the past and finding that because the partition it represents is a fixed size (and files can be scattered anywhere over it) you always end up with a file as big as the partition size, regardless of how much of the space you've actually used. This means the maximum size (not just used space) of any partition you want to copy to CD using the cat /dev/hda1 | cdrecord -dev 0,0,0 - method must be smaller than the capacity of the CD. sure, unless someone writes a fs compactor for SMSQ. A script using qxltool could also read all files and create an exactly fitting filesystem, qxltool even has a clone command to copy all files, this would make it pretty easy. This simple solution would require up to 800MB temporary storage though and clone doesn't preserve all attributes like file version, this would have to be fixed. Afaic all publicly known specs about QXL filesystems are scattered through UQLX, qxltool and qxl_fschk sources. Bye Richard
Re: [ql-users] Digital Precision collection
At 10:16 ðì 27/6/2001 +, you wrote: Hi All, I would concur with Tony - Freddy would certainly sue, all depends on if he still actually owns the copyright or not, or they were indeed time limited and have reverted to Simon et al as the authors. Simon doesn't subscribe to this list, but I have forwarded this email to him for comment - I'm sure he'll know the score and I'll pass on his response. He is busy doing a regular contribution to Linux Format magazine now among many other Amiga related things. Cheers, Darren. [EMAIL PROTECTED] Ack! Okay okay okay! I will wait to see what Simon says (sic!). Anyway, after running the software AGAIN on QPC I have to say that I am amazed how well these were written in order to withstand SMSQ/E - 96 Mbytes of allocated memory - A 5 Gb WIN and lotsa colours :-) Certainly some problems exist like with the ACT system (can be started from harddrive but the PTHx_ device has to be used afterwards in order to get some of the subprograms working :-) but overall they behave amazingly well... even the Conqueror works JUST FINE :-) And provides a USABLE system with QPC especially now that my old MS-DOS programs are impossible to run in one of the X re-incarnations of DOS, it provides you a decent way to run old MS programs (IMAGINE THAT! You need a QL emulating a PC under a PC in order to run PC programs!) Phoebus Phoebus
Re: Q40/Q60 device drivers (was: Re: [ql-users] Derek Stewart BB)
In article [EMAIL PROTECTED], Q Branch [EMAIL PROTECTED] writes In article [EMAIL PROTECTED], Richard Zidlicky [EMAIL PROTECTED] writes there is no need to add the bloat of ISO9660 just to read a single QXL.WIN Putting the QXL.WIN image directly on the CD is much cleaner and files inside are still trivially accessible using qxltool on any reasonable OS. Time to set out own standards :) This was not what I suggested. The ability to read PC format CDs from the Q 40 would open up a vast amount of Clip Art etc. to the QL user at a stroke. I know I can read QXL.WIN files with qxltool but the ability to access it as a straight directory would open it up to those who want to do just that without having to download extra tools and work their way through the usual freeware jungle of no front ends or user interfaces. Yes we could set our own standards and remain isolated or we could do what other commercial systems are not capable of and read as many formats as we can. I would agree that it is best to embrace the wider 'standard'. This choice was also faced some time back by my RISC OS system, another minority OS, which generated a long debate ... now you just read any PC format CD. -- Malcolm Cadman
Re: [ql-users] Virus alert (No, not a hoax !)
In article [EMAIL PROTECTED] , Norman Dunbar [EMAIL PROTECTED] writes -Original Message- From: Tony Firshman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 10:51 PM To: [EMAIL PROTECTED] Subject: Re: [ql-users] Virus alert (No, not a hoax !) I don't run M$ mail programs - that is the reason I don't spread them! At work, I have no option - Outlook 2000 but seriously protected on the email server and on individual PCs with Macafee - which is probably the best AV on the go at the moment. At home, I use Opera and my wife uses Netscape. OT - Yet Opera is good, well worth having as a Browser. I would love to run a QL mail program - not least because it would simplify mailing lists. That would be nice :o) It will have to have sensible 'defaults', and easy configuration ... to be a good example of a mail client :-) -- Malcolm Cadman
Re: [ql-users] Q40/Q60 device drivers
Nasta wrote: Let's also remember that users that do not have a Q40/60 may also want CD access. Not everyone has (or for that matter can have or wants) Linux on their QL compatible hardware. I think most of us are well aware of this. *If* a plain QDOS/SMSQ CD-recording software gets written, that is the best, of course! Knowing that such a software is not trivial, I just thought of a simple alternative for Q40 / Q60 users that would use a minimized Linux solution just for CD-Recording, without forcing the user to install or know Linux. To have a CD-Writing solution (directly callable from SMSQ!) that uses a Linux kernel/ramdisk is better than having no solution at all. I do not think we should forget such possibilities for Q40/Q60 users, just because the other QL hardware platforms do not have the same. Thierry has already explained that his initially Q40/Q60 specific work could be ported to other QL hardware. It may lead to CD read-access for GC/SGC. So if Q40/Q60 *SMSQ* users can write a CD, with a Q40/Q60 specific solution (hidden Linux), and this CD is readable on the other QL hardware platforms, that seems to be progress for all. Why not? BTW, GC/SGC do not seem especially well-suited for CD-Recording (data rate!), so being Q40/Q60 specific for such steps toward CD-Recording doesn't hurt them too much. Peter
Re: Q40/Q60 device drivers (was: Re: [ql-users] Derek Stewart BB)
Richard Zidlicky wrote: Afaic all publicly known specs about QXL filesystems are scattered through UQLX, qxltool and qxl_fschk sources. I think Gerhard Plavec has also put some information on his Austrian QL site, address available on my 'ql links' page on my website -- Dilwyn Jones [EMAIL PROTECTED] http://www.soft.net.uk/dj/index.html
Re: [ql-users] Re: Q40/Q60 device drivers
IAn Interesting discussion this and some very good points raised by all. I see, as usual that Thierry has his finger firmly on the pulse here and is way ahead of most of us. When we discussed CD drivers at Eindhoven last weekend we were suggesting that it be ported to the Qubide and that a new Qubide ROM would be commissioned ( Phil is making the sources available soon I gather). I had no idea that it might be a problem with the rate though. My suggestion of being able to at least read a QXL.WIN file was based on that being in the root directory and on the complaints over the years from QXL / QPC users that they can backup their files to CDs or ZIP drives but then not read them on the Aurora etc. -- Roy Wood Q Branch 20 Locks Hill, Portslade, Sussex BN41 2LB Tel : +44(0)1273-386030 / Mobile : +44 (0) 7836-745501 Fax +44 (0)1273-381577 web site : http://www.qbranch.demon.co.uk/
Re: [ql-users] Re: Q40/Q60 device drivers
Well, I hate to be a party breaker, but guess what: all standard CD file systems have a deeper directory structure and/or longer names than the QL is capable of handling with it's 36 character path+name limit. Wrong! ISO9660 is limited to 32 chars in filenames (path name included) and to 8 levels of sub-directories... True, as long as the unextended ISO9660 is used (without Joliet). I don't have the ISO specs handy, but wasn't it originally 8+3 filenames? As a result, it is not possible to implement a directory device driver that would do anything but direct sector access, or some sort of bodged file access. Wrong again ! By using a small trick, I can make a SMSQ/E (NOT QDOS !) directory device driver to use long filenames. Here is how the trick works: In QDOS/SMS, when an OPEN system call is issued, the IOSS (Input Output Sub System) first extract the device/file name and asks to each non- directory device driver if it recognizes this name as one of its device (+parameters) name, the length of this name is not limited (well it is, but to a bigger number of chars: 127 if the name was not quoted, 32765 if it was). Yes, once a long time ago I wrote about this. because non-directory devices are searched first, and they basically accept a QDOS string as name plus parameters, this enables a driver to get to the untruncated string which may or may not be a file name. To overcome the 36 chars limit, [a non directory device driver has to] to store the long filename somewhere, truncate it to 36 chars [and return not found so that scanning continues to the directory driver which then sees a 36 character name and handles it] When a new device driver wants support for long filename, the only thing it must do is to register itself to the long filename thing... by passing it it's device driver linkage block address [where the pointer to the long name will be placed] Now why only SMSQ/E and not QDOS? Because SMSQ/E implements support for all TRAP #2 calls into the non-directory device drivers. E.g., when issuing a DELETE system call under QDOS, only the directory device drivers list is scanned [so the long file name handler would not be called] Well, I am glad to have been proven wrong on this. Briliant idea! I wonder if a more complete spec could be made for such 'registration' mechanisms as they could be useful for other parts of the driver, not only the long file names. Regarding long file names, some kind of 'shorthand' may be required when referring to them, such as the concept of 'current directory'. Are we going to have the directory separateor argument again, i wonder? :-) I do see one remaining problem, though. There is still a limit to the number of directory devices that can be in use simultaneously. Since all calls in SMSQ/E are passed to a non-directory driver, I have to ask, why bother with a directory driver? I won't even go into ideas of having the CD driver being modular, something that links to a regular 'ide' driver through correct sector access - cause QDOS has no real linking capability, so it would have to be yet another bodge. Still wrong... My CD-ROM device driver is implemented as a thing and will implement a registering thing extension that will allow for a module to plug itself into the device driver. The module will have to implement OPEN, CLOSE and all I/O sytem calls for its own filesystem. This is not really what I meant. What I emant is that 'mounting' of a devices, i.e. linking of a driver to a piece of physical hardware, should logically be handled by TRAP #2. However, there are no calls to do this - but special parameters passed to open/close or even format calls could be used for this. However, even if they are, at the very lowest level, where a single piece of hardware can be used by many drivers, there may be a problem, unless all of the drivers that can access the hardware are rewritten to take account of each other, or a 'hardware' driver was written, into which other drivers are linked (problem here is that we might end up with more than the max number of simultaneous directory drivers). IDE is the example that comes to mind on a QL. Suppose that the user connects a hard drive and a CD ROM as master and slave on a single IDE channel. Effectively, this looks like a set of registers for each device, however, only one set at a time can be used, and this is switched by one bit. This bit is visible and changeable by both drivers. Unfortunately, most (if not all) drivers assume the hardware will exclusively be used by themselves - and here we have a problem, they rely on the state of registers to be preserved. SCSI is another related example. A SCSI host adapter does nothing of itself, but may have many different devices connected to it, that all require treatment by essentially different drivers. This may look irrelevant, however, ATAPI is essentially a SCSI data transport protocol that works over IDE, which wasn't originally planned
Re: [ql-users] Re: Q40/Q60 device drivers
At 10:13 PM 6/27/2001 -0400, Nasta wrote: SCSI is another related example. A SCSI host adapter does nothing of itself, but may have many different devices connected to it, that all require treatment by essentially different drivers. Just to expand on what Nasta said, different drivers (such as disk or tape) utilize the SCSI controller to talk with their respective devices. The controller is opened as a device and just handles the SCSI conversation between the devices and their drivers. I've done some SCSI Bus trace analysis so I'm familiar with how the protocol works. I wrote an article for Sys Admin mag on the subject if anyone wants to know more. Tim Swenson
