re: Commercial use of FreeDOS / BETA status and missing features

Hi, to answer several questions of this discussion in a single
reply mail:

- you can have disks up to 2 GB size (4 GB experimental) per partition
  with FAT16, but FreeDOS even supports the FAT32 filesystem, which
  uses space more efficiently and allows even bigger partitions. Long
  filenames are not supported, but you can install a third-party driver
  (Like doslfn or lfndos, both GPL software) to provide long file name
  services to long file name aware programs (e.g. programs compiled with
  DJGPP - take care, such programs run in 32bit protected mode, so you
  need a 386 CPU and must not use the FreeDOS EMS driver). The FreeCOM
  command.com shell does not see long file names, though.

- You can still buy licenses for DR-DOS (it became free for noncommercial
  use, and single licenses can no longer be bought). It should run basically
  all software that was written for MS DOS.

- Most software that was written for MS DOS runs in FreeDOS, too. Windows 3.x
  is a well-known exception. The memory management is limited, though: If you
  need UMBs (for devicehigh=... and for loadhigh), you need either the third-
  party freeware driver UMBPCI (and a supported motherboard chipset) or some
  EMM386: The FreeDOS one is not compatible with protected mode DOS software,
  the DR-DOS one is only free for noncommercial use, the MS-DOS one is neither
  free nor available separately (I asked somebody about that), but both the
  MS-DOS and the Quarterdeck one could be considered abandonware: You can no
  longer buy them, so you SHOULD be allowed to copy them. However, they are
  not officially re-released as freeware by MS or Quarterdeck!

- SCANDISK is not that important, as only more recent MS DOS versions have it.
  However, we should have CHKDSK (difference: Scandisk has a nice user inter-
  face...). This is currently being worked on, as we know :-).

- It is cool that the kernel is FAT32 capable, and making FDISK FAT32 capable
  should be easy. I think FORMAT already is FAT32 capable. Having a FAT32
  capable CHKDSK would be nice (being worked on) but not extremely important.
  As FAT32 is a bonus compared to MS DOS, I think not all disk tools need to
  support it. By the way, we don't have a working DEFRAG either, but this is
  being worked on, you can use the open source freeware DEFRAGR (only FAT16),
  and it is, as SCANDISK, not that important to have.

- If we cannot offer UMB and DPMI (protected mode stuff: we do have cwsDPMI,
  but the problem is that our only FreeDOS UMB driver, emm386, is incompatible
  with it (see above) - I prefer to say "UMB and protected mode access"), we
  still offer what OLDER versions of MS-DOS could offer (DOS 4.01, I guess).
  As said, with a suitable chipset, you can use UMBPCI freeware to solve the
  problem. Otherwise, you need to use one of the third-party EMM386 drivers
  discussed above.

- Suggestion: Make an ALIAS for DIR in autoexec.bat, which points to a BATCH
  file that "translates" the /On (etc.) arguments to DRL syntax and calls DRL.
  DRL output differs from DIR output. Hm. Sigh. Depends on why and for what
  you need DIR /O.. and DIR /A..! I recommend that FreeCOM should get the /A
  soon and that somebody should take DRL and make a spin-off version that uses
  the same arguments and output format as DIR (so: remove color from DRL and
  make /O always on, forcing DRL to write to standard output) of MS DOS.

- I agree with the others on the license: Of course you can use FreeDOS, but
  you must offer your customers a way to get the FreeDOS sources. However, if
  you sell some embedded system which is in fact like a PC, I do not think
  using FreeDOS as operating system conflicts in any way with running non-GNU
  software on the PC. This is a bit tricky, but you can compare it with Linux
  distributions: The sources of the GNU programs in the distribution have to
  be accessible for people that buy the distribution, but the distribution
  may include commercial non-open-source software as well (Debian Linux tries
  to avoid this, however).

- Concerning the BETA status: We wanted to offer MS DOS 5.0 functionality in
  general, and we still lack some parts of it. FreeDOS is very stable and can
  do many things that MS DOS 5.0 could not do, but in some aspects, it is the
  other way round. We should be self-confident enough to DIFFER from MS DOS,
  so for example we do not have to clone its command line syntax. For example,
  if DRL became official part of FreeDOS, I consider the DIR /O problem to be
  solved for my part. DRL can produce the listing you want in the format you
  want (short format) or at least a format you can read just as well (verbose
  format), it can sort in all needed ways and you can redirect its output.
  However, we should at least wait for an EMM386 with VCPI (what makes it DPMI

  compatible: Then we have UMB, EMS and DPMI all at the same time) and better
  versions of CHKDSK (and have some bugs like the FDISK/FAT32 one fixed) etc.
  before we leave BETA status.
  By the way, do we need a BASIC to leave beta status? Our BASIC is a very
  limited version, I wonder if anybody still buys MS DOS because of QBASIC ???
  If yes, we cannot really offer QBASIC. But we could take efforts to have a
  "no line numbers needed" clone of GWBASIC. Most people use QBASIC that way,
  only few use the other (many) advanced features of QBASIC.

Have a nice DOS :-). Eric.