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