Mmmnice Editor, test it for me please :-)

I was messing with DOSBox as usual and at some point i thought to try the DOS version of the OpenWatcom compiler i have installed (i did a new installation in DOSBox... which seems to be the same as the windows installation i have in Windows). OpenWatcom seems to support a lot of systems (although most of them aren't mainstream anymore) and DOS is one (or actually, two - 16bit and 32bit, with the latter to support a bunch of DOS extenders) of them. So i was just playing around with the 16bit compiler using the OpenWatcom VI, which is a nice VI clone. However OWVI is still a VI and i don't like its modal nature, so i decided to write an editor for DOS using OpenWatcom (which, btw, i think is the only "complete" toolset that is still in active development and supports DOS - and a bunch of other stuff, like Win16 and OS/2). Besides i always wanted to write a text editor.

And i wrote a bunch of them at the past. But that was in the past, long forgotten, stored on old dusty 5.25" floppies (which, btw, are just behind me), etc. Also they were written when i was still learning how to program, thus they sucked .

So, since i decided to write a DOS text editor, i thought to make it usable even on older PCs. With older i mean, the original PC and XT and clones like those i used when i was 7 and making ASCII animations pretending to be games .

However there is a small problem with that: when i moved from my parents' house, they considered a good idea to throw all my older computers, including a pair of HYUNDAI PC XTs (awesome machines, not that i knew anything else) and some gray, probably Tulip, thing i don't remember much about. So i don't have any real hardware to test it and in my current house all i have is three laptops, the oldest of which is a Pentium 1 (the next best computer is a dualcore i'm writing this post from).

So i made the editor in DOSBox with the cycles turned all down to about 400 and assumed that thats a good speed because other editors also crawled at that speed .

So here is where you come in. I would like you to test this editor in real hardware and tell me if it works nice, especially the scrolling part which i'm sure DOSBox doesn't slowdown properly . Basically what i want to know is if the editor has a usable speed or i should get down and dirty with assembly (i don't mind assembly, although it has been a few years since i touched it, but i don't know how to write it in OpenWatcom and i remember from older listings i saw back when Watcom was the dominant compiler that its inline assembler syntax was ugly and based on #pragmas).

Here is a screenshot of the editor running inside the PicoXT emulator, which is the closest i could find to the real hardware (not that i searched past the first two pages of Google's search for a xt emulator). Which seems to be a bit buggy, especially given that it misses the blinking cursor and messes up a bit the scrolling. Unless the original CGA didn't had a blinking cursor (i don't know, i had some ATI card in one of my XTs and a -huge- hercules card in the other and the gray one... i have no idea what was inside).



And here is the test download:
http://www.badsectoracula.com/peponi/medtest1.zip

Just run MED.EXE. It will load MED.TXT. Move around and maybe type some text. Horizontal scrolling doesn't work yet. Also if you press ENTER for a new line, it redraws the whole screen currently (later it'll just scroll).

Use F10 to exit. By doing this, it saves the MED.TXT file and exits the program.

I'm liking it. I'm at work ATM so can't test, but two things:

- Thanks for the lead on PicoXT - I'm sure that'll be useful to me at some point.
- How big is the editor's binary file, and is it in .com or .exe format? I might use this on some boot disks when it's developed a bit further to replace edit.com, which is.. erm... huge, due to dependency on qbasic.

I uploaded an updated version with a couple of bugfixes. Either CGA *does* have an issue with the cursor, or both DOSBox's CGA mode and PicoXT's CGA emulation have a similar bug - both do not show a cursor. However DOSBox understands the Int 10h/01h interrupt service to set the shape of the cursor and i use this to make it visible inside the editor (but PicoXT doesn't).

@Raven:
Its an EXE file weighting ~11kb so far. However after i add a few needed features, like file open/save mode, search and a few editing stuff, i suppose it'll grow a bit.

Do me a favor and when you get all the bugs worked out, make sure to take a snapshot of the source and give me a compiled copy (and the source if you're making it open), because a ~11KB editor with the F10->Save&Quit is brilliantly simple. The less features the better, if I wanted more I'd use a word processor, IMO.

Works great in 32-bit Win7 command prompt, but I noticed it doesn't clear the screen when you quit - it just overlays the prompt on whatever was there. A cls command rectifies that, maybe you can make your program call it when it's done?

Edit: I noticed that it opened MED.TXT by default, and that's fine, but it doesn't have any method to open another file - add a command line parameter so it can override what txt file it looks for. On the bright side it does create med.txt when you try to open med with no txt file present and you save.

Well, some much needed features must be added (you want the editor to understand tabs, don't you? . I doubt it'll stay at 11k but maybe i can keep it under 15k .

The F10=exit+save is a byproduct of F10 being the exit key (probably temporary because i want to avoid F-keys for the moment since at some point i might port it to Linux and the F-keys via SSH are a pain to use) and the current main code:

Well, i downloaded the file and wanted to give it a try.

Unfortunaltely, all i see after launching the program, is a black screen.
No help function, no hint what to do, just nothing. So how to use this editor?

Perhaps it would have been helpfull, if the acompanying textfile told us less
about "replenishing energy without sleeping" and more about the editor itself?

@wiwa64:
The final version will contain a help screen and a text file, but for now i just wanted something random to fill the screen in order to test the editing and scrolling .

The keys are the arrow keys and pageup/down for moving around. F10 exits.

Have you tried the .exe file in the updated version (the old version is ~14k, the new is ~11k)? The previous .exe used only B800h for writing to video memory, which means that if you have a hercules or MDA you wouldn't see anything. The new .exe checks the BIOS data area to see what card is available and uses B800 or B000 so both MDA/Hercules and CGA/EGA/etc are supported.

In what computer did you tested it? OS? How much memory?

Basically if you run the MED.EXE file with the MED.TXT at the same place, you should see MED.TXT's contents. MED uses the whole screen for editing and if it doesn't found MED.TXT it simply creates a new file and since the file's contents are empty, all you see its a blank black screen. Maybe that is the case?

Update: http://gimme.badsectoracula.com/med.zip

This should be usable now. It also includes the source code in C (zlib license). Use OpenWatcom to compile if you want to compile it. The included Makefile is supposed to be used with wmake.

A key reference (you can use F1 or Ctrl+J to see the keys in program):

Also horizontal scrolling etc has been added. You can open a file by typing

The file has grown to ~14K. I still want to add a few other stuff (like search, justification and optionally showing the line numbers at the left side like some more modern editors) but since Raven asked for it, i decided to release a 14K version .

Some bugs are still around, but i'll fix them later.

Thanks, I'll be putting this on my new T6600C and mucking around with it later.

I appreciate the tiny minimal version, since I know it's just for me.

Yeah, actually i wrote the get_args() function to use a DOS service to get the arguments especially for keeping it below 15K because just *using* the argc/argn in main() added a bunch of code that the OpenWatcom linker removed from the program's initialization code and increased the .EXE to 20K .

This shows how awesome the OpenWatcom linker is, keeping only what is used inside (to a degree larger than what i've seen in other compilers, like GCC for example . Also makes MED to understand files with spaces because it tries to open *whatever* is after it's name. So if you write "med foo bar" it'll try to open a file named "foo bar" (with space included).

Hi Kostas,

now, having some more information, i tryed the "new" version of MED, the one that is 14KB in size.

I essentially only tryed viewing files: an especially generated test-text with 99 numbered lines, to test the scrolling and the source file of MED itself (med.c). I didn't do any further testing: no test for reliability or completeness nor did i try to undertake any code review.

I tryed MED

• in a DOS-Window under Windows98, running on a 700MHz Petium
• under genuine MS-DOS 6.22, running on a 60MHz AT486 computer
• under DR-DOS 6.0, running on a 40MHz AT386 computer
• under genuine MS-DOS 6.22, running on a 25MHz AT386SX

In all theese environments it performed quite well (as far as my limited test effords could tell).

I even tried it as a sub-process under my RMENU server (see thread: "Remote control of DOS-Box"), running on a 66MHz AT486DX2, where it also performed quite well, unlike, e.g. EDIT.COM from Microsoft, which doesn't work at all in this environment.

However, when trying to use it on an old Commodore PC10-III (12MHZ 8088 processor) i was very surprized: It didn't work at all! The screen just remained black. I must admit, that i didn't explore the reasons for this failure any further, but did you consider the HERCULES monochrome graphics adaptor in your screen routines? It once was quite popular, back in those days.

Thanks for the tests .

Yes i have added Hercules support in the editor. I used a BIOS memory area to check for the "current" card type which seems to work on DOSBox, but i don't have a real hardware anymore to test it (if i find some space here i might try and find an original IBM PC or some 100% compatible clone at some point). I'll make a special binary that has forced Hercules support later so you can see if it runs there, in which case it means that my check for Hercules is flawed.

I'll also check an old book i have on the topic which i remember having a routine in Turbo Pascal that worked on the real hardware i tested it - what i use now is what i figured out by reading some docs on the internet.

Can you add one final tweak to my "minimal" branch? If you open med with a filename argument, and the file doesn't exist, instead of creating it, it says "CANNOT OPEN FILE!" and then lets you continue, allowing you to save it as whatever you want. This, functionally, is not a problem, but being used to edit, it would be preferable if it stored the filename you gave it as an argument when the file doesn't exist, and then use that name when hitting F10 to save.

I've switched to it as my only DOS editor, btw. My new T6600C has no other text editor outside of Windows. I just made an edit.bat with med %1 in it and now even if I forget not to type edit I'm set.

Edit:

I just thought of a nice "touch" that could be added. There's no feedback when you save a file, so perhaps it could print "FILE.EXT successfully saved." to the console after med quits, so you know that it saved. I suspect that this is a pretty easy thing to implement.

There also should be a key that quits *without* saving - perhaps F9 in the minimal version, since it's close to F10.

I'm seriously liking this editor. Might I recommend you keep both versions - the minimal one I requested as a simple "notepad-like" editor, and the other one as a more complex editor, ala "wordpad".

I don't keep two branches, i just made a release before the 15K mark i mentioned above. Also the program has a quick without saving keystroke, its Ctrl+J+Q

Now i uploaded a new version, 1.01, which goes beyond that mark. But only by 0.8K . I fixed a couple of bugs and made page scrolling faster. Also i added a couple of command-line options to force an adapter (use med /c to force CGA/EGA/VGA/etc or med /m to force MDA/Hercules). This should make clear if the reason for not working in wiwa64's computer is an incorrect mode detection (although from what i've seen in an assembly book i have here - the tp book used an internal tp function i had forgotten - what i'm doing seems correct).

Beyond the bugs and the command line options, 1.01 adds a new keystroke, Ctrl+Q+G, which can be used to go to a specified line. This helps a lot when your compilation fails and the code is large . I used MED for editing its own code to find some obvious bugs (and i found) and this helped me. Another feature i added (ok, that one existed in previous MED but i forgot to add it to the help screen) is the Ctrl+AF or Ctrl+Left/Right keystrokes which can be used to move to the previous/next word.

Also now if you try to open a file or create a new file or exit the program without saving and the current buffer is modified, the program asks for a confirmation. Another enhancement on that part is that if you try to open a file that doesn't exist, the "current filename" is set to the filename you used and you're informed that the editor cannot open the file but if you press the save keystroke, the fill will be created.

Lastly, i added a small notice that if the last operation made by the editor before existing was to save the file, to show a "File saved" message.

http://gimme.badsectoracula.com/med.zip <-- here is the new version

I now tryed the new version (1.01) on that old Commodore PC10-III. 12MHz (or was it only 9?) and an 8088 processor.

Result:

• Without switch: same behaviour as before.
• With /m switch: works fine and reasonably fast.

The cursor looks a bit strange however, even after using <CTRL/Q>-=. Perhaps this is due to the fact, that the graphics "card" of this computer is not a genuine HERCULES one, but something compatible and directly built-in. Never the less try to find out about the, possibly subtle, differences in defining the cursor shapes.

I didn't repeat the tests on the other mashines, so it's not a real "regression test".

What do you mean strange?

In DOSBox's hercules mode the cursor looks correctly, but i use it as a CGA cursor (with 8 scanlines). In Hercules though the cursor can have 14 or 16 (dont remember) scanlines, but i only use the scanlines from 6 to 7 (as in CGA). Some cards "translate" these to something else - some cards (like possibly VGA and DOSBox's Hercules emulation) use the lower scanlines (which effectively make bottom-aligned cursor shapes to be similar to those specified), some cards stretch the scanlines to fit in the character cells and some simply use them directly. The last part is what original Hercules does, which would make my code to have the cursor at about the center of the cell instead of bottom.

Bad Sector said:

What do you mean strange?

. . . which would make my code to have the cursor at about the center of the cell instead of bottom.

Click to expand...

That seems to be what it actually does.

To me this appeared "strange", as usually cursors
either appear as (blinking or steady) underline
or as (blinking or steady) box, covering the whole cell.

A cursor which strikes through the caracter
isn't really a problem, but it's unusual and confusing.

I can test this on my Tandy w/ monochrome monitor, but it'll be a few days before I get around to it.

I made a new version (1.02) which addresses the "strange cursor problem" by not touching it in monochrome screens . Also it has a few enhancements:

1. Searching (Ctrl+Q+F) and repeat-last-search (Ctrl+L) keystrokes
2. Automatic indentation (which can be toggled with Ctrl+Q+I)
3. A command-line option to jump to a specified line (/l<number>, for example med /l100 med.c opens med.c and jumps to its 100th line).
4. Memory allocation failure tests everywhere memory is allocated to avoid program crashes in case the program runs out of memory (like when editing a very large file)

These increased the file to about 22K (sorry Raven ) and i think the editor is "good enough" to warrant its own page at my site. So from now on you can get it from here:

http://www.badsectoracula.com/projects/med/

22K is still small (but 14K was damned tiny and impressive!), it's when it starts to pass 30-40K that it will be too big for most uses, and the small version is still there for those.

I have found a glitch (note that I am using the version you let out for me earlier still). If you use the DEL key to delete characters, and just hold it down to delete entire lines, when you run out of on-screen lines, the new text that was off-screen doesn't appear, even if you use the down arrow to scroll to it.

Since that sounds confusing, I will illustrate:
Imagine you have this file:

This is a file
fluff
fluff
delete me
fluff fluff
this is a file

Click to expand...

Pretend that that fills the screen vertically, with the lines starting with "fluff fluff" being off of the screen at the bottom.

If I go to the front of the line that says "delete me", and start holding down DEL, it will delete the characters on the line, and then continue if there were any more below it ON screen. When it gets to the lines that are offscreen, however, blank space just scrolls up instead of the lines.