I tried it, and I get the same error message. I tried to mount the C-drive with a large -freesize 2000 but that didn't make any difference. Don't know what could be wrong here.

Thanks for trying it 😀

it doesn't seem to use dos calls to determine the write protection.

It uses portlevel disk access. Will not be supported by dosbox.

Besides that, it should again be noted that dosbox is supposed to be used
with games only, every other usage may have arbitrary results and we
won't take ANY responsibility (train crashes? hm).

Why does it work in NTVDM though?

it might just use some values to detect the write protection or so.
Or some different branch is taken in dosbox.

Similar application worked fine according to the OP.

Why does it work in NTVDM though?

The ports stuff? Wouldn't know why there'd be a problem with it.

NT will certainly not let a DOS application touch the real hardware ports.

afaik that's wrong, like floppy ports are fully accessible, part of the vga registers.
Guess the same for the ide stuff.
Of course they're virtualized so the vdm can modify/disallow combinations.

If that was true a virus running in NTVDM could kill the system. They may be emulated to some extent but are not forwarded to real hardware.

Anyway, I've given the program the register read value it wants (IDE register write-read test): it will go further but later complain about write protection again, this time without accessing IDE ports.

They may be emulated to some extent but are not forwarded to real hardware.

That's up to the vdm, iirc the floppy stuff was forwarded in most parts.

Hacking out the port checks makes the app work.

The ports are not forwarded directly to hardware under Windows.
Windows decides which ones it will service on its own, and which it will queue for eventual passing to the hardware (because it can't pass it immediately in case another request is already active).
I'll have a look at this. It sounds like a fun puzzle.

Windows decides which ones it will service on its own, and which it will queue for eventual passing to the hardware

"queuing+passed to hardware" isn't THAT far from "virtualitzed+forwardedifneeded".

It sounds like a fun puzzle.

As noted above it's already solved, but feel free to have additional fun.

My computer has no floppy but still the program works in NTVDM.

> Hacking out the port checks makes the app work.

Even after pressing Y ?

wd wrote:

Besides that, it should again be noted that dosbox is supposed to be used with games only, every other usage may have arbitrary results and we won't take ANY responsibility (train crashes? hm).

Don't worry about that! 😀

I attach the similar program that works. I guess this one it uses regular DOS calls instead, doesn't it?

There's a check for write-protection, whose result is checked in two different places in the code. The code that sets the state can be patched (just one byte), which makes the program run for a while. Then I see "unexpected error" (perhaps because it can't communicate with anything).
Use a hex editor to change the byte at offset 0xb82d from 03 to 00.

but what does it check ? (as it works on hals pc without a floppy drive)

Even after pressing Y ?

Yes. If it's the same that i remember.

as it works on hals pc without a floppy drive

Suppose real hw, even if no drive is attached, return 0 instead of 0xff.