On Sun, Jan 06, 2002 at 07:32:14AM +0100, Thierry Godefroy wrote: > > the problems are QDOS specific: > > - drivers can be practically written only in assembler, > > True, but as far as I am concerned (I don't want to restart the "assembler vs > C" flame war), this is not a problem but a GOOD THING !
may be a good thing for you but not everyone is good enough with assembler to write more complex pieces of software in it and hardware drivers are the worst nightmare to debug if something doesn't work. Realistically we would probably have a few more drivers if it was possible to write them eg in 'c' or even SBasic. > > Not many people around who > > have the thorough knowledge about the hardware and software to write > > more complicated drivers. > > True, but knowledge can be acquired by anyone, the problem being the time > needed to do so... Note that most of the knowledge to acquire is NOT > QDOS/SMS specific, whatever driver you are going to implement on whatever > plateform, you need to learn about protocols, standards, etc... > > As an example, for the ATAPI thing and the CDROM device driver, most of > the development time was spent searching, printing, reading and under- > standing the ATA, ATAPI and ISO specs (nothing less than 10Mb of PDF > files...). The actual implementation of ATA/ATAPI took about 40% of the > total time... why did you bother with the broken standard if HW vendors obviously don't read it ;) > > Judging by source fragments and disassembly it is rather messy, even > > simple things like partitioned harddrives are a disaster. > > It's difficult to "judge by source fragments and disassembly", unless you > got the documented sources... it is very easy to judge if you see the bugs, I spent some time disassembling the stuff and identifying workarounds. Sometimes the disassembly is much clearer than source, I do even frequently disassemble the Linux kernel. Many of the bugs exist only because there is not something like a block device concept in QDOS. > > To be fair, all QDOS/SMSQ filesystems are long overdue to be scraped. > > To be fair, do you know of a filesystem in _any_ 20 years old OS (QDOS > is already 19 years old !) that did not or should not get scraped ? > The mass media just evolved too fast and too hugely for anyone to guess > right what the filesystems limitations had to be in first place... absolutely agreed, although there are notbale exceptions of filesystems older 20 years which arent completely obsolete most are. Doesn't change the situation though, there is not a single QDOS filesystem that is worth to be reused. > > There are jewels like maximum 65535 files per drive, > > This is driver specific, there is no such limitation into QDOS/SMS OS > itself, as an example, the "maximum file per drive" (I suppose you > are talking about the 16 bits "File Id" into the files channel > definition block) will be 4 billion (32 bits) for the CDROM device > driver. there are many places where this and similar limits are implicitly hardwired into SMSQ. Nothing that could not be cured with a whole new filesystem design. > > maximum name length (including directory path) 36 chars > > I already explained on this list how to circumvent this problem under > SMSQ/E. In fact, with my "trick", you can use up to 32765 characters > (QDOS string limit) per path+filename. This should hopefully be enough, > even in a far future... ;-) agreed, and I will patch QDOS and Minerva to allow for this trick. > > and complete and useless incompatibility with anything else on the > > planet. > > Such as ? > > If you are making allusion to the file naming conventions (such as the > directory separator which is "_" in current QDOS/SMS filesystems), they > are just that: conventions ! The CDROM device driver will accept both > "/" (natively) and "_" (for backward compatibility) separators... "_" is still a problem when the rules whether it can be part of filenames are rather complicated. Basically SMSQ has no working concept of subdirectories. Overly complicated and inconsistent just to allow some compatibility with earliest MDV drivers and long forgotten software. > > Unfortunately > > the OS interface in both QDOS and SMSQ still has severe limitations, > > practically enforcing the 36 chars limit. > > Untrue, SMSQ/E DV3 (device driver level 3) has built-in support for 80 > chars filenames instead of 36. Alas the current (native) SMSQ/E device > drivers don't use this feature. the IOSS is still enforcing this limit. The only way around is your "trick" ( quite legal and reasonable IMO) but that requires a wholy different filesystem design and thus obsoletes DV3. Not a problem, just making my point that it needs a new filesystem. > > If you write eg an > > PCI bus initialiser the OS must have hooks to execute the code very > > early. Both QDOS and SMSQ have some way to do it but eg the SMSQ way > > appears very cumbersome. It would work somehow by linking the code > > into SMSQ which seems like a nightmare (for all parties) to get > > the distribution and copyright somehow correct. > > TT himself explained how to link new modules into SMSQ/E (in QL Today or > IQLR IIRC), he did not mention any copyright restriction. I think that > this would not pose any problem as long as you ask him. there is a copyright problem because I can't possibly distribute any SMSQ, so I would have to get TT or someone else with a valid license to do that. This is simply inconvenient for all parties. Btw, if you want to modify the MMU setup sequence in SMSQ how do you do that? > Another way around > is to provide the module separately from SMSQ/E together with a small > installer which would then link in the module on the user system (Aurora > was provided which such a module); this would only pose a problem if the > target system can't initialize without the module... which would be the case with a PCI initialiser. Note that in QDOS this could be possibly done with an expandeROM hook although this gets called pretty late in the boot sequence Bye Richard
