DOS ain't dead

On 16 October 2008 I finished my 32-bit DOS port of Marko Macek's Folding Text Editor (FTE) version 0.50.01-cvs using DJGPP version 2.04 beta.

This is slightly newer than the version by Deniska of www.hitechlabs.tk, but it doesn't have his "several minor improvements", because he doesn't provide full source code and I don't wanna violate the "Artistic License".

A binary, a user manual in HTML format, and fully configured sources plus some simple instructions on how to rebuild are available at http://www.bttr-software.de/ports/.

---
Forum admin

> A binary, a user manual in HTML format, and fully configured sources plus
> some simple instructions on how to rebuild are available at
> http://www.bttr-software.de/ports/.

Thanks! Since FTE is my favorite DOS editor, I did a few tests. It works fine, and in a WinXP DOS-Box there's nothing to complain about. However, in plain DOS - no cache loaded! - there's a small problem: it's very slow if large files are viewed/edited. To load a 85 MB text file it needs 1-2 minutes, and pressing Alt-X to exit (file unmodified!) needs about 3-4 minutes until the DOS prompt appears.

[The test machine has 1 GB memory]

---
MS-DOS forever!

> Thanks! Since FTE is my favorite DOS editor, I did a few tests. It works
> fine, and in a WinXP DOS-Box there's nothing to complain about. However,
> in plain DOS - no cache loaded! - there's a small problem: it's very slow
> if large files are viewed/edited. To load a 85 MB text file it needs 1-2
> minutes, and pressing Alt-X to exit (file unmodified!) needs about
> 3-4 minutes until the DOS prompt appears.
>
> [The test machine has 1 GB memory]

Could this be due to DJGPP's default (slow) malloc()? I think it's free() is said (by CWS) to be "O(n*n) due to free()'s block merge". Try Nmalloc instead, and see if that makes a difference. (Latest DJGPP ports of GCC use this because "otherwise it would be too slow" [Andris Pavenis].)

P.S. What are you trying to edit that's 85 MB in size?? CWS claims his EDT-alike editor is very fast at editing huge files. But it's a different interface entirely to FTE. And although I like FTE, I prefer others that are good too: TDE, Mined, JED, VILE, JASSPA MicroEmacs, etc. although I never edit such huge files (not even close!). What does FTE offer that's so unique? (Just curious.)

(edited for corrections, additional info)

> Thanks! Since FTE is my favorite DOS editor, I did a few tests. It works
> fine, and in a WinXP DOS-Box there's nothing to complain about. However,
> in plain DOS - no cache loaded! - there's a small problem: it's very slow
> if large files are viewed/edited. To load a 85 MB text file it needs 1-2
> minutes, and pressing Alt-X to exit (file unmodified!) needs about
> 3-4 minutes until the DOS prompt appears.
>
> [The test machine has 1 GB memory]

Wait a minute, you didn't forget and accidentally use CWSDPMI r5, did you? It's much slower, esp. on machines w/ > 512 MB of RAM since it then always needs to swap out to disk because of page tables in low memory. r6 (which isn't quite stable) is at least a lot faster due to 4 MB pages. However, all of this is moot if you're using HDPMI32. But unless you manually loaded it first or run it as TSR (like DOS386 likes to do), then CWSDPMI is used by default (as always for DJGPP v2 unless you change it via STUBEDIT).

> This is slightly newer than the version by Deniska of
> www.hitechlabs.tk, but it doesn't
> have his "several minor improvements", because he doesn't provide full
> source code and I don't wanna violate the "Artistic License".

From memory, one of the improvements is the position of the mouse, which I place in the corner of the screen after the program is loaded, instead of the center.

> Wait a minute, you didn't forget and accidentally use CWSDPMI r5, did you?
> It's much slower, esp. on machines w/ > 512 MB of RAM since it then always
> needs to swap out to disk because of page tables in low memory. r6 (which
> isn't quite stable) is at least a lot faster due to 4 MB pages. However,
> all of this is moot if you're using HDPMI32. But unless you manually
> loaded it first or run it as TSR (like DOS386 likes to do), then CWSDPMI
> is used by default (as always for DJGPP v2 unless you change it via
> STUBEDIT).

Yes, the delays seems to be caused by CWSDPMI - there is a "r5" version on the test machine. If I load HDPMI first, the editor exits within 1 second.

---
MS-DOS forever!

> From memory, one of the improvements is the position of the mouse, which I
> place in the corner of the screen after the program is loaded, instead of
> the center.

I don't see this as an improvement.

---
Forum admin

> in plain DOS - no cache loaded! - there's a small problem: it's very slow
> if large files are viewed/edited. To load a 85 MB text file it needs 1-2

OK, I didn't try files that large.

---
Forum admin

Rugxulo wrote:

> you didn't forget and accidentally use CWSDPMI r5, did you?
> all of this is moot if you're using HDPMI32. But unless you manually
> loaded it first or run it as TSR (like DOS386 likes to do), then
> CWSDPMI is used by default (as always for DJGPP v2 unless

Japheth wrote:

> Yes, the delays seems to be caused by CWSDPMI - there is a "r5" version on
> the test machine. If I load HDPMI first, the editor exits within 1 second.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

rr wrote:

> OK, I didn't try files that large.

My 15 MiB test text file securely kills 99.99% of editors around ... only Kinesics works. No test of this FTE port yet.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> My 15 MiB test text file securely kills 99.99% of editors around ... only
> Kinesics works. No test of this FTE port yet.

How does the textmode FPC ide fare? Do you have that file online?

Note that the FPC textmode IDE has a limit on 256 char lines. Less of a problem with sourcecode, but with other files it can be limiting.

there's another tiny problem, this time with the Tools/Shell command. In DOS, if I exit to the shell from the editor and try to launch another DOS-extended program, I experienced 4 results so far:

1. it runs without problems and "exit" returns to FTE.
2. it crashes with an exception, but at least "exit" returns to FTE.
3. it crashes and silently exits FTE as well, but I can continue to work.
4. it crashes and then freezes, only reset helps.

regrettably 2.- 4. occur more often than 1. It seems that CWSDPMI r5 doesn't like neither HX nor DOS4GW (i.e. Open Watcom tools).

---
MS-DOS forever!

> there's another tiny problem, this time with the Tools/Shell command. In
> DOS, if I exit to the shell from the editor and try to launch another
> DOS-extended program, I experienced 4 results so far:
>
> 1. it runs without problems and "exit" returns to FTE.
> 2. it crashes with an exception, but at least "exit" returns to FTE.
> 3. it crashes and silently exits FTE as well, but I can continue to work.
> 4. it crashes and then freezes, only reset helps.
>
> regrettably 2.- 4. occur more often than 1. It seems that CWSDPMI r5
> doesn't like neither HX nor DOS4GW (i.e. Open Watcom tools).

Is this via "HDPMI32" or "HDPMI32 -r"? The latter may work better (or not, dunno). Also, try to disable NULL pointer protection (-x) in CWSDPMI via CWSPARAM. And maybe even copy / rename HDPMI32 to CWSDPMI and copy / rename DOS32A to DOS4GW. And don't forget w/ 1 GB RAM machines for r5 you can "lh CWSDPMI -sf:\ -p" (but F: should be a small RAM drive of several MBs). See if any of that helps. If you can specify exactly what command you're trying to run, I can try to duplicate it on my setup.

P.S. FTE supports folds, undo, accurate syntax highlighting, tags, etc. (which TDE doesn't). It's actually got some of the same code base as TDE, I think.

> My 15 MiB test text file securely kills 99.99% of editors around ... only
> Kinesics works. No test of this FTE port yet.

This can't be right (unless you tested only old GNU Emacs, like 19.24 or whatever). Besides, some (smart) editors don't load the whole file into memory anyways since you can't edit all that at once anyways (unless you reformat block / region or insert something in the middle). The only popular editors I can think of to surely fail this are FD Edit and FreeMacs (64k limit FTW !!).

Try GNU Emacs 20.5, VIM 7.2, VILE 9.7 at least (because they are popular and almost definitely well tested). If any of them fail, report a bug.

> FTE supports folds, undo, accurate syntax highlighting

For what languages ? C##, Perl, Python, Fortran, Cobol, Ru[g]by, Lua, ... (many more ) are not that useful for me

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Is this via "HDPMI32" or "HDPMI32 -r"? The latter may work better (or not,
> dunno). Also, try to disable NULL pointer protection (-x) in CWSDPMI via
> CWSPARAM. And maybe even copy / rename HDPMI32 to CWSDPMI and copy /
> rename DOS32A to DOS4GW. And don't forget w/ 1 GB RAM machines for r5 you
> can "lh CWSDPMI -sf:\ -p" (but F: should be a small RAM drive of several
> MBs). See if any of that helps.

Thanks, I bet your suggestions would help, but I prefer to avoid DGPJJ. Here's a replacement for fte.exe:

http://www.japheth.de/Download/fte-hx.zip

with the following benefits:

- uses free MS VC Toolkit 2003 instead of DGPJJ
- DPMI host is included (HDPMI)
- binary isn't packed
- UPX will - hopefully - refuse to pack it

besides fte.exe the package just contains the modified fte-msvc.mak.

---
MS-DOS forever!

marcov wrote:

...

see other thread

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > can "lh CWSDPMI -sf:\ -p" (but F: should be a small RAM drive of several M

COOL. Hog away all memory for file caching and then brew a swap file to allow apps to "run". Why not invent a HD fitting into RAM slots and RAM modules connectable at the end of IDE and SATA cable ?

> - uses free MS VC Toolkit 2003 instead of DGPJJ

Many compilers ... every of them has some faults, I'm not aware of a perfect one

> - DPMI host is included (HDPMI)



> - binary isn't packed



> - UPX will - hopefully - refuse to pack it

Let's drop a request ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > FTE supports folds, undo, accurate syntax highlighting
>
> For what languages ?

Look for the "m_XXX" files in directory "config".

---
Forum admin

> COOL. Hog away all memory for file caching and then brew a swap file to
> allow apps to "run".

Do you know that physical memory has other uses?

> Why not invent a HD fitting into RAM slots

Why? Is your RAM too fast?

> and RAM modules connectable at the end of IDE and SATA cable?

You don't know that they exist now?

Steve ( Welcome back dude ! I had thought you would be dead ) wrote:

> Do you know that physical memory has other uses?

NO.

> Why? Is your RAM too fast?

YES.

> You don't know that they exist now?

Feel free to donate me some

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Steve ( Welcome back dude !

Thank you.

> I had thought you would be dead

I have risen.

> > Do you know that physical memory has other uses?
>
> NO.

Well, it does. Now you know.

> > Why? Is your RAM too fast?
>
> YES.

Interesting problem. Try slowing down your CPU to balance it.

> > You don't know that they exist now?
>
> Feel free to donate me some

I responded to the question you asked. This is a different issue. Give me time to think about it. Just sit there and wait for my decision.

> This can't be right (unless you tested only old GNU Emacs, like 19.24 or
> whatever). Besides, some (smart) editors don't load the whole file into
> memory anyways since you can't edit all that at once anyways (unless you
> reformat block / region or insert something in the middle). The only
> popular editors I can think of to surely fail this are FD Edit and
> FreeMacs (64k limit FTW !!).
>
> Try GNU Emacs 20.5, VIM 7.2, VILE 9.7 at least (because they are popular
> and almost definitely well tested). If any of them fail, report a bug.

We were talking about editors not resp. an OS and a SM tools for the kinky.

rr wrote:

> > For what languages ?
> Look for the "m_XXX" files in directory "config".

Indeed many ... but nothing for me

Japheth wrote:

> your suggestions would help, but I prefer to avoid DGPJJ.
> Here's a replacement for fte.exe: http://www.japheth.de/Download/fte-hx.zip

> - uses free MS VC Toolkit 2003 instead of DGPJJ
> - DPMI host is included (HDPMI)
> - binary isn't packed
> - UPX will - hopefully - refuse to pack

Tested (see shot) :



1. Japheth's version is considerably less bloated.

2. rr's and hitech's ports contain a large bunch of files of unknown purpose, obsolete or inappropriate (install instructions for OS/2 or Linuux)

3. Japheth's version seems to include a very broken LOADPEX/HDPMI, if no better HDPMI resident, it securely crashes immediately when I touch the rat ... see shot (3.) done in BOCHS. It also crashes on real PC and in QEMU, even worse, a crash inside QEMU crashes QEMU as well ( critical BUG ) and the chain of destruction continues with GPF in Ring0 on host PC + filesystem corruption If "-C" is omitted is also crashes, even before, see shot (4.). IIRC I has similar problems with the updated "S" thingie ... DPMI host included is good, a working DPMI host included would be even better

4. None of the ports includes info about who compiled it at what time and with what ... all do show the same, OTOH, see shot (1.), they do boast with (C)'s from 1998 (newest) down to year 200 !!!

5. Loading file works, is fast, and has a P.I.

6. S&R works, is fast, but antiintuitive, no P.I., even worse, last query isn't deleted from screen, see shot (2.), so it looks frozen while it isn't - it already works

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > > For what languages ?
> > Look for the "m_XXX" files in directory "config".
>
> Indeed many ... but nothing for me

Which do you miss?

> 2. rr's and hitech's ports contain a large bunch of files of
> unknown purpose, obsolete or inappropriate (install instructions for OS/2
> or Linuux)

Which exactly?

> 4. None of the ports includes info about who compiled it at what time and
> with what ... all do show the same, OTOH, see shot (1.), they do boast

You still didn't understand what a port is. And my "ftecvss.zip" has a README.DOS, where you can find the author and the tools I've used.

> with (C)'s from 1998 (newest) down to year 200 !!!

One "!" is enough, boy. And "200" is just a truncated "2000-2006 Others". Blame the FTE authors, that they didn't take care of 80 columns displays.

> 5. Loading file works, is fast, and has a P.I.

This is no quiz show here: P.I. = progress indicator

> 6. S&R works, is fast, but antiintuitive, no P.I., even worse, last query
> isn't deleted from screen, see shot (2.), so it looks frozen while it
> isn't - it already works

Please report this to the FTE authors, if you care.

---
Forum admin

> DPMI host included is good, a working DPMI host included would
> be even better

I agree ... to some extend. This new stub is slightly buggy, I have to confirm a tiny problem with real-mode callbacks, which might result in a crash occasionally, but OTOH this version is new, modern, advanced, state of the art, ...

edit: I replaced the loadpex stub of the binary, to make the mouse happy...

---
MS-DOS forever!

> > > For what languages ?
> > Look for the "m_XXX" files in directory "config".
>
> Indeed many ... but nothing for me

It supports assembly highlighting, which you know / grok. No FreeBASIC "out of the box", but I can't imagine that's a shocker.

> edit: I replaced the loadpex stub of the binary, to make the mouse
> happy...

IMO, this (w/ makefile) would be a nice addition to the main .ZIP of rr's build. At least it would have a full install (and srcs) easily available. Just my $0.02.

> 2. rr's and hitech's ports contain a large bunch of files of
> unknown purpose, obsolete or inappropriate (install instructions for OS/2
> or Linuux)

Still awaiting your explanation.

---
Forum admin

> Still awaiting your explanation.

OK, since it's important, I'm going to sink into details:

- Directory "Debian"
- File "install"
- 3 history files (wouldn't one be better ?)
- File "BUGS" (nor related to DOS at all)
- README + README.1ST (50 (!!!) bytes)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> - Directory "Debian"

No "debian" in "ftecvsb.zip". But it's in "ftecvss.zip".

> - File "install"

No "install" in "ftecvsb.zip". But it's in "ftecvss.zip".

I'm so sorry for you, that I always distribute complete sources for a project.

> - 3 history files (wouldn't one be better ?)

I'm really tired telling you all the time, that you don't know, what "porting" or "building" means.

> - File "BUGS" (nor related to DOS at all)

It contains a useful link to the FTE bug tracker.

> - README + README.1ST (50 (!!!) bytes)

README = original README
README.1ST = created by me for the DOS release

Sorry, but there's no "meat" in your "issues".

---
Forum admin

> > This can't be right (unless you tested only old GNU Emacs, like 19.24 or
> > whatever). Besides, some (smart) editors don't load the whole file into
> > memory anyways since you can't edit all that at once anyways (unless
> you
> > reformat block / region or insert something in the middle). The only
> > popular editors I can think of to surely fail this are FD Edit and
> > FreeMacs (64k limit FTW !!).
> >
> > Try GNU Emacs 20.5, VIM 7.2, VILE 9.7 at least (because they are
> popular
> > and almost definitely well tested). If any of them fail, report a bug.
>
> We were talking about editors not resp. an OS and a SM tools for the
> kinky.

"vi is hard on the brain, but Emacs is hard on the hands." (Of course, you can always rebind Emacs to something else. Besides, what other editor can play gomoku? )

You can (like I did) compile GNU Emacs 22.3 from srcs for DJGPP. Since 22.1, the buffer limit is 256 MB now (although modern Windows, esp. Vista, greatly hinder it by reporting bogus DPMI memory amount values). However, I've been told by a certain Emacs Lover Infinitum that 23.0.60 (in CVS) is the only active branch, so maybe waiting for that is best (unless you need UTF-8 support, like, now, which 20.5 doesn't have. 23.x will have internal UTF-8 and is already considered plenty stable by some.)

The only tiny bug (bogus warning, really) is in startup and is fixed below (in case anybody cares to compile it themselves: 39 MB .tar.gz srcs, unpacks to 150 MB on NTFS or worse on FAT, just do "config.bat msdos" then "make install"):

2008-11-08  Eli Zaretskii  <eliz _AT_ gnu !DOTDOT! org>

       * startup.el (command-line): Ignore init-file-user when checking
       user's home directory on MS-DOS as well.

Index: lisp/startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.520
diff -u -r1.520 startup.el
--- lisp/startup.el     4 Nov 2008 16:54:25 -0000       1.520
+++ lisp/startup.el     8 Nov 2008 13:13:33 -0000
@@ -977,13 +977,15 @@
                                  init-file-user)
                          :error)
       (if (file-directory-p (expand-file-name
-                              ;; We don't support ~USER on MS-Windows except
-                              ;; for the current user, and always load .emacs
-                              ;; from the current user's home directory (see
-                              ;; below).  So always check "~", even if invoked
-                              ;; with "-u USER", or if $USER or $LOGNAME are
-                              ;; set to something different.
-                              (if (eq system-type 'windows-nt)
+                              ;; We don't support ~USER on MS-Windows
+                              ;; and MS-DOS except for the current
+                              ;; user, and always load .emacs from
+                              ;; the current user's home directory
+                              ;; (see below).  So always check "~",
+                              ;; even if invoked with "-u USER", or
+                              ;; if $USER or $LOGNAME are set to
+                              ;; something different.
+                              (if (memq system-type '(windows-nt ms-dos))
                                  "~"
                                (concat "~" init-file-user))))
           nil

GNU Emacs 22.3 "stable" was released on September 5, 2008.

http://www.gnu.org/software/emacs/

---
Know your limits.h

> README = original README
> README.1ST = created by me for the DOS release

What about renaming README.1ST to something that shows it's for the DOS release?

---
l

> GNU Emacs 22.3 "stable" was released on September 5, 2008.
>
> http://www.gnu.org/software/emacs/

Another problem is (maybe) fixed below:

P.S. Vista seems to have problems with REL_ALLOC (unlike XP), so you can try defining SYSTEM_MALLOC instead (in CONFIG.H) to work better, but my experience has been that it seems to consistently crash upon compiling somewhere (no matter what I try). Even the few random times it seemed to work, I'm not sure it truly dumped itself correctly.

> > > ... the DPMI call used by Emacs to find out how much free
> > > memory is there lies on Windows XP. I fixed this in Emacs 23, I
> > > think.
> >
> > I know of no good solution for something like that. What did your
> > fix entail?
>
> I replaced this implementation of get_lim_data in vm-limit.c:

#ifdef MSDOS
 void
 get_lim_data ()
 {
   _go32_dpmi_meminfo info;

   _go32_dpmi_get_free_memory_information (&info);
   lim_data = info.available_memory;
 }
 #else /* not MSDOS */

> with this:

#ifdef MSDOS
 void
 get_lim_data ()
 {
   _go32_dpmi_meminfo info;
   unsigned long lim1, lim2;

   _go32_dpmi_get_free_memory_information (&info);
   /* DPMI server of Windows NT and its descendants reports in
      info.available_memory a much lower amount that is really
      available, which causes bogus "past 95% of memory limit"
      warnings.  Try to overcome that via circumstantial evidence.  */
   lim1 = info.available_memory;
   lim2 = info.available_physical_pages;
   /* DPMI Spec: "Fields that are unavailable will hold -1."  */
   if ((long)lim1 == -1L)
     lim1 = 0;
   if ((long)lim2 == -1L)
     lim2 = 0;
   else
     lim2 *= 4096;
   /* Surely, the available memory is at least what we have physically
      available, right?  */
   if (lim1 >= lim2)
     lim_data = lim1;
   else
     lim_data = lim2;
   /* Don't believe they will give us more that 0.5 GB.   */
   if (lim_data > 512U * 1024U * 1024U)
     lim_data = 512U * 1024U * 1024U;
 }
 #else /* not MSDOS */

---
Know your limits.h

Rugxulo wrote:

> You can (like I did) compile GNU Emacs 22.3 from srcs for DJGPP

> anybody cares to compile it themselves: 39 MB .tar.gz srcs,
> unpacks to 150 MB on NTFS or worse on FAT

Good to know the difference between the good and the evil in advance !

> just do "config.bat msdos" then "make install")

I see

rr wrote:

> really tired telling you all the time, that you don't know, what
> "porting" or "building" means.

Right.

> there's no "meat" in your "issues"

This is surprising, considering I'm a vegetarian.

Anyway, other editors have a slightly higher priority for me

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Rugxulo wrote:
>
> > You can (like I did) compile GNU Emacs 22.3 from srcs for DJGPP
>
> > anybody cares to compile it themselves: 39 MB .tar.gz srcs,
> > unpacks to 150 MB on NTFS or worse on FAT
>
> Good to know the difference between the good and the evil in advance !
>

Most of that is necessary Elisp files and other (unneeded for DOS) fluff since it's the source package. You could make a minimal package in a few MB. GNU Emacs is not meant to be truly small, though, just insanely powerful.

Eli Z. says on comp.os.msdos.djgpp that 23.0 is gearing up for release, so anybody wanting to try compiling from CVS is welcome. And he will make a binary package if enough interest is shown. I think it's worth the upgrade (unless you like old "non-UTF8" 20.5 or prefer something else, but it's really quite powerful and very very useful for some things).

> rr wrote:

> > there's no "meat" in your "issues"
>
> This is surprising, considering I'm a vegetarian.

Yes, but are you a vegetable? If it's true that we are what we eat...