GNU Emacs for MS-Windows and MSDOS
Darryl Okahata
within a Windows DOS box. ]
A preliminary version of "oemacs" has been made available via
anonymous ftp. Oemacs is, basically, a version of GNU Emacs V18.59 that
will work inside a Windows 3.1 DOS box (note that it is NOT a native
Windows application, but works within a DOS box). It is partially based
upon demacs, but is not compatible with it.
At the end of this message, I've enclosed a copy of the file
"readme.dos", which describes the features and problems of oemacs. READ
THIS BEFORE OBTAINING OEMACS.
***** Why would you want to use "oemacs"? Because:
* It works within a Windows DOS box. If you're feeling particularly
masochistic, you can start more than one copy of oemacs, each in a
different DOS box.
* It works with plain MSDOS or Windows 3.1.
* It fixes some bugs that demacs has.
* It is based upon GNU Emacs V18.59.
* It contains a few more useful emacs-lisp packages. One or two of the
existing emacs-lisp packages have been upgraded, like info.el.
* Pressing Ctrl-Break at *ANY* time will interrupt whatever Emacs is
doing (assuming that it has not crashed and is not running
"subprocesses"). With demacs, pressing Ctrl-Break just sends a C-c to
demacs.
* It does not require an ANSI.SYS that allows the keyboard to be
redefined. Some versions of "ANSI.SYS" would crash if you tried to
redefine the keyboard.
***** Why would you *NOT* want to use "oemacs"? Because:
* It requires lots of RAM and lots of disk space. In order to run
within Windows, you need at least 8MB of motherboard RAM, and I
recommend that you have at least 12-16MB. You also need about 14MB of
disk space to install oemacs, *NOT* including any space used to hold
the .ZIP distribution files. Demacs requires much less resources.
* It can take a while to start up (because it is not dumped, as is
demacs). On my 33MHz 486DX, it takes about 10 seconds to start up.
Demacs starts up much faster.
* It doesn't handle large files very well. Demacs works much better for
this. The biggest file that oemacs can handle is probably just under
16MB (although I haven't tried this -- the largest file that I've
tried editing is 5MB).
* It has a fixed internal stack size. Any highly recursive emacs-lisp
functions *might* fail with this version. However, to minimize this
problem, I've set the maximum stack size to 300KB. A typical Emacs
running on my (real ;-) workstation uses up 100-150KB of stack, and so
I gave oemacs a stack twice that size. The majority of people will
probably never run into any stack problems, but you never know.
Demacs doesn't have this problem.
* Subprocesses don't work inside Windows. Then again, demacs doesn't
work at all inside Windows. "Subprocesses" in MSDOS are also
asynchronous; you CANNOT DO ANYTHING while a subprocess is running.
* It is based upon GNU Emacs V18.59. (Yes, this is both a "feature" and
a "problem".) A version by Pearl Software is based upon Lucid Emacs
V19.
***** Where can you get a copy?
NOTE: please access the following ftp site during "off-hours" --
sometime OTHER THAN 10AM-6PM EST (1500-2300 hours GMT/UTC). The
site adminstrators have graciously provided the disk space, and I
don't want to annoy them by overloading their site with ftp
requests.
NOTE THAT THIS IS A PRELIMINARY VERSION! BACKUP YOUR HARD DISK
BEFORE USING OEMACS!
Oemacs is available via anonymous ftp from theory.lcs.mit.edu, in
/pub/emacs/oemacs:
-rw-r--r-- 1 5536 toc 1065 Apr 2 16:15 README
-rw-rw-rw- 1 5536 toc 1077736 Apr 2 08:26 oemacs1.zip
-rw-rw-rw- 1 5536 toc 1089291 Apr 2 08:26 oemacs2.zip
-rw-rw-rw- 1 5536 toc 1094240 Apr 2 08:27 oemacs3.zip
-rw-rw-rw- 1 5536 toc 719295 Apr 2 08:27 oemacs4.zip
All four files have been compressed using the new .zip 2.0 format (you
can't use the old pkunzip programs), and must be extracted such that the
subdirectory hierarchy is preserved (i.e., give the -d flag to pkunzip).
Also, *ALL* four archives must be extracted in order to use this version
of Emacs; while some files are unnecessary, they must be manually
deleted (if you don't want them), after all of the files are extracted.
Complete sources and binaries, with the exception of GNU termcap, are
included.
For a starting point, see the file "emacs-18.59/readme.1st".
-- Darryl Okahata
Internet: dar...@sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion or policy of Hewlett-Packard or of the
little green men that have been following him all day.
===============================================================================
OEMACS
Release 1.0
Thu Apr 1 1993
While I would have liked to have used the name "demacs" or
"demacs2", I didn't, because I don't want people thinking that this
version is compatible with demacs. For reasons of ease-of-use and
ease-of-installation, this version is partially incompatible with
demacs. In particular, the two versions cannot share the same "_emacs"
file (the "_emacs" file is the MSDOS equivalent of ".emacs"). The major
differences between oemacs and demacs are:
* Oemacs works within a Windows 3.1 DOS box.
* Oemacs does not require a memory manager like EMM386 or QEMM, although
it is recommended that one be used.
* The _emacs files are different. In oemacs, the _emacs file has been
simplified and streamlined. Demacs cannot use the oemacs' _emacs
file, and oemacs cannot use the demacs' _emacs file.
* The terminal config files ("lisp/term/ibmpc.el") are different.
Oemacs doesn't rely on reprogramming the keyboard mapping via
ANSI.SYS. Some versions of ANSI.SYS don't allow keyboard mapping, and
some versions even crashed if this was attempted, and so oemacs uses a
different method of keyboard handling.
* Oemacs doesn't have the NEMACS or FEPCTRL code merged into the Emacs C
code. I can't test these features, and so I didn't bother merging
them in. The merge was done by hand (and not via patch(1)), and so
merging these untestable features would have added more work, which I
didn't want. The 8-bit support was kept, although it hasn't been
tested much.
* Oemacs needs to load the emacs-lisp files at startup. Demacs can be
dumped, but oemacs cannot, and so oemacs needs to load the emacs-lisp
at startup.
* Oemacs is based upon Emacs V18.59. Demacs is based upon
V18.55/V18.57.
* The version of dired that comes with oemacs has been modified, and
will work only with oemacs. This version of dired will not work with
demacs.
Here is a list of features and non-features in oemacs:
* Oemacs works within a Windows 3.1 DOS box.
* Enhanced C++ support has been added. Barry A. Warsaw's latest and
greatest C++ mode has been added (including the "new syntax table" C
code from Lucid V19 for better and quicker editing of C++/C comments).
However, because DOS filenames cannot contain "+" characters, the
filename has been renamed from "c++-mode.el" to "cpp-mode.el".
* You can press Ctrl-Break at any time to interrupt oemacs. Note that
the C-g key will only interrupt Emacs if Emacs is waiting for input.
* Added Sam Kendall's (ken...@CenterLine.COM) etags++ tags program,
which generates etags for C++ programs, as well as C, lisp, scheme,
TeX, and Fortran programs. The DOS program name is "etags.exe". See
the sources in "emacs-18.59/tags.xx" for details.
* Better error message support. If there's an error in _emacs, you'll
get something a bit more useful than "error in init file".
* Fixed the bug where files on the command line had to contain names
with forward slashes if they were not in the current directory.
Filenames on the command line are now allowed to contain backslashes
("\") as directory separators. Users of MSDOS filename completion
programs (like 4DOS) can use them to complete filenames for Emacs.
The primary fix for this is in `expand-file-name'; this function will
now lower-case the filename, and convert backslashes to forward
slashes.
* Fixed the bug where dired "randomly" displayed some file dates with a
year (e.g., "1990") instead of a time (e.g., "14:53"). Now, dired
will display the file's modification year if the file is
*approximately* over six months old (the actual time is around six
months plus or minus a day or two). This is more like Unix.
* If Emacs runs out of memory, Emacs should get a "memory exhausted"
error (however, I suspect that there are occasional corner cases where
Emacs will crash). If Emacs does get a "memory exhausted" error, I
strongly recommend that you exit and restart Emacs. Not only will
this unfragment memory, but it will insure that Emacs' internal data
structures are correct (which should be, but might not be, after a
"memory exhausted" condition).
* If Emacs is improperly installed and `(load "loadup.el")' cannot be
done or encounters errors, Emacs will display an error message, abort,
and return to the DOS prompt. Other versions of Emacs would simply
start up an unusable (and nearly unquittable) Emacs.
* I strongly recommend that you have 12-16MB of RAM on your motherboard,
and that you have a permanent swap large enough to give you at least
16MB of free RAM after starting Windows 3.1. Merely starting Emacs
within a Windows DOS box sucks up FOUR MEGABYTES of (virtual) RAM. I
have no idea where the memory is going. I've written some code to do
malloc(3) instrumentation, to see where the memory is going, but Emacs
is only allocating 200-300KB of RAM at startup. I suspect that most
of the RAM is being eaten by the DOS extender. (Interestingly enough,
running this version under plain DOS uses much less memory.)
Also note that Emacs allocates memory in sizes that are a power of 2.
If, for example, you try to edit a 5MB file, Emacs will attempt to
allocate an 8MB chunk of memory to hold the file. If you don't have
that much memory left, Emacs will get a "memory exhausted" error.
* `M-x compile' does not work within a Windows 3.1 DOS box, while it
does work outside of Windows. If you try running Borland C++ 3.1 via
M-x compile, the Borland compiler will hang. If you try running the
WATCOM C/386 compiler via M-x compile, Emacs will abort (you will lose
*ALL* your work) after the compile/link has completed. I suspect that
this is a problem with the DOS extender (I can reproduce the problem
with a small program that does nothing but execute system(2)), and so
this problem will probably not get fixed.
However, if you do `M-x compile' under plain MSDOS (which does seem to
work), this version fixes the bugs in demacs 1.2.0 where the current
drive is not saved. Your compile process can now switch drives and
change directories, and the current drive/directory will still be
saved. Also, as a special case, if the compile program is not on the
current drive, the drive/current directory will be saved/restored on
the drive where the compiled program is stored.
* I've had this version lock up if I tried to execute a built-in DOS
command (e.g., "rmdir") via `call-process' (the dired "delete
directory" command will fail without locking up Emacs, though).
* Running this version within a Windows 3.1 DOS box seems to cause
Windows to disable the screen saver (if one is used). I have no idea
what is happening here.
* I left in the "int86" function. Be careful using this function, as
you can easily crash the system by passing incorrect or bad values.
* Because this version is compiled using WATCOM C/386 9.0, the maximum
runtime stack size must be specified at link time (unlike demacs,
whose stack grows as necessary). In this version, the stack size is
fixed at 300K (if you want this changed, you'll have to relink emacs).
* This version suffers from the NIH syndrome. While much of the code
was stolen from demacs 1.2.0, much of it wasn't. I merged in, by hand
(from diff -c), much of the MSDOS- and 8-bit-specific code, but left
out the NEMACS and FEPCTRL (??) code. This will probably make a lot
of people unhappy. However, I didn't want to introduce bugs by
merging in code that I can't test, and so I didn't.
* Undump/unexec does not, and probably will never, work. This means
that you'll need mondo quantities of disk space to store ALL of the
emacs-lisp files, and that starting Emacs will be SLOW. You will need
perhaps 5-10MB for a minimal Emacs installation. On my 33MHz 486DX
w/256KB cache, it takes about 10 seconds to start Emacs from DOS, and
about 11 seconds to start from a Windows 3.1 DOS box. Not fast, but
bearable.
This problem is caused by the fact that the DOS extender (DOS/4GW)
that comes with WATCOM C/386 has an sbrk() that somehow returns some
pointer values LESS THAN the ending address of the BSS space. Can you
say #define VIRT_ADDR_VARIES (for Emacs)? Another related problem
is that the addresses returned by the DPMI provider in Windows 3.1
have some of the most significant bits set (e.g., 0x80000000 or
0x81000000). Can you say #define DATA_SEG_BITS with variable data
segment bits (they vary between plain MSDOS and a Windows 3.1 DOS
box)? Ptuii. This means that there's a potentially nasty situation
that could occur if, in Windows, the DPMI provider starts returning
pointers whose ~GCTYPEMASK bits vary; currently, Emacs will abort()
if:
(raw_pointer1 & ~GCTYPEMASK) != (raw_pointer2 & ~GCTYPEMASK)
("raw pointers" are pointers without the GC type bits.) Great
possibilities for DATA LOSS exist here (if Emacs aborts), and I'm not
sure if this "problem" will ever get solved. If this problem exists,
it'll probably manifest itself as intermittent Emacs abort()'s
(abortions?).
However, I've tried editing 5MB files under Windows 3.1, and I haven't
noticed any problems.
I'd like to use djgcc, but I can't, until the djgcc DPMI issues are
straightened out.
* While I have pruned out much of the unnecessary, often
platform-specific code and other files, I haven't cleaned out the
emacs-18.59/etc and emacs-18.59/lisp directories; these directories
contain unnecessary and often useless files (as far as MSDOS is
concerned).
* Unfortunately, this version does NOT work on Windows NT. At one time,
I thought that it might, but it doesn't.
* Instructions on compiling this version of Emacs has not been written.
Everything that you need is here (except for the WATCOM C/386 C
compiler, and the GNU termcap library).
* Some new emacs-lisp files were added. Note that not all of the
packages in the following list have been ported to MSDOS, if they need
porting:
+ c++-mode.el (renamed to cxx-mode.el in this version)
Barry A. Warsaw's C/C++ editing mode.
+ c-style.el
This file allows you to configure sets of C code editing files.
This is most useful if you have to edit C code in a number of
different editing styles (e.g, different indentation, etc.).
+ header.el
Add and maintain file headers. This mode knows about C
comments (as well as shell script/perl comments), and will
insert an appropriately-commented-out file header. When a file
with a file header is saved, the modification time in the header
is automatically updated just before the file is saved.
+ add-doc.el
Appends user documentation to the end of the mode description.
Normally, this would contain documentation about user
enhancements/changes to the mode.
+ asm-mode.el
A major mode for editing typical assembler code.
+ b-k-ring.el
Browses the kill ring in another buffer. Use C-y to yank most
recent kill ring entry (number 1.) into the buffer which was
current when browse-kill-ring was invoked. Use a numeric
argument (M-# C-y) to yank the corresponding entry.
If you move point into the browse-kill-ring buffer, the keys
C-y, y, Y, or SPC will yank the entry on the current line into
the previous buffer.
Note that browse-kill-ring should always be called before its
contents is used; its buffer is not automatically updated when
kills and yanks are done. This is normally not a problem, since
yanks will cause the buffer to be deleted automatically.
+ blink-mt.el (was: blink-mtch.el)
Yet another form of parenthesis-matching code.
+ c-com-ed.el (was: c-com-edit.el)
c-comment-edit is a command that copies a C comment into a
temporary buffer for editing under a more suitable major mode
(usually text-mode). Once the comment is edited,
c-comment-edit-end (normally bound to C-c ESC) replaces the old
comment with the edited version, adding comment delimiters and
leaders as necessary. c-comment-edit is ideal for large
comments of these styles:
/* /* /*
... * ... ** ...
... * ... ** ...
*/ */ */
+ c-doc.el
This package allows you to:
1) Enter a description of a function, with its name, a module,
a file (normally taken to be the file the current buffer is
visiting), a documentation string (as large as you'd like),
the arguments (each with a name and a type and a
documentation string), and a result type.
2) Edit the description (i.e., any name, doc string, containing
module, etc.).
3) Get a buffer listing all functions/variables currently
defined, all functions residing in a given module, etc.
4) Get a buffer showing all the information on a given
function.
5) Read/write the documentation info from/to a file.
6) Visit a function's definition (basically a regexp on the
function's name within the defining file). Kind of like a
tags visit, but driven from its own info.
7) Insert an (ANSI-compatible?) external decl of the function.
(Mostly works :-)).
8) Prompt for the arguments for a call to a given function,
showing argument types/names for each one.
9) Complete the symbol in front of point from the function
information. (Like M-Tab, but again using its own table.)
10) Read a function definition from C source, prompt for
documentation, and add it to the list.
+ completi.el (was: completion.el)
After you type a few characters, pressing the "complete" key
inserts the rest of the word you are likely to type.
This watches all the words that you type and remembers them.
When typing a new word, pressing "complete" (meta-return)
"completes" the word by inserting the most recently used word
that begins with the same characters. If you press meta-return
repeatedly, it cycles through all the words it knows about.
If you like the completion then just continue typing, it is as
if you entered the text by hand. If you want the inserted extra
characters to go away, type control-w or delete. More options
are described below.
The guesses are made in the order of the most recently "used".
Typing in a word and then typing a separator character (such as
a space) "uses" the word. So does moving a cursor over the
word.
You automatically save the completions you use to a file
between sessions.
+ edebug.tex
+ edebug.el
Contains functions to allow the user to step through Emacs-lisp
code (as a function is executed, the cursor moves over the
source code). Breakpoints can be set. This is a much better
Emacs-lisp debugger than the one that comes with GNU Emacs.
+ ereplace.el
This source code replaces the emacs commands replace-string,
replace-regexp, query-replace, and query-replace-regexp with a
single command electric-replace-string. While entering from
string, the user can use keystrokes to toggle between replacing
regexps and strings, or between query and noquery modes. In
addition, the user can choose to apply the replace over the
entire (potentially narrowed) buffer, or over the entire region.
Lastly, the user can yank the last string or regexp searched
(depending on mode) to the from-string buffer.
Quick summary:
C-h Print this help message
C-r Toggle between string/regexp replace
M-q Toggle in and out of query replace mode
C-l Toggle region mode (replace only in region)
M-a Toggle full buffer mode
C-s Yank the last string/regexp searched
The key bindings are far from perfect. Perfect bindings should
a) not interfere with useful standard editing functions
(hence M-a and M-q instead of C-a, C-q).
b) be reasonably mnemonic.
+ infer-mo.el (was: infer-mode.el)
Functions to infer the proper mode of a file from its contents,
not from its file extension.
+ info.el
A new version of the info file reader.
+ log-msg.el
Have you ever been frustrated by not being able to read an emacs
message because it gets overwritten by another message? Then
this package is for you. By setting the user variable
"log-messages" to non-nil, you can have the messages logged for
you in the buffer "*Message Log*"
+ macedit.el
A keyboard macro editor. Very useful. From GNU Calc.
+ minibuf.el
Functions to grow/shrink minibuffer window so that all lines show.
Darryl Okahata
> [ Here's yet another version of GNU Emacs that runs within Windows, but
> within a Windows DOS box. ]
I forgot to mention one thing: I'll be away from my desk from April
4-7, and so I won't be reading any mail or newsgroups then. I'll answer
any questions when I get back (on April 8).
Darryl Okahata
> [ Here's yet another version of GNU Emacs that runs within Windows, but
> within a Windows DOS box. ]
I've had to temporarily (hopefully) withdraw this from public
distribution, as Richard Stallman has said that the current distribution
violates the GNU Public License, because it uses a proprietary DOS
extender (which is part of the compiler that is being used). I'm
working with him to resolve this, and it will, hopefully, be resolved in
a couple of weeks.
George Mills
>Darryl Okahata (dar...@srgenprp.sr.hp.com) wrote:
Regardless of the outcome and independent of this project. Can you
explain to us how you violated the GNU Public License. This may help
prevent anyone of us from making the same mistake.
G. Lee Owen
> > I've had to temporarily (hopefully) withdraw this from public
> >distribution, as Richard Stallman has said that the current distribution
> >violates the GNU Public License, because it uses a proprietary DOS
> >extender (which is part of the compiler that is being used). I'm
> >working with him to resolve this, and it will, hopefully, be resolved in
> explain to us how you violated the GNU Public License. This may help
> prevent anyone of us from making the same mistake.
As I understand it (from reading gnu.misc.discuss), the
problem is that this program requires a DOS-extender that comes with
Watcom C (which Darryl is using? I think its Watcom). The extender
can be distributed as _part_ of the binaries royalty-free, but may
_not_ be distributed as a single unit. Therefore, the software is not
technically 'free' because another user cannot recompile it from the
sources unless he has the same compiler.
I hope rms and Darryl can reach a compromise.
Greg Owen { go...@forte.cs.tufts.edu, go...@jade.tufts.edu }
Systems Programmer and TA, Tufts University Computer Science Dept.
230- All transfers are disclaimed by my host name and boss's address.
230- If you don't like this policy, disconnect now!
Darryl Okahata
> > I've had to temporarily (hopefully) withdraw this from public
> >distribution, as Richard Stallman has said that the current distribution
> >violates the GNU Public License, because it uses a proprietary DOS
> >extender (which is part of the compiler that is being used). I'm
> >working with him to resolve this, and it will, hopefully, be resolved in
> >a couple of weeks.
>
> Regardless of the outcome and independent of this project. Can you
> explain to us how you violated the GNU Public License. This may help
> prevent anyone of us from making the same mistake.
The problem is that the compiled code uses a DOS extender, for
which sources are not supplied.
Even though the sources to GNU Emacs are provided, which is enough
to recompile it, the DOS extender is causing problems. Note that there
is nothing in the SOURCES that require that this DOS extender be used;
it is the code produced by the COMPILER that requires the DOS extender.
The DOS extender comes with the compiler, and so I don't have the
sources, and, even if I did have the sources, I couldn't redistribute
them because I would not be allowed to.
George Mills
was in violation. It was still not clear to me until I read this. I hope
that person does not mind my posting this.
>Every piece of GNU must be freely distributable (with copyright notices
>intact). Proprietary code (owned by some entity other than FSF) cannot
>be in there. If every line of code is owned by FSF, they can allow it
>to go anywhere to everyone for free--if they don't, some entity may
>prevent some distribution some time in the future even if they allow
>distribution today. As we know, lawyers make their livings by stirring up
>issues that are considered settled now--we can't let the GNU project be
>subject to that kind of uncertainty (or CERTAINTY since it is the greed of
>lawyers we are talking about here).
>Stallman is a hero of our industry. Make stuff easier, not harder for the
>FSF. Write routines for GNU and give them to the FSF (not public domain,
>not shareware--true copyrighted code) and leave out stuff that came from
>any company or person who has a copyright.
>
>John D. and Catherine T. never spent a better 100 G's!
>Down with software patents!
>Let's get this industry moving forward instead of sideways!
Rob Ryan
>> Regardless of the outcome and independent of this project. Can you
>> explain to us how you violated the GNU Public License. This may help
>> prevent anyone of us from making the same mistake.
>
> The problem is that the compiled code uses a DOS extender, for
>which sources are not supplied.
>
> Even though the sources to GNU Emacs are provided, which is enough
>to recompile it, the DOS extender is causing problems. Note that there
>is nothing in the SOURCES that require that this DOS extender be used;
>it is the code produced by the COMPILER that requires the DOS extender.
>The DOS extender comes with the compiler, and so I don't have the
>sources, and, even if I did have the sources, I couldn't redistribute
>them because I would not be allowed to.
>
> -- Darryl Okahata
> Internet: dar...@sr.hp.com
I really respect the GNU operation, but is there some reason why the
program *has* to bear the GNU license? Clearly you'd have to give
credit where credit is due, but there doesn't seem to be any obvious
solutions to this until a GNUish DOS extender hits the market. I'm
skeptical that you're going to convince them to change their mind
(pardon me for saying it, but I get the impression that GNU is on its
"high horse" quite a bit). So, while you'd like to integrate your
version with the GNU project, is there really any need to do so? Or
is one obliged to get a GNU license if you use any of their code?
--
Rob Ryan, System Constructs Inc.
rr...@panix.com
Pete Halverson
>I really respect the GNU operation, but is there some reason why the
>program *has* to bear the GNU license?
Perhaps because it's based on GNU source code?
>So, while you'd like to integrate your version with the GNU project, is
>there really any need to do so? Or is one obliged to get a GNU license if
>you use any of their code?
The original code is copyrighted (actually, "copylefted") material. Just
because it's free doesn't mean it doesn't come with restrictions. In
particular, the GNU General Public License includes the following clauses:
2. You may modify your copy or copies of GNU Emacs source code or
any portion of it, and copy and distribute such modifications under
the terms of Paragraph 1 above, provided that you also do the following:
a) cause the modified files to carry prominent notices stating
that you changed the files and the date of any change; and
b) cause the whole of any work that you distribute or publish,
that in whole or in part contains or is a derivative of GNU Emacs
or any part thereof, to be licensed at no charge to all third
parties on terms identical to those contained in this License
Agreement (except that you may choose to grant more extensive
warranty protection to some or all third parties, at your option).
of which the latter precludes requiring a non-free DOS extender.
Pete Halverson INET: halv...@crd.ge.com
GE Corporate R&D Center UUCP: uunet!crd.ge.com!halverson
Schenectady, NY
Leslie Mikesell
>Someone sent me a very clear explaination of Why GNU EMacs for WIndows
>was in violation. It was still not clear to me until I read this. I hope
>that person does not mind my posting this.
>
>>Every piece of GNU must be freely distributable (with copyright notices
>>intact). Proprietary code (owned by some entity other than FSF) cannot
>>be in there. If every line of code is owned by FSF, they can allow it
>>to go anywhere to everyone for free--if they don't, some entity may
>>prevent some distribution some time in the future even if they allow
>>distribution today. As we know, lawyers make their livings by stirring up
>>issues that are considered settled now--we can't let the GNU project be
>>subject to that kind of uncertainty (or CERTAINTY since it is the greed of
>>lawyers we are talking about here).
This is actually pretty funny since what we are talking about here is
someone who *wants* to distribute free binaries along with the sourece
and it's the FSF preventing it.
>>Stallman is a hero of our industry. Make stuff easier, not harder for the
>>FSF. Write routines for GNU and give them to the FSF (not public domain,
>>not shareware--true copyrighted code) and leave out stuff that came from
>>any company or person who has a copyright.
But why should we trust the FSF to own it any more than anyone else?
Stallman could change his mind (again?) about what are "appropriate"
conditions for free distributions. And besides, Stallman won't live
forever - why should we believe that the FSF lawyers will always be
less greedy than others?
Les Mikesell
l...@chinet.chi.il.us
Darryl Okahata
> In <C5CG4...@srgenprp.sr.hp.com> dar...@srgenprp.sr.hp.com (Darryl Okahata) writes:
>
> > Even though the sources to GNU Emacs are provided, which is enough
> >to recompile it, the DOS extender is causing problems. Note that there
> >is nothing in the SOURCES that require that this DOS extender be used;
> >it is the code produced by the COMPILER that requires the DOS extender.
> >The DOS extender comes with the compiler, and so I don't have the
> >sources, and, even if I did have the sources, I couldn't redistribute
> >them because I would not be allowed to.
>
> I really respect the GNU operation, but is there some reason why the
> program *has* to bear the GNU license?
Which "program" are you talking about: my version of GNU Emacs or
the DOS extender? If you're talking about GNU Emacs, it must bear the
GPL because it is GNU code. The DOS extender, on the other hand,
CANNNOT bear the GPL because the DOS extender does not belong to me (I
did NOT write it), and this is the crux of the matter.
-- Darryl Okahata
Internet: dar...@sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
Christopher Rath
>> Someone sent me a very clear explaination of Why GNU EMacs for WIndows
>> was in violation. It was still not clear to me until I read this. I hope
This is still NOT clear to me, even with the posted explanation.
>> that person does not mind my posting this.
>>
>> >Every piece of GNU must be freely distributable (with copyright notices
>> >intact). Proprietary code (owned by some entity other than FSF) cannot
>> >be in there. If every line of code is owned by FSF, they can allow it
>> >to go anywhere to everyone for free--if they don't, some entity may
>> >prevent some distribution some time in the future even if they allow
>> >distribution today.
"some entity" ... you mean, someone like the FSF? I think this
specific prevention of the distribution of GNU EMacs for WIndows by
the FSF is a case in point.
>> > As we know, lawyers make their livings by stirring up
>> >issues that are considered settled now--we can't let the GNU project be
>> >subject to that kind of uncertainty (or CERTAINTY since it is the greed of
>> >lawyers we are talking about here).
>> >Stallman is a hero of our industry.
However there isn't any legal precedence I'm aware of for what is
being suggested in the above quote. If Watcom allows free
distribution of code compiled by their compiler (and last time I
checked they did), then even if they change their mind at some time in
the future, how does that change of heart alter the rights granted to
an executable compiled today?
>> > Make stuff easier, not harder for the
>> >FSF. Write routines for GNU and give them to the FSF (not public domain,
>> >not shareware--true copyrighted code) and leave out stuff that came from
>> >any company or person who has a copyright.
I agree. It would be great if someone wrote an MS-DOS extender and
donated it to the FSF. However, what's wrong with using the tools at
hand, be they commercial or otherwise? Especially if the commercial
tool in question specifically allows distribution of binaries
generated using that tool!
>> >
>> >John D. and Catherine T. never spent a better 100 G's!
>> >Down with software patents!
>> >Let's get this industry moving forward instead of sideways!
Someone else on this thread has suggested that the FSF is on a
high-horse regarding this issue. I have to agree with that sentiment.
If there is a real issue here then why does the FSF allow some
commercial companies to bundle FSF code and executables along with
their machines, even though every line of code written and distributed
by those vendors is not *owned* by the FSF. There seems to be a
double standard at work here!
These are my thoughts, not my employers,
Christopher
P.S. I spend a considerable amount of time trying to formulate a
rational response. I realize this is an emotionally laden issue, but
please file name-calling, irrational flames to /dev/null. I reserve
the right to post privately mailed flames of the name-calling type.
--
Christopher Rath | cr...@bnr.ca
BNR Lab 5 |
Ottawa, ON, Canada | "Hydrogen is a colourless, odourless gas which, given
(613) 765-3141 | enough time, turns into people." -- Henry Hiebert
Jason Zions
> I've had to temporarily (hopefully) withdraw this from public
>distribution, as Richard Stallman has said that the current distribution
>violates the GNU Public License, because it uses a proprietary DOS
>extender (which is part of the compiler that is being used). I'm
>working with him to resolve this, and it will, hopefully, be resolved in
>a couple of weeks.
Darryl -
If I understand correctly, Stallman only has a gripe if you distribute
binaries. At the very least, you can distribute source, can't you? It would
be like porting gnu emacs to native VMS and VMS/C; if you don't have VMS and
the DEC C compiler, the code is no help to you, but if you had the compilers
you'd be okay. The same would apply here - if you had a compiler which
produced protected-mode code, it would work.
Or does your port incorporate calls directly to the DOS-mode extender? Can
you extract those into macros or portability routines? The idea is that
anyone could take your code and run it through any compiler capable of
compiling it.
Of course, what I personally wish for is a port of epoch to Win/3.1; i.e. a
server that creates editing screens as needed, rather than an emacs that
runs as a DOS app in a window. I know, picky picky, dream on. If I ever find
time for another hobby, I'll let y'all know.
Jazz
P.S. Hi, Darryl! Drop me a line and let me know what you're up to!
Jason Zions HaL Computer Systems ja...@hal.com
David H Shane
I'm looking for a small editor written for use in X Windows.
I'd like to source to it so that I can compile it on my machine and
maybe see how it works. If you know of anything a little more
versitile than xedit and less cumbersome than emacs, I'd appreciate
it if you would let me know either by e-mail or posting here.
Thanks
Chris Waters
>I really respect the GNU operation, but is there some reason why the
>program *has* to bear the GNU license?
Yes. The program in question is a copyrighted product of the FSF (the
"GNU operation").
> Clearly you'd have to give
>credit where credit is due, but there doesn't seem to be any obvious
>solutions to this until a GNUish DOS extender hits the market.
That *is* whole reason for the existence of the GPL! To motivate people
to create free software. The restrictions on GNU code exist for this
purpose alone. Yes, the correct solution *is* to build a GNUish DOS
extender.
> I'm
>skeptical that you're going to convince them to change their mind
>(pardon me for saying it, but I get the impression that GNU is on its
>"high horse" quite a bit).
Why? Because they wish to retain control over the code they wrote? How
does that make them any different from any other source of non public
domain software? Just because they don't charge money for their work?
Seems like pretty screwy reasoning to me! If you don't like their
licensing terms, go to another vendor! :-)
--
Chris Waters | the insane don't |"Judy's in the bedroom,
xt...@netcom.COM| need disclaimers | Inventing situations." -D. Byrne
Chris Waters
>In article <mills.7...@dialup.athena.lkg.dec.com> mi...@athena.lkg.dec.com (George Mills) writes:
>This is actually pretty funny since what we are talking about here is
>someone who *wants* to distribute free binaries along with the sourece
>and it's the FSF preventing it.
The purpose of the FSF is to encourage the creation of freely
distributable SOURCE! Not to give away free binaries. In fact, they
*encourage* people to charge money for creating, distributing, and
supporting binaries.
>But why should we trust the FSF to own it any more than anyone else?
What does that have to do with anything? They *own* the code! Whether
you trust them or not has *nothing* to do with it!
>Stallman could change his mind (again?) about what are "appropriate"
>conditions for free distributions.
Yes he can, that's his right, he owns the code.
Chris Waters
>In article <mills.7...@dialup.athena.lkg.dec.com> mi...@athena.lkg.dec.com (George Mills) writes:
>>> Someone sent me a very clear explaination of Why GNU EMacs for WIndows
>>> was in violation. It was still not clear to me until I read this. I hope
>This is still NOT clear to me, even with the posted explanation.
It's very simple. The purpose of the FSF is to encourage the creation
of freely redistributable SOURCE code. For this reason, they do not
allow their code to be linked in with any other code unless the source
is freely available for that other code.
Before I go on, I have to say that this article displayed more insight
into the real issues involved here than the several other whining posts
I saw previously. This one asks some good questions, and deserves a
detailed response.
>>> >Every piece of GNU must be freely distributable (with copyright notices
>>> >intact). Proprietary code (owned by some entity other than FSF) cannot
>>> >be in there. If every line of code is owned by FSF, they can allow it
>>> >to go anywhere to everyone for free--if they don't, some entity may
>>> >prevent some distribution some time in the future even if they allow
>>> >distribution today.
>"some entity" ... you mean, someone like the FSF? I think this
>specific prevention of the distribution of GNU EMacs for WIndows by
>the FSF is a case in point.
There is absolutely *nothing* here preventing anyone from distributing
source code. Binaries are another matter. The FSF puts more severe
limitations on the distribution of binaries, because they want to
encourage the distribution of source, rather than binaries. And, under
fair use laws, there is no way for the FSF to prevent you from linking
their code with proprietary code *for your own use*. Nor do they wish
to prevent this. They merely wish to prevent people from
*redistributing* binaries linked with proprietary code.
Actually, proprietary code is the wrong word here--FSF code *is*
proprietary. It is just freely distributable. The FSF owns the
copyright on GNU EMACS, and it is technically as proprietary as, e.g.,
MS Windows. They just have more liberal distribution policies (and
lower prices :) than MS. They *do*, however, wish to prevent you from
linking their code with non-GPL'd code. (They make a specific exception
for the system libraries that come with a compiler.) That is their
right, it is their code. TANSTAAFL.
>>> > As we know, lawyers make their livings by stirring up
>>> >issues that are considered settled now--we can't let the GNU project be
>>> >subject to that kind of uncertainty (or CERTAINTY since it is the greed of
>>> >lawyers we are talking about here).
>>> >Stallman is a hero of our industry.
>However there isn't any legal precedence I'm aware of for what is
>being suggested in the above quote. If Watcom allows free
>distribution of code compiled by their compiler (and last time I
>checked they did), then even if they change their mind at some time in
>the future, how does that change of heart alter the rights granted to
>an executable compiled today?
It doesn't. This is why the FSF has to insist on the *letter* of the
GPL. Perhaps they might like to allow the distribution of an MS Windows
version of EMACS that uses a free-but-non-GPLed-and-no-source-code-
available DOS extender, but it still violates their existing license,
and they would have to create a new license to allow this. Otherwise,
they could justly be accused of playing favorites, and could be in for
serious legal problems, especially from some of their commercial customers.
To be honest, though, I doubt if they really care that much about the
problems of Windows users. If you ask RMS, he might simply suggest that
you switch to an OS/GUI where you don't have these kind of problems.
Which is my feeling as well, but I'm trying not to let my personal
prejudices interfere with rational discourse here. :-)
(I will mention that you wouldn't have these sorts of problems, *and*
you'd still be able to use all your favorite Windows programs, if you'd
switch to OS/2. EMACS has been available for OS/2 for nearly a year.
And, having mentioned it, I'll drop the subject.) :-)
>I agree. It would be great if someone wrote an MS-DOS extender and
>donated it to the FSF. However, what's wrong with using the tools at
>hand, be they commercial or otherwise? Especially if the commercial
>tool in question specifically allows distribution of binaries
>generated using that tool!
It's a violation of the GPL. The GPL has to do specifically with the
distribution of source. Distribution of binaries is almost an
afterthought. The purpose of the FSF is not to give people free
programs (in fact, there is nothing wrong with charging money for FSF
code), it is to make sure that people can get the source to their
programs. RMS is a programmer, and he wants the SOURCE, dammit! <grin>
>>> >John D. and Catherine T. never spent a better 100 G's!
>>> >Down with software patents!
>>> >Let's get this industry moving forward instead of sideways!
>Someone else on this thread has suggested that the FSF is on a
>high-horse regarding this issue. I have to agree with that sentiment.
Hey, if you don't like their policies, go to another vendor! :-)
>If there is a real issue here then why does the FSF allow some
>commercial companies to bundle FSF code and executables along with
>their machines, even though every line of code written and distributed
>by those vendors is not *owned* by the FSF. There seems to be a
>double standard at work here!
That is covered by the "mere aggregation" clause of the GPL. If these
commercial companies actually linked their non-GPLed code in with FSF's
code, that would be a violation of the GPL. However, providing a binary
for EMACS and a binary for a non-GPLed version of, say, ksh is not a
problem, even if they're both stored on the same tape. As long as gcc
and ksh aren't linked together. :-)
I'm sure that NeXT, and other companies that distribute GPLed code are
*very* careful to keep that separate from their *own* proprietary code!
>P.S. I spend a considerable amount of time trying to formulate a
>rational response. I realize this is an emotionally laden issue, but
>please file name-calling, irrational flames to /dev/null. I reserve
>the right to post privately mailed flames of the name-calling type.
I think you did a good job of making it clear what your concerns in this
issue are. I hope I did an equally good job of explaining what the
situation is really like. However, my mailbox is always open to flames
if you don't like my posts! :-)
cheers
Charles R. Martin
the point is that since the compiler Darryl is using uses a proprietary
extender, Stallman feels that the distribution of binaries violates the
GPL.
But then I'd also understood that Stallman/FSF also have held that they
preserve no proprietary rights to binaries compiled from GCC; according
to the notes on this so far, Watcom doesn't restrict the distribution of
the binaries from their compiler; and Darryl has promised to distribute
the modified sources.
So it appears that the problem is that Darryl wants to distribute free
binaries and FSF sources.
So what's the problem?
--
Charles R. Martin/(Charlie)/mar...@cs.unc.edu/Dept. of Computer Science/CB
#3175 UNC-CH/Chapel Hill, NC 27599-3175/3611 University Dr #13M/Durham, NC
27707/(919) 419 1754/"Ignorant opinions are just not as useful as informed
ones." -- James Preston
Darryl Okahata
Last Friday, RMS sent the following messsage to gnu-emacs-help:
-------------------------------------------------------------------------------
Date: Fri, 09 Apr 1993 17:05:12 EDT
To: help-gn...@gnu.ai.mit.edu
From: r...@gnu.ai.mit.edu (Richard Stallman)
Subject: Emacs and memory extenders
From help-gnu-em...@prep.ai.mit.edu Sat Apr 10 06: 04:23 1993
I've concluded that the GPL does allow distributing Emacs
linked with a memory extender *provided* the extender comes
with the compiler you compile it with. This portion of the GPL
permits it, because the compiler counts as a major component
of the operating system.
...the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs...
So there's no problem with the Windows port that was announced a
couple of days ago.
I had to let some time elapse so I could feel confident of this
conclusion, before stating it.
-------------------------------------------------------------------------------
From the above message and private communications with him, RMS
considers a compiler something that is "normally distributed with the
major components of the operating system", regardless of whether or not
it actually comes with the operating system. As a result, as long as a
library or DOS extender COMES WITH the compiler, the library or extender
does not have to fall under the GPL.
Yay!
Andrew Berry
heard anyone suggest the Watcom (Darryl's compiler vendor) could be
asked to distribute their DOS extender freely. Darryl could then simply
distribute the emacs binary (and source), and put the extender on some
FTP sites for downloading by those who need it.
Would this still violate the GPL?
If not, then given the amount of controversy that this issue has caused,
it would be good publicity for Watcom, so it's probably worth a try.
--
AndyB (Andrew Berry)
======================================================================
DSTC \||/ internet: be...@dstc.edu.au
University of Queensland @@ voice: +61 7 365 4378
Australia \/ fax: +61 7 365 4399
Darryl Okahata
> I've been following this thread for a few days now, and haven't yet
> heard anyone suggest the Watcom (Darryl's compiler vendor) could be
> asked to distribute their DOS extender freely. Darryl could then simply
> distribute the emacs binary (and source), and put the extender on some
> FTP sites for downloading by those who need it.
>
> Would this still violate the GPL?
No, but it would violate WATCOM's licensing agreement, which says
something like the DOS extender can only be distributed as part of a
program complied with WATCOM C/386.
In any event, everything seems to have been clarified and resolved.
See my earlier postin for details.
Darryl Okahata
*AND* an MS WIndows DOS box, is again available via anonymous ftp. The
uncertainties between this version and the GNU Public License have been
cleared up, and it can again be made availble. Sources and binaries are
part of the standard distribution.
For those of you who missed the first announcement, a copy of it
has been appended to this message. PLEASE READ IT CAREFULLY BEFORE
DECIDING TO DOWNLOAD A COPY.
-- Darryl Okahata
Internet: dar...@sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion or policy of Hewlett-Packard or of the
little green men that have been following him all day.
===============================================================================
[ Here's yet another version of GNU Emacs that runs within Windows, but
within a Windows DOS box. ]
A preliminary version of "oemacs" has been made available via
anonymous ftp. Oemacs is, basically, a version of GNU Emacs V18.59 that
will work inside a Windows 3.1 DOS box (note that it is NOT a native
Windows application, but works within a DOS box). It is partially based
upon demacs, but is not compatible with it.
At the end of this message, I've enclosed a copy of the file
"readme.dos", which describes the features and problems of oemacs. READ
THIS BEFORE OBTAINING OEMACS.
***** Why would you want to use "oemacs"? Because:
* It works within a Windows DOS box. If you're feeling particularly
masochistic, you can start more than one copy of oemacs, each in a
different DOS box.
* It works with plain MSDOS or Windows 3.1.
* It fixes some bugs that demacs has.
* It is based upon GNU Emacs V18.59.
* It contains a few more useful emacs-lisp packages. One or two of the
existing emacs-lisp packages have been upgraded, like info.el.
* Pressing Ctrl-Break at *ANY* time will interrupt whatever Emacs is
doing (assuming that it has not crashed and is not running
"subprocesses"). With demacs, pressing Ctrl-Break just sends a C-c to
demacs.
***** Why would you *NOT* want to use "oemacs"? Because:
* It requires lots of RAM and lots of disk space. In order to run
within Windows, you need at least 8MB of motherboard RAM, and I
recommend that you have at least 12-16MB. You also need about 14MB of
disk space to install oemacs, *NOT* including any space used to hold
the .ZIP distribution files. Demacs requires much less resources.
* It can take a while to start up (because it is not dumped, as is
demacs). On my 33MHz 486DX, it takes about 10 seconds to start up.
Demacs starts up much faster.
* It doesn't handle large files very well. Demacs works much better for
this. The biggest file that oemacs can handle is probably just under
16MB (although I haven't tried this -- the largest file that I've
tried editing is 5MB).
* It has a fixed internal stack size. Any highly recursive emacs-lisp
functions *might* fail with this version. However, to minimize this
problem, I've set the maximum stack size to 300KB. A typical Emacs
running on my (real ;-) workstation at work uses up 100-150KB of
-- Darryl Okahata
Internet: dar...@sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion or policy of Hewlett-Packard or of the
little green men that have been following him all day.
===============================================================================
filename has been renamed from "c++-mode.el" to "cxx-mode.el".
alex colburn
Followup-To:
Distribution: inet
Organization: University of Iowa, Image Analysis Facility
Keywords:
How about vi? :)
Alex.
--
__ __| \ __| Alex Colburn
| / \ | Image Analysis Facility
| _____ \ __| University of Iowa
______| _/ _\ _| col...@tessa.iaf.uiowa.edu
Richard L. Krehbiel
> Someone else on this thread has suggested that the FSF is on a
> high-horse regarding this issue. I have to agree with that sentiment.
Instead of "high horse" you could say "insistent about their
ideology", which is of course true, because it is the purpose of the
FSF to promote the ideology that source code should be freely
available.
--
Richard Krehbiel ri...@kastle.com or ri...@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
Jim Edwards-Hewitt
dar...@srgenprp.sr.hp.com (Darryl Okahata) writes:
> The problem is that the compiled code uses a DOS extender, for
>which sources are not supplied.
>
> Even though the sources to GNU Emacs are provided, which is enough
>to recompile it, the DOS extender is causing problems. Note that there
>is nothing in the SOURCES that require that this DOS extender be used;
>it is the code produced by the COMPILER that requires the DOS extender.
>The DOS extender comes with the compiler, and so I don't have the
>sources, and, even if I did have the sources, I couldn't redistribute
>them because I would not be allowed to.
I fail to see what the distinction is between the DOS extender and the
libraries supplied with the compiler. The DOS extender is not a separate
piece of software, it is something supplied in object form which is bound
into the program in the process of producing an executable. (I use Watcom,
so I know how it works.) If this is prohibited, why is linking with ANY
vendor-supplied library permitted?
-- Jim
---------------------------------------------------------------------------
Jim Edwards-Hewitt j...@visix.com | Aieee! Death from above!
Visix Software Inc. ...!uupsi!visix!jim | -- Sam&Max
---------------------------------------------------------------------------
Jonathan M. Gilligan
compiler and linking with the commercial vendor's proprietary
implementation of the standard C library (printf, etc.) does not
violate the GPL (witness RMS's acceptance of the GNUish DOS project,
whose binary executable files contained proprietary implementations of
the standard C library), but linking with a proprietary OS-extender
(specifically for MS-DOS in this case) does. I'm a bit thick and do
not see the essential difference.
---Jon
--
Disclaimer --- The government probably disagrees with my opinions.
Milt Epstein
>In article <mills.7...@dialup.athena.lkg.dec.com> mi...@athena.lkg.dec.com (George Mills) writes:
[ ... ]
>>>Stallman is a hero of our industry. Make stuff easier, not harder for the
>>>FSF. Write routines for GNU and give them to the FSF (not public domain,
>>>not shareware--true copyrighted code) and leave out stuff that came from
>>>any company or person who has a copyright.
>
>But why should we trust the FSF to own it any more than anyone else?
>Stallman could change his mind (again?) about what are "appropriate"
>conditions for free distributions. And besides, Stallman won't live
>forever - why should we believe that the FSF lawyers will always be
>less greedy than others?
Taken from the GPL (you can view it online in GNU Emacs by doing "C-h
C-c"):
| 7. The Free Software Foundation may publish revised and/or new versions
|of the General Public License from time to time. Such new versions will
|be similar in spirit to the present version, but may differ in detail to
|address new problems or concerns.
|
|Each version is given a distinguishing version number. If the Program
|specifies a version number of the license which applies to it and "any
|later version", you have the option of following the terms and conditions
|either of that version or of any later version published by the Free
|Software Foundation. If the Program does not specify a version number of
|the license, you may choose any version ever published by the Free Software
|Foundation.
This clause seems to protect people pretty well from drastic changes
in the GPL -- it guarantees that anything covered by it will be *at
least* as free as the version it was licensed under. In fact, when I
read this clause, I was quite surprised -- I've never heard of a
guarantee over changes in conditions over time like it.
--
Milt Epstein
Department of Computer Science
University of Illinois
eps...@cs.uiuc.edu
Milt Epstein
> OK, this issue seems to have been cleared up.
>
> Last Friday, RMS sent the following messsage to gnu-emacs-help:
[message deleted]
>From the above message and private communications with him, RMS
>considers a compiler something that is "normally distributed with the
>major components of the operating system", regardless of whether or not
>it actually comes with the operating system. As a result, as long as a
>library or DOS extender COMES WITH the compiler, the library or extender
>does not have to fall under the GPL.
I'm still not totally clear on what's involved in this issue, and I
hope you can bear a few more questions.
Is the DOS extender in question needed in order to use the package
you're making available?
If yes, then even though this may not violate the letter of the
current GPL, doesn't it violate the spirit (i.e. this package is not
available free to everyone -- they must have that compiler/extender)?
If not, why was it an issue at all? Was it because you just happened
to use that compiler/extender to create the binaries you're
distributing? Couldn't you have used a different compiler? I saw a
post of yours that said the sources in your package were sufficient to
allow recompilation -- did that mean possibly with a different
compiler than the one that has the extender?
(None of these questions are intended as flames -- I'm just trying to
understand the situation.)
Thanks.
Darryl Okahata
> If I understand correctly, Stallman only has a gripe if you distribute
> binaries.
Yes, but this has been cleared up, at least for my version of MSDOS
GNU Emacs. There apparently are still problems with the Windows-only
version of GNU Emacs.
> At the very least, you can distribute source, can't you? It would
> be like porting gnu emacs to native VMS and VMS/C; if you don't have VMS and
> the DEC C compiler, the code is no help to you, but if you had the compilers
> you'd be okay. The same would apply here - if you had a compiler which
> produced protected-mode code, it would work.
Unfortunately, the vast majority of MSDOS users do not have a
compiler. Distributing sources is somewhat like giving seeds to
starving people.
> Or does your port incorporate calls directly to the DOS-mode extender? Can
> you extract those into macros or portability routines? The idea is that
> anyone could take your code and run it through any compiler capable of
> compiling it.
No, there are no calls specific to this DOS extender, although
there are calls to an MSDOS DPMI provider, of which this DOS extender is
one. Doing this is fine by the GPL, as it's possible for people to use
other DOS extenders which do not provide DPMI services, as long as they
have a DPMI provider installed on their system (in other words, any
required parts would be independent ("part" of the OS) and distributed
separately from this GPL-encumbered program).
> Of course, what I personally wish for is a port of epoch to Win/3.1; i.e. a
> server that creates editing screens as needed, rather than an emacs that
> runs as a DOS app in a window. I know, picky picky, dream on. If I ever find
> time for another hobby, I'll let y'all know.
I've been toying with the idea of modifying my version to be a
native Windows application, but I don't know if it's really worth doing.
I'm happy with running Emacs within a DOS window.
Darryl Okahata
> Is the DOS extender in question needed in order to use the package
> you're making available?
The compiled binaries need it. The sources do not.
> If yes, then even though this may not violate the letter of the
> current GPL, doesn't it violate the spirit (i.e. this package is not
> available free to everyone -- they must have that compiler/extender)?
As RMS has recently said, this is fine as long as the DOS extender
is part of the compiler, which it is, in this case.
> If not, why was it an issue at all? Was it because you just happened
> to use that compiler/extender to create the binaries you're
> distributing?
Yes.
> Couldn't you have used a different compiler?
Not really. The number of MSDOS compilers with the necessary
features are very few. The biggest problem is that there are very few
compilers that produce flat, 32-bit code that runs within an MS Windows
DOS box.
> I saw a
> post of yours that said the sources in your package were sufficient to
> allow recompilation -- did that mean possibly with a different
> compiler than the one that has the extender?
In theory, yes. You'd have to tweak a few #ifdefs, though.
Gary Moyer
Hows about Axe? Its relatively small and has an emacs-like interface.
Its multi-windowed with builtin help.
Check out one of the X oriented archives and you should find it..
-g.m.