Newsgroups: comp.emacs,comp.editors,comp.os.ms-windows.programmer.tools
Path: gmd.de!newsserver.jvnc.net!yale.edu!nigel.msen.com!sdd.hp.com!
col.hp.com!news.dtc.hp.com!srgenprp!darrylo
From: darr...@srgenprp.sr.hp.com (Darryl Okahata)
Subject: GNU Emacs for MS-Windows and MSDOS
Sender: n...@srgenprp.sr.hp.com (News Administrator)
Message-ID: <C4vIHC.1G9@srgenprp.sr.hp.com>
Date: Fri, 2 Apr 1993 20:34:23 GMT
Reply-To: darr...@sr.hp.com
Organization: Hewlett-Packard / Center for Primal Scream Therapy
X-Newsreader: TIN [version 1.1 PL9.2]
Lines: 471
[ 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.
* 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: darr...@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 (kend...@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.
Path: gmd.de!Germany.EU.net!mcsun!uunet!decwrl!bu.edu!nntp-read!jbw
From: j...@bigbird.bu.edu (Joe Wells)
Newsgroups: gnu.emacs.help,gnu.misc.discuss
Subject: Re: GNU Emacs for MS-Windows and MSDOS
Message-ID: <JBW.93Apr5203422@bigbird.bu.edu>
Date: 6 Apr 93 01:34:22 GMT
References: <9304022042.AA08053@hpnmxx.sr.hp.com>
Sender: n...@bu.edu
Followup-To: gnu.emacs.help
Organization: Boston University Computer Science Department
Lines: 16
In-reply-to: darrylo@hpnmxx.sr.hp.com's message of 2 Apr 93 20:57:42 GMT
In article <9304022042.AA08...@hpnmxx.sr.hp.com> darr...@hpnmxx.sr.hp.com
(Darryl Okahata) writes:
[ Note: with the exception of the DOS extender, this version falls under
the GNU Public License. ]
[ Here's yet another version of GNU Emacs that runs within Windows, but
within a Windows DOS box. ]
Is the DOS extender linked with a distributed binary? Is this allowed by
the GNU General Public License?
??????
--
Joe Wells <j...@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details
Path: gmd.de!Germany.EU.net!mcsun!uunet!zaphod.mps.ohio-state.edu!
pacific.mps.ohio-state.edu!cis.ohio-state.edu!hpnmxx.sr.hp.com!darrylo
From: darr...@hpnmxx.sr.hp.com (Darryl Okahata)
Newsgroups: gnu.misc.discuss
Subject: Re: GNU Emacs for MS-Windows and MSDOS
Date: 7 Apr 1993 21:30:53 -0400
Organization: GNUs Not Usenet
Lines: 83
Sender: dae...@cis.ohio-state.edu
Distribution: gnu
Message-ID: <9304080124.AA09833@hpnmxx.sr.hp.com>
In gnu.emacs.help, Joe Wells (j...@bigbird.bu.edu) writes:
> In article <9304022042.AA08...@hpnmxx.sr.hp.com> darr...@hpnmxx.sr.hp.com
(Darryl Okahata) writes:
>
> [ Note: with the exception of the DOS extender, this version falls under
> the GNU Public License. ]
>
> [ Here's yet another version of GNU Emacs that runs within Windows, but
> within a Windows DOS box. ]
>
> Is the DOS extender linked with a distributed binary? Is this allowed by
> the GNU General Public License?
The DOS extender is a royalty-free, redistributable part of the C
compiler that I used (in this case, WATCOM C/386). The DOS extender is
part of the compiler's runtime environment, and is a separate
executable/program. Note that I do *NOT* have the source code for the
DOS extender.
The problem here is that the GPL seems a bit "vague" regarding
compiler libraries/environments. As far as the source code for my
version of GNU Emacs is concerned, the DOS extender is *NOT* necessary.
However, the machine code generated by the C compiler does require the
DOS extender.
Because the FSF has, in the past, allowed the distribution of
binaries that require the use of "libraries" which do not fall under the
GPL, I assumed that DOS extenders (which can be considered a form of
runtime "library") would pose no problems with the GPL. After all,
there is nothing in the source code that requires the presence of a DOS
extender; only the compiler-generated machine code requires it.
However, I'm not a lawyer, and could easily be wrong.
BTW, Pearl Software's Win-Emacs uses the same compiler that I use.
For Win-Emacs, the "DOS extender" has been bound into the executable
(here, "bound" means "merging"; it is very similar to, but is not the
same as, the process of linking). Unfortunately, only native Windows
programs can take advantage of "binding"; programs which run under MSDOS
or within a Windows DOS box cannot have the DOS extender merged into
them. [ In any case, the process of "binding" is only a subterfuge that
hides the fact that a proprietary DOS extender is being used. ]
If this is not allowed, then the only alternative is to completely
stop the distribution of this "free" software. Why? Read on.
It can be suggested that the problem can be solved by separating
the DOS extender from the Emacs distribution. Unfortunately, this
cannot be done, because the license for the DOS extender requires it to
be distributed WITH the binary produced by the compiler; it cannot be
separately distributed.
It can be suggested that a different compiler be used.
Unfortunately, I don't know of ANY other compiler that allows the
corresponding DOS extender to be separately distributed, and meets the
following (necessary) criteria:
1. Produces flat, 32-bit code that runs under MSDOS.
2. Produces code that runs within Microsoft Windows.
3. Has a DOS extender that is royalty-free, and can be redistributed with
compiled programs. There are other DOS extenders, but they either do
not work within Microsoft Windows, or are not royalty-free.
The MSDOS GCC fails criteria #2 above, and so I can't use it. [ And
please don't propose that I help modify the DOS GCC to work within
Microsoft Windows. While I *might* be able to do it, it would take a
couple of months of painful work, and I'm much rather go to the dentist
and have my mouth excavated, than do it. ]
I really hope that there's no problem distributing the DOS extender
as part of the Emacs package. If there is, I'll have to stop
distributing this version entirely, as I don't know of any other way to
meet the terms of the GPL. This would make a lot of people very
unhappy, and reduce the amount of "free" software. I want to write
"free" software, and I hope that the GPL won't hinder me.
-- Darryl Okahata
Internet: darr...@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.
Path: gmd.de!ira.uka.de!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!
magnus.acs.ohio-state.edu!cis.ohio-state.edu!gnu.ai.mit.edu!rms
From: r...@gnu.ai.mit.edu (Richard Stallman)
Newsgroups: gnu.misc.discuss
Subject: Re: GNU Emacs for MS-Windows and MSDOS
Date: 8 Apr 1993 02:05:00 -0400
Organization: GNUs Not Usenet
Lines: 18
Sender: dae...@cis.ohio-state.edu
Distribution: gnu
Message-ID: <9304080600.AA13497@mole.gnu.ai.mit.edu>
References: <9304080124.AA09833@hpnmxx.sr.hp.com>
I think your executable violates the GPL. As it stands, it is not
free software--it is a black box which users can only execute.
The purpose of the GNU project and the GPL is to spread free
software--which means, among other things, that *every* user has to
have access to the complete source code.
So, for now, you'll have to stop distributing this executable. You
can distribute the sources for the modified GNU program.
By the way, Pearl Software is also violating the GPL for various
reasons, as I've already announced. I've already taken this matter up
with them.
It might be possible to find a way to permit what you'd like to do.
I'm willing to discuss it with you to look for a way. But ensuring
the integrity of the GPL is paramount.
Path: gmd.de!ira.uka.de!scsing.switch.ch!news.univie.ac.at!
paladin.american.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!
pacific.mps.ohio-state.edu!cis.ohio-state.edu!hpnmxx.sr.hp.com!darrylo
From: darr...@hpnmxx.sr.hp.com (Darryl Okahata)
Newsgroups: gnu.misc.discuss
Subject: MSDOS GNU Programs violate the GPL
Date: 8 Apr 1993 12:54:17 -0400
Organization: GNUs Not Usenet
Lines: 81
Sender: dae...@cis.ohio-state.edu
Distribution: gnu
Message-ID: <9304081649.AA22343@hpnmxx.sr.hp.com>
References: <9304080600.AA13497@mole.gnu.ai.mit.edu>
> I think your executable violates the GPL. As it stands, it is not
> free software--it is a black box which users can only execute.
It is not a black box. The sources to GNU Emacs are included, and
users need only a compiler with certain features (e.g., flat, 32-bit
linear address space). I know of two compilers that meet this criteria,
and there are probably others.
There is NOTHING in the SOURCE CODE that requires the use of a
proprietary library, etc.. The COMPILER-GENERATED BINARY, however, does
require a runtime program.
The key paragraph in the GPL (version 2) is:
------------------------------------------------------------------------------
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, 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, unless that component
itself accompanies the executable.
-------------------------------------------------------------------------------
By the above paragraph, JUST ABOUT EVERY MSDOS PROGRAM VIOLATES THE GPL,
AND HAS DONE SO FOR YEARS. If you're worried about preserving the GPL,
you'd better stop the distribution of virtually all MSDOS executables
(with the probable exception of DJGCC-compiled executables).
Why? Because the word "accompany" (in the last sentence) is
somewhat vague. By "accompany", an argument can be made that, because
proprietary libraries are linked into a binary, the proprietary routines
*accompany* the executable, which means that the source code for the
proprietary routines must also be provided in order to preserve the GPL.
I can think of a number of MSDOS GNU programs (e.g., ghostscript) that
violate the GPL, and have done so for quite some time.
I'd say that proprietary libraries "go with" MSDOS executables:
-------------------------------------------------------------------------------
Word: accompany
ac.com.pa.ny \-(*-)ne_-\ vb
1: to go or occur along with : ESCORT, ATTEND
2: to play an accompaniment for
-- ac.com.pa.nist \-(*-)n*st\ n
-------------------------------------------------------------------------------
An argument can probably be made that, because the FSF has allowed
these MSDOS executables to be distributed for so long, the GPL may be
found null and void.
What is the reasoning behind the phrase "unless that component
itself accompanies the executable" in:
-------------------------------------------------------------------------------
However, as a special exception, 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, unless that component
itself accompanies the executable.
-------------------------------------------------------------------------------
That last phrase is what's causing the problems. With MSDOS, compiled
programs may require "runtime components", which few users may already
have.
If you want to distribute "usable" software for MSDOS, you must
distribute binaries (in addition to the source code). If you don't,
only a small percentage of users will be able to use the program,
because only a small percentage of users have a compiler.
Is there any way that the GPL can be amended to handle the case
where a program DOES NOT REQUIRE a library/program to compile, but DOES
REQUIRE one to execute?
-- Darryl Okahata
Internet: darr...@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.
Path: gmd.de!ira.uka.de!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!
pacific.mps.ohio-state.edu!cis.ohio-state.edu!gnu.ai.mit.edu!rms
From: r...@gnu.ai.mit.edu (Richard Stallman)
Newsgroups: gnu.misc.discuss
Subject: Re: MSDOS GNU Programs violate the GPL
Date: 8 Apr 1993 16:23:24 -0400
Organization: GNUs Not Usenet
Lines: 46
Sender: dae...@cis.ohio-state.edu
Distribution: gnu
Message-ID: <9304082018.AA15154@mole.gnu.ai.mit.edu>
References: <9304081649.AA22343@hpnmxx.sr.hp.com>
There is NOTHING in the SOURCE CODE that requires the use of a
proprietary library, etc.. The COMPILER-GENERATED BINARY, however, does
require a runtime program.
Exactly. Thus, distributing the modified Emacs source code is
certainly legitimate; but distributing the executable raises a
problem, because the executable is (partly) a black box and users
cannot reconstruct it from the source.
I'd say that proprietary libraries "go with" MSDOS executables:
They do, but that question has nothing to do with what the GPL
permits.
The GPL exception is for proprietary libraries that accompany *the
components of the operating system*. Not for libraries that accompany
the executable.
There is no sense in which proprietary libraries that "go with" the
executable are on that account permitted for use in free executables.
Rather the reverse. The exception has an exception:
...operating system on which the executable runs, unless that component
itself accompanies the executable.
In longer words, this says: if the library comes with a component of
the operating system, but that component of the operating system comes
with the executable in question, then the library *may not* be used in
the executable (unless the library is free, of course).
This exception to the exception places an extra requirement on
operating system distributors, but not on anyone else. It blocks a
loophole that would permit various abuses if it were not blocked.
I suggest that people raise these issues with me in private if they
wish to do so constructively. In a private discussion, I can
entertain ideas tentatively, which is important for solving problems;
but it would be inadvisable for me to do this in public statements.
People who insist on posting rather than discussing the issue with me
should use gnu.misc.discuss. That's the mailing list/newsgroup which
is appropriate for such topics.
I urge all readers to take everything other people post about the
meaning of the GPL with a pound of salt.
Newsgroups: comp.emacs,comp.editors,comp.os.ms-windows.programmer.tools
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!sdd.hp.com!
hpscit.sc.hp.com!news.dtc.hp.com!srgenprp!darrylo
From: darr...@srgenprp.sr.hp.com (Darryl Okahata)
Subject: Re: GNU Emacs for MS-Windows and MSDOS
Sender: n...@srgenprp.sr.hp.com (News Administrator)
Message-ID: <C56rIy.3Gu@srgenprp.sr.hp.com>
Date: Thu, 8 Apr 1993 22:23:21 GMT
Reply-To: darr...@sr.hp.com
References: <C4vIHC.1G9@srgenprp.sr.hp.com>
Organization: Hewlett-Packard / Center for Primal Scream Therapy
X-Newsreader: TIN [version 1.1 PL9.2]
Followup-To: comp.emacs,comp.editors,comp.os.ms-windows.programmer.tools
Lines: 18
Darryl Okahata (darr...@srgenprp.sr.hp.com) wrote:
> [ 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.
-- Darryl Okahata
Internet: darr...@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.
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!
elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!random!
dialup.athena.lkg.dec.com!mills
From: mi...@athena.lkg.dec.com (George Mills)
Newsgroups: comp.emacs,comp.editors,comp.os.ms-windows.programmer.tools
Subject: Re: GNU Emacs for MS-Windows and MSDOS
Message-ID: <mills.734363106@dialup.athena.lkg.dec.com>
Date: 9 Apr 93 13:45:06 GMT
References: <C4vIHC.1G9@srgenprp.sr.hp.com> <C56rIy.3Gu@srgenprp.sr.hp.com>
Lines: 24
darr...@srgenprp.sr.hp.com (Darryl Okahata) writes:
>Darryl Okahata (darr...@srgenprp.sr.hp.com) wrote:
>> [ 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.
> -- Darryl Okahata
> Internet: darr...@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.
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.
Path: gmd.de!Germany.EU.net!mcsun!uunet!psinntp!crynwr!nelson
From: nel...@crynwr.com (Russell Nelson)
Newsgroups: gnu.misc.discuss
Subject: MSDOS GNU Programs violate the GPL
Distribution: world
Message-ID: <734406663snx@crynwr.com>
References: <9304081649.AA22343@hpnmxx.sr.hp.com>
Date: Sat, 10 Apr 93 01:51:03 GMT
Organization: Crynwr Software
Lines: 42
In article <9304081649.AA22...@hpnmxx.sr.hp.com> darr...@hpnmxx.sr.hp.com writes:
The key paragraph in the GPL (version 2) is:
------------------------------------------------------------------------------
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, 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, unless that component
itself accompanies the executable.
-------------------------------------------------------------------------------
By the above paragraph, JUST ABOUT EVERY MSDOS PROGRAM VIOLATES THE GPL,
AND HAS DONE SO FOR YEARS. If you're worried about preserving the GPL,
you'd better stop the distribution of virtually all MSDOS executables
(with the probable exception of DJGCC-compiled executables).
This only applies to MSDOS programs that use a proprietary library.
For example, the Crynwr packet drivers are distributed with full source.
An argument can probably be made that, because the FSF has allowed
these MSDOS executables to be distributed for so long, the GPL may be
found null and void.
Probably not. A copyright is not like a trademark. A trademark can
be lost if it is not vigorously defended. That's why you see
"Band-Aid brand adhesive strips", and "Kleenex brand facial tissues".
The GPL would only be null and void if a precedent was set in court
that found the language unenforcable under copyright law. THAT would
be a problem.
What is the reasoning behind the phrase "unless that component
itself accompanies the executable" in:
You are correct. That is important to know. I believe the word
"component" refers to "compiler, kernel, and so on". In that case,
you are off the hook unless Waterloo C accompanies GNU Emacs for DOS.
-russ <nel...@crynwr.com> What canst *thou* say?
Crynwr Software Crynwr Software sells packet driver support.
11 Grant St. 315-268-1925 Voice | LPF member - ask me about
Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
Newsgroups: gnu.misc.discuss
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!wupost!uunet!
news.cs.jhu.edu!jyusenkyou!arromdee
From: arrom...@jyusenkyou.cs.jhu.edu (Ken Arromdee)
Subject: Re: MSDOS GNU Programs violate the GPL
Message-ID: <C5A62z.7Iu@blaze.cs.jhu.edu>
Sender: n...@blaze.cs.jhu.edu (Usenet news system)
Organization: Johns Hopkins University CS Dept.
References: <9304081649.AA22343@hpnmxx.sr.hp.com> <734406663snx@crynwr.com>
Date: Sat, 10 Apr 1993 18:30:34 GMT
Lines: 32
In article <734406663...@crynwr.com> nel...@crynwr.com (Russell Nelson) writes:
> The source code for a work means the preferred form of the work for
> making modifications to it. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scripts used to
> control compilation and installation of the executable. However, as a
> special exception, 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, unless that component
> itself accompanies the executable.
>This only applies to MSDOS programs that use a proprietary library.
>For example, the Crynwr packet drivers are distributed with full source.
You distributed them with source to the library too?
>You are correct. That is important to know. I believe the word
>"component" refers to "compiler, kernel, and so on". In that case,
>you are off the hook unless Waterloo C accompanies GNU Emacs for DOS.
On a Unix system, the compiler is a component of the OS. On an MSDOS
system, no compilers are components of the OS--you buy them all separately.
Not all compilers fall under the given category; only those compilers which are
components of the OS, and for MSDOS there is no such thing.
--
"On the first day after Christmas my truelove served to me... Leftover Turkey!
On the second day after Christmas my truelove served to me... Turkey Casserole
that she made from Leftover Turkey.
[days 3-4 deleted] ... Flaming Turkey Wings! ...
-- Pizza Hut commercial (and M*tlu/A*gic bait)
Ken Arromdee (arrom...@jyusenkyou.cs.jhu.edu)
Newsgroups: comp.emacs,comp.editors,comp.os.ms-windows.programmer.tools
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!sdd.hp.com!
hpscit.sc.hp.com!news.dtc.hp.com!srgenprp!darrylo
From: darr...@srgenprp.sr.hp.com (Darryl Okahata)
Subject: Re: GNU Emacs for MS-Windows and MSDOS
Sender: n...@srgenprp.sr.hp.com (News Administrator)
Message-ID: <C5CG49.KIJ@srgenprp.sr.hp.com>
Date: Mon, 12 Apr 1993 00:02:32 GMT
Reply-To: darr...@sr.hp.com
References: <mills.734363106@dialup.athena.lkg.dec.com>
Organization: Hewlett-Packard / Center for Primal Scream Therapy
X-Newsreader: TIN [version 1.1 PL9.2]
Followup-To: comp.emacs,comp.editors,comp.os.ms-windows.programmer.tools
Lines: 30
George Mills (mi...@athena.lkg.dec.com) wrote:
> > 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.
-- Darryl Okahata
Internet: darr...@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.
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!cs.utexas.edu!
uunet!pipex!uknet!uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Newsgroups: gnu.misc.discuss
Subject: Re: MSDOS GNU Programs violate the GPL
Message-ID: <1993Apr13.103303.4691@swan.pyr>
Date: 13 Apr 93 10:33:03 GMT
References: <9304081649.AA22343@hpnmxx.sr.hp.com> <734406663snx@crynwr.com>
<C5A62z.7Iu@blaze.cs.jhu.edu>
Organization: Swansea University College
Lines: 38
In article <C5A62z....@blaze.cs.jhu.edu> arrom...@jyusenkyou.cs.jhu.edu
(Ken Arromdee) writes:
>On a Unix system, the compiler is a component of the OS. On an MSDOS
>system, no compilers are components of the OS--you buy them all separately.
>Not all compilers fall under the given category; only those compilers which are
>components of the OS, and for MSDOS there is no such thing.
On a _FEW_ UNIX systems these days the compiler is a component of the OS.
Most no longer ship in that form, how about SCO (and don't suggest GCC because
gcc uses the SCO libraries only shipped with the SCO compiler and development
package - which isn't an OS component any more than Microsoft C is a DOS
component). What will happen about Univel and all the other systems. Lots of
people WANT to distribute GNU material in binary form and make sources
available, but if each vendor has to sell the buyer a complete compiler
kit to compile the software from source because they can't supply the binaries
then the GNU project might as well just go bankrupt now rather than waiting
a year or two before its own thick headedness kills it off.
These issues need solving NOW, in fact not now but years ago. Once we get
into object based systems the current GPL becomes an unusable product
destined for /dev/null. When the OS is a few objects and everything is
built from groups of objects from assorted sources how can you even
define what constitutes a library needed by the application. This is
already true in some areas. A GPL'd graphic viewer using external
libraries to proces .JPG .GIF etc is the classic example. How does it
know which external libraries it will be used with so that you can be
sure they are supplied with source. You can't distribute it without the
libraries because it need them, but you don't supply the libraries and
even if you gave source to some who knows who else might supply libraries
to these interfaces.
You could argue that these components are not part of the program, in
which case I'll just define all my programs as needing a user
supplied library to this spec .. where the spec is compatible with
XXX compiler suppliers C library.
>
>Ken Arromdee (arrom...@jyusenkyou.cs.jhu.edu)
Alan