Lightweight TSR DOS Text Editor; Your Favorite?

[clh333]

Which DOS program do you prefer to use to effect these types of modifications?

Anybody else with a preferred program for this procedure, please chime in.

DEBUG is handy, convenient and suitable for something so simple as this; even a noob like me can use it...

-CH-

 

[Stone]

Other than G=C800:5 and its ilk I know nothing about DEBUG.

Got any tips and pointers to share to get me going in the right direction?

 

[Malc]

..Anybody else with a preferred program for this procedure, please chime in.

A Hex editor, Windows or DOS, I use HxD in Windows and HIEW in DOS

 

[clh333]

Other than G=C800:5 and its ilk I know nothing about DEBUG.

Got any tips and pointers to share to get me going in the right direction?

DEBUG allows you to view, execute and change programs and runs under DOS; I believe it is included, for those who may not know, with many DOS versions up to 7. (I don't know about < 3.11)

Someone who goes by the sobriquet "Starman" (Daniel B. Sedory) has posted a useful tutorial: https://thestarman.pcministry.com/asm/debug/debug2.htm#D

DEBUG Path\UFN.XTN loads a file** into memory and presents you with a "-" prompt. From there you can (D)ump code for viewing, G(o) - execute, either to a breakpoint or to completion, (E)nter - change one byte instruction or (A)ssemble many instructions, (U)nassemble lines of code, view the contents of the (R)egisters as of the current line of code or (W)rite all or a portion of memory to disk. Writing to disk is not recommended unless you first specify a name for the block you are writing with the (N)ame command; given a path and name and DEBUG will place the file in the appropriate place in the file system. If you Write without thinking who knows what will happen to your disk.

Since SIMON is a COM program and COM programs are by definition <= one Code Segment (64k) there is only one CS value in the register to deal with. DEBUG only knows abut hexadecimal values, so there is no need to differentiate values, except of course for strings: -e 7791 90 changes the first byte of the two-byte instruction b44ccd21 mentioned in his listing (jae loc-779A). Note there is no leading zero or trailing H on hex value 90, which is substituting a NO OP for the jump. Another 90 at the next location, 7792, and the change is complete. Use the N command to specify a path and name for the new file and W, write it to disk. Q is for "quit".

-CH-

**File does not have to be a COM or EXE: You can submit a text file containing valid machine instructions as a source, which you can then save as a COM file. Or the file doesn't have to be code at all; DEBUG will list (as hex) or disassemble (to mnemonics) any source, up to its limits. See Van Wolverton's Supercharging MS-DOS for examples.

 

[clh333]

A Hex editor, Windows or DOS, I use HxD in Windows and HIEW in DOS

There is a "better" DEBUG which is part of the FREE DOS project as well. Don't know HIEW. Initially I considered MASM and TurboDebugger but it was like swatting flies with a Howitzer.

HxD or Hex Editor NEO are favored for Windows.

By the way, thanks for all your help and Merry Christmas!

-CH-

 

[Stone]

Charlie, thanks for your detailed help and guidance. I know it's right on because I actually figured it out about 30 minutes before you posted your dissertation. Gee, and it only took me ~ 18 hours -- minus a few hours while I slept. But, thanks, again as it is really helpful and I'll definitely look at the FREE DOS version as well.

Merry Christmas

 

[clh333]

... you posted your dissertation.

Yah, my wife's eyes kinda glaze over when I try to explain something to her...

-CH-

And Merry Christmas to you as well.

 

[clh333]

... (E)nter - change one byte instruction or ...
... changes the first byte of the two-byte instruction...

The proper term, of course, is "word", not "byte". Somebody, who should know better, must have been thinking about something else to make a mistake like that. Mea culpa.

-CH-

 

[Malc]

There is a "better" DEBUG which is part of the FREE DOS project as well. Don't know HIEW. Initially I considered MASM and TurboDebugger but it was like swatting flies with a Howitzer.

HxD or Hex Editor NEO are favored for Windows.

By the way, thanks for all your help and Merry Christmas!

-CH-

My DEBUG mojo is virtually non existent, Shouldn't be considering the years i've been playing with old computers, I started messing around with the likes of HIEW, OllyDbg, HxD, IDA Pro etc or i try and throw something together in C but my skills in C are not up to much either.
Merry Christmas to you

 

[kgober]

On the PC, the tools I generally used for this kind of thing in the DOS days were Turbo Debugger to identify what to patch (and to test patches), and Norton Disk Editor to actually apply (i.e. save) the patch once it was finalized. This of course required a 386, but it was a lot easier to work with than Debug. In particular this method worked well for patching large .EXE files, while I only felt comfortable using Debug for .COM files. I did not do this very often so I had no need to invest in more sophisticated tools.

Many years later I invested in a copy of IDA Pro during a period where I was doing a lot of reverse-engineering of C++ code, but that was mostly for identifying function entry points rather than actually patching anything. I think I only ever used IDA Pro for static analysis of EXE files on disk (unlike the dynamic analysis of running programs I did with Turbo Debugger).

 

[luiz]

Using the built-in editor in a DOS D-Base clone was almost enough to make me give up programming. Every time I touched the source file it would leave an "artifact" that would be invisible on the screen but would drive the compiler nuts.

I finally decided to install a TSR editor so I could jump out of the IDE, modify the source and jump back in to test the code. I was never a big fan of TSRs so the only thing I had available for install was PC Tools Desktop. I limped though with that but I figured there must be a better way.

Some Internet research turned up references to Qedit and Ntaker (for a more thorough compilation go to http://www.oldskool.org/guides/texteditors - be sure to return) but none of these were suitable.

So, if we can avoid WWIII I would like to ask the experts for their nominations: What's your favorite DOS TSR PLAINTEXT EDITOR?

Thanks,

-CH-

Hi everyone,


I've been a Simon user since the DOS days and recently downloaded the demo version shared here in this thread. After running it in DOSBox and reliving the experience, I decided to build a modern reimplementation from scratch in Go for Linux and Windows.


The project is called Simon2026. Same philosophy: lightweight, keyboard-driven, no bloat. Features include WordStar-style key bindings, easy one-key macro recording (just like the original), and a resident mode that pops up with a hotkey over any application, just like the original TSR.


Before moving forward, I'd like to ask: does anyone here think this is a good idea? And more importantly, does anyone have any objections? I want to make sure no one has concerns about this kind of project, especially regarding the original Simon. To be clear, this would be 100% new code, not a copy or decompilation of the original — just inspired by its design and philosophy.


If anyone has memories of using Simon, documentation, or the original manual, I'd love to hear from you. Once it's ready I plan to publish it on GitHub as open source.


Cheers.