DOS ain't dead

Hey guys,
If any of you has a preference for the ultra powerful tool that is GNU Emacs, you may like to know about two DJGPP possibilities:

1). older "stable" (but unsupported) 22.3 (pre-built with a few patches, as previously mentioned) -> 30 MB download
2). newer "alpha" 23.0.92 (in testing, need to build it yourself) -> 43 MB download

1a). http://rapidshare.com/files/216240319/emacs-22.3-djgpp.7z.html
2a). ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.92.tar.gz

Note that a lot of that size is .c and .el sources, .elc byte compiled, .tex and .eps, Info docs, eLisp tutorial + reference, as well as Changelogs etc. etc. (Obviously JED is similar but smaller. And TDE and FTE are good in their own right. But GNU Emacs does lots more, maybe too much [gomoku, tetris, doctor].)

> But GNU Emacs does lots more, maybe
> too much [gomoku, tetris, doctor].)

Yes. If it just had a decent editor, it would make a great OS!

> > But GNU Emacs does lots more, maybe
> > too much [gomoku, tetris, doctor].)
>
> Yes. If it just had a decent editor, it would make a great OS!

The Changelog files alone (not to mention everything else) are bigger than most text editors.

> > > But GNU Emacs does lots more, maybe
> > > too much [gomoku, tetris, doctor].)
> >
> > Yes. If it just had a decent editor, it would make a great OS!
>
> The Changelog files alone (not to mention everything else) are bigger than
> most text editors.

Eighty Megabytes And Constantly Swapping

Gnu Emacs contributor Eric S. Raymond was going on a while back about what Emacs got wrong, and comparing the virtues of Lisp and Python. I suggested he rewrite Emacs to use Python as the underlying language instead of Lisp, and the response was "Don't tempt me!"

Emacs using Lisp made sense at the time. Lisp was designed for string processing, which is essentially what an editor does, and the versions of Lisp on a couple of early Emacs targets were much better suited for the task than writing Emacs in something else would have been.

Eric also mentioned liking Lua. There's an interesting open source editor called TextAdept which is a small kernel in C and a lot of Lua code. The author calls it "infinitely extensible". I'll have to drop Eric a note to see if he knows of it. He might just decide to make it look like Emacs...

But meanwhile, I wouldn't try to use Gnu Emacs under DOS. It's just way more than I would ever require. I used to use Daniel Lawrence's MicroEMACS under DOS a good deal, and wrote or rewrote an assorment of macros for it. It built "out of the box" on my AT&T 3B1 under SysV R2, and it was nice to have the same editor on multiple platforms.
______
Dennis

> Eighty Megabytes And Constantly Swapping

Oh, so now it's 80, eh?

I just checked on this machine, 22.3 seems to use almost 8 MB just to start up (even though I compiled -Os to save space). Obviously would be a little painful on my 486 (640k + 7 MB extended RAM = not quite 8 MB), esp. since I'd probably be swapping like mad!

P.S. Was (crazily) curious about Win 3.1 Emacsen recently, found JED 0.98-4, notGNU, and heard (but didn't find) GNU Emacs 19.27 EMX for OS/2 (sadly, I'll bet Steve knew where to find it, sigh) that supposedly ran under RSHELL (or DOS with RSX).

> Gnu Emacs contributor Eric S. Raymond was going on a while back about what
> Emacs got wrong, and comparing the virtues of Lisp and Python. I suggested
> he rewrite Emacs to use Python as the underlying language instead of Lisp,
> and the response was "Don't tempt me!"

He claims to have written more Elisp code than anyone. But yes, he's a bit eccentric ("we don't need the GPL anymore", uh what?)

> Emacs using Lisp made sense at the time. Lisp was designed for string
> processing, which is essentially what an editor does, and the versions of
> Lisp on a couple of early Emacs targets were much better suited for the
> task than writing Emacs in something else would have been.

Well, Richard Stallman basically invented Emacs, and he worked at MIT in the AI Lab using Lisp. That's probably the only real reason for using it.

> Eric also mentioned liking Lua. There's an interesting open source editor
> called TextAdept which is a small kernel in C and a lot of Lua code. The
> author calls it "infinitely extensible". I'll have to drop Eric a note to
> see if he knows of it. He might just decide to make it look like Emacs...
>

The ones that are extensible (i.e. not "ersatz") have all kinds of extension languages: Mocklisp, S-Lang, eLisp, and who knows what else! Sure Lua and Python are hot right now, but I'm not sure how good an idea it would be to use them. (In particular, I assume Python 3000 would be preferred, but that's not stable yet, is it?)

> But meanwhile, I wouldn't try to use Gnu Emacs under DOS. It's just way
> more than I would ever require.

I don't want to say it's overkill, but yeah, it does a lot! I like it, it's cool. Doesn't mean I can't also use others, though.

> I used to use Daniel Lawrence's
> MicroEMACS under DOS a good deal, and wrote or rewrote an assorment of
> macros for it. It built "out of the box" on my AT&T 3B1 under SysV R2,
> and it was nice to have the same editor on multiple platforms.

I think JASSPA is the best MicroEmacs variant, personally, unless you count things like VILE (which also has a good DOS port). My main favorite is TDE (BTW, URL change!), which is pretty small (160k via gcc -Os & upx --ultra-brute), but I'm open to trying others too.

> 2). newer "alpha" 23.0.92 (in testing, need to build it yourself) -> 43 MB
> download
>
> 2a). ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.0.92.tar.gz
>
> Note that a lot of that size is .c and .el sources, .elc byte compiled,
> .tex and .eps, Info docs, eLisp tutorial + reference, as well as
> Changelogs etc. etc.

Here's what's GNU:

>>> P.S. It still claims an error when I try building with SYSTEM_MALLOC:
>>>
>>> msdos.o w16select.o xmenu.o termcap.o tparam.o lastfile.o
>>> getloadavg.o
>>> -lg -lm
>>> dosfns.o:dosfns.c:(.text+0x663): undefined reference to
>>> `_ret_lim_data'
>>> collect2: ld returned 1 exit status
>>> make.exe[1]: *** [temacs.exe] Error 1
>>> make.exe[1]: Leaving directory `c:/Armslurp/emacs-23.0.92/src'
>>> make.exe: *** [src] Error 2
>>>
>>> Now this time you have to admit that it isn't my imagination.
>
>> I will look into it. Please submit a bug report with
>>
>> M-x report-emacs-bug RET
>
> I've just fixed this in the Emacs CVS with the following change:
>
> 2009-04-04 Eli Zaretskii <eliz@nobody.nospam>
>
> * dosfns.c (system_process_attributes) [SYSTEM_MALLOC]:
> Don't call ret_lim_data. (Bug#2867)
>
> Index: src/dosfns.c
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/src/dosfns.c,v
> retrieving revision 1.53
> retrieving revision 1.54

diff -u -r1.53 -r1.54
--- src/dosfns.c        3 Jan 2009 15:02:30 -0000       1.53
+++ src/dosfns.c        4 Apr 2009 09:42:12 -0000       1.54
@@ -571,7 +571,9 @@
       int i;
       Lisp_Object cmd_str, decoded_cmd, tem;
       double pmem;
+#ifndef SYSTEM_MALLOC
       extern unsigned long ret_lim_data ();
+#endif

       uid = getuid ();
       attrs = Fcons (Fcons (Qeuid, make_fixnum_or_float (uid)), attrs);
@@ -604,8 +606,12 @@
                            make_fixnum_or_float ((unsigned long)sbrk(0)/1024)),
                     attrs);
       attrs = Fcons (Fcons (Qetime, tem), attrs);
+#ifndef SYSTEM_MALLOC
+      /* ret_lim_data is on vm-limit.c, which is not compiled in under
+        SYSTEM_MALLOC.  */
       pmem = (double)((unsigned long) sbrk (0)) / ret_lim_data () * 100.0;
       if (pmem > 100)
+#endif
        pmem = 100;
       attrs = Fcons (Fcons (Qpmem, make_float (pmem)), attrs);
       /* Pass 1: Count how much storage we need.  */

> > Eighty Megabytes And Constantly Swapping
>
> Oh, so now it's 80, eh?

Depending upon architecture...

> I just checked on this machine, 22.3 seems to use almost 8 MB just to
> start up (even though I compiled -Os to save space). Obviously would be a
> little painful on my 486 (640k + 7 MB extended RAM = not quite 8 MB), esp.
> since I'd probably be swapping like mad!

A little painful?

I'm currently playing with a Fujitsu Lifebook p2110 cicra 2002. It was a gift from a friend who had upgraded to a faster machine. She loved it, but said it was "slow slow slow". Well, no surprise. It has an 867mhz "Crusoe" processor, a 30GB HD, and a whole 256MB of RAM. It came from Fujitsu with WinXP Pro installed! XP wants 512MB minimum to think about performing. Can you say "Death by thrashing"?

Right now it's dual booting Xubuntu and Puppy Linux, and performance is acceptable under Puppy. The big limit is a slow (even for when it was made) HD with low transfer rate. So things work when up, but can take a bit to load. Like, FF 3 takes 45 seconds to load/initialize, and Eclipse takes about a minute and a half.

> P.S. Was (crazily) curious about Win 3.1 Emacsen recently, found JED
> 0.98-4, notGNU, and heard (but didn't find) GNU Emacs 19.27 EMX for OS/2
> (sadly, I'll bet Steve knew where to find it, sigh) that supposedly ran
> under RSHELL (or DOS with RSX).

I have Jed and notGnu. If you want it, I may know where to find Eamcs for OS/2.

> > Gnu Emacs contributor Eric S. Raymond was going on a while back about
> > what Emacs got wrong, and comparing the virtues of Lisp and Python. I
> > suggested he rewrite Emacs to use Python as the underlying language
> > instead of Lisp, and the response was "Don't tempt me!"
>
> He claims to have written more Elisp code than anyone.

He may be right.

> > But yes, he's a bit eccentric ("we don't need the GPL anymore", uh what?)

I knew him before he was famous. Eccentric is a good description.

> > Emacs using Lisp made sense at the time. Lisp was designed for string
> > processing, which is essentially what an editor does, and the versions
> > of Lisp on a couple of early Emacs targets were much better suited for
> > the task than writing Emacs in something else would have been.
>
> Well, Richard Stallman basically invented Emacs, and he worked at MIT in
> the AI Lab using Lisp. That's probably the only real reason for using it.

The original Emacs (Editing MACroS) was a set of macros in the TECO language that ran on MIT's ITS system. TECO is an early "write only" language, with a syntax that looks a lot like line noise. One favorite game of old-time hackers was to figure out what your name would do as TECO code.

I believe James Gosling (creator of Java) wrote the first C implementation of Emacs. But as mentioned, Lisp already existed for an assortment of machines and was well suited for the sort of things an editor did, so writing Emacs in it made sense.

> > Eric also mentioned liking Lua. There's an interesting open source
> > editor called TextAdept which is a small kernel in C and a lot of Lua
> > code. The author calls it "infinitely extensible". I'll have to drop
> > Eric a note to see if he knows of it. He might just decide to make it
> > look like Emacs...
>
> The ones that are extensible (i.e. not "ersatz") have all kinds of
> extension languages: Mocklisp, S-Lang, eLisp, and who knows what else!

Java, Python, Tcl, Rexx...

> Sure Lua and Python are hot right now, but I'm not sure how good an idea
> it would be to use them. (In particular, I assume Python 3000 would be
> preferred, but that's not stable yet, is it?)

I don't believe so, and there's a fair bit of argument in the Python community over it.

How good an idea it is depends on what you think the downside is.

Lua looks interesting. I have a version on my Palm OS PDA.

> > But meanwhile, I wouldn't try to use Gnu Emacs under DOS. It's just way
> > more than I would ever require.
>
> I don't want to say it's overkill, but yeah, it does a lot! I like it,
> it's cool. Doesn't mean I can't also use others, though.

"Why do you use Emacs under DOS?"

"Because I can!"

> > I used to use Daniel Lawrence's MicroEMACS under DOS a good deal, and
> > wrote or rewrote an assortment of macros for it. It built "out of the
> > box" on my AT&T 3B1 under SysV R2, and it was nice to have the same
> > editor on multiple platforms.
>
> I think JASSPA is the best MicroEmacs variant, personally, unless you

I have that here, and tend to agree.

> count things like VILE (which also has a good DOS port). My main favorite
> is TDE (BTW, URL change!), which is
> pretty small (160k via gcc -Os & upx --ultra-brute), but I'm open to
> trying others too.

I have TDE, and have been in touch with Jason Hood on occcasion. I also use a few of his utilities under WinXP, like Ansicon, so I can use my preferred DOS prompt: PROMPT=$e[s$e[H$e[7;44m$e[K$D $B $P$e[m$e[u$g

I also like Blair Thompson's X2, which uses REXX as the macro language.

One of my favorite MS-DOS editors was Dr. David Nye's e.com. E was written in TASM. It edited files up to the limit of memory, had word wrap, search and replace, block move/copy/delete, and settable right and left margins, and did it all in 5KB. It also had programmable F-Keys: you could attach BAT files to F-Keys. Press the F-key, and E wrote the file being edited to a temp file on disk, and ran the BAT file attached to the F-key on it, then reloaded the modified temp file. You could create filters in batch files to perform text processing and call them from E. The big limit was that lines were limited to 80 characters because of how text was stored in memory, and longer lines would be silently truncated.
______
Dennis

> A little painful?
>
> I'm currently playing with a Fujitsu Lifebook p2110 cicra 2002. It was a
> gift from a friend who had upgraded to a faster machine. She loved it,
> but said it was "slow slow slow". Well, no surprise. It has an 867mhz
> "Crusoe" processor, a 30GB HD, and a whole 256MB of RAM. It came from
> Fujitsu with WinXP Pro installed! XP wants 512MB minimum to
> think about performing. Can you say "Death by thrashing"?

Yeah, my Dad has an older XP machine with only 256 MB, and it really did start to bog down. Of course, he had too many startup processes (iTunes, Acrobat, etc). Sometimes I wonder if XP is too slow due to bad optimizations from MS' compiler. At least, it always felt like it should be faster. And yet they claim that it runs faster than Vista on the same machine. Maybe it's just me with the stupid antivirus / anti-spyware etc. running in the background a lot. (But I use this Vista laptop more these days anyways ... even if I can't build GNU Emacs/DJGPP on it, doh.)

> Right now it's dual booting Xubuntu and Puppy Linux, and performance is
> acceptable under Puppy. The big limit is a slow (even for when it was
> made) HD with low transfer rate. So things work when up, but can take a
> bit to load. Like, FF 3 takes 45 seconds to load/initialize, and Eclipse
> takes about a minute and a half.

I've seen my brother run Puppy on one of his (slightly old) recycled PCs, and it ran pretty well. Obviously FF3 and Eclipse are bloat hogs, but you don't need to start them up too often (just keep 'em open). Heh, you think GNU Emacs is bloated, I think Eclipse (Java-based?) is worse.

> I have Jed and notGnu. If you want it, I may know where to find Emacs for
> OS/2.

I found (and tested) 19.33, but it officially wasn't tested for DOS, so it didn't actually work in that way. And for good or bad, the typical modern Emacs for OS/2 isn't EMX, only OS/2 only. (Even VILE for OS/2 via EMX is OS/2 only. Kinda almost defeats the point, IMHO.)

> > > But yes, he's a bit eccentric ("we don't need the GPL anymore", uh
> what?)
>
> I knew him before he was famous. Eccentric is a good description.

Well, all the bigwigs in the software world are considered a little crazy, rightly or wrongly. It takes a special breed, so to speak.

> The original Emacs (Editing MACroS) was a set of macros in the TECO
> language that ran on MIT's ITS system. TECO is an early "write only"
> language, with a syntax that looks a lot like line noise. One favorite
> game of old-time hackers was to figure out what your name would do as TECO
> code.

Yeah, I've heard of TECO but never gotten bored enough to actually try it.

> I believe James Gosling (creator of Java) wrote the first C implementation
> of Emacs.

Officially, the C part is only for portability and speed of the main core.

> But as mentioned, Lisp already existed for an assortment of
> machines and was well suited for the sort of things an editor did, so
> writing Emacs in it made sense.

Even VILE I think supports Perl and maybe Python (and who knows what else).

> > The ones that are extensible (i.e. not "ersatz") have all kinds of
> > extension languages: Mocklisp, S-Lang, eLisp, and who knows what else!
>
> Java, Python, Tcl, Rexx...

Ah yes, I forgot about Rexx. Earlier I was thinking, "I've never seen one", but that's because I never tried THE (or ever used OS/2 natively).

I forget the name of that (non-Emacs) Java editor that was pretty powerful sounding. There was even another editor written in Ruby, IIRC.

> > Sure Lua and Python are hot right now, but I'm not sure how good an
> idea
> > it would be to use them. (In particular, I assume Python 3000 would be
> > preferred, but that's not stable yet, is it?)
>
> I don't believe so, and there's a fair bit of argument in the Python
> community over it.

There is actually a (supposedly) good DOS port of Python, but I've never tested it.

> How good an idea it is depends on what you think the downside is.
>
> Lua looks interesting. I have a version on my Palm OS PDA.

Dungeon Crawl: Stone Soup and Doom: The Roguelike both use Lua internally. (I know those aren't editors, but still ....)

> "Why do you use Emacs under DOS?"
>
> "Because I can!"

It really is very customizable (even beyond the "obviously because it's open source" deal). I'm checking a (slightly older) copy of my notes, but the only really obvious thing (besides that) it has over almost all others is much much better online help (Info and Man readers, describe-key, describe-function, describe-variable, apropos).

You could also say its portability and various key emulations (Brief, CUA, vi) help too, but it's not really alone in that. Probably (depending on OS) Tramp, ERC, Gnus, Calc, Eshell, Diary, Calendar, flyspell, auto-compression, Org mode, Ediff, etc. help a lot too. Oh, and multiple frames (not buffers or windows although those also work), even in DOS. And editing various encodings (even UTF-8) without needing special fonts, is nice.

> > count things like VILE (which also has a good DOS port). My main
> favorite
> > is TDE (BTW, URL change!), which is
> > pretty small (160k via gcc -Os & upx --ultra-brute), but I'm open to
> > trying others too.
>
> I have TDE, and have been in touch with Jason Hood on occcasion. I also
> use a few of his utilities under WinXP, like Ansicon, so I can use my
> preferred DOS prompt: PROMPT=$e[s$e[H$e[7;44m$e[K$D $B
> $P$e[m$e[u$g

Note that he moved web providers recently ("ran out of room" on Geocities, surprised he lasted that long! 15 MB ftw!! What is this, 1996???) and also updated ANSICON to work even with DEP turned on (NX bit or whatever), so finally it works on Vista.

> I also like Blair Thompson's X2, which uses REXX as the macro language.

I never learned REXX, so I can't say. But the investigating I've done makes it look very interesting, at least. And yes, I know, there are at least two DOS ports (Regina and something else, I forget).

> One of my favorite MS-DOS editors was Dr. David Nye's e.com. E was
> written in TASM. It edited files up to the limit of memory,

Yes, I know. No more stinkin' 64k limit (sorry FD Edit and Freemacs!).

> had word
> wrap, search and replace, block move/copy/delete, and settable right
> and left margins, and did it all in 5KB.

6k, IIRC. And the search and replace was fairly basic, no regex (obviously no surprise but would've been nice).

> It also had programmable
> F-Keys: you could attach BAT files to F-Keys. Press the F-key, and E
> wrote the file being edited to a temp file on disk, and ran the BAT file
> attached to the F-key on it, then reloaded the modified temp file. You
> could create filters in batch files to perform text processing and call
> them from E. The big limit was that lines were limited to 80 characters
> because of how text was stored in memory, and longer lines would be
> silently truncated.

Yes, 80 lines max., always truncated, tabs always expanded, .BAK always created, and even that .BAK was overwritten later if you made even the slightest change, which almost defeats the point, IMO. If I wasn't so lazy, I would've translated it from TASM to FASM, but then again, I don't really use it. Still, if you ignore all that, it's a fairly good editor (if you don't need hard tabs, e.g. makefiles, and don't mind 80 columns max). At one time I used it on all my floppies, but then I migrated to Ezedit.

> > It came fromFujitsu with WinXP Pro installed! XP wants 512MB
>> minimum to think about performing. Can you say
> > "Death by thrashing"?
>
> Yeah, my Dad has an older XP machine with only 256 MB, and it really did
> start to bog dwon.

I'd expect it. XP might be bearable if you had a fast HD for swapping, but not otherwise. The Lifbook does not have a fast HD.

> > Right now it's dual booting Xubuntu and Puppy Linux, and performance is
> > acceptable under Puppy. The big limit is a slow (even for when it was
> > made) HD with low transfer rate. So things work when up, but can take
> > a bit to load. Like, FF 3 takes 45 seconds to load/initialize, and
> > Eclipse takes about a minute and a half.
>
> I've seen my brother run Puppy on one of his (slightly old) recycled PCs,
> and it ran pretty well.

It's intended for lower end hardware. There are reports in the Puppy forums of Puppy running successfully (for suitable values of success...) on P200s with 48MB of RAM.

Even Linus sometimes seems bloated. I have an AT&T 3B1 (enhanced model of their old UNIX-PC. It uses a 10mhz MC68010 CPU, and will boot and run a port of AT&T Unix System V Release 2 in one megabyte of RAM and perform acceptably. Give it more (I have 3.5MB). and it flies.

> Obviously FF3 and Eclipse are bloat hogs, but you
> don't need to start them up too often (just keep 'em open).

That's pretty much what I do.

> Heh, you think GNU Emacs is bloated, I think Eclipse (Java-based?) is worse.

Yes, written in Java. The nice thing is that it's cross-platform. If you have a current JVM, it will run. It's effectively the same under Windows and Linux.

Eclipse seems to have largely killed the market for commercial programmers IDEs. Microsoft Visual Studio still gets used, because it's Microsoft. Codegear (the former Borland tools operation) still sells and supports C++ Builder and J Builder, but seems to be mostly catering to an established market.

The thing is, hardware is fast and cheap enough that increasingly fewer people care about bloat. It's faster and cheaper to throw more hardware at it than to optimize for size, unless you are doing embedded development.

> > If you want it, I may know where to find Emacs for OS/2.
>
> I found (and tested) 19.33, but it officially wasn't tested for DOS, so it
> didn't actually work in that way.

I'd be slightly surprised if it did.

> And for good or bad, the typical modern Emacs for OS/2 isn't EMX, only OS/2
> only. (Even VILE for OS/2 via EMX is OS/2 only. Kinda almost defeats the
> point, IMHO.)

I don't know enough about OS/2 to comment. (I used to have an OS/2 server in my computer room, but it was effectively an appliance running a third-party telephony system, and all I had to do was bring it up and down.)

> Well, all the bigwigs in the software world are considered a little crazy,
> rightly or wrongly. It takes a special breed, so to speak.

RMS is even more eccentric.

> Yeah, I've heard of TECO but never gotten bored enough to actually try it.
>

If you feel like poking around, you can get it for DOS, Windoze, OS/2, Linux, and Mac OS/X here: http://almy.us/teco.html

> > I believe James Gosling (creator of Java) wrote the first C
> > implementation of Emacs.
>
> Officially, the C part is only for portability and speed of the main
> core.

That's for the Gnu and Xemacs versions. Gosmacs implemented "Mocklisp", and became the basis for a commercial version by CCA. There used to be an outfit called Convex Systems that made baby supercomputers. They reported being able to close every open bug filed against CCA Emacs by substituting Gnu Emacs.

> > > The ones that are extensible (i.e. not "ersatz") have all kinds of
> > > extension languages: Mocklisp, S-Lang, eLisp, and who knows what
> > > else!
> >
> > Java, Python, Tcl, Rexx...
>
> Ah yes, I forgot about Rexx. Earlier I was thinking, "I've never seen
> one", but that's because I never tried THE (or ever used OS/2 natively). I
> forget the name of that Java one that was pretty powerful sounding. There
> was even one written in Ruby, IIRC.

Four that I know of. Hop over to TextEditors, and look that the JavaBasedEditors, PythonEditorFamily, RubyEditorFamily, and TclTkEditorFamily for editors written entirely in a script language.

> > > Sure Lua and Python are hot right now, but I'm not sure how good an
> > > idea it would be to use them. (In particular, I assume Python 3000
> > > would be preferred, but that's not stable yet, is it?)
> >
> > I don't believe so, and there's a fair bit of argument in the Python
> > community over it.
>
> There is actually a (supposedly) good DOS port of Python, but I've never
> tested it.

There is at least one, though not of Python 3. There's even a partial port of Python to Palm OS called Pippy.

> > Lua looks interesting. I have a version on my Palm OS PDA.
>
> Dungeon Crawl: Stone Soup and Doom: The Roguelike both use Lua internally.
> (I know those are editors, but still ....)

Lots of things use Lua internally. It's meant to be embedded.

> > "Why do you use Emacs under DOS?"
> > "Because I can!"
>
> It really is very customizable (even beyond the "obviously because it's
> open source" deal). I'm checking a (slightly older) copy of my notes, but
> the only really obvious thing it has over almost all others is much much
> better online help (Info and Man readers, describe-key, describe-function,
> describe-variable, apropos).

More than that, really. There are email reader and news reader modes for emacs among other things. The usual practice among old time emacs hackers was to invoke emacs when they logged in, and use emacs as their shell. They could do everything they needed to do from within emacs.

> > I have TDE, and have been in touch with Jason Hood on occcasion. I also
> > use a few of his utilities under WinXP, like Ansicon, so I can use my
> > preferred DOS prompt: PROMPT=$e[s$e[H$e[7;44m$e[K$D $B
> > $P$e[m$e[u$g
>
> Note that he moved web providers recently ("ran out of room" on Geocities,
> surprised he lasted that long! 15 MB ftw!! What is this, 1996???) and also

Thanks for the update. The older URLs still work, however.

> updated ANSICON to work even with DEP turned on (NX bit or whatever).

Cool. I don't run Vista, so I don't think I need that update, but nice to see it in any case.

> > I also like Blair Thompson's X2, which uses REXX as the macro language.
>
> I never learned REXX, so I can't say. But the investigating I've done
> makes it look very interesting, at least. And yes, I know, there are at
> least two DOS ports (Regina and something else, I forget).

There's one called BRexx. Quercus Systems used to have a shareware version called Personal REXX, but they seem to be gone as well.

> > One of my favorite MS-DOS editors was Dr. David Nye's e.com. E was
> > written in TASM. It edited files up to the limit of memory,
>
> Yes, I know. No more stinkin' 64k limit (sorry FD Edit and Freemacs!).

I kinda like Freemacs. And you can make a case that if the file you are editing is bigger than 64KB, you are doing soomething wrong...

> > had word wrap, search and replace, block move/copy/delete, and settable
> > right and left margins, and did it all in 5KB.
>
> 6k, IIRC. And the search and replace was fairly basic, no regex (obviously
> no surprise but would've been nice).

And would have been fun to implement in TASM. Most folks don't need it, so I never saw it as a lack. In any case, the author was an MD, hacking for fun, not a professional developer. He may not have been aware of regexes.

> > It also had programmable F-Keys: you could attach BAT files to F-Keys.
> > Press the F-key, and E wrote the file being edited to a temp file on
> > disk, and ran the BAT file attached to the F-key on it, then reloaded the
> > modified temp file. You could create filters in batch files to perform
> > text processing and call them from E. The big limit was that lines were
> > limited to 80 characters because of how text was stored in memory, and
> > longer lines would be silently truncated.
>
> Yes, 80 lines max., always truncated, tabs always expanded, .BAK always
> created, and even that .BAK was overwritten later if you made even the
> slightest change, which almost defeats the point, IMO. If I wasn't so
> lazy, I would've translated it from TASM to FASM, but then again, I don't
> really use it. Still, if you ignore all that, it's a fairly good editor
> (if you don't need hard tabs, e.g. makefiles, and don't mind 80 columns
> max). At one time I used it on all my floppies, but then I migrated to
> Ezedit.

I used to be involved in BBSes, back in the days when you called a BBS with a dial up modem. I used to moderate ten message areas for one of the big BBS networks (RIME), and made heavy use of an offline reader. With teh reader, you called the BBS, opened a mail door, and downloaded a packet of messages posted since your last call. You could read and reply offline, then call the BBS, post your replies, and download the new message packet.

E was a perfect replies editor. I kept it and various other things like LIST on a RAMdisk for instant invocation. I kept it stashed on my floppies as well, but had to remember the 80 col limit.

Another neat tiny editor is Brian KElley's TM, a "Tiny eMacs" editor in 4K.
See http://www.bhk.com/tm/

(It does have the 64K limit.)
______
Dennis

> > > One of my favorite MS-DOS editors was Dr. David Nye's e.com. E was
> > > written in TASM. It edited files up to the limit of memory,
> >
> > Yes, I know. No more stinkin' 64k limit (sorry FD Edit and Freemacs!).
>
> I kinda like Freemacs. And you can make a case that if the file you are
> editing is bigger than 64KB, you are doing soomething wrong...

RXDOSDEV ASM        63.854  20.01.2009  20:40
RXDOSCFG ASM        64.057  11.01.2009  19:55
RXDOSDV2 ASM        70.480  14.12.2008  21:30
RXDOSINI ASM        83.478  01.04.2009  15:55
RXDOSLFN ASM       119.038  11.01.2009  21:11
RXDOS    ASM       160.990  01.04.2009  18:54

There you go. (The decimal point of the file sizes is none, it's the European thousands separator.) The RxDOSLFN file really contains the LFN handling only, while the main RxDOS file contains some tables and interrupt handlers plus the high layer of many subfunctions. These files, as opposed to the originals, already use tabs. If you're interested, the remaining kernel files (mostly below 30 KiB each) sum up to another 336,070 bytes.

You could argue that writing stuff in C is better, then

---
l

> > I've seen my brother run Puppy on one of his (slightly old) recycled
> PCs,
> > and it ran pretty well.
>
> It's intended for lower end hardware. There are reports in the Puppy
> forums of Puppy running successfully (for suitable values of success...)
> on P200s with 48MB of RAM.

It was lower requirements back in Puppy 2.16 or so (which ironically wasn't that long ago). Same for DeLi 0.7.2. But once you add certain features (UTF-8 support in DeLi), you lose some of that small footprint.

> Even Linus sometimes seems bloated. I have an AT&T 3B1 (enhanced model of
> their old UNIX-PC. It uses a 10mhz MC68010 CPU, and will boot and run a
> port of AT&T Unix System V Release 2 in one megabyte of RAM and
> perform acceptably. Give it more (I have 3.5MB). and it flies.

Minix is pretty good and small too (hint hint: DOSMinix, heh, boots from on top of DOS).

> The thing is, hardware is fast and cheap enough that increasingly fewer
> people care about bloat. It's faster and cheaper to throw more
> hardware at it than to optimize for size, unless you are doing embedded
> development.

Ugh. C++ Builder is 390 MB though!! Ridiculous. I recently crammed a workable DJGPP compiler (compressed) onto a single floppy.

> > I forget the name of that Java one that was pretty powerful sounding.
> > There was even one written in Ruby, IIRC.
>
> Four that I know of. Hop over to TextEditors, and look that the
> JavaBasedEditors, PythonEditorFamily, RubyEditorFamily, and
> TclTkEditorFamily for editors written entirely in a script language.

Okay, I think I was vaguely remembering (although not trying) Jedit and Diakonos, respectively. I think I got turned off by lack of DOS portability (although Ruby 1.8.4 exists, but I was too skeptical to bother trying).

> > > "Why do you use Emacs under DOS?"
> > > "Because I can!"
> >
> > It really is very customizable (even beyond the "obviously because it's
> > open source" deal). I'm checking a (slightly older) copy of my notes,
> > but the only really obvious thing it has over almost all others is
> > much much better online help (Info and Man readers, describe-key,
> > describe-function, describe-variable, apropos).
>
> More than that, really. There are email reader and news reader modes for
> emacs among other things.

But for the DOS port, I only know of Eli Z. (the DJGPP port maintainer) ever actually using that, and only then on Win9x, IIRC.

> The usual practice among old time emacs hackers
> was to invoke emacs when they logged in, and use emacs as their shell.
> They could do everything they needed to do from within emacs.

Yes, esp. because it was so slow to start up anyways.
But yeah, compile, edit, debug, jump to errors, play games, shell crud, etc. It's an all-in-one suite.

> > Note that [Jason Hood] moved web providers recently ("ran out of room"
> > on Geocities, surprised he lasted that long! 15 MB ftw!! What is
> > this, 1996???) and also
>
> Thanks for the update. The older URLs still work, however.

Yes, but they don't have the latest stuff.

> > updated ANSICON to work even with DEP turned on (NX bit or whatever).
>
> Cool. I don't run Vista, so I don't think I need that update, but nice to
> see it in any case.

Updated again on the 3rd, something about "XCOPY now works" (whatever that means).

> > I never learned REXX, so I can't say. But the investigating I've done
> > makes it look very interesting, at least. And yes, I know, there are at
> > least two DOS ports (Regina and something else, I forget).
>
> There's one called BRexx. Quercus Systems used to have a shareware
> version called Personal REXX, but they seem to be gone as well.

Oh, I've long ago downloaded BRexx and Regina, just never learned yet.

> > > One of my favorite MS-DOS editors was Dr. David Nye's e.com. E was
> > > written in TASM. It edited files up to the limit of memory,
> >
> > Yes, I know. No more stinkin' 64k limit (sorry FD Edit and Freemacs!).
>
> I kinda like Freemacs. And you can make a case that if the file you are
> editing is bigger than 64KB, you are doing soomething wrong...

DTE (ancestor of TDE and FTE) had such a limit. I don't doubt you can whip some bastardly > 64k files into shape. (In fact, my text editor comparison comments are all inside a bat called V49SPLIT.BAT, intended to split a 160k .ASM into < 64k pieces "just in case", heh.)

> > Yes, 80 lines max., always truncated, tabs always expanded, .BAK always
> > created, and even that .BAK was overwritten later if you made even the
> > slightest change, which almost defeats the point, IMO. If I wasn't so
> > lazy, I would've translated it from TASM to FASM, but then again, I
> > don't really use it. Still, if you ignore all that, it's a fairly
> > good editor (if you don't need hard tabs, e.g. makefiles, and don't
> > mind 80 columns max). At one time I used it on all my floppies,
> > but then I migrated to Ezedit.
>
> I used to be involved in BBSes, back in the days when you called a BBS
> with a dial up modem. I used to moderate ten message areas for one of the
> big BBS networks (RIME), and made heavy use of an offline reader. With teh
> reader, you called the BBS, opened a mail door, and downloaded a packet of
> messages posted since your last call. You could read and reply offline,
> then call the BBS, post your replies, and download the new message
> packet.
>
> E was a perfect replies editor. I kept it and various other things like
> LIST on a RAMdisk for instant invocation. I kept it stashed on my
> floppies as well, but had to remember the 80 col limit.
>
> Another neat tiny editor is Brian KElley's TM, a "Tiny eMacs" editor in
> 4K.
> See http://www.bhk.com/tm/
>
> (It does have the 64K limit.)

I've tried it. IIRC, it has a search/replace bug. And no regex. But yeah, it's pretty good, esp. for its size!

P.S. I was recently wondering to myself, "Since GNU Emacs takes so much space anyways, and since Freemacs IS GPL, why don't they include that in the distribution? It wouldn't hurt, and would be a nice alternative for old old machines." (Quick guess: they would be enraged at the idea of 16-bit, and/or mad that it uses TASM, doh. Still, the Changelogs take up more space!! And it IS extensible! Oh well, just a daydream I guess.)

> RXDOSDEV ASM        63.854  20.01.2009  20:40
> RXDOSCFG ASM        64.057  11.01.2009  19:55
> RXDOSDV2 ASM        70.480  14.12.2008  21:30
> RXDOSINI ASM        83.478  01.04.2009  15:55
> RXDOSLFN ASM       119.038  11.01.2009  21:11
> RXDOS    ASM       160.990  01.04.2009  18:54
>
> There you go. (The decimal point of the file sizes is none, it's the
> European thousands separator.) The RxDOSLFN file really contains the LFN
> handling only, while the main RxDOS file contains some tables and
> interrupt handlers plus the high layer of many subfunctions. These files,
> as opposed to the originals, already use tabs. If you're interested, the
> remaining kernel files (mostly below 30 KiB each) sum up to another
> 336,070 bytes.
>
> You could argue that writing stuff in C is better, then

No way! What you save in source size is lost in .EXE size. Ideally, mix and match C + ASM for best results either way.

> > You could argue that writing stuff in C is better, then
>
> No way! What you save in source size is lost in .EXE size.

I'd actually forked DOS-C if I intended writing stuff in C.

> Ideally, mix and match C + ASM for best results either way.

Nah, I prefer writing ASM only. What you save in the .EXE size you lose in time, but who cares how long it takes, anyway? It's not like I'm doing it for money.

> > > You could argue that writing stuff in C is better, then
> >
> > No way! What you save in source size is lost in .EXE size.
>
> I'd actually forked DOS-C if I intended writing stuff in C.

I don't prefer C, in fact I think it's overkill sometimes.

> > Ideally, mix and match C + ASM for best results either way.
>
> Nah, I prefer writing ASM only. What you save in the .EXE size you lose in
> time, but who cares how long it takes, anyway? It's not like I'm doing it
> for money.

I always find I'm fighting against the compiler. It's no faster from my experience, esp. when compilers are so much slower than assemblers. After all the "but compilers are so smart and computers are so fast", then why the hell does it (allegedly) take 24 hours to build Firefox??? (And to dispel another myth: if GCC is always better than assembly optimization, then why is GCC compiled by itself so slow??)

> (And to dispel another myth: if GCC is always better than assembly
> optimization, then why is GCC compiled by itself so slow??)

http://compilers.iecc.com/comparch/article/03-11-086

> > (And to dispel another myth: if GCC is always better than assembly
> > optimization, then why is GCC compiled by itself so slow??)
>
> http://compilers.iecc.com/comparch/article/03-11-086

I really hope that the GCC devs still test on stuff older than a Core 2. (Sometimes I regret that developers have such fast machines because I think it makes them lazy ... or blind perhaps.)

EDIT: Headers vs. units still doesn't explain why successive GCCs keep getting slower, even with -O0. It shouldn't have to do that much more these days than it did ten years ago (for C89, at least), right?

> > > (And to dispel another myth: if GCC is always better than assembly
> > > optimization, then why is GCC compiled by itself so slow??)
> >
> > http://compilers.iecc.com/comparch/article/03-11-086
>
> I really hope that the GCC devs still test on stuff older than a Core 2.
> (Sometimes I regret that developers have such fast machines because I
> think it makes them lazy ... or blind perhaps.)
>
> EDIT: Headers vs. units still doesn't explain why successive GCCs keep
> getting slower, even with -O0.

I've no idea. I've never benchmarked gcc versions against itself (and never used gcc on dos in practice)

> It shouldn't have to do that much more
> these days than it did ten years ago (for C89, at least), right?

If so, why don't you use a ten years old version? If it doesn't matter....

> > EDIT: Headers vs. units still doesn't explain why successive GCCs keep
> > getting slower, even with -O0.
>
> I've no idea. I've never benchmarked gcc versions against itself (and
> never used gcc on dos in practice)

Never used DJGPP? Well, you are odd.

> > It shouldn't have to do that much more
> > these days than it did ten years ago (for C89, at least), right?
>
> If so, why don't you use a ten years old version? If it doesn't matter....

I do, remember my GCC 2.95.3 / BinUtils 2.16 / DJGPP 2.03p2 single-floppy package? But that was more of a size consideration. If I could've crammed the latest, I probably would have. The whole idea was the have a stand-alone GCC compiler that was as new as possible (-mcpu=pentiumpro) but still small and useful. Still, it should be "good enough" for normal ANSI C stuff. (Okay, March 2001 -> April 2009 is only eight years, but since you consider WinME's 8.5 to be 10, I guess this counts too, heh.) BTW, it matters less on newer machines, but it still does matter, unless you like buying new cpus every six months (I don't).

> I do, remember my GCC 2.95.3 / BinUtils 2.16 / DJGPP 2.03p2 single-floppy

Nice, where can I find it? For a need to make a smallest djgpp code as possible I still keep on HDD some very old DJGPP installation GCC 2.7.2. It's only 6,7MB of space. It makes about 20-30kB smaller binaries after UPXing of small programs compared to the latest GCC. But it doesn't understand newer C sources so the usability is quite limited.

---
DOS gives me freedom to unlimited HW access.

> > I do, remember my GCC 2.95.3 / BinUtils 2.16 / DJGPP 2.03p2
> single-floppy
>
> Nice, where can I find it?

http://rugxulo.googlepages.com/djgpp203.7z
http://rugxulo.googlepages.com/7zdec.zip

---
Forum admin

> > I've no idea. I've never benchmarked gcc versions against itself (and
> > never used gcc on dos in practice)
>
> Never used DJGPP? Well, you are odd.

For the few C work I did, I had access to gcc on BSD before DJGPP existed. There was never reason to torture myself with it.

I did look at it at some point because of the DXE stuff.

> > If so, why don't you use a ten years old version? If it doesn't
> matter....
>
> I do, remember my GCC 2.95.3 / BinUtils 2.16 / DJGPP 2.03p2 single-floppy
> package?

No.

> But that was more of a size consideration.

Ah, that's probably why.

> is only eight years, but
> since you consider WinME's 8.5 to be 10, I guess this counts too, heh.)
> BTW, it matters less on newer machines, but it still does matter, unless
> you like buying new cpus every six months (I don't).

My first DOS PC in '92 already had a harddisk, so I never bothered to torture myself with floppy versions on PC.

> > > I've no idea. I've never benchmarked gcc versions against itself (and
> > > never used gcc on dos in practice)
> >
> > Never used DJGPP? Well, you are odd.
>
> For the few C work I did, I had access to gcc on BSD before DJGPP existed.
> There was never reason to torture myself with it.

It's not torture. And it's been around since 1989 (history).

> > But that was more of a size consideration.
>
> Ah, that's probably why.

Actually, I'm fairly certain even 3.4.4 (or similar) would've been good enough for me. But 2.95.3 was the last of its branch, and something increased the size a lot after that. I wasn't willing to sacrifice the stable 2.03p2 library or some auxiliary tools (make, rm, cwsdpmi, wmemu387) just to fit a slightly bigger compiler.

> > is only eight years, but
> > since you consider WinME's 8.5 to be 10, I guess this counts too, heh.)
> > BTW, it matters less on newer machines, but it still does matter,
> unless
> > you like buying new cpus every six months (I don't).
>
> My first DOS PC in '92 already had a harddisk, so I never bothered to
> torture myself with floppy versions on PC.

It's not a "run from floppy" version, it just fits compressed on a single 1.44 MB (not overformatted) floppy. The idea is to make migration between machines easier, to have a small but good ANSI C compiler (32-bit, POSIX, LFN). It only needs 6 MB of space (or 3.5 if UPX'd), which is good for hard disks or even RAM disks. And I finally got it to pack with .7z, so you don't need a bunch of RAM to decompress anymore either (tested unpacking successfully on my 486 Sx/25 w/ 8 MB of RAM without swapping). I consider this the spiritual successor of EZ-GCC for v1 (which was quickly outdated) even if not exactly meant to be a 1-to-1 mirror (no G++, no GDB, no GRX).

> > I do, remember my GCC 2.95.3 / BinUtils 2.16 / DJGPP 2.03p2
> single-floppy
>
> Nice, where can I find it? For a need to make a smallest djgpp code as
> possible I still keep on HDD some very old DJGPP installation GCC 2.7.2.
> It's only 6,7MB of space. It makes about 20-30kB smaller binaries after
> UPXing of small programs compared to the latest GCC. But it doesn't
> understand newer C sources so the usability is quite limited.

Well, I wanted the latest / greatest I could find while still cramming it as small as possible. No, there's no C++ or C99, but it's good enough for most C apps (can compile TDE, Info-Zip, NASM 0.98.39, CWS-ED, WMemu, probably GNU Emacs too if you add mv and sed, etc).

* djgpp203.7z (main archive, fits on a 1.44 MB floppy w/ 7zdec.exe)
* djgpp203.txt (readme/changes)
* dj203lst.txt (list of all files)
* dj203-7z.txt (.BAT used to make the .7z archive)

And to comply with the GPL, here's the full sources for everything: bnu2161s.tbz, gcc2953s.tbz, fil41s.tbz, djlsr204.tbz, djlsr203.tbz, mak3791s.tbz, wmemu21s.tbz, csdpmi5s_u.tbz, csdpmi6t.zip, xgrep103.zip, ezedit20.zip, d3x-090h.zip

Note that I really should've perhaps put all those sources in one big file to make it easier to download it all. I also experimented with not using .tar inside the .7z, but not sure about that (7zdec doesn't unpack dirs, so I'd have to manually mkdir/move via .BAT, and some filenames conflict). But it's not hugely important, I guess. (Nag me if interested.)

P.S. I recompiled (for Win2k fixes) and put on my website w/ srcs: 2.7.2.3 twice (DJGPP and DJ's heavily-unfinished 16-bit target hack), 2.8.1 (oops, I removed it, ask if interested), and 2.95.3 twice (DJGPP target, MOSS target).

> It's not a "run from floppy" version, it just fits compressed on a single
> 1.44 MB (not overformatted) floppy. The idea is to make migration between
> machines easier, to have a small but good ANSI C compiler (32-bit, POSIX,
> LFN).

Damn, my 386 had only a 5 1/4 HD floppy. Well, then it wouldn't have worked anyway.

> > It's not a "run from floppy" version, it just fits compressed on a
> single
> > 1.44 MB (not overformatted) floppy. The idea is to make migration
> between
> > machines easier, to have a small but good ANSI C compiler (32-bit,
> POSIX,
> > LFN).
>
> Damn, my 386 had only a 5 1/4 HD floppy. Well, then it wouldn't have
> worked anyway.

In theory, since you don't still have that 386 (right?), if you "downgraded" to 2.8.1 or 2.7.2.3, removed AR.EXE, and used UHarc, etc., you could probably fit it in 1.2 MB.

> In theory, since you don't still have that 386 (right?), if you
> "downgraded" to 2.8.1 or 2.7.2.3, removed AR.EXE, and used UHarc, etc.,
> you could probably fit it in 1.2 MB.

Well, but that is removing functionality? Can't you just remove some bloat, but keep functionality?

And yes, I might still have that mobo somewhere. (with a SX20 soldered on it)

> > In theory, since you don't still have that 386 (right?), if you
> > "downgraded" to 2.8.1 or 2.7.2.3, removed AR.EXE, and used UHarc, etc.,
> > you could probably fit it in 1.2 MB.
>
> Well, but that is removing functionality? Can't you just remove some
> bloat, but keep functionality?

Maybe. BTW, the only thing 2.8.1 has over 2.7.2.3 is wimpy 586 optimizations and stabs debug info, not exactly useful for a 386, is it?

> And yes, I might still have that mobo somewhere. (with a SX20 soldered on
> it)

I'm honestly not sure why I included AR.EXE at all, but I guess I figured some people might find libraries more convenient (and some makefiles require it). I'm sure I could remove some of the superfluous DPMI servers and stick with good ol' CWSDPMI r5.

Does the 386 have a VGA? If not, I should remove the 4k tiny EZEDIT. (And even then that was a bonus. I assume most people have their own preferred editors.)

EDIT: Did I mention that 2.7.2.3 is a billion times easier to build than later versions? Heck, I was able to build it on my P166 with SFNs only (!) in ten minutes. And the sources are only like 6 MB .tar.bz2'd (unlike billion megs later, probably mostly due to more frontends).

> Hey guys,
> If any of you has a preference for the ultra powerful tool that is GNU
> Emacs, you may like to know about

a). newer "pretest" 23.0.92 + tiny SYSTEM_MALLOC patch

"Your file has been saved and can now be downloaded 10 times. It will
be deleted after 90 days without download."

http://rapidshare.com/files/219396153/emacs-23-0-92.7z.html
MD5: 38D3E41C8AE67469DF422E02A7F5DF60

34 MB .7z, packed via -mx5 (since higher was too slow). Takes approx. 180 MB of space unpacked on NTFS (DOS386, I know I know ...). Includes everything: precompiled .EXEs, sources, docs, etc.

> * djgpp203.7z (main
> archive, fits on a 1.44 MB floppy w/
> 7zdec.exe)
> * djgpp203.txt
> (readme/changes)
> * dj203lst.txt
> (list of all files)
> * dj203-7z.txt
> (.BAT used to make the .7z archive)

Just a note, I didn't use UPX LZMA option and the CC1.EXE was compressed much better - 580 vs 703 kB :)

---
DOS gives me freedom to unlimited HW access.

> Just a note, I didn't use UPX LZMA option and the CC1.EXE was compressed
> much better - 580 vs 703 kB :)

CC1 (the real internal compiler) is not compressed before being put inside the .7z to facilitate better compression (since it's by far the biggest file). But the DJPACK.BAT file does use some low number for UPX (-2 or -4, I forget) due to my 486's 8 MB not liking higher options (and swapping forever, ugh).

> I'm honestly not sure why I included AR.EXE at all, but I guess I figured
> some people might find libraries more convenient (and some makefiles
> require it). I'm sure I could remove some of the superfluous DPMI servers
> and stick with good ol' CWSDPMI r5.

If you reuse certain .o's a lot, you better AR them together. Clustersize.

FPC in heavy smartlink mode compiles every separate symbol to a separate .o, and then ARs them all together.

> Does the 386 have a VGA?

Trident 9000 iirc.

Note that this is only semi jokedly. I do have the machine (on the attic I hope), but it is not in working order. I kept it so that I have something without copro for FPC copro emulation testing if I really have _TOO_ much time on my hands

> But the DJPACK.BAT file does use some low number for UPX
> (-2 or -4, I forget) due to my 486's 8 MB not liking higher options (and
> swapping forever, ugh).

OK, I missed that you use diff. compression level for various files. Well that you didn't forget to exclude cwsdpmi from packing :)

---
DOS gives me freedom to unlimited HW access.

> Note that this is only semi jokedly. I do have the machine (on the attic I
> hope), but it is not in working order. I kept it so that I have something
> without copro for FPC copro emulation testing if I really have _TOO_ much
> time on my hands

Well, I did find a way to barely squeeze it into 1200k (1.2 MB) for 5.25" FD, but as mentioned, I sadly had to remove all the unnecessary frills. In other words, your best bet is if you used 2.8.1 or 2.7.2.3 (instead of 2.95.3) plus if I went ahead and made the DJ203-7Z.BAT magically rename conflicting files (and DJINSTAL.BAT mkdir / move the files into appropriate places) so that .tar isn't needed, only .7z (since 7ZDEC won't restore dir structures). Actually, in theory, I'd make a better DJ203-7Z.BAT that would optionally let you choose any of those options, but it'll take a bit of work. No promises, but I'll think about it some more. It's definitely worth doing, though, IMO.

Well, I hate to revive an old thread but if anybody cares ...

1). My mini DJGPP floppy package no longer needs a .tar since 7zdec from LZMA SDK 9.04 beta supports 'x' (extract with dirs) now. I also added a few tiny .C examples (not mine, mostly from IOCCC).

2). GNU Emacs 23.0.95 pretest was released recently. I did build and test in FreeDOS a bit. Eli even fixed a frames bug, which then caused me to recompile the main .EXE. All this info can be found on the corresponding comp.os.msdos.djgpp thread.

GNU Emacs 23.0.96 pretest is available now, and "barring any huge bugs", it will be the last before final 23.1. In other words, test test test test test!!!

http://groups.google.com/group/comp.os.msdos.djgpp/browse_frm/thread/2c7d3becd02057e8#

> GNU Emacs 23.0.96 pretest is available now, and "barring any huge bugs", it
> will be the last before final 23.1. In other words, test test test test
> test!!!


Well, obviously, 23.1 was released recently (July 29, IIRC). No premade packages yet, but it compiles pretty easily.