March 2007 - Wine-Devel - list.winehq.org

x11drv: XDND: Fix file drop to properly support file:/// URIs (debugging problem)
by Maciej Katafiasz March 22, 2007

March 22, 2007

Hi, I'm working on a bug in winex11drv/xdnd.c, where file:/// URIs are not correctly interpreted, resulting in DnD broken most of the time. There are two parts of that bug: 1) X11DRV_XDND_BuildDropFiles() fails to properly handle absolute unix paths, which is exactly what you get from file:///, so it won't find the file unless $PWD and the constructed Windows drive-absolute path happen to have the same root. For example, file:///home/mathrick/foo.txt will yield "\\home\\mathrick\\foo.txt" and work only if the current directory is on a drive letter on which that path is valid. 2) X11DRV_XDND_DeconstructTextPlain() fails to accommodate for the fact file:/// URIs are, in fact, URIs and not paths, and doesn't check for validity nor does it unescape % sequences. The result is that paths with spaces, etc. in them won't work. The attached patch is my first take at 1), it works, but there is a problem. My test application is μTorrent, and it'll randomly lock up with the following errors printed: err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process heap section" wait timed out in thread 001f, blocked by 0019, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process heap section" wait timed out in thread 001e, blocked by 0019, retrying (60 sec) I can reproduce them by attempting to drop a file on µT's window right after startup. If I wait a while, it works. It also happens if I switch to another virtual desktop, then back to the one µT is on and then try to drop. I tried to check the code as well as I could (win32 API is not exactly my everyday environment), and I believe it's correct. At least all the allocations appear to be correct, nothing is overwritten. I've tried debugging in several ways using winedbg, but it fails pretty hard with various exceptions that aren't there when running outside the debugger, or fails to attach to the process, etc. From the circumstances, I believe there's some kind of race condition in allocation from process heap. However, I'm unable to find it as I have no idea about wine internals and how exactly DnD happens, and what threads do what and when. I'd be therefore very grateful if someone knowledgeable would take a look at it and see what's wrong, or at least help me with debugging the issue, as my ideas how to attack it have run out. Cheers, -- Maciej Katafiasz <email(a)mathrick.org>

1 0

Re: [3/4] WineD3D: Store the pixel format in the texture
by H. Verbeet March 21, 2007

March 21, 2007

Shouldn't this be done for volume textures as well?

2 1

Accessing File > 4gb problem (was: Debugging Supreme Commander)
by Stephan Rose March 21, 2007

March 21, 2007

I apologize in advance if this ends up on the mailing list twice but..it's been over 12 hours now and my e-mail, as my previous (but now unimportant one) still didn't make it so I am going to try to resend this. =) Allright, I've got the bug nailed to the wall with all of its 6 legs. What I don't know though is what to do about it. Still trying to find the right sledgehammer to squash it with.... Problem boils down to this: Supreme Commander has a .cab file that is just under 6 gigs in size. 0x178d42fce bytes to be exact Now here are the last 5 file seek positions in order from first to last: 0x0ff697fb4 0x0ff69800b 0x0ffebc19a 0x0ffebc1f0 All those succeed fine. But #5 ... 0x1007bc160 results in NTSTATUS c000000d, Invalid Parameter. That address is well within the range of the file though. The status occurs when lseek is called in this part of NtSetInformation, don't mind my added debug fixme's =) case FilePositionInformation: if (len >= sizeof(FILE_POSITION_INFORMATION)) { const FILE_POSITION_INFORMATION *info = ptr; unsigned int* iptr = (unsigned int*)&info->CurrentByteOffset.QuadPart; FIXME( "%i, 0x%08x%08x\n", fd, *(iptr+1), *iptr); if (lseek( fd, info->CurrentByteOffset.QuadPart, SEEK_SET ) == (off_t)-1) { FIXME("Bad result from lseek"); // Above fixme triggered past 4gb io->u.Status = FILE_GetNtStatus(); } } else io->u.Status = STATUS_INVALID_PARAMETER_3; break; I checked sizeof(off_t) and it correctly reports as 8-bytes, so I am not sure what the problem is and why this is happening. I know my system can handle files > 4 gigs....wine dumped 9 gigs of relay output onto my hard drive the first time I played with that debug channel =P Any ideas? On a bright note...I almost have my Supreme Commander CD Key memorized now...how many people can say that!!! ;) Thanks, Stephan

3 4

Debugging Supreme Commander Installer
by Stephan Rose March 21, 2007

March 21, 2007

I've been playing around with the supreme commander install most of today trying to figure out why it does not want to install. Running with +file,+msgbox and noticed the following error for virtually all files: warn:file:wine_nt_to_unix_file_name L"TUB500.xsb" not found in /home/stephan/.wine/dosdevices/c:/Program Files/THQ/Gas Powered Games/Supreme Commander/sounds/Voice/fr/Tutorials This is the file being copied when I get the "Error 87" message from Install shield. Also, pretty much every file, if not every file, gives the same trace in the debug log. It's weird that install shield will copy hundreds of files with that warning in their trace and not complain until it is 80% through. So then I wondered, is that really the cause or not? I think yes. Install shield appears to be kind enough to not re-copy the files if they already exist, so I killed the process to keep all files already copied and added the one missing file above from my windows install and then ran install shield again. This time around, the file was processed correctly and no error. Instead it gives the error now on the next file, which is TUB500.xwb. Some more trace below: trace:file:GetFileAttributesW L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb" trace:file:RtlDosPathNameToNtPathName_U (L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\ \TUB500.xwb",0x334b84,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb" 520 0x3348f8 (nil)) warn:file:wine_nt_to_unix_file_name L"TUB500.xwb" not found in /home/stephan/.wine/dosdevices/c:/Program Files/THQ/Gas Powered Games/Supreme Commander/sounds/Voice/fr/Tutorials trace:file:MoveFileWithProgressW (L"",(null),(nil),(nil),0004) trace:file:RtlDosPathNameToNtPathName_U (L"",0x3348b8,(nil),(nil)) trace:file:GetFileAttributesW L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb" trace:file:RtlDosPathNameToNtPathName_U (L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\ \TUB500.xwb",0x334800,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb" 520 0x334574 (nil)) warn:file:wine_nt_to_unix_file_name L"TUB500.xwb" not found in /home/stephan/.wine/dosdevices/c:/Program Files/THQ/Gas Powered Games/Supreme Commander/sounds/Voice/fr/Tutorials Followed by this resulting in the error message box: trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\temp\ \{62CDECF0-D5B2-11DB-C687-0018F32E4A94}\ \ISSetup.dll",0x341404,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"C:\\windows\\temp\ \{62CDECF0-D5B2-11DB-C687-0018F32E4A94}\\ISSetup.dll" 520 0x3411c4 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\windows\\temp\ \{62CDECF0-D5B2-11DB-C687-0018F32E4A94}\\ISSetup.dll" -> "/home/stephan/.wine/dosdevices/c:/windows/temp/{62CDECF0-D5B2-11DB-C687-0018F32E4A94}/ISSetup.dll" trace:file:RtlGetFullPathName_U (L"C:\\windows\\temp\ \{62CDECF0-D5B2-11DB-C687-0018F32E4A94}\\ISSetup.dll" 522 0x34149e (nil)) trace:msgbox:MSGBOX_OnInit L"Error:\t87" So it seems that it freaks out because somehow the file appears in the directory tree late. I'm still trying to think of a way of reproducing this with a test case...but that won't be all that easy without knowing precisely what Install Shield is actually doing in their code! Any thoughts? Stephan Rose

4 4

Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
by Alexandre Julliard March 21, 2007

March 21, 2007

Robert Shearman <rob(a)codeweavers.com> writes: > I've also modified tools/makerule to respect the "-s" flag passed into make. > > Alexandre suggested on IRC that I always print the destination file, > but I want to make sure that the technical details of this patch are > acceptable before making tweaks to the printed commands. I've been thinking about this some more, and I don't think I'll put it in. It's going to cause a lot of trouble and portability headaches, for only a minor cosmetic gain. This thing really belongs in make itself; it shouldn't be hard to patch GNU make to have a mode where it only displays the command name and target instead of the whole command line. Then it would work for all projects, and wouldn't require adding complexity to the makefiles. -- Alexandre Julliard julliard(a)winehq.org

2 4

Link creation not working _properly_ under 2.6 kernel?
by Tom Spear March 21, 2007

March 21, 2007

Hi all, I just got Slackware 11, and have a couple issues with link creation. I cant say that this worked with 10.2 either though, as I havent had a Linux machine in about a year, since the motherboard died on my last one.. The first issue is that regardless of which kernel I use, the Desktop link doesn't have the WinRAR icon, just the default blank paper KDE icon, and the menu entries have no icons at all. Second, with 2.4 the icon is created and put on my desktop, but with 2.6 it is created and put where I have Drive C pointed to in winecfg. Third, with 2.4 the menu entries are put in the menu under the wine folder, but with 2.6 they are put under the installdir of the app. I am using 0.9.32, as I cannot download the git version due to the corporate firewall, and transparent web proxy.. If needed I can create a bug for this issue, and as soon as I get a free minute I will reinstall and get the debug messages. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

4 18

Re: Enlarge max. length of PATH variable in programs/cmd/wcmdmain.c
by Ann & Jason Edmeades March 21, 2007

March 21, 2007

>However according to http://support.microsoft.com/kb/830473 : "the total length .... >cannot contain more than either 2047 or 8191 characters (as appropriate to your >operating system)" I'd suggest changing it to MAXSTRING which is used throughout cmd to refer to a 'big' string (of 8192 chars). At least this way you can grow the max line length simply! >PS: I think char string[1024]; in the main() should be extended > to char string[2048]; as well! (please see the MS note above) Yes, I'd agree (to MAXSTRING, but change the 1024 in at least one of the calls appropriately as well) Jason

2 1

Re: wined3d: Check for float texture formats correctly.
by H. Verbeet March 21, 2007

March 21, 2007

On 21/03/07, Vitaly Budovski <vbudovski(a)gmail.com> wrote: > Move the checks for float texture formats into the correct location. > This allows some Direct3D sample applications to start up which check > for any of the float formats together with D3DUSAGE_RENDERTARGET. > --- That's better, but now those formats can only be used with render targets. I don't think that's correct, since they were probably added in the other place to make some application work.

2 2

wine opinion of a user
by Vijay Kiran Kamuju March 21, 2007

March 21, 2007

Hi, http://www.selfadhesivelabels.com/blog/2007/03/20/windos-software-that-we-d… This is a response from a user. Can any one order and test sage 50 line business s/w. And other s/w. Dan, you can redirect them to appdb. Thanks, VJ

4 5

Ok... Someone tell me WTF is going on here.
by Giles Cameron March 21, 2007

March 21, 2007

Ok. I have been tring to track down what appears to be a bug in wine while trying to get The Sims 2 (Seasons) to work. And so I have been tring to add to the debug a bunch of useless bunk. and I am getting VERY strange results, attached are the cdrom.c file I edited in dlls/ntdll/ and the output. Did I manage to break the wine debugger? or uncover the monster of all bugs? I am sitting here wondering "WTF" right now.... Wtf did I do, Giles Cameron

3 3