Message-ID: <06e601c0c35f$581a4540$6c08e289@mpaul> From: "Matthias Paul" To: References: <01c0c264$381b3840$8b5bb7d4 AT default> Subject: Re: DOS issues Date: Thu, 12 Apr 2001 16:33:55 +0200 Organization: Rechenzentrum RWTH Aachen MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id KAA16867 Reply-To: opendos AT delorie DOT com 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. 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 < < [...] < < I have recently become the Chief Technical Officer of < Caldera Thin Clients, the company that owns and develops < DR-DOS. I agree (somewhat painfully) with Yesss' < assessment of the recent changes to FDISK. Many were < ill-advised. Because of limited staff, wide testing on < some of the new modifications has been limited, and < likely insufficient. < < We do not currently target the desktop environment as a < primary market for DR-DOS. It is a secondary market for us, < which generates a small amount of revenue. It is unlikely that < you will see major revisions to things like DOSBOOK, Stacker, < Personal NetWare, or other large-grained components of DR-DOS. < We are deeply interested in problem reports like the one posted < on FDISK, but you may see large time lags before these get < addressed in released product. Because FDISK does not hold < much intellectual property value for us, and new functionality is < almost completely unnecessary in the embedded market, I am < considering making the source code public. (Feedback on this < would be greatly appreciated.) < < 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? (Notes. a) As most of you sure know, Lineo, Inc. is the successor of Caldera Thin Clients, Inc. b) The GEM sources have in fact been released under the GNU GPL 2 soon after Tim made this statement. c) And I´d like to add, that any kind of bug reports on DR-DOS can always be sent to me for my knowledge base and personal use.) > >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... ;-) > >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. ;-) > BTW: I read, that Lineo wrote a tool to support Win9x on top > of Dr-DOS 7.03, it is somewhere avaiable or hasn't it been > released? No, AFAI can tell it was originally planned to release this little gem with sources. This was the talk in the UK operation back in 1997/1998, but also what Bryan Sparks announced to the press - at least I have seen him cited in news articles stating this. Unfortunately, it never was, presumably because later improved issues would not work on out-of-the-box 7.02/7.03 kernels, anyway. It was, however, successfully demonstrated to selected press and in court. > >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... 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. Whereever possible, I try to design my software, so that it will work under any DOS issue from any vendor. Of course, this also holds true for my work on DR-DOS. It should be the user´s choice which OS he/she uses... I have more than enough reasons to prefer DR-DOS, but if someone wants to stick with MS-DOS, well, that should be up to him/her... > >Is Free-DOS any good? How advanced is it on these issues? Any DOS development is a good thing in general! :-) FreeDOS is still very experimental, but recently (Beta 6 is about to be released!) has reached a state where it becomes at least useable for enthusiast and might already be a good solution for a number of embedded systems applications or use as boot disk - mind, that when you develop the application you can take the FreeDOS quirks and omissions into account, something you cannot with pre-compiled software. However, it still requires much more memory due to the fact that the major parts are written in C rather than assembler and it is lacking many IMHO significant features. Comparing FreeDOS with DR-DOS. Well, DR-DOS clearly plays circles around it in any discipline but the Open Source status. I think, that FreeDOS will be a useful DOS platform (for example with DOSEMU) in a few years, but it will most probably never reach the performance, optimization, stability and compatibility of DR-DOS. Personally I try to support FreeDOS whereever possible, for example by making my binaries interchanceable between the OSes, but I will probably remain a DR-DOS fan. Some - unfortunately only few - of the currently available FreeDOS executables are already quite mature and stable (one such example is Brian Reifsnyder´s Free FDISK), although when you have a look at the sources, there are still alot of things missing. 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... 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).