peterferrie wrote:

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.

That would work for me 😀 I'll test the whole program on monday.

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

Nope, that's not the case:
a: 3f0 d: ff
a: 3f1 d: ff
a: 3f2 d: ff
a: 3f3 d: ff
a: 3f4 d: ff
a: 3f5 d: ff
a: 3f6 d: 50
a: 3f7 d: ff

(3f6 is part of the IDE controller)

Direct port access might have been the case in the Windows 9x VDM but on NT with all its security it's not done. The floppy drivers don't have a 'back off, now NTVDM is messing with the ports' function.

outb 3f5,4 (sense drive status)
outb 3f5,x (drive letter - 0x41, so 0 for A, 1 for B, etc)
[delay]
inb 3f5
returns zero (no write-protect) on my Vista32 system.
Other versions of Windows might behave differently, but I haven't tested them.

I don't have a real floppy to test, only USB which always returns 0xff in real DOS.
Anyway, that's essentially the code that the program is using, too.

but on NT with all its security it's not done. The floppy drivers don't have a 'back off, now NTVDM is messing with the ports' function.

Dunno, some time ago i've tried own stuff that does floppy formatting through
ports access, that was pre-sp2 xp though. I didn't expect it to work, but it did
for whatever reason (there can't be an emulation layer for that imo because
it's quite nonstandard stuff).
Doesn't matter for this thing here though.

Maybe not relevant, but I remember (I think) some time in the dark past having used a thing called GIVEIO.SYS:

http://www.computing.net/answers/windows-nt/g … osys/13067.html

Sounds like it is/was used to circumvent some IO-restrictions.

mclatilla wrote:

peterferrie wrote:

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.

That would work for me 😀 I'll test the whole program on monday.

Thanks for everything! The patch works as expected 😀