Message-ID: <01FD6EC775C6D4119CDF0090273F74A4022036@emwatent02.meters.com.au> From: "da Silva, Joe" To: "'opendos AT delorie DOT com'" Subject: RE: DOS issues #2 Date: Thu, 19 Apr 2001 20:27:59 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id GAA01190 Reply-To: opendos AT delorie DOT com Thanks, Matthias. See below ... Joe. > -----Original Message----- > From: Matthias Paul [SMTP:Matthias DOT Paul AT post DOT rwth-aachen DOT de] > Sent: Friday, 13 April 2001 0:34 > To: opendos AT delorie DOT com > Subject: Re: DOS issues > > On 2001-04-11, Florian Xaver wrote: > > >> Firstly, do you have some idea of how likely it is, that Lineo > >> (Caldera) will release DR-DOS as open-source, and in what > >> time-frame? > > > > Mh...not so fast, they cannot, because of their DOS-competitors > > and because of the OEMs... > > You (we) will have to ask them. But my *personal* judgement > is quite similar to Florianīs. As long as the money rolls and they > have competitors in the DOS market, they will probably not > open up the relevant parts (that is the kernel, shell, memory > managers, and redirectors), Iīm afraid. > [da Silva, Joe] Well, I have already made some comments in the other post, so I won't repeat them here ... From a "competitor" perspective (I presume this means potential IP leakage), they have already published the kernel source, so the only other consideration is with their OEM business. It's up to Caldera/Lineo what licence conditions they apply to the kernel source, so perhaps this could be like : 1. Open-source, non-commercial distribution of the kernel or any derivative works. 2. Free use of the kernel or any derivative works for DR-DOS licensees or for non-commercial use. This would not affect their OEM business, since the OEMs would still require a license for commercial use, however they (and other existing customers) could take advantage of any upgrades to the kernel. > I hope, however, that Lineo would agree to GPL some of the > other drivers and tools, which are of no interest for their OEM > market or could need some serious maintenance to bring them > in better shape and to the current state of things, anyway. > Having these drivers maintained by the community might be > in their interest as well as in ours - if not only to keep some > form of DOS development and knowledge alive. These tools > could also be very interesting for FreeDOS to finally have > professional-level implementions... > > My hopes that this might be possible at some stage are partially > supported by posts like the following. After all, Caldera and > Lineo are companies being heavily involved in (and dependent > on) Open Source projects - this should imply an open view to > GPL. > > < Date: Mon, 05 Apr 1999 12:23:25 -0600 > < From: Tim Bird > < To: caldera-opendos AT rim DOT caldera DOT com > < Subject: Status of DR-DOS from Tin > < > ----- snip ----- [da Silva, Joe] Hmmm ... The comment about "publishing ... went badly" is interesting! Any idea what it means? > < Our initial try at publishing the source code to the kernel went > < badly, as did our recent attempt to GPL GEM technologies. > < Unfortunately, we are a small company, and we can't afford > < to expend enough resources to make some of these projects > < occur, even though it appears it would benefit the small community > < of desktop DR-DOS users. This is a real shame, and I welcome > < comments on how we might address this problem for future > < projects of interest to the DR-DOS community. > < > < [...] > > Some components such as Personal NetWare, Stacker, or NWCACHE, > can probably never be published as Open Source, because they contain > licensed code from other vendors. This is a pitty, because I have a > couple of fixes also for components such as NWCACHE... > > Maybe we should set up a petition? > [da Silva, Joe] If you think it will help! WRT, the other components ... see below. ----- snip ----- > > >Have the various problems with EMM386.EXE been resolved, in > > >the meantime? Eg. are there still DPMI problems with DJGPP, > > >or VCPI problems with Causeway and others? > > > > Ask Matthias ;)) > > Well, I havenīt worked on EMM386 recently. I fixed a number > of other problems with EMM386, but these issues are still not > addressed (at least not by me), sorry. > > To avoid any misconception I should stress that Iīm not on their > payroll - Iīm doing this in my free time and for my personal > enlightment, and just because Iīm still feeling committed to support > and further enhance the system. And I still have an endless wishlist > myself. I try to do as much as possible, but my resources and time > are limited. My day has only 48 hours, unfortunately, and improving > DR-DOS is only one - though a big - project from many for me... > (If you know of a prooven method to change this to the better, > please drop me an email... ;-) > > I cannot promise anything, but I wonīt let down DR-DOS until > there would be a better DOS (which is extremely unlikely to > occur), or until I will have completely switched over to Linux, > or for some other reasons would have no time left to work on > it. I could probably do much more on behalf of DR-DOS if there > would still be active development on Lineoīs or the OEMsī side > or if I would receive some form of sponsoring from someone... ;-) > [da Silva, Joe] I think we all appreciate your efforts with DR-DOS. As for your last remark, although made in jest, I really think Caldera/Lineo should sponsor/pay you to help sort out this stuff - seriously! If they don't want to release this stuff as open-source because of their OEM business, then clearly they have a commercial interest in getting this stuff fixed. The reputation of DR-DOS, and it's continued use on the desktop, has a direct affect on OEM interest in the product. Caldera/Lineo may not be rich like M$, but surely they can afford to hire one more programmer on a part-time basis! If not, then it's time to open-source the product! > > >How "close" is the code to supporting LBA, FAT32 and > > LFN stuff properly? > > My estimate is that itīs relatively close, but for use on desktop > systems it would still need some man months work (including > testing) to get rid of a few quirks and to make it perfect. Well, > Iīm a perfectionist and donīt like 95 percent solutions. ;-) > [da Silva, Joe] Here, here! ----- snip ----- > > >Are there any M$ patent problems with using FAT32 and LFN > > >together? If so, would the US government department which is > > >pursuing M$ for anti-trust, help to revoke such a patent? Why > > >does the patent office grant patents for stuff that is clearly not > > >innovative, anyway??? > > To summarize what has been said in public already, Microsoft has > been granted a patent on writing long filenames in the FAT filesystem. > This does not affect FAT32 (without LFN), but it does affect LFN- > writing software such as LONGNAME. This is the very reason why > Caldera withdrew this driver from public. > > In their expressed view (for example in Tim Birdīs above mentioned > post) the patent should never have been granted, as Microsoft omitted > to mention some significant Prior Art (by Digital Research/Novell) > in that document. But I think, Lineo/Caldera has no further interest > in yet another battle, as such a law suit would be very expensive. > For justice I would personally still appreciate to see the US > government investigating the issue... > [da Silva, Joe] Yes, DR-DOS is not sufficiently commercial to justify an expensive legal battle. That's why I mentioned the US government department that wants to break-up M$ as the only possible initiator of such a legal move. It's a pity the patent system today is so open to this kind of abuse! The patent system was supposed to reward innovation. Now however, it's just used to stifle innovation! The patent office doesn't seem to care; a patent is only "real" if it "holds up" in court! And now they even grant patents on things invented by God, in the interests of the giant corporations, and to the detriment of scientific progress and the general public. Anyway, the US patent office seems to have granted our "friends" in Redmond about five patents on this LFN crap, and a further patent to IBM (for a different way of converting an LFN to an SFN ...). It seems there are no future Albert Einsteins at the patent office, just lawyers (this is not meant as a slur on lawyers, but if you have read (just about) any patent, you'll know what I mean)! > > My personal opinion on patents is a German (or European???) one: > AFAIK it is not possible to invoke patents on algorithms here, as > they are considered to be public property (although there are now > forces that try to establish the US customs in the EU, too, and some > patents on algorithms have already been granted by "accident"...) > > BTW. The GNU GPL shows an interesting mechanism in order to > defeat the excesses of the US patent habits. > > I second Joeīs statement, that MS-LFN is not innovative in any way, > both, because of the fact, that the existence of that very patent > obstructs > equivalent 3rd-party implementations from occuring (which for the > most part would benefit Microsoft Windows 9x customers), and also > because their LFN and ACCDATE implementation is questionable > per se. If you analyze how it works, it comes out that it is: > > 1. very fragile and sometimes ambiguous, > 2. not fully compatible with older issues of DOS (of any vendor), > 3. (deliberately???) breaks other older features such as > DR DOSī password security & DELWATCH, > 4. contains a number of strange hacks to cover design > inconsistencies or omissions, > 5. with minor changes could have been designed to avoid > any of these problems. (But I guess MS has had no > actual interest in designing a truely compatible solution.) > > Well, the LFN-API is not affected by the patent. This is why > in the given situation I would opt for a virtual file system that > can read MS-LFNs, but stores long filenames in a way similar > to 4DOS DESCRIPT.ION files. This would probably give a > small performance hit and would not be fully compatible with > Windows 9x (although it would be possible to add support for > it to the Windows VxD layer), but it would allow to use long > filenames under plain DOS without any headaches. > > A technical brighter solution might be to just improve the method > how LFNs are stored in the directory entries, but this would make > it incompatible with many disk utilities that support the MS-LFN- > way now. So, this would be a solution only for isolated embedded > systems, not for shared desktop machines. > > > In an open source program no problem. > [da Silva, Joe] M$-DOS (aka Windoze 9X) is the prevalent DOS, so any LFN implementation really needs to be compatible with this. If non-commercial applications are exempt from patent problems (where's a lawyer when you need one? ;-), then perhaps a separate freeware driver like Henrik Haftmann's DOSLFN is the answer ... ----- snip ----- > I think the most serious problem with FreeDOS is that there > is only a handful of people, who have solid knowledge of > DOS internals. Developing a new DOS now implies the > serious risk that many of the known peculiarities in older > DOS issues and older DOS applications are long forgotten, > but by ignoring them, one will never be able to design and > develop a 100% compatible DOS... > [da Silva, Joe] You're quite right. That's why the DR-DOS kernel is the most important thing to open-source. Most of the utilities would not need such specialist knowledge, nor require so much manpower ... > Just my thoughts, > > Matthias > > DISCLAIMER: I should stress that anything said in this post > reflects nothing but my personal opinion and view, and that > Iīm no spokesperson of whomever (except of myself). >