Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Ispell
82 views
Skip to first unread message
Stephen W. Bullington
Jul 6, 2012, 6:00:36 PM7/6/12
to
I can't get ispell to work with DJGPP Emacs 23.3 on pure DOS. I have
Emacs installed on two 8.3 file-name machines, 1) a DOS 6.22 one and 2)
an OS/2 Warp 3 (blue spine) one. Ispell doesn't work on either, using
Emacs (in both cases it works OK from the command line, though). When I
try to use it I get the message "Failed to open temporary file: no such
file or directory (ENOENT), detmp.XXX". I get the same message if I try
to run a shell command. I also have DJGPP Emacs installed on a Windows
98SE box, with LFN=Y, and Ispell works fine there.
What am I doing wrong under pure DOS?
Thanks.
Steve B.
Eli Zaretskii
Jul 7, 2012, 2:54:05 AM7/7/12
to dj...@delorie.com
> From: "Stephen W. Bullington" <s...@key-net.net>
> Date: Fri, 6 Jul 2012 18:00:36 -0400
Not sure what is going on. One potential problem could be that you
don't have any of the following environment variables defined: TMPDIR,
TMP, TEMP. If none of these are defined, Emacs will try to open the
temporary file in C:/temp, and if you don't have that, either, it will
fail. It will also fail if one of the above environment variables is
set, but points to a non-existent directory.
djgpp.env, the file all DJGPP programs read to set up their
environment, defines TMPDIR to point to the 'tmp' subdirectory of the
directory where you have djgpp.env. Could it be that this directory
doesn't exist on those machines where you see the problem?
If none of the above helps, I'm clueless. If you can build Emacs
yourself and you can debug the resulting binary with GDB, perhaps you
could step through the code (I can tell you where exactly) and report
what you see. I myself don't have access to a plain DOS machine for a
long time now, and can only run the DJGPP build of Emacs on Windows.
> Date: Fri, 6 Jul 2012 18:00:36 -0400
don't have any of the following environment variables defined: TMPDIR,
TMP, TEMP. If none of these are defined, Emacs will try to open the
temporary file in C:/temp, and if you don't have that, either, it will
fail. It will also fail if one of the above environment variables is
set, but points to a non-existent directory.
djgpp.env, the file all DJGPP programs read to set up their
environment, defines TMPDIR to point to the 'tmp' subdirectory of the
directory where you have djgpp.env. Could it be that this directory
doesn't exist on those machines where you see the problem?
If none of the above helps, I'm clueless. If you can build Emacs
yourself and you can debug the resulting binary with GDB, perhaps you
could step through the code (I can tell you where exactly) and report
what you see. I myself don't have access to a plain DOS machine for a
long time now, and can only run the DJGPP build of Emacs on Windows.
rug...@gmail.com
Jul 7, 2012, 5:53:29 PM7/7/12
to dj...@delorie.com
Hi,
On Saturday, July 7, 2012 1:54:05 AM UTC-5, Eli Zaretskii wrote:
>
> Not sure what is going on. One potential problem could be that you
> don't have any of the following environment variables defined: TMPDIR,
> TMP, TEMP.
I tested under FreeDOS, same problem, even with all of the above (TEMP TMP TMPDIR) set to "g:\tony".
> If none of these are defined, Emacs will try to open the
> temporary file in C:/temp, and if you don't have that, either, it will
> fail. It will also fail if one of the above environment variables is
> set, but points to a non-existent directory.
It seems to only happen with SFNs. If I load DOSLFN, then "M-! blah.exe" works fine.
A quick grep shows callproc.c as the culprit for "detmp.xxx", but I have no idea how to fix whatever is causing this.
> djgpp.env, the file all DJGPP programs read to set up their
> environment, defines TMPDIR to point to the 'tmp' subdirectory of the
> directory where you have djgpp.env. Could it be that this directory
> doesn't exist on those machines where you see the problem?
No, that's not the problem.
> If none of the above helps, I'm clueless. If you can build Emacs
> yourself and you can debug the resulting binary with GDB, perhaps you
> could step through the code (I can tell you where exactly) and report
> what you see.
Tried several times to rebuild Emacs, didn't really work, had minor issues, and I always got stuck at "Compiling ../lisp/abbrev.el" and couldn't get past that. Tested GCC 3.4.4 and (Andris') 4.4.5.
I don't know, "make -n" isn't helpful here, and I keep occasionally running into "Descriptors exhausted". Silly me, I thought "HDPMI32 -r" would avoid that, but then it just rebooted, heh. :-P
> I myself don't have access to a plain DOS machine for a
> long time now, and can only run the DJGPP build of Emacs on Windows.
Yeah, that sucks, but you're too low on time anyways. I would suggest VirtualBox, but nowadays I think it's too buggy to be usable for DJGPP. Not honestly sure anymore, I don't use it much for DOS these days.
Anyways, I can try building it again, of course, in native FreeDOS, but I might need a few hints or tips as it doesn't seem to like me right now!! (Setting myself up for pain: maybe DOSEMU is better??? ....)
On Saturday, July 7, 2012 1:54:05 AM UTC-5, Eli Zaretskii wrote:
>
> Not sure what is going on. One potential problem could be that you
> don't have any of the following environment variables defined: TMPDIR,
> TMP, TEMP.
> If none of these are defined, Emacs will try to open the
> temporary file in C:/temp, and if you don't have that, either, it will
> fail. It will also fail if one of the above environment variables is
> set, but points to a non-existent directory.
A quick grep shows callproc.c as the culprit for "detmp.xxx", but I have no idea how to fix whatever is causing this.
> djgpp.env, the file all DJGPP programs read to set up their
> environment, defines TMPDIR to point to the 'tmp' subdirectory of the
> directory where you have djgpp.env. Could it be that this directory
> doesn't exist on those machines where you see the problem?
> If none of the above helps, I'm clueless. If you can build Emacs
> yourself and you can debug the resulting binary with GDB, perhaps you
> could step through the code (I can tell you where exactly) and report
> what you see.
I don't know, "make -n" isn't helpful here, and I keep occasionally running into "Descriptors exhausted". Silly me, I thought "HDPMI32 -r" would avoid that, but then it just rebooted, heh. :-P
> I myself don't have access to a plain DOS machine for a
> long time now, and can only run the DJGPP build of Emacs on Windows.
Anyways, I can try building it again, of course, in native FreeDOS, but I might need a few hints or tips as it doesn't seem to like me right now!! (Setting myself up for pain: maybe DOSEMU is better??? ....)
rug...@gmail.com
Jul 7, 2012, 8:18:28 PM7/7/12
to comp.os.m...@googlegroups.com, dj...@delorie.com
Hi,
On Saturday, July 7, 2012 1:54:05 AM UTC-5, Eli Zaretskii wrote:
> > From: "Stephen W. Bullington" <s..@nospam.key-net.net>
On Saturday, July 7, 2012 1:54:05 AM UTC-5, Eli Zaretskii wrote:
> > Date: Fri, 6 Jul 2012 18:00:36 -0400
> >
> > When I try to use [Emacs] I get the message "Failed to
> >
> > open temporary file: no such
> > file or directory (ENOENT), detmp.XXX". I get the same message if I try
> > to run a shell command. I also have DJGPP Emacs installed on a Windows
> > 98SE box, with LFN=Y, and Ispell works fine there.
Annoying. I really suck at using GDB, or I could've found this faster. Anyways ....
> > file or directory (ENOENT), detmp.XXX". I get the same message if I try
> > to run a shell command. I also have DJGPP Emacs installed on a Windows
> > 98SE box, with LFN=Y, and Ispell works fine there.
The problem is that src\callproc.c uses mkstemp(), hence callproc's "Failed to open temporary file" message, since mkstemp() calls mktemp() which requires a filename using "emXXXXXX" and fails on "emxxxxxx" (lower case 'x's).
Here's callproc.c's culprit line (indirectly):
pattern = Fexpand_file_name (Vtemp_file_name_pattern, tmpdir);
See src\fileio.c for that definition, which basically uses this:
name = FILE_SYSTEM_CASE (name);
Which is defined in src\s\msdos.h as this:
#define FILE_SYSTEM_CASE Fmsdos_downcase_filename
Which is ultimately defined in src\msdos.c and basically says this:
"Under LFN we expect to get pathnames in their true case."
So there, problem solved! Now Dr. Watson ... er, Eli, can suggest a tiny patch or you can probably figure it out yourself. :-)
Eli Zaretskii
Jul 7, 2012, 10:51:04 PM7/7/12
to dj...@delorie.com
> From: rug...@gmail.com
> Date: Sat, 7 Jul 2012 14:53:29 -0700 (PDT)
> Cc: dj...@delorie.com
works for you), and just debug on DOS.
> Date: Sat, 7 Jul 2012 14:53:29 -0700 (PDT)
> Cc: dj...@delorie.com
>
> > If none of the above helps, I'm clueless. If you can build Emacs
> > yourself and you can debug the resulting binary with GDB, perhaps you
> > could step through the code (I can tell you where exactly) and report
> > what you see.
>
> Tried several times to rebuild Emacs, didn't really work, had minor issues, and I always got stuck at "Compiling ../lisp/abbrev.el" and couldn't get past that. Tested GCC 3.4.4 and (Andris') 4.4.5.
I use GCC 3.4.x, FWIW. Anyway, you could build on Windows (if that
> > If none of the above helps, I'm clueless. If you can build Emacs
> > yourself and you can debug the resulting binary with GDB, perhaps you
> > could step through the code (I can tell you where exactly) and report
> > what you see.
>
> Tried several times to rebuild Emacs, didn't really work, had minor issues, and I always got stuck at "Compiling ../lisp/abbrev.el" and couldn't get past that. Tested GCC 3.4.4 and (Andris') 4.4.5.
works for you), and just debug on DOS.
Eli Zaretskii
Jul 8, 2012, 11:35:05 AM7/8/12
to dj...@delorie.com
> Date: Sat, 7 Jul 2012 17:18:28 -0700 (PDT)
> From: rug...@gmail.com
> Cc: dj...@delorie.com
I think I will simply remove that #define of FILE_SYSTEM_CASE for the
DJGPP port. I don't see why we need it nowadays, that all file names
are compared case-insensitively on DOS and Windows.
> From: rug...@gmail.com
> Cc: dj...@delorie.com
>
> The problem is that src\callproc.c uses mkstemp(), hence callproc's "Failed to open temporary file" message, since mkstemp() calls mktemp() which requires a filename using "emXXXXXX" and fails on "emxxxxxx" (lower case 'x's).
>
> Here's callproc.c's culprit line (indirectly):
>
> pattern = Fexpand_file_name (Vtemp_file_name_pattern, tmpdir);
>
> See src\fileio.c for that definition, which basically uses this:
>
> name = FILE_SYSTEM_CASE (name);
>
> Which is defined in src\s\msdos.h as this:
>
> #define FILE_SYSTEM_CASE Fmsdos_downcase_filename
>
> Which is ultimately defined in src\msdos.c and basically says this:
>
> "Under LFN we expect to get pathnames in their true case."
>
> So there, problem solved! Now Dr. Watson ... er, Eli, can suggest a tiny patch or you can probably figure it out yourself. :-)
Thanks, this is indeed the cause of the problem.
> The problem is that src\callproc.c uses mkstemp(), hence callproc's "Failed to open temporary file" message, since mkstemp() calls mktemp() which requires a filename using "emXXXXXX" and fails on "emxxxxxx" (lower case 'x's).
>
> Here's callproc.c's culprit line (indirectly):
>
> pattern = Fexpand_file_name (Vtemp_file_name_pattern, tmpdir);
>
> See src\fileio.c for that definition, which basically uses this:
>
> name = FILE_SYSTEM_CASE (name);
>
> Which is defined in src\s\msdos.h as this:
>
> #define FILE_SYSTEM_CASE Fmsdos_downcase_filename
>
> Which is ultimately defined in src\msdos.c and basically says this:
>
> "Under LFN we expect to get pathnames in their true case."
>
> So there, problem solved! Now Dr. Watson ... er, Eli, can suggest a tiny patch or you can probably figure it out yourself. :-)
I think I will simply remove that #define of FILE_SYSTEM_CASE for the
DJGPP port. I don't see why we need it nowadays, that all file names
are compared case-insensitively on DOS and Windows.
rug...@gmail.com
Jul 12, 2012, 7:58:27 PM7/12/12
to dj...@delorie.com
Hi,
On Sunday, July 8, 2012 10:35:05 AM UTC-5, Eli Zaretskii wrote:
>
> Thanks, this is indeed the cause of the problem.
>
> I think I will simply remove that #define of FILE_SYSTEM_CASE for the
> DJGPP port. I don't see why we need it nowadays, that all file names
Anyways, we haven't heard back from the OP, so I don't know if he is able to rebuild it himself or not. That kinda bugs me, heh. I have my own (very very) wimpy source patch to fix it, but it's far from optimal.
========================================
--- callproc.c 2011-01-08 19:45:14 +0000
+++ callproc.new 2012-07-07 19:37:48 +0000
@@ -929,6 +929,10 @@
int fd;
BLOCK_INPUT;
+
+ char* rugxulo = strstr(tempfile,".xxx");
+ if (rugxulo) strncpy(rugxulo,".XXX",4);
+
fd = mkstemp (tempfile);
UNBLOCK_INPUT;
if (fd == -1)
========================================
See? :-))
For simplicity and easier deployment, I'd almost rather we had a small binary patch for EMACS.EXE, so I tried to make my own. It seems to work, but it's very rough, so perhaps it's not totally flawless (huge understatement).
I basically just hacked around in raw assembly via HIEW. It's quite weird seeing GCC output, esp. because it (sometimes) does some unusual things. Long story short, I'm basically moving, calling the patch (more or less just "and blah, 0xDF" for a rough toupper() functionality), returning, etc. Ugly, confusing, difficult, probably not ideal, but it seems to work.
BTW, I didn't use "cmp -l" because I hate octal. Then I had to use sed to mask FC's unnecessary 8-bit output so nobody would complain.
fc /m35 /b emacs.old emacs.exe$
$
Comparing G:\\TONY\\EMACS.OLD and G:\\TONY\\EMACS.EXE$
00115D83: A9 \251 AE \256$
00145F00: 80 \200 E8 \350$
00145F01: 7B { 1E $
00145F02: FF \377 01 $
00145F03: 58 X 00 $
00145F04: 75 u 00 $
00145F05: 0C 90 \220$
00146021: 89 \211 C9 \311$
00146022: EC \354 C3 \303$
00146023: 5D ] 80 \200$
00146024: C3 \303 63 c$
00146025: 8D \215 FF \377$
00146026: 76 v 58 X$
00146027: 00 80 \200$
00146028: 00 7B {$
00146029: 00 FF \377$
0014602A: 00 58 X$
0014602B: 00 74 t$
0014602C: 00 07 $
0014602D: 00 5A Z$
0014602E: 00 E9 \351$
0014602F: 00 DF \337$
00146030: 55 U FE \376$
00146031: 89 \211 FF \377$
00146032: E5 \345 FF \377$
00146033: 81 \201 90 \220$
00146034: EC \354 C3 \303$
00146035: 04 C8 \310$
00146036: 01 04 $
00146037: 00 01 $
I don't really know of a better way to binary patch things outside of manually writing my own wimpy .c program to do so (as I've done twice fairly recently). Maybe CWS knows, maybe bdiff or xdiff or whatever else I'm forgetting. Bah.
Feel free to suggest another solution.
On Sunday, July 8, 2012 10:35:05 AM UTC-5, Eli Zaretskii wrote:
>
> Thanks, this is indeed the cause of the problem.
>
> I think I will simply remove that #define of FILE_SYSTEM_CASE for the
> are compared case-insensitively on DOS and Windows.
FYI, the reason I had trouble recompiling initially was due to not unpacking the *.elc files. (I was trying to use my 150 MB RAM drive. Alas.) I guess the makefile didn't like those missing. Otherwise fairly straightforward, though I still needed to use $(CURDIR) in two makefiles due to FreeDOS.
Anyways, we haven't heard back from the OP, so I don't know if he is able to rebuild it himself or not. That kinda bugs me, heh. I have my own (very very) wimpy source patch to fix it, but it's far from optimal.
========================================
--- callproc.c 2011-01-08 19:45:14 +0000
+++ callproc.new 2012-07-07 19:37:48 +0000
@@ -929,6 +929,10 @@
int fd;
BLOCK_INPUT;
+
+ char* rugxulo = strstr(tempfile,".xxx");
+ if (rugxulo) strncpy(rugxulo,".XXX",4);
+
fd = mkstemp (tempfile);
UNBLOCK_INPUT;
if (fd == -1)
========================================
See? :-))
For simplicity and easier deployment, I'd almost rather we had a small binary patch for EMACS.EXE, so I tried to make my own. It seems to work, but it's very rough, so perhaps it's not totally flawless (huge understatement).
I basically just hacked around in raw assembly via HIEW. It's quite weird seeing GCC output, esp. because it (sometimes) does some unusual things. Long story short, I'm basically moving, calling the patch (more or less just "and blah, 0xDF" for a rough toupper() functionality), returning, etc. Ugly, confusing, difficult, probably not ideal, but it seems to work.
BTW, I didn't use "cmp -l" because I hate octal. Then I had to use sed to mask FC's unnecessary 8-bit output so nobody would complain.
fc /m35 /b emacs.old emacs.exe$
$
Comparing G:\\TONY\\EMACS.OLD and G:\\TONY\\EMACS.EXE$
00115D83: A9 \251 AE \256$
00145F00: 80 \200 E8 \350$
00145F01: 7B { 1E $
00145F02: FF \377 01 $
00145F03: 58 X 00 $
00145F04: 75 u 00 $
00145F05: 0C 90 \220$
00146021: 89 \211 C9 \311$
00146022: EC \354 C3 \303$
00146023: 5D ] 80 \200$
00146024: C3 \303 63 c$
00146025: 8D \215 FF \377$
00146026: 76 v 58 X$
00146027: 00 80 \200$
00146028: 00 7B {$
00146029: 00 FF \377$
0014602A: 00 58 X$
0014602B: 00 74 t$
0014602C: 00 07 $
0014602D: 00 5A Z$
0014602E: 00 E9 \351$
0014602F: 00 DF \337$
00146030: 55 U FE \376$
00146031: 89 \211 FF \377$
00146032: E5 \345 FF \377$
00146033: 81 \201 90 \220$
00146034: EC \354 C3 \303$
00146035: 04 C8 \310$
00146036: 01 04 $
00146037: 00 01 $
I don't really know of a better way to binary patch things outside of manually writing my own wimpy .c program to do so (as I've done twice fairly recently). Maybe CWS knows, maybe bdiff or xdiff or whatever else I'm forgetting. Bah.
Feel free to suggest another solution.
Eli Zaretskii
Jul 13, 2012, 1:12:29 AM7/13/12
to dj...@delorie.com
> From: rug...@gmail.com
> Date: Thu, 12 Jul 2012 16:58:27 -0700 (PDT)
> Cc: dj...@delorie.com
> Date: Thu, 12 Jul 2012 16:58:27 -0700 (PDT)
> Cc: dj...@delorie.com
>
> FYI, the reason I had trouble recompiling initially was due to not unpacking the *.elc files. (I was trying to use my 150 MB RAM drive. Alas.) I guess the makefile didn't like those missing.
Yes, it thinks it needs to bootstrap.
> FYI, the reason I had trouble recompiling initially was due to not unpacking the *.elc files. (I was trying to use my 150 MB RAM drive. Alas.) I guess the makefile didn't like those missing.
Eli Zaretskii
Jul 14, 2012, 6:50:10 AM7/14/12
to dj...@delorie.com
> Date: Sun, 08 Jul 2012 18:35:05 +0300
> From: Eli Zaretskii <el...@gnu.org>
> From: Eli Zaretskii <el...@gnu.org>
>
> > Here's callproc.c's culprit line (indirectly):
> >
> > pattern = Fexpand_file_name (Vtemp_file_name_pattern, tmpdir);
> >
> > See src\fileio.c for that definition, which basically uses this:
> >
> > name = FILE_SYSTEM_CASE (name);
> >
> > Which is defined in src\s\msdos.h as this:
> >
> > #define FILE_SYSTEM_CASE Fmsdos_downcase_filename
> >
> > Which is ultimately defined in src\msdos.c and basically says this:
> >
> > "Under LFN we expect to get pathnames in their true case."
> >
> > So there, problem solved! Now Dr. Watson ... er, Eli, can suggest a tiny patch or you can probably figure it out yourself. :-)
>
> Thanks, this is indeed the cause of the problem.
>
> I think I will simply remove that #define of FILE_SYSTEM_CASE for the
> DJGPP port.
Done.
> > Here's callproc.c's culprit line (indirectly):
> >
> > pattern = Fexpand_file_name (Vtemp_file_name_pattern, tmpdir);
> >
> > See src\fileio.c for that definition, which basically uses this:
> >
> > name = FILE_SYSTEM_CASE (name);
> >
> > Which is defined in src\s\msdos.h as this:
> >
> > #define FILE_SYSTEM_CASE Fmsdos_downcase_filename
> >
> > Which is ultimately defined in src\msdos.c and basically says this:
> >
> > "Under LFN we expect to get pathnames in their true case."
> >
> > So there, problem solved! Now Dr. Watson ... er, Eli, can suggest a tiny patch or you can probably figure it out yourself. :-)
>
> Thanks, this is indeed the cause of the problem.
>
> I think I will simply remove that #define of FILE_SYSTEM_CASE for the
> DJGPP port.
Stephen W. Bullington
Jul 18, 2012, 11:11:51 PM7/18/12
to
In article <83sjd41...@gnu.org>, el...@gnu.org says...
Sorry I took so long to reply. I have SET TEMP=C:\TEMP in the
autoexec.bat file for both machines Ispell doesn't work on, as well as
SET TEMP=C:WINDOWS\TEMP in the autoexec.bat for the Win98SE machine it
does work on. There is also a C:\DJGPP\TMP directory on all three
machines.
To switch subjects, I've tried to compile Emacs on all three and on all
the compilation works up to a point, and then chokes on what looks to me
like some assembly code. I don't have time tonight to outline the exact
screen output but I'll post again in a day or so with the details. In
the past I managed (with an older setup) to compile Emacs 20.5
successfully on all three machines. BTW, I have bnu2211 installed as
well as NASM. I think my current DJGPP C/C++ setup is mostly OK because
I've managed to use it for compiling Quake on Win98SE and for compiling
MicroEmacs '06 everywhere (Quake, though, does flub on the SFN
machines). Quake, SETEdit, and Microemacs '02 compiled flawlessly on
all installs of my earlier DJGPP set up.
I upgraded both my DJGPP installations and Emacs mainly
because I have Emacs 23.4 installed on a Windows 7 laptop, and wanted to
use org mode everywhere. I've got some problems there too with the DOS
setups but I think they're eLisp related and I'll cover them
later.
After I started writing this I noticed that another person figured out
what is wrong and developed a code patch. But I'll have to get the old
code to compile before I can append it. So I'll post later on my
problems compiling 23.3.
Something to be thinking about--is there a GnuPG for DJGPP (I couldn't
find it, but that doesn't mean its not there)? If there isn't it would
sure be useful to read Emacs diary.gpg files encrypted on Windows-based
systems, but opened on DOS ones.
Thanks to everyone for taking time to help.
Steve B.
autoexec.bat file for both machines Ispell doesn't work on, as well as
SET TEMP=C:WINDOWS\TEMP in the autoexec.bat for the Win98SE machine it
does work on. There is also a C:\DJGPP\TMP directory on all three
machines.
To switch subjects, I've tried to compile Emacs on all three and on all
the compilation works up to a point, and then chokes on what looks to me
like some assembly code. I don't have time tonight to outline the exact
screen output but I'll post again in a day or so with the details. In
the past I managed (with an older setup) to compile Emacs 20.5
successfully on all three machines. BTW, I have bnu2211 installed as
well as NASM. I think my current DJGPP C/C++ setup is mostly OK because
I've managed to use it for compiling Quake on Win98SE and for compiling
MicroEmacs '06 everywhere (Quake, though, does flub on the SFN
machines). Quake, SETEdit, and Microemacs '02 compiled flawlessly on
all installs of my earlier DJGPP set up.
I upgraded both my DJGPP installations and Emacs mainly
because I have Emacs 23.4 installed on a Windows 7 laptop, and wanted to
use org mode everywhere. I've got some problems there too with the DOS
setups but I think they're eLisp related and I'll cover them
later.
After I started writing this I noticed that another person figured out
what is wrong and developed a code patch. But I'll have to get the old
code to compile before I can append it. So I'll post later on my
problems compiling 23.3.
Something to be thinking about--is there a GnuPG for DJGPP (I couldn't
find it, but that doesn't mean its not there)? If there isn't it would
sure be useful to read Emacs diary.gpg files encrypted on Windows-based
systems, but opened on DOS ones.
Thanks to everyone for taking time to help.
Steve B.
rug...@gmail.com
Jul 19, 2012, 4:18:31 PM7/19/12
to
Hi,
On Wednesday, July 18, 2012 10:11:51 PM UTC-5, Stephen W. Bullington wrote:
>
> Sorry I took so long to reply. I have SET TEMP=C:\TEMP in the
> autoexec.bat file for both machines Ispell doesn't work on, as well as
> There is also a C:\DJGPP\TMP directory on all three
> machines.
Okay, but unless you have DJGPP=c:\djgpp\djgpp.env set or TMPDIR manually set to it, that won't affect anything.
Anyways, that wasn't the problem, so no worries.
> To switch subjects, I've tried to compile Emacs on all three and on all
> screen output but I'll post again in a day or so with the details.
There are too many GCC versions over the years, so the Emacs dudes don't test all of them. Last I read somewhere, they only tested certain 4.x versions. Unfortunately, DJGPP's unexec() apparently relies on COFF debug info, which is horribly deprecated and somewhat broken in newer releases.
Somewhat blindly guessing, it's probably best to try GCC 3.4.4 (like Eli does) or 4.4.5 or older. Though a few years ago I tried 2.95.3 on Emacs 23.1, and that didn't work, so that's probably too old. (Silly but unfortunate problem.)
> In the past I managed (with an older setup) to compile Emacs 20.5
> successfully on all three machines.
In theory, everything would work fine, but reality is different. Anyways, 20.5 is much older, so I guess it didn't stress test GCC as much.
> BTW, I have bnu2211 installed as
> well as NASM.
Latest BinUtils for DJGPP is 2.22r3 (though the Zip Picker still suggest that older one, for now). However, I don't think it matters here (and you don't need NASM at all).
bnu222br3.zip 22-Apr-2012 21:18 5297698
http://na.mirror.garr.it/mirrors/djgpp/current/v2gnu/bnu222br3.zip
> I think my current DJGPP C/C++ setup is mostly OK because
> I've managed to use it for compiling Quake on Win98SE and for compiling
> MicroEmacs '06 everywhere (Quake, though, does flub on the SFN
> machines). Quake, SETEdit, and Microemacs '02 compiled flawlessly on
I don't recall compiling MicroEmacs '06 (JASSPA, presumably) nor SetEDIT (needs C++, right?). I did a few times recompile Quake, but it's a little bitrotted for DOS (they didn't re-test in 1999 source release), esp. due to *nix sbrk() handling, so you have to set a crt0 flag somewhere (and it won't run on NT-based machines due to near ptrs).
> I upgraded both my DJGPP installations and Emacs mainly
> because I have Emacs 23.4 installed on a Windows 7 laptop, and wanted to
> use org mode everywhere.
org-mode sounds too complicated for me, but I've not looked too closely.
> I've got some problems there too with the DOS
> setups but I think they're eLisp related and I'll cover them
> later.
Okay, though I know nil about that. :-P
> After I started writing this I noticed that another person figured out
> what is wrong and developed a code patch. But I'll have to get the old
> code to compile before I can append it. So I'll post later on my
> problems compiling 23.3.
Recompiling is easier, but I (weakly) tried to also make a binary patch. Dunno if hexl mode and -batch would allow for a potential to patch itself, heh.
> Something to be thinking about--is there a GnuPG for DJGPP (I couldn't
> find it, but that doesn't mean its not there)? If there isn't it would
http://www.caddit.net/php/download.php?file=dg-gnupg.zip
> Thanks to everyone for taking time to help.
Be sure to post back whether any of this helps!
On Wednesday, July 18, 2012 10:11:51 PM UTC-5, Stephen W. Bullington wrote:
>
> Sorry I took so long to reply. I have SET TEMP=C:\TEMP in the
> SET TEMP=C:WINDOWS\TEMP in the autoexec.bat for the Win98SE machine it
> does work on.
I assume you really meant C:\WINDOWS\TEMP here (as without the first slash it probably wouldn't work). Anyways, it depends on the app how it handles temporary files. Usually they seem to check TMPDIR, TEMP, TMP, /tmp, or similar.
> does work on.
> There is also a C:\DJGPP\TMP directory on all three
> machines.
Anyways, that wasn't the problem, so no worries.
> To switch subjects, I've tried to compile Emacs on all three and on all
> the compilation works up to a point, and then chokes on what looks to me
> like some assembly code. I don't have time tonight to outline the exact
> screen output but I'll post again in a day or so with the details.
There are too many GCC versions over the years, so the Emacs dudes don't test all of them. Last I read somewhere, they only tested certain 4.x versions. Unfortunately, DJGPP's unexec() apparently relies on COFF debug info, which is horribly deprecated and somewhat broken in newer releases.
Somewhat blindly guessing, it's probably best to try GCC 3.4.4 (like Eli does) or 4.4.5 or older. Though a few years ago I tried 2.95.3 on Emacs 23.1, and that didn't work, so that's probably too old. (Silly but unfortunate problem.)
> In the past I managed (with an older setup) to compile Emacs 20.5
> successfully on all three machines.
> BTW, I have bnu2211 installed as
> well as NASM.
bnu222br3.zip 22-Apr-2012 21:18 5297698
http://na.mirror.garr.it/mirrors/djgpp/current/v2gnu/bnu222br3.zip
> I think my current DJGPP C/C++ setup is mostly OK because
> MicroEmacs '06 everywhere (Quake, though, does flub on the SFN
> machines). Quake, SETEdit, and Microemacs '02 compiled flawlessly on
> all installs of my earlier DJGPP set up.
For GNU Emacs, you need Make, GCC, BinUtils, DJDEV, mv, rm, sed. I think that's all. I can't remember needing much else. mv and rm are in DJGPP's FileUtils (fil41b.zip).
I don't recall compiling MicroEmacs '06 (JASSPA, presumably) nor SetEDIT (needs C++, right?). I did a few times recompile Quake, but it's a little bitrotted for DOS (they didn't re-test in 1999 source release), esp. due to *nix sbrk() handling, so you have to set a crt0 flag somewhere (and it won't run on NT-based machines due to near ptrs).
> I upgraded both my DJGPP installations and Emacs mainly
> because I have Emacs 23.4 installed on a Windows 7 laptop, and wanted to
> use org mode everywhere.
> I've got some problems there too with the DOS
> setups but I think they're eLisp related and I'll cover them
> later.
Okay, though I know nil about that. :-P
> After I started writing this I noticed that another person figured out
> code to compile before I can append it. So I'll post later on my
> problems compiling 23.3.
Recompiling is easier, but I (weakly) tried to also make a binary patch. Dunno if hexl mode and -batch would allow for a potential to patch itself, heh.
> Something to be thinking about--is there a GnuPG for DJGPP (I couldn't
> find it, but that doesn't mean its not there)? If there isn't it would
> sure be useful to read Emacs diary.gpg files encrypted on Windows-based
> systems, but opened on DOS ones.
The only unofficial DJGPP build I'm aware of is below (but I've never tried it nor GnuPG in general):
> systems, but opened on DOS ones.
http://www.caddit.net/php/download.php?file=dg-gnupg.zip
> Thanks to everyone for taking time to help.
USA Choice User
Jul 28, 2012, 11:35:02 AM7/28/12
to
compile using DJGPP on Windows 98SE, with LFN set to "Y". Following
your version suggestion, I only had to make one change--I substituted
GCC 4.4.4 for GCC 4.7.0. I also substituted GPP 4.4.4 for GPP 4.7.0.
for consistency.
However, I can't figure out how or where to splice in your patch, in
callproc.c. I did find the file in the source folder, but to me at
least it's not obvious how to fix it (I'm not a C programmer yet, but
I can figure things out and follow directions).
If you could walk me through the process I'd appreciate it. Thanks.
Steve Bullington
rug...@gmail.com
Jul 31, 2012, 7:55:06 AM7/31/12
to
Hi,
On Saturday, July 28, 2012 10:35:02 AM UTC-5, USA Choice User wrote:
> On Jul 12, 7:58 pm, rugx...@gmail.com wrote:
>
> > ========================================
> > --- callproc.c 2011-01-08 19:45:14 +0000
> > +++ callproc.new 2012-07-07 19:37:48 +0000
> > @@ -929,6 +929,10 @@
> > int fd;
> >
> > BLOCK_INPUT;
> > +
> > + char* rugxulo = strstr(tempfile,".xxx");
> > + if (rugxulo) strncpy(rugxulo,".XXX",4);
> > +
> > fd = mkstemp (tempfile);
> > UNBLOCK_INPUT;
> > if (fd == -1)
> > ========================================
>
Normally I hate the idea of using billions of different versions of the same tool, but in this case it's almost unavoidable.
> However, I can't figure out how or where to splice
> in your patch, in callproc.c. I did find the file
> in the source folder, but to me at least it's not
> obvious how to fix it (I'm not a C programmer yet,
> but I can figure things out and follow directions).
>
> If you could walk me through the process I'd
> appreciate it. Thanks.
It's just a diff file from DIFF.EXE that can be manually typed in (see section beginning at line 929 of callproc.c) or just use PATCH.EXE, e.g. "patch -i rugxulo.dif", then it should build.
Really, I hate the idea that end users have to recompile anything, esp. if that's not their thing, hence the binary patch (technically easier to apply but inferior overall). But I admit I didn't really make that automated either. Oh well.
DJGPP doesn't come with diff.exe or patch.exe by default, so you'll have to grab them separately.
http://na.mirror.garr.it/mirrors/djgpp/beta/v2gnu/dif32br3.zip
http://na.mirror.garr.it/mirrors/djgpp/beta/v2gnu/pat261b.zip
On Saturday, July 28, 2012 10:35:02 AM UTC-5, USA Choice User wrote:
> On Jul 12, 7:58 pm, rugx...@gmail.com wrote:
>
> > ========================================
> > --- callproc.c 2011-01-08 19:45:14 +0000
> > +++ callproc.new 2012-07-07 19:37:48 +0000
> > @@ -929,6 +929,10 @@
> > int fd;
> >
> > BLOCK_INPUT;
> > +
> > + char* rugxulo = strstr(tempfile,".xxx");
> > + if (rugxulo) strncpy(rugxulo,".XXX",4);
> > +
> > fd = mkstemp (tempfile);
> > UNBLOCK_INPUT;
> > if (fd == -1)
> > ========================================
>
> Sorry I took so long to reply. I finally got Emacs
> 23.3 so it will compile using DJGPP on Windows 98SE,
> with LFN set to "Y". Following your version suggestion,
> I only had to make one change--I substituted GCC 4.4.4
> for GCC 4.7.0. I also substituted GPP 4.4.4 for GPP
> 4.7.0 for consistency.
> 23.3 so it will compile using DJGPP on Windows 98SE,
> with LFN set to "Y". Following your version suggestion,
> I only had to make one change--I substituted GCC 4.4.4
> for GCC 4.7.0. I also substituted GPP 4.4.4 for GPP
Normally I hate the idea of using billions of different versions of the same tool, but in this case it's almost unavoidable.
> However, I can't figure out how or where to splice
> in your patch, in callproc.c. I did find the file
> in the source folder, but to me at least it's not
> obvious how to fix it (I'm not a C programmer yet,
> but I can figure things out and follow directions).
>
> If you could walk me through the process I'd
> appreciate it. Thanks.
Really, I hate the idea that end users have to recompile anything, esp. if that's not their thing, hence the binary patch (technically easier to apply but inferior overall). But I admit I didn't really make that automated either. Oh well.
DJGPP doesn't come with diff.exe or patch.exe by default, so you'll have to grab them separately.
http://na.mirror.garr.it/mirrors/djgpp/beta/v2gnu/dif32br3.zip
http://na.mirror.garr.it/mirrors/djgpp/beta/v2gnu/pat261b.zip
rug...@gmail.com
Aug 3, 2012, 1:03:15 AM8/3/12
to
Hi,
I had a longer reply, but it didn't post correctly (blech). Not a huge loss, just saying ....
On Tuesday, July 31, 2012 6:55:06 AM UTC-5, rug...@gmail.com wrote:
>
> On Saturday, July 28, 2012 10:35:02 AM UTC-5, USA Choice User wrote:
>
> > Sorry I took so long to reply. I finally got Emacs
> > 23.3 so it will compile using DJGPP on Windows 98SE,
> > with LFN set to "Y". Following your version suggestion,
> > I only had to make one change--I substituted GCC 4.4.4
> > for GCC 4.7.0. I also substituted GPP 4.4.4 for GPP
> > 4.7.0 for consistency.
>
So a binary patch (as shown by my FC output) is easier, IMHO, but it's still not automatic. GNU Diff and Patch may? support binary files, but I've not tried. I've also not tried new Xdelta3 nor Courgette nor Open-VCdiff nor bsdiff (needs Bzip2) nor others. Emacs' own hexl-mode is broken by this same bug, so that's ruled out too!
DJGPP does have older XDelta 1.12 (from 2002) in /current/v2apps/ so I did earlier today make a quick patch and UUencode it.
EDIT: Google Groups is having problems posting this, ugh. Maybe if I remove this .uue below it will help (doh).
(snip, email me directly if it's desired)
I also wrote a really crappy tool in .C that you can compile that will read the FC output and automatically fix it for you. For cleanliness in this newsgroup, I've edited out the 8-bit chars, as they were unnecessary anyways.
==emacs.pat======================
fc /m35 /b emacs.old emacs.exe
Comparing G:\TONY\EMACS.OLD and G:\TONY\EMACS.EXE
00115D83: A9 AE
00145F00: 80 E8
00145F01: 7B 1E
00145F02: FF 01
00145F03: 58 00
00145F04: 75 00
00145F05: 0C 90
00146021: 89 C9
00146022: EC C3
00146023: 5D 80
00146024: C3 63
00146025: 8D FF
00146026: 76 58
00146027: 00 80
00146028: 00 7B
00146029: 00 FF
0014602A: 00 58
0014602B: 00 74
0014602C: 00 07
0014602D: 00 5A
0014602E: 00 E9
0014602F: 00 DF
00146030: 55 FE
00146031: 89 FF
00146032: E5 FF
00146033: 81 90
00146034: EC C3
00146035: 04 C8
00146036: 01 04
00146037: 00 01
==emacs.pat======================
You can optionally verify (before and after) by using "md5sum -c blah.md5":
==oldemacs.md5===================
4f171dddc36898e8e3003d5cefae2497 *emacs.exe
==oldemacs.md5===================
==newemacs.md5===================
ad14f38a625ccbfff98510ae832bf734 *emacs.exe
==newemacs.md5===================
BTW, the following .C code is rubbish, but it seems to still work anyways. ;-)
==tonyhack.c=====================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef FILE* FilePtr;
void seekit(FilePtr t, long o) {
fflush(t); fseek(t,o,SEEK_SET);
if (ftell(t) != o) {
printf("Couldn't seek!\n");
exit(EXIT_FAILURE);
}
}
int main(void) {
static long offset=0L,lineno=0L;
int rc=EXIT_SUCCESS,res=0;
FilePtr patch, target;
char format1[]="%lX: %02X %02X", format2[]="%lX: %02X %*c %02X";
char buf[1024], *fmt;
unsigned int hex[3];
target=fopen("emacs.exe","rb+"); patch=fopen("emacs.pat","r");
if ((target == NULL) || (patch == NULL))
rc=EXIT_FAILURE;
else {
while (fgets(buf,sizeof(buf),patch) != NULL) {
lineno++;
/* adjust for DOS' fc.exe output if no char literal found */
fmt=format1; if (buf[18] != ' ') fmt=format2;
res=sscanf(buf,fmt,&offset,&hex[0],&hex[1]);
if (res > 1) {
seekit(target,offset);
fread(&hex[2],1,1,target); hex[2]=(unsigned char)hex[2];
if (hex[2] != hex[0]) {
printf("WARNING: %d != %d\n",hex[2],hex[0]);
}
seekit(target,offset);
if (fwrite(&hex[1],1,1,target) == 1L) {
printf("(res %d) [line %5ld] 0x%lX: %02X => %02X\n",
res,lineno,offset,hex[2],hex[1]);
}
}
} /* while */
fclose(patch); fclose(target);
} /* if */
return rc;
} /* main */
==tonyhack.c=====================
I did briefly consider making a Shar archive, but that's still more external utils you need (and probably don't have). I wanted clean, simple, and small, esp. for mailing across the online group, so this way seemed better to my eyes.
I had a longer reply, but it didn't post correctly (blech). Not a huge loss, just saying ....
On Tuesday, July 31, 2012 6:55:06 AM UTC-5, rug...@gmail.com wrote:
>
> On Saturday, July 28, 2012 10:35:02 AM UTC-5, USA Choice User wrote:
>
> > Sorry I took so long to reply. I finally got Emacs
> > 23.3 so it will compile using DJGPP on Windows 98SE,
> > with LFN set to "Y". Following your version suggestion,
> > I only had to make one change--I substituted GCC 4.4.4
> > for GCC 4.7.0. I also substituted GPP 4.4.4 for GPP
> > 4.7.0 for consistency.
>
> > However, I can't figure out how or where to splice
> > in your patch, in callproc.c. I did find the file
> > in the source folder, but to me at least it's not
> > obvious how to fix it (I'm not a C programmer yet,
> > but I can figure things out and follow directions).
>
> > If you could walk me through the process I'd
> > appreciate it. Thanks.
As mentioned, for text files, the best way to send small fixes is via (unified) Diff (and Patch in lieu of Ed). But you'd still have to grab the (big) sources and recompile, assuming you had all the correct tools. Even a refreshed, patched binary would make everyone download 40+ MB yet again. Yuck.
> > in your patch, in callproc.c. I did find the file
> > in the source folder, but to me at least it's not
> > obvious how to fix it (I'm not a C programmer yet,
> > but I can figure things out and follow directions).
>
> > If you could walk me through the process I'd
> > appreciate it. Thanks.
So a binary patch (as shown by my FC output) is easier, IMHO, but it's still not automatic. GNU Diff and Patch may? support binary files, but I've not tried. I've also not tried new Xdelta3 nor Courgette nor Open-VCdiff nor bsdiff (needs Bzip2) nor others. Emacs' own hexl-mode is broken by this same bug, so that's ruled out too!
DJGPP does have older XDelta 1.12 (from 2002) in /current/v2apps/ so I did earlier today make a quick patch and UUencode it.
EDIT: Google Groups is having problems posting this, ugh. Maybe if I remove this .uue below it will help (doh).
(snip, email me directly if it's desired)
I also wrote a really crappy tool in .C that you can compile that will read the FC output and automatically fix it for you. For cleanliness in this newsgroup, I've edited out the 8-bit chars, as they were unnecessary anyways.
==emacs.pat======================
fc /m35 /b emacs.old emacs.exe
Comparing G:\TONY\EMACS.OLD and G:\TONY\EMACS.EXE
00115D83: A9 AE
00145F00: 80 E8
00145F01: 7B 1E
00145F02: FF 01
00145F03: 58 00
00145F04: 75 00
00145F05: 0C 90
00146021: 89 C9
00146022: EC C3
00146023: 5D 80
00146024: C3 63
00146025: 8D FF
00146026: 76 58
00146027: 00 80
00146028: 00 7B
00146029: 00 FF
0014602A: 00 58
0014602B: 00 74
0014602C: 00 07
0014602D: 00 5A
0014602E: 00 E9
0014602F: 00 DF
00146030: 55 FE
00146031: 89 FF
00146032: E5 FF
00146033: 81 90
00146034: EC C3
00146035: 04 C8
00146036: 01 04
00146037: 00 01
==emacs.pat======================
You can optionally verify (before and after) by using "md5sum -c blah.md5":
==oldemacs.md5===================
4f171dddc36898e8e3003d5cefae2497 *emacs.exe
==oldemacs.md5===================
==newemacs.md5===================
ad14f38a625ccbfff98510ae832bf734 *emacs.exe
==newemacs.md5===================
BTW, the following .C code is rubbish, but it seems to still work anyways. ;-)
==tonyhack.c=====================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef FILE* FilePtr;
void seekit(FilePtr t, long o) {
fflush(t); fseek(t,o,SEEK_SET);
if (ftell(t) != o) {
printf("Couldn't seek!\n");
exit(EXIT_FAILURE);
}
}
int main(void) {
static long offset=0L,lineno=0L;
int rc=EXIT_SUCCESS,res=0;
FilePtr patch, target;
char format1[]="%lX: %02X %02X", format2[]="%lX: %02X %*c %02X";
char buf[1024], *fmt;
unsigned int hex[3];
target=fopen("emacs.exe","rb+"); patch=fopen("emacs.pat","r");
if ((target == NULL) || (patch == NULL))
rc=EXIT_FAILURE;
else {
while (fgets(buf,sizeof(buf),patch) != NULL) {
lineno++;
/* adjust for DOS' fc.exe output if no char literal found */
fmt=format1; if (buf[18] != ' ') fmt=format2;
res=sscanf(buf,fmt,&offset,&hex[0],&hex[1]);
if (res > 1) {
seekit(target,offset);
fread(&hex[2],1,1,target); hex[2]=(unsigned char)hex[2];
if (hex[2] != hex[0]) {
printf("WARNING: %d != %d\n",hex[2],hex[0]);
}
seekit(target,offset);
if (fwrite(&hex[1],1,1,target) == 1L) {
printf("(res %d) [line %5ld] 0x%lX: %02X => %02X\n",
res,lineno,offset,hex[2],hex[1]);
}
}
} /* while */
fclose(patch); fclose(target);
} /* if */
return rc;
} /* main */
==tonyhack.c=====================
I did briefly consider making a Shar archive, but that's still more external utils you need (and probably don't have). I wanted clean, simple, and small, esp. for mailing across the online group, so this way seemed better to my eyes.
rug...@gmail.com
Aug 4, 2012, 7:08:06 PM8/4/12
to
Hi, yet again,
On Friday, August 3, 2012 12:03:15 AM UTC-5, rug...@gmail.com wrote:
>
> 00146023: 5D 80
> 00146024: C3 63
> 00146025: 8D FF
> 00146026: 76 58
That should probably be "DF" instead of "58" here. Not sure why I didn't catch that (or why it mostly worked without it). That was the whole point, to uppercase it!
00146023: 8063FFDF and byte [ebx-1],0xDF
And, of course, this changes the md5sum, so here's the newer one:
==newemacs.md5===================
51a76c475ccfc50d341cee9990655808 *emacs.exe
==newemacs.md5===================
BTW, here's a quick sed operation to avoid the compile problem when using FreeDOS' FreeCOM (untested but should work, heh):
==fcomfix.bat====================
@echo off
if not exist mainmake.v2 set MOO=msdos
gsed -i "s/subst.*shell.*)/CURDIR)/" %MOO%.\mainmake.v2 %MOO%.\sed*.inp
set MOO=
==fcomfix.bat====================
P.S. I still feel like I need to kick the tires a lot more. I guess I'll keep playing with it, and see what I can find out.
On Friday, August 3, 2012 12:03:15 AM UTC-5, rug...@gmail.com wrote:
>
> 00146023: 5D 80
> 00146024: C3 63
> 00146025: 8D FF
> 00146026: 76 58
00146023: 8063FFDF and byte [ebx-1],0xDF
And, of course, this changes the md5sum, so here's the newer one:
==newemacs.md5===================
51a76c475ccfc50d341cee9990655808 *emacs.exe
==newemacs.md5===================
BTW, here's a quick sed operation to avoid the compile problem when using FreeDOS' FreeCOM (untested but should work, heh):
==fcomfix.bat====================
@echo off
if not exist mainmake.v2 set MOO=msdos
gsed -i "s/subst.*shell.*)/CURDIR)/" %MOO%.\mainmake.v2 %MOO%.\sed*.inp
set MOO=
==fcomfix.bat====================
P.S. I still feel like I need to kick the tires a lot more. I guess I'll keep playing with it, and see what I can find out.
Stephen W. Bullington
Aug 5, 2012, 12:44:04 PM8/5/12
to
In article <301af96d-3710-4a4e...@googlegroups.com>,
rug...@gmail.com says...
I haven't had time to do much, and don't know enough yet to understand
most of what you've written. I was able, however, to modify callproc.c
as per your instructions, and then recompile emacs with the modified
file. It worked. Ispell now works in DOS Emacs with the new EXE, in an
SFN environment.
I'll try to figure out the rest of what you posted as can, but it may
take some time.
Thnaks.
Steve Bullington
rug...@gmail.com says...
most of what you've written. I was able, however, to modify callproc.c
as per your instructions, and then recompile emacs with the modified
file. It worked. Ispell now works in DOS Emacs with the new EXE, in an
SFN environment.
I'll try to figure out the rest of what you posted as can, but it may
take some time.
Thnaks.
Steve Bullington
0 new messages