What to do when an application misuses an API ...

Rico Schüller kgbricola at web.de
Wed Jul 24 02:44:53 CDT 2013


Hi Michael,

there are several thinks you could check.

1. Could you get a wrong order on winxp/vista/7 by using the default 
installation on a local FAT32 partition? Or does the order by accident 
match? If this doesn't reproduce the issue, you may also try the ext2fs 
driver for windows, as this seems to be allowed too. Does the default 
installation on a network drive with e.g. ext3 work correctly? I 
couldn't find anything, that the game has to be on NTFS, so this might 
be a valid bug to report to the support for the game. The solution might 
be, that they fix the issue (then we are lucky) or they will only allow 
NTFS (FAT32) partitions.

2. While we don't know if this will be fixed in 1. in one way or the 
other, we may try the following. What happens if you use wine and a NTFS 
or FAT32 partition where the game is on? Does the order match? Maybe the 
game requires NTFS (and/or FAT32) as file system? Does the NTFS (FAT32) 
driver handle the order correctly? Maybe it's a bug in the NTFS (FAT32) 
driver or i might just work by accident?

3. What's the network file system type in your test? Does it work if it 
is a NTFS (FAT32) file system?

I think, changing the Find* functions is bad, as there will most likely 
an app which depends on the order of the file creation date on FAT32 
partitions...

It may be worth a try to report it as a bug to the game support, but try 
to be as close to the system requirements as possible.

Cheers
Rico

On 24.07.2013 04:17, Michael Casadevall wrote:
> Hey all,
> I've been working on trying to get Sid Meier's Civilization V (Civ5) up
> to a point where it works relatively flawlessly on WINE. The largest
> issue is that installing the latest expansion pack has completely hosed
> the game under WINE unless some rather ugly workarounds have been taken.
> Specifically, the main issue is that Civ5 loads its data files in the
> order returned by Find{First,Next}File(), and breaks spectacularly if
> that order is disrupted. I documented my findings here:
> http://bugs.winehq.org/show_bug.cgi?id=34122
>
> As I sat to look at a possible patch, I'm not sure what I can actually
> do. Its clearly stated on the MSDN page that the order returned is
> dependent on the underlying filesystem, and Googling suggests that while
> NTFS seems to always return in a roughly alphabetical order, FAT32 will
> return by creation date, and with network drives all bets are off. I was
> even able to reproduce similar bugs in Civ5 by launching it from a
> network drive (which I had already tested in advance to make sure it
> returned an odd file order). FindFirstFile essentially calls down to
> NtQueryDirectoryFile, which in turn either calls a system specific
> syscall or readdir to get a list of files in a directory.
>
> My first thought is to extend the underlying read_directory_* functions
> in ntdll/directory.c so that they return an alphabetized list
> (essentially taking the results from getdents/getdirentries/readdir,
> sort them, then returning in the sort order whichever entry is next in
> line). This would produce a behavior similar (but not identical) to what
> is seen when operating under an NTFS filesystem.
>
> This approach seems wrong to me, and is further compounded by the fact
> this is a bug in an application, and not in WINE specifically; Under the
> correct circumstances, Windows will return a "non-sorted" list of files
> and in those cases Civilization V breaks. The flipside is that in the
> most common case, it works correctly, and furthermore, given how easy it
> is to assume that Find*File does return a sorted list, I won't be
> surprised if this issue has cropped up elsewhere (figuring out the
> underlying cause was exceedingly annoying). Any insight in to what the
> most correct course of action would be most appreciated
>
> I'm perfectly willing to put the legwork in fixing this bug, but I want
> to make sure I'm fixing it in a way that will be accepted :-).
>
> Regards,
> Michael
>
>
>




More information about the wine-devel mailing list