Int21 bug

[Valentijn Sessink]

Hi folks,

I think I hunted down a bug in DOS int21 function 0x5b (my DOS book insists
this is 91 decimal). My older version of wine, 2000821, goes like this:

trace:int21:DOS3Call CREATE NEW FILE 0x00 for X:\TMP41.$$$
trace:file:CreateFileA X:\TMP41.$$$ GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE_NEW
trace:dosfs:DOSFS_GetFullName X:\TMP41.$$$ (last=0)
trace:string:lstrcpynA (0x40e35fa0, "/tmp", 1024)
trace:dosfs:DOSFS_FindUnixName /tmp,TMP41.$$$
trace:heap:HeapAlloc (403c0000,00000002,0000022c): returning 414c9cf4
trace:heap:HeapAlloc (65430000,04000000,00000018): returning 65432c30
warn:dosfs:DOSFS_FindUnixName 'TMP41.$$$' not found in '/tmp'
trace:heap:HeapFree (65430000,04000000,65432c30): returning TRUE
trace:heap:HeapFree (403c0000,00000002,414c9cf4): returning TRUE
trace:dosfs:DOSFS_GetFullName returning /tmp/TMP41.$$$ = X:\tmp41.$$$
080732c8: create_file( access=c0000000, inherit=0, sharing=00000003, create=1, attrs=00000000, filename="/tmp/TMP41.$$$" )
080732c8: create_file() = 0 { handle=136 }
trace:file:FILE_AllocDosHandle Got 10 for h32 136
trace:int21:DOS3Call returning: AX=000a BX=5b0c CX=0000 DX=e9a8 SI=0000 DI=e9a8 DS=0a27 ES=0907 EFL=00000202
trace:global:GlobalHandle16 0107
Ret  KERNEL.102: DOS3CALL() retval=none ret=0347:2513 ds=0a27
     AX=000a BX=5b0c CX=0000 DX=e9a8 SI=0000 DI=e9a8 ES=0907 EFL=00000202
trace:global:GlobalHandle16 0107

So: file handle 0x136 translates to DOS handle 10, and int21 returns AX=0x000a

My newer version, Wine 20030408, does the following:

000a:trace:int21:INT_Int21Handler CREATE NEW FILE 0x00 for X:\TMP18467.$$$
000a:trace:heap:RtlAllocateHeap (0x40370000,00000002,00000020): returning 415b32c0
000a:trace:file:CreateFileW L"X:\TMP18467.$$$" GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE CREATE_NEW attributes 0x0
000a:trace:dosfs:DOSFS_GetFullName L"X:\TMP18467.$$$" (last=0)
000a:trace:string:lstrcpynA (0x40f40d84, "/tmp", 1024)
000a:trace:dosfs:DOSFS_FindUnixName /tmp,L"TMP18467.$$$"
000a:trace:dosfs:DOSFS_ToDosFCBFormat (L"TMP18467.$$$", 0x40f40ce4)
000a:trace:heap:RtlAllocateHeap (0x40370000,00000002,00000110): returning 415cc890
000a:trace:dosfs:DOSFS_OpenDir "/tmp"
000a:trace:heap:RtlAllocateHeap (0x40370000,00000002,00000018): returning 415cbca0
000a:trace:heap:RtlReAllocateHeap (0x40370000,00000002,415cc890,00000210): returning 415cc890
000a:trace:heap:RtlReAllocateHeap (0x40370000,00000002,415cc890,00000410): returning 415cc890
000a:trace:heap:RtlReAllocateHeap (0x40370000,00000002,415cc890,00000810): returning 415cc890
000a:trace:heap:RtlReAllocateHeap (0x40370000,00000002,415cc890,00001010): returning 415cc890
000a:trace:heap:RtlFreeHeap (0x40370000,00000002,415cbca0): returning TRUE
000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L".", short_name: (null)
000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L"..", short_name: (null)
000a:trace:dosfs:DOSFS_ReadDir Read: long_name: L".font-unix", short_name: (null)
           [cut directory listing]
000a:warn:dosfs:DOSFS_FindUnixName L"TMP18467.$$$" not found in '/tmp'
000a:trace:heap:RtlFreeHeap (0x40370000,00000002,415cc890): returning TRUE
000a:trace:dosfs:DOSFS_GetFullName returning /tmp/TMP18467.$$$ = L"X:\tmp18467.$$$"
000a:trace:dosfs:GetDriveTypeW (L"X:\tmp18467.$$$")
000a: create_file( access=c0000000, inherit=0, sharing=00000003, create=1, attrs=00000000, drive_type=3, filename="/tmp/TMP18467.$$$" )
000a: create_file() = 0 { handle=0x98 }
000a:trace:file:CreateFileW returning 0x98
000a:trace:heap:RtlFreeHeap (0x40370000,00000002,415b32c0): returning TRUE
000a:trace:file:Win32HandleToDosFileHandle Got 10 for h32 0x98
000a:Ret  kernel32.INT_Int21Handler() retval=00000000 ret=41560c39
000a:trace:int21:DOSVM_Int21Handler failed, error 0
000a:trace:int21:DOSVM_Int21Handler returning: AX=0000 BX=5b0f CX=0000 DX=e9a8 SI=0000 DI=e9a8 DS=0a47 ES=0927 EFL=00000203
000a:Ret  winedos.CallBuiltinHandler() retval=0000007c ret=4008d9f0
000a:trace:global:GlobalHandle16 011f

This seems weird: there's a file handle, there's a DOS file handle but Int21
returns AX=0, indicating an error.

I did not yet check the code (will do this afternoon, but beware: I'm not
much of a coder), but I think a fix should be rather easy, there's probably
just a typo (or a thinko) in the Int21 handler.

I'm not sure, but this bug could also help number 1170, that seems related
in that there's a file that is not actually there, and 717, which also tries
to make a file that isn't created.

Please Cc: my e-mail-address as I'm not on the Wine-devel list. the "nospam"
part has an MX record, so mailing shouldn't be a problem.

We also checked Codeweavers Wine for this bug; it seems to be there, but
after two days of bug hunting our hunting ground is a bit of a mess, so I'm
not sure if we tested 2.0 or 2.1. I searched Bugzilla for a DOS related bug
and couldn't find one, but if it's fixed between 20030408 and now, then
please accept my apologies for wasting your precious reading time.

Best regards,

Valentijn

[Marcus Meissner]

On Wed, Oct 29, 2003 at 01:24:42PM +0100, Valentijn Sessink wrote:
> Hi folks,
>
> I think I hunted down a bug in DOS int21 function 0x5b (my DOS book insists
> this is 91 decimal). My older version of wine, 2000821, goes like this:
>
> We also checked Codeweavers Wine for this bug; it seems to be there, but
> after two days of bug hunting our hunting ground is a bit of a mess, so I'm
> not sure if we tested 2.0 or 2.1. I searched Bugzilla for a DOS related bug
> and couldn't find one, but if it's fixed between 20030408 and now, then
> please accept my apologies for wasting your precious reading time.

I have read through the code and this condition should not happen.

There has been some large reconstruction in that area, so please test yourself :/

Ciao, Marcus

[Valentijn Sessink]

Hello Marcus,

At Wed, Oct 29, 2003 at 10:25:45PM +0100, Marcus Meissner wrote:
> I have read through the code and this condition should not happen.

I've read code too, now. Version 1.80 of int21.c introduced the error. The
0x5b code here is plainly wrong, as AX can return an error *or* a file
handle.

I think it's been fixed in 20030911, but maybe even earlier, by introducing
INT21_CreateFile in dlls/winedos/int21.c version 1.38.

Function 0x5b might sttill not return the correct value when file creation
does not succeed, as I see no place where AX gets a correct error value.
> There has been some large reconstruction in that area, so please test
> yourself :/

I tried to, unfortunately the application I'm trying to test does things
with CD-ROM and thus broke - as I understood from the mailing list archives
- as result of a bug in 20030813 - where Wine crashes.

Now unfortunately, 0813 and 0911 just crash; versions before 0911 do not
have the RESET_CFLAG fixes; versions before 0813 differ too much in their
DOS file handling. Now version 1016 should be OK, but here the application
ends with a rather cryptic Windows dialog that says "error 6806".

So I gave up and reversed the 0x5b handling in msdos/int21.c in 20030408, so
my application works. I hope the 20031016++ versions will not barf with
"error 6806" - or maybe I'll sort out what change causes this.

Thanks for helping & checking my messages.

Best regards,

Valentijn

[Sylvain Petreolle]

Could you retry with current CVS, or if you cant, 20031016 ?
> So: file handle 0x136 translates to DOS handle 10, and int21 returns
> AX=0x000a
>
> My newer version, Wine 20030408, does the following:

<snip>
> I'm not sure, but this bug could also help number 1170, that seems
> related
> in that there's a file that is not actually there, and 717, which
> also tries
> to make a file that isn't created.

=====
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
 ICQ #170597259
Say NO to software patents
Dites NON aux brevets logiciels

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com