Hi Bret.

Thanks so much for that information, which underpins the entire
issue. I had indeed managed to stuff up the test.

After fixing that:

https://sourceforge.net/p/pdos/gitcode/ci/ede042ced72fd2482a4ea1c8f79a80dfe2b69561/

by changing:

mov word ptr [info], dx

to:

mov word ptr [bx], dx

The problem went away.

Very sorry to everyone for wasting your time if current Freedos
behavior for setinfo when given odd (0, 1, or 81h) is working as designed.

I did always mention "unless I stuffed up my test". I had in fact
already added CF detection so that I could have an int return
instead of void, and it was passing my test.

It was only when I found out that it is supposed to be returning
something other than 0 that I finally spotted what was wrong.

Took me a while to see it even then, as moving into "info" still
looked correct to me.

Thanks. Paul.



On Mon, 31 Jul 2023 at 15:13, Bret Johnson <bretj...@juno.com> wrote:

> > So (unless I stuffed the test up), it's not just me that says
> > that stdin isn't stdin - Freedos get device info returns 0.
> > So freedos reports that stdin is not stdin, and I took its
> > word for it in my test of set device info.
>
> I just tested FreeDOS 1.2 and 1.3 and a couple of other versions of MS-DOS
> and issuing a Get Device Info (INT 21.4400) for STDIN (BX=0) returns
> attributes of 80D3h in DX, not 0.
>
> I also know that if STDIN is redirected that attributes returned will be
> those of the device that STDIN is redirected to, but I don't know if you're
> doing anything like that.  In at least some of my programs I actually use
> INT 21.4400 on the STDOUT device to see if the output of my program has
> been redirected, and if so I know the output is not going to the screen
> (and is probably going to a file or to NUL or to PAUSE or something like
> that).
>
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to