DOS ain't dead

Hi

My next cool TSR is out. It isn't unique by features but by size and memory hoggines , and it is still useful. All size/memory related bugs of my FIX7ZIP TSR pointed by Cm some time ago are fixed here in.

Download now

link



What it does:

* It permanently disables Abort Retry Fail (see shot) and workarounds the "Must-press-A-or-F-1'000'000-times-BUG" of FreeDOS

What it doesn't:

* It fails to prevent FreeDOS from accessing the floppy 1'000'000 times before it believes that there is really no disk in the drive. I'm going to "fix" this later. And finally really fix this by a better DOS kernel + command thing in far future.

* It doesn't prevent the intrusive "Remove diskette from A: Insert diskette into B:" messages ... I have no idea where they come form, but since I am getting them with both FreeDOS and EDR-DOS, this can't be a FreeDOS BUG
Hints how to kill them also are welcome

PS: UI21DEB isn't dead

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

Well. I rather suggest you to patch FreeDOS kernel. Contact Eric Auer before it.

---
DOS-u-akbar!

> My next cool TSR is out. It isn't unique by features but by size and
> memory hoggines , and it is still useful. All size/memory related
> bugs of my FIX7ZIP TSR pointed by Cm some time ago are fixed
> here in.

Well there are still some things I'd do another way:

- Stop using god damned hardcoded values for the size of all data and code parts of your program. This makes everything impossible to maintain and you can't write any large program.

- Stop hooking interrupts by modifying the IVT.

- Comment your files better. F.e. I had to study the complete TSR (and evaluate some hardcoded values) before I understood what the second handler in the resident part is for.

- Free the environment if you don't need it anymore. Especially with such a small resident part, this often enables programs with simple memory allocation schemes to move that part to an optimal position, avoiding any (further) memory fragmentation.

- Write the allocated memory block's segment into its MCB. This enables MEM to show the name of the resident part.

- Please use the IBM Interrupt Sharing Protocol (IISP) when hooking permanent interrupt vectors (i.e. anything except Int22, Int23, Int24).

> * It permanently disables Abort Retry Fail (see shot) and
> workarounds the "Must-press-A-or-F-1'000'000-times-BUG" of FreeDOS

It does this by re-storing it's own Int24 handler on any Int21 call by modifying the IVT directly. Because you can't call Int21.25 in MS-DOS safely, this is a legitimate direct IVT modification.

However, other programs might want to hook Int24 for one or another reason, and their hook will be disabled by the next Int21 call after Int21.2524. Although the Int24 handler is not permanent (i.e. restored by PSP termination) programs might try to unhook their Int24 handler, and if they do so carefully, they'll fail because ARFKILL's (or ARFSUCKS's) handler has overwritten the IVT reference to their handler.

The short version: This is bad hack which might work most of the time but could cause quirky behaviour of some programs.

There's also the point that Int25, Int26 and I think some Int2F calls (NLSFUNC file open/lseek/read/close?) might cause Int24 errors. If one of these is called by any program after Int21.4B but before any other Int21 call, and if it does cause a critical error, then the previously restored Int24 handler is used, not the ARFSUCKS handler. This is a really improbable situation and I'm not even certain it would work this way, but it could do.

> * It doesn't prevent the intrusive "Remove diskette from A: Insert
> diskette into B:" messages ... I have no idea where they come form, but
> since I am getting them with both FreeDOS and EDR-DOS, this can't be a
> FreeDOS BUG
> Hints how to kill them also are welcome

This is the message popping up if you access a phantom floppy drive B: (i.e. actually the same Int13 drive as A:, but other DPB and device unit). Read in RBIL about Int2F.4A00, which is queried by the block device's code before showing this prompt.

---
l

Some new DOS TSR and driver development is much appreciated.

Not really worth for this small one, but perhaps for your next project try showing some support for Japheth's work and and provide a Jemm Loadable Module build.

> My next cool TSR is out.

Still waiting for the first cool one.

> * It doesn't prevent the intrusive "Remove diskette from A: Insert
> diskette into B:" messages ... I have no idea where they come form, but
> since I am getting them with both FreeDOS and EDR-DOS, this can't be a
> FreeDOS BUG

PEBCAK

---
Forum admin

> Not really worth for this small one, but perhaps for your next project try
> showing some support for Japheth's work and and provide a Jemm Loadable
> Module build.

Would you please provide the requested technical documentation (or ask Japheth for it) before demanding JLMs?

---
l

> > Not really worth for this small one, but perhaps for your next project
> try
> > showing some support for Japheth's work and and provide a Jemm Loadable
> > Module build.
>
> Would you please provide the requested technical documentation (or ask
> Japheth for it) before demanding JLMs?

In this board where Japheth is reading there are only offtopic discussions about JLM's. It can not be expected that Japheth is following every postings.

Therefore if you are interested in JLMs and need documentation please make a new topic with all your suggestions / bug reports / questions / requests / comments / ect. Japheth seams to be communicative person and I think there is at least a chance.

> Therefore if you are interested in JLMs and need documentation please [...]

Well who of us is requesting JLMs instead of TSRs from other people? It's not like I can't do that. But as mentioned in other discussions, too, I didn't yet came across something that required Protected Mode or a JLM. So I'm not really interested. I however want to get rid of repeated requests for JLMs from some people in any program discussion.

---
l

> > Therefore if you are interested in JLMs and need documentation please
> [...]
>
> Well who of us is requesting JLMs instead of TSRs from other people? It's
> not like I can't do that. But as mentioned in other discussions, too, I
> didn't yet came across something that required Protected Mode or a JLM. So
> I'm not really interested. I however want to get rid of repeated requests
> for JLMs from some people in any program discussion.

Your last answer was about lack of documentation. And now such an answer? Your fancy changed?

> In this board where Japheth is reading there are only offtopic discussions
> about JLM's. It can not be expected that Japheth is following every
> postings.
>
> Therefore if you are interested in JLMs and need documentation please make
> a new topic with all your suggestions / bug reports / questions / requests
> / comments / ect. Japheth seams to be communicative person and I think
> there is at least a chance.

It seems you are the one who asked for JLMs. If you want the brilliant DOS386 to contribute by writing JLMs, you should have asked Japheth to provide the needed documentation. At least you should do it as long as DOS386 doesn't do it himself and you still need JLMs.

---
Glory to God for all things

> Your last answer was about lack of documentation. And now such an answer?
> Your fancy changed?

Sorry if it sounds strange, but I requested that documentation from you if you want TSR developers (which I'm one, too) to write JLMs instead. It's not like we're all hating Japheth or disliking his programs. Quoting you however makes it seem to me you think this:

> try showing some support for Japheth's work

As Khusraw put it, you're apparently the one who asked for JLMs.

---
l

Personally I don't use JEMM386, but I think there are situations where JLMs could be useful and have their advantage over TSRs. For example I expect Japheth in his infinite wisdom to write a JLM providing Sound Blaster emulation for AC97 and/or Intel HDA. These very poor, "on-board", sound cards are commonly used now, as there are places in the world where you couldn't find a mainboard without having them integrated.

---
Glory to God for all things

AFAIU your TSR installs a simple int 24h handler on every int 21h call. The handler always returns al=3.

My suggestion is to modify FDCONFIG.SYS:

shell=C:\FDOS\BIN\COMMAND.COM /P /E:512

by:

shell=C:\FDOS\BIN\COMMAND.COM /F /P /E:512

The "undocumented" switch /F is described in RBIL. It works for FD command.com, but also for 4DOS. It prevents the command interpreter from installing its error handler (which displays the "Abort, Retry ..." string).

So this version needs 0/0/0/0 Bytes. Try to beat that!

---
MS-DOS forever!

> So this version needs 0/0/0/0 Bytes. Try to beat that!

If the command interpreter was written to free some memory occupied by the normal Int24 handler if /F is used, you could even gain some memory. (Beside the Int24 handler code itself the Int24 error message table and messages wouldn't be required resident.)

---
l

> The "undocumented" switch /F is described in RBIL. It works for FD
> command.com, but also for 4DOS. It prevents the command interpreter from
> installing its error handler (which displays the "Abort, Retry ..."
> string).

Correct me if I'm wrong, but I assume this is most useful when doing "CTTY COM1" via local network or whatever.

> Personally I don't use JEMM386, but I think there are situations where JLMs
> could be useful and have their advantage over TSRs. For example I expect
> Japheth in his infinite wisdom to write a JLM providing Sound Blaster
> emulation for AC97 and/or Intel HDA. These very poor, "on-board", sound
> cards are commonly used now, as there are places in the world where you
> couldn't find a mainboard without having them integrated.

Yeah SB emulation on SB live! I would donate some beers to author for that :)

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

Japheth wrote:

> AFAIU your TSR installs a simple int 24h handler on every int 21h call. The
> handler always returns al=3.

YES.

> My suggestion is to modify FDCONFIG.SYS:
> shell=C:\FDOS\BIN\COMMAND.COM /P /E:512
> shell=C:\FDOS\BIN\COMMAND.COM /F /P /E:512

Got:

SHELL=C:\BLAH\FREECOM.COM /F /E:512 /P:FDAUTO.BAT
REM "/F" disables AbortRetryFail
REM "/P" makes it permanent (no chance to EXIT)
REM "/E:512" increases enviriioment size to 512 bytes
REM            for some buggy stuff, but it doesn't really help

And it works ... Thanks However it works in FreeDOS only, not in EDR-DOS, so you reduced the usefulness of my TSR by factor 2 only.

Khusraw wrote:

> the one who asked for JLMs. If you want the brilliant DOS386 to contribute by

Again

rr wrote:

> PEBCAK

I will

Cm wrote:

> Stop using god damned hardcoded values for the size of all data and code
> parts of your program. This makes everything impossible to maintain and
> you can't write any large program.

This one isn't ...

> Stop hooking interrupts by modifying the IVT.

If you supply a reason why ...

> Comment your files better. F.e. I had to study the complete TSR (and evaluate
> some hardcoded values) before I understood what the second handler in
> the resident part is for.

See UI21DEB

> Free the environment if you don't need it anymore.

Maye good idea.

> Write the allocated memory block's segment into its MCB.
> This enables MEM to show the name of the resident part.

Done ! But MEM fails completely and [J]DEBUG reveals 2 letters only

> use the IBM Interrupt Sharing Protocol (IISP) when hooking permanent
> interrupt vectors (i.e. anything except Int22, Int23, Int24).

Benefit ?

> if they do so carefully, they'll fail because

you always find a risk

> The short version: This is bad hack which might work most of the time but could cause quirky behaviour of some programs.

YES.

> There's also the point that Int25, Int26 and I think some Int2F calls
> (NLSFUNC file open/lseek/read/close?) might cause Int24 errors.

See 10 lines above.

> Read in RBIL about Int2F.4A00, which is queried by the block device's code

Thanks, I'll check it. (actually INT $2F is not very inviting to me ... guess why)

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

.

---
MS-DOS forever!

> Cm wrote:
>
> > Stop using god damned hardcoded values for the size of all data and code
> > parts of your program. This makes everything impossible to maintain and
> > you can't write any large program.
>
> This one isn't ...

Isn't what?

> > Stop hooking interrupts by modifying the IVT.
>
> If you supply a reason why ...

What's your reason not to? Some nanosecond "speed gain" by not using the Int21 service? Then DOS is rather not what you want to use, I think.

> > Comment your files better. F.e. I had to study the complete TSR (and
> evaluate
> > some hardcoded values) before I understood what the second handler in
> > the resident part is for.
>
> See UI21DEB

See what? See bad comments in UI21DEB, too?

> > Write the allocated memory block's segment into its MCB.
> > This enables MEM to show the name of the resident part.
>
> Done ! But MEM fails completely and [J]DEBUG reveals 2 letters only
>

Because the owner value is 0008h which is reserved for system blocks. And because MS-DOS system blocks only used the first 2 letters as actual name and didn't initialize the remaining 6 bytes, resulting in unterminated trash. Give your MCB an owner value of the associated memory block. (Same as MCB segment plus one.)

> > use the IBM Interrupt Sharing Protocol (IISP) when hooking permanent
> > interrupt vectors (i.e. anything except Int22, Int23, Int24).
>
> Benefit ?

Your TSR then wouldn't stop IISP-aware TSRs (that hooked Int21) when they want to uninstall their interrupt handlers. IISP is a great solution to the "can't uninstall because of other TSR" problem, and easily disabled by interrupt hookers that don't conform to it. [Sometimes it's possible to tweak around this by searching through information provided by the AMIS interface but then again it sometimes isn't.]

> > if they do so carefully, they'll fail because
>
> you always find a risk

Yes, look at my signature Thinking about everything a lot helps a lot with bugfixing, too.

> > There's also the point that Int25, Int26 and I think some Int2F calls
> > (NLSFUNC file open/lseek/read/close?) might cause Int24 errors.
>
> See 10 lines above.

I counted 10 lines in various ways and didn't get a useful answer. Please cite the line you referenced.

> > Read in RBIL about Int2F.4A00, which is queried by the block device's
> code
>
> Thanks, I'll check it. (actually INT $2F is not very inviting to me ...
> guess why)

I have no idea. Int2F contains some essential DOS internal services which should be used, if available, instead of guessing the layout of all DOS internal data. It also contains the well-designed (just not as well-implemented) redirector interface. And then much other services, most of which I never want to use. [Maybe because you're a real DOS user and think Int2F was only added in later MS-DOS versions so that it "isn't quite DOS" enough?]

---
l

> > > you can't write any large program
> > This one isn't ...
> Isn't what?

Large maybe ?

> What's your reason not to?

Risk.

> > > Comment your files better.
> > See UI21DEB
> See what? See bad comments in UI21DEB

I'm waiting for good comments in RxDOS source

> Because the owner value is 0008h which is reserved for system blocks. And
> because MS-DOS system blocks only used the first 2 letters as actual name

I see ...

> Give your MCB an owner value of the associated memory block

Then it would unhog of course.

> use the IBM Interrupt Sharing Protocol (IISP) when hooking

> want to uninstall their interrupt handlers. IISP is a great solution to
> the "can't uninstall because of other TSR" problem

Interesting, if such a thing existed at all: UTFG UTFI

> Maybe because you're a real DOS user and think Int2F was only added in
> later MS-DOS versions so that it "isn't quite DOS" enough?

Because RBIL has much bloat on INT $2F and most of the stuff is either unreproductable, useless, or evil (all the "GetWindaubeVersion", "WindaubeOldApp", ... stuff).

BTW, I fixed most of the BUG's in UI21DEB, now it can also uninstall, and also it will refuse to uninstall if it is not safe to do

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

> > What's your reason not to?
>
> Risk.

Of what? Is Int21.25 crashing your system?

> > > > Comment your files better.
> > > See UI21DEB
> > See what? See bad comments in UI21DEB
>
> I'm waiting for good comments in RxDOS source

Yeah, I can promise you that you'll have to wait some more. I recently worked a bit on the 7.20N sources (and finally separated my macro files for this and 7.30) and might push it for a release soon. However I consider this alone useless anyway, because it aims to re-create any bug of RxDOS 7.1.5/7.2 it's based on. So I might as well just release it along with usable 7.30 betas later on.

> > Give your MCB an owner value of the associated memory block
>
> Then it would unhog of course.

No it won't unless the memory block which is to be hold resident is the same one as your precious PSP (then close all file handles and use Int27 or 21.31 instead). DOS memory deallocation during termination works by freeing all MCBs that are owned by the terminating PSP. If you allocate a new memory block then hack its MCB so that it points at the memory block itself (instead of to your PSP) it won't be freed by the program termination.

> > use the IBM Interrupt Sharing Protocol (IISP) when hooking
>
> > want to uninstall their interrupt handlers. IISP is a great solution to
> > the "can't uninstall because of other TSR" problem
>
> Interesting, if such a thing existed at all:

I don't know what "UTFG UTFI" is, but just read the AMIS description at Int2D in RBIL 61. It also presents how the IBM Interrupt Sharing Protocol entry looks and sometimes uses the abbreviated form ISP, which I don't want to use to avoid confusion with the term "Internet Service Provider". (There's also an older INTSHARE.DOC [but plain text] or something similar named file floating through the internets which describes only the IISP.)

> > Maybe because you're a real DOS user and think Int2F was only added in
> > later MS-DOS versions so that it "isn't quite DOS" enough?
>
> Because RBIL has much bloat on INT $2F

And it doesn't have much "bloat" on Int21, or what?

> and most of the stuff is either
> unreproductable, useless, or evil (all the "GetWindaubeVersion",
> "WindaubeOldApp", ... stuff).

Interestingly RBIL never uses such crappy fake Win32 function names as you seem to like doing.

---
l

> Of what? Is Int21.25 crashing your system?

NO:

1. reentrancy problems
2. implementation bugs
3. deliberately bad implementations

> new memory block then hack its MCB so that it points at the memory block
> itself (instead of to your PSP) it won't be freed by the program termination.

OK.

> I don't know what "UTFG UTFI" is

Clicking the 2 links would have revealed the truth.

> but just read the AMIS description at Int2D in RBIL 61.

OK.

> It also presents how the IBM Interrupt Sharing Protocol

that IBM is not aware of

> entry looks and sometimes uses the abbreviated form ISP, which I don't
> want to use to avoid confusion with the term "Internet Service Provider".

again, try the 2 links

> And it doesn't have much "bloat" on Int21, or what?

It does ... at least some of the subfunctions are somewhat useful here

> uses such crappy fake Win32 function names as you seem to like

I care more about crappy-or-non-crappy and fake-or-non-fake implementations than crappy-or-non-crappy and fake-or-non-fake function names.

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

> > Of what? Is Int21.25 crashing your system?
>
> NO:
>
> 1. reentrancy problems

That's the reason I wrote this:

> > It does this by re-storing it's own Int24 handler on any Int21 call by
> > modifying the IVT directly. Because you can't call Int21.25 in MS-DOS
> > safely, this is a legitimate direct IVT modification.

I'm rather refering to your direct IVT modification when installing the TSR.

> 2. implementation bugs
> 3. deliberately bad implementations

Erm, what?

> > It also presents how the IBM Interrupt Sharing Protocol
>
> that IBM is not aware of

At least Microsoft apparently was, because the MS-DOS kernel uses IISP compatible entries when hooking hardware interrupts to provide the STACKS. (Documented in RBIL as well, and you can boot MS-DOS and look at the entries with DEBUG yourself.)

Use Google wisely!

INTSHARE.TXT (I was wrong on .DOC) which is provided inside INTSHARE.ZIP also states:

In the PS/2 BIOS Interface Technical Reference, IBM has suggested a
protocol for the sharing of system interrupts.  Although the protocol
was intended to allow sharing of hardware interrupts, it is equally
usable for software interrupts.

plus

Let me add as a caveat that I do not have and have not examined the
primary source for this information--the PS/2 BIOS reference.  Most of
the information in this paper was gleaned from other sources, augmented
by my own experiences in writing TSRs.  The most recent writeup as of
this date (August 6, 1991) was in the 7/91 issue of the Microsoft
Systems Journal.

> > uses such crappy fake Win32 function names as you seem to like
>
> I care more about crappy-or-non-crappy and fake-or-non-fake
> implementations than crappy-or-non-crappy and fake-or-non-fake function
> names.

Whatever.

---
l

Hi DOS386,

> My next cool TSR is out. It isn't unique by features but by size and
> memory hoggines , and it is still useful.

Reading your original post it seemed that you were setting down a bit of a challenge here with others re usable functional TSR vs size. Is this correct?