http://bugs.winehq.org/show_bug.cgi?id=5042
------- Additional Comments From shadow.wizzard(a)gmail.com 2007-12-03 04:10 -------
Please delete my last comments and attachment - I've mistake bug nr -
should be posted for 5721.
Once again sorry/
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5042
------- Additional Comments From shadow.wizzard(a)gmail.com 2007-12-03 04:05 -------
This bug need to be REOPEN.
This is because if only joystick is present
the game will segfault on start.
I've attached the log +dinput,+warn.
Why joystick can't work for this game ?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5567
------- Additional Comments From rich(a)hq.vsaa.lv 2007-12-03 03:56 -------
unarchived console output is larger than 100mb, archived it is ~1.3mb, which still too large for an
attachment...
i could either re-run the test or reduce the output in other way.
ps. sorry about the version change, different projects have different policies on this :)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3817
------- Additional Comments From scott(a)open-vote.org 2007-12-03 03:11 -------
It shouldn't be that complicated.
Get a list of every file in a directory, and then determine the distance on the
character table between lower case and upper case.
Write a comparison function, it theoretically should just be twice as slow as
finding a case insensitive string in a list of case insensitive strings.
If the function is building a list of every possible filename outcomes for each
file before checking against it, _THAT_ is a waste of CPU cycles and will work
slow as hell. It should just be done realtime...I haven't looked at the code yet.
The method I described would be fast, any modern PC could do it hundreds of
thousands of times a second.
So, it's a matter of...lets say we have a directory
c:\whatever
contains
hello.txt
HeLlO.txt(at least in *nix FS)
llama.txt
kitty.txt
We're looking for case insensitive hell.txt
so we iterate through the list looking for H and h, for each match, take the
next letter of hell, compare against e and E. It's just a couple embedded loops,
and it would be pleanty fast. Do it for the last two letters of hell. Don't
apply this algorithm to the list of files preemptively, apply it to the file
we're looking for on the fly, in an embedded loop that would only have to scan
the list once.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3817
------- Additional Comments From scott(a)open-vote.org 2007-12-03 03:11 -------
1st comment:
The bug pretty clearly shows a specific case of showing nonexistence of a
case-insensitive name on a case sensitive filesystem, which isn't exactly a
string comparison like I talked about before (in-memory comparison). The problem
is higher level than the one that call would help out with. Personally, I would
have written the operation as a lookup on a trie generated for each directory's
file listings. I specifically say trie because so, so many people just dump shit
into a hash table and don't give a rip about memory use.
I'm not precisely sure how the vfat / fat32 driver handles existence of
case-insensitive filenames, but I'd recommend looking at that for a solution
from those who have put more than 2 minutes thinking about the issue. From what
I can tell in the posts, the existing method is really, really inefficient for
large numbers of files (and even worse for longer filename inputs).
I think it wouldn't be a problem to add some code to Wine itself to cache
filenames it encounters on a path internally - not necessarily as a kernel
extension for userspace. Another option as a stopgap solution is to write
something for FUSE to cover the case insensitivity problem at the filesystem
level and have Wine wrap around the local filesystem via FUSE. I dunno how
lightweight FUSE is, but it may be worth a shot.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7306
------- Additional Comments From blin(a)gmx.net 2007-12-03 02:23 -------
Can you please provide +winsock trace of a login attempt?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5783
------- Additional Comments From thestig(a)google.com 2007-12-03 01:45 -------
The updated pass works for me. Sorry about the large attachment to the list.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=7555
------- Additional Comments From dmitry(a)codeweavers.com 2007-12-03 01:38 -------
> It could be GetWindow returns 0, which is passed into MFC71.2372, which
> returns 0, which causes the crash. But GetWindow is asked for the next
> sibling, which is nil. Is it some obscure bug in wine's window management?
Only a test case which precisely reproduces what the app does while creating
a similar window tree would tell.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.