DOS ain't dead

Before I begin writing it, let's ask me whether someone is interested in yet another assembly TSR frame. I thought about creating one from the program described below.

The RxANSI program I'm developing is now near completion (older beta versions 1-3 could've been available for months if Robert uploaded them) and includes some neat features regarding TSR installation and memory management. It is of course just an ordinary 16-bit Real Mode DOS TSR. It is compatible to the latest AMIS (as described in RBIL 61 only), thus supports interrupt sharing* which allows TSRs to uninstall interrupt handlers when not installed as last TSR. It installs itself using a special method instead of Int27. This requires some MS-DOS compatibility regarding the process termination code and MCB layout of the used DOS. For better placement of the resident portion if there's no UMA the installer contains code to relocate the PSP; this however is executed only with user permission because it requires DOS to be really MS-DOS compatible.

Both RxANSI's and a possible TSR frame's source will be provided by me in NASM style assembly of course. Note that I rely heavily on NASM's preprocessor, don't expect the source to work immediately with old NASM versions or YASM. Someone else could probably port it to JWASM/MASM or FASM if required.


* While interrupt sharing is useful not much software hooking interrupts utilizes it. When no non-compliant TSRs/drivers are installed on an interrupt, it allows any software to trace the chain of interrupt hooks back to the first non-compliant interrupt handler. (The first interrupt handler is of course always non-compliant, because there is no previous one.) Uninstalling of TSRs is then easier and, if required for whatever, software could even do things like re-ordering handlers.

---
l

> Before I begin writing it, let's ask me whether someone is interested in
> yet another assembly TSR frame.

It can't hurt. But honestly I'm not going to write a TSR anytime soon. Nevertheless, if it works with FreeDOS, I'm sure they'd love to consider it.

> The RxANSI program I'm developing is now near completion (older beta
> versions 1-3 could've been available for months if Robert uploaded them)

Sorry! You should have put more pressure on me.

---
Forum admin

> But honestly I'm not going to write a TSR anytime soon.

I am going to write a bunch of cool TSR's ASAP and release them (not all at same time, one after other ...).

> Nevertheless, if it works with FreeDOS, I'm sure they'd love to consider it.

Mine also ?

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

> I am going to write a bunch of cool TSR's ASAP and release them (not all
> at same time, one after other ...).

Please write Jemm Loadable Module!

> > I am going to write a bunch of cool TSR's ASAP and release them (not all
> > at same time, one after other ...).
>
> Please write Jemm Loadable Module!

TSRs are more compatible, not all DOS users are JEMM386 users. And the interest for JLMs from the part of the few developers left is minimal. Do you know why?

---
Glory to God for all things

> > > I am going to write a bunch of cool TSR's ASAP and release them (not
> all
> > > at same time, one after other ...).
> >
> > Please write Jemm Loadable Module!

Please do it yourself first and show us. Thanks.

> TSRs are more compatible, not all DOS users are JEMM386 users.

True.

> And the
> interest for JLMs from the part of the few developers left is minimal. Do
> you know why?

Speaking for myself, I thought about developing JLMs but found it not to be as easy as writing normal TSRs. Some binaries created with NASM and WLINK weren't accepted by closed-source JLOAD (provided JLM examples have JWASM and FASM source), and some of the API isn't documented. While it might be useful to have some compatibility with Windows 9x VMM32 by providing similar functions, the hint that you need the Windows 98 DDK to develop JLMs troubles me. I would also like to know how JLOAD's DOS memory allocation works and how I can affect it, which is (just as all JLM-specific functions) not documented anywhere. While this information might be available from Japheth I think it's just not worth the effort asking for it when writing something that doesn't have to be a JLM.

So if someone really wants developers to write JLMs it would be useful to provide more technical information to them.

---
l