Mail Archives: djgpp-workers/2005/04/24/11:19:12
According to Eli Zaretskii:
> Therefore, I think we have some kind of bug here, which should be
> investigated. The trick with a signal handler is just a means to ease
> that investigation.
I've done a simple test program to show that the bug is in the FreeDOS
kernel. This program written in djasm (I call it w.asm):
.org 0x100
mov ax, 0x6c00
mov bx, 0x0001 ; Write only.
xor cx, cx
mov dx, 0x0011
mov si, file_name
int 0x21
mov dx, open_failed_msg
jc error_exit
mov [ file_handle ], ax
write_more:
mov ah, 0x40
mov bx, [ file_handle ]
mov cx, file_data_size
mov dx, file_data
int 0x21
jc write_error
test ax, ax
jnz write_more
write_error:
mov ah, 0x3e
mov bx, [ file_handle ]
int 0x21
mov dx, end_msg
error_exit:
mov ah, 9
int 0x21
ret
file_data:
.db '0123456789'
.db 0 .dup 128
file_data_size = . - file_data
file_handle:
.dw 0
file_name:
.db 'x', 0
open_failed_msg:
.db 'Open failed.', 10, 13, '$'
end_msg:
.db 'File written.', 10, 13, '$'
doesn't stop writing either (on FAT32).
Things to note:
1. FreeDOS doesn't need any FAT32 extended size flag (right now at least).
2. The kernel doesn't see when the file has reached maximum size.
3. On a FAT16 with ~800MB free, it stopped correctly.
4. In MS-DOS 7.<something>, I can't C-c it.
(5. This sucker is even slower than my other test program. Hence I
conclude DJGPP caching is working. 5 hours wasn't enough to reach 4GB,
at that point it the file was ~2.9GB. I ran it again and after C-c
after 10 hours I had a 4GB file. You've been warned.)
Right,
MartinS
- Raw text -