Mail Archives: opendos/2001/04/12/10:49:25
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 <tbird AT caldera DOT com>
< 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).
- Raw text -