Mail Archives: djgpp/2012/07/28/11:45:16
On Jul 12, 7:58 pm, rugx DOT DOT DOT AT gmail DOT com wrote:
> 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
> > 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.
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.
Steve Bullington
- Raw text -