Sandy's view is that we will support any software that is generally backwards compatible.
We face enough challenges coming up with designing generally backwards compatible hardware that we can't worry about the OS or software except in the broadest terms. The only pieces of code we're actively working at now are the ones we need to develop in the immediate short term: IDE drivers and a very safe flash utility/ROM image manager[1]. Anything that moves us forward. I'd like to see long filenames. My preferred solution would be new code and a new format that can accommodate long names natively. The code would have to recognize both formats. New format partitions wouldn't necessarily have to be readable on old format machines, because we can bring the new capabilities to most older machines. Sandy will support this with our plan to offer upgrades for all existing QubIDEs at cost price, and to make sure the GPL'd code is easily available. Dave [1] Are you up to the challenge? :) On Tue, Feb 11, 2014 at 10:17 AM, Ralf Reköndt <ralf.rekoe...@t-online.de>wrote: > Well, I think, the most problem is that, the Level 2 subdirectory names > are part of the filename. It would be interesting to know, how this was > done with the first hardisk systems (like Quest or similar). I think, a > device can use its own way to manage this, as long as the OS can know, > where to go (the WIN2 way for example). > > Or have a look at the TK3 sources. There, you could set (in the old TK2 > way) a "DDOWN test", where a "BOOT" was located and LRUN FLP1_BOOT and all > files were able to find other files, even in the (old TK2 way) subdirectory > "test". That worked perfectly. Files in the root were always be able to be > located with i.e. "FLP1_\FULL_NAME". > > Cheers...Ralf > > > ----- Original Message ----- From: "Tobias Fröschle" > > > Derek, > > I guess it won't. This has been discussed quite a bit in the past, but in > my opinion, there's no compatible way to overcome this limitation whithout > a fundamental change in how device drivers work together with the operating > system. > > The file/path name length in QDOS/SMSQE is deeply buried in the channel > definition block which is not allocated by the device driver, but instead > by the operating system itself. Without changing that part of the OS, the > device driver can't do much about it. Once the OS is changed, it would > create files no longer accessible with the "original" OS. > > What could be done, maybe, would be a similar kludge to what MS did when > they introduced long file names - mainly "translating" long names into > short ones that can be handled by an unchanged OS. Short names would still > be limited to the known path name length, though. > > Along that line, there used to be a promising extension named "QVFS" by > Hans-Peter Recktenwald that allowed the usage of longer path names as an > "overlay" on top of the actual device driver - The code is still around, > but has never been widely adopted, because it was not exactly easy to > handle. > > Regards, > Tobias > > > Am 11.02.2014 um 10:08 schrieb Derek Stewart <de...@q40.de>: > > Hi Dave, >> >> Are you going to have long file names, that is longer than the current >> length in SMSQ/E. >> >> Regards, >> >> Derek >> > > _______________________________________________ > QL-Users Mailing List > http://www.q-v-d.demon.co.uk/smsqe.htm > -- Dave Park Sandy Electronics, LLC d...@sinclairql.com _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
