wine-devel July 2013

wine-devel@winehq.org

63 participants
129 discussions

How to get involved in Windows Store API implement?
by 中川祥 29 Jul '13

29 Jul '13

I do not know much about the store apps development. What is Windows.winmd? Do I need disassemble it and create wine version ?If I need C++,I wouldn't do. Is there any planning to support them?

2 1

NtCreateFile fails
by Mislav Blazevic 29 Jul '13

29 Jul '13

First of all, pardon my ignorance, I am new to wine and winapi. I am trying to implement apphelp.dll and I ran into issues with NtCreateFile: It always returns 0xc0000103, STATUS_NOT_A_DIRECTORY, and I am not sure what that means. Here is code: /* This function is not in API, but written for internal use */ HANDLE WINAPI SdbOpenFile( LPCWSTR path, PATH_TYPE type ) { /* SNIP */ if (type == DOS_PATH) if (!RtlDosPathNameToNtPathName_U(path, &str, NULL, NULL)) return NULL; InitializeObjectAttributes(&attr, &str, OBJ_CASE_INSENSITIVE, NULL, NULL); status = NtCreateFile(&file, GENERIC_READ | SYNCHRONIZE | FILE_READ_ATTRIBUTES, &attr, &io, NULL, FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ, FILE_OPEN, FILE_DIRECTORY_FILE, NULL, 0); /* SNIP */ return file; } Function is called like this: WCHAR szFileName[1024] = {0}; ExpandEnvironmentStringsW(L"%SystemRoot%\\sample.sdb", szFileName, 1024); // for testing purposes SdbOpenFile(szFileName, DOS_PATH); Compiled with winegcc. I am sure that C:\windows\sample.sdb exists. What am I doing wrong?

3 2

Re: [PATCH 3/5] d3dx9: Add support for structs to ID3DXConstantTable.
by Matteo Bruni 28 Jul '13

28 Jul '13

2013/7/24 Rico Schüller <kgbricola(a)web.de>: > --- > dlls/d3dx9_36/shader.c | 79 > ++++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 77 insertions(+), 2 deletions(-) > So there was actually a logic (an insane one, but yeah...). Have you found any game actually using this? Annoying question: have you checked if it's the same with newer d3dx9 dlls (e.g. d3dx9_43)? It still looks to me like buggy behavior and it might be that MS fixed that in later d3dx9 versions. This is not blocking the patch of course.

2 1

Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.
by Vincent Povirk 27 Jul '13

27 Jul '13

I have no opinion on this sort of work-around (it should work afaict, and I haven't found any other places where we currently use toff_t), but did you file a bug with whatever distro has such broken headers?

3 3

Windows 7 64-bit?
by Ken Sharp 27 Jul '13

27 Jul '13

I have to ask: Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTesting…

3 4

Need help with debugging a directx9 game crashing
by Qian Hong 25 Jul '13

25 Jul '13

Hello, I was debugging on a popular game [1] [2] (9 GB), it crashes on start. +relay,+seh,+tid log show that there are some calls to wined3d.wined3d_mutex_lock / wined3d.wined3d_buffer_map / wined3d.wined3d_mutex_unlock before crashing, so I turn on +d3d9 trace to get a new log in details. To my surprise, the game doesn't crash anymore with +d3d9 trace! After a serials of bisect, I found d3d9_AddRef is the key function call related to the crashing. If I remove the TRACE statement in line 71, the game will crash with +d3d9 as well; if I upgrade the TRACE in 71 to FIXME, the game will not crash even without +d3d9. 66 static ULONG WINAPI d3d9_AddRef(IDirect3D9Ex *iface) 67 { 68 struct d3d9 *d3d9 = impl_from_IDirect3D9Ex(iface); 69 ULONG refcount = InterlockedIncrement(&d3d9->refcount); 70 71 TRACE("%p increasing refcount to %u.\n", iface, refcount); 72 73 return refcount; 74 } Further tests show that the simplest hack to avoid crashing is replacing line 71 to: FIXME("anything %x\n", 0xdeadbeef); I have no idea what the real fix is, any suggestion what is the next step to debug? Thanks in advance! Environment: Wine 1.6-rc5 Ubuntu 12.04.2 LTS gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) The installer ship with native d3dx9_40.dll Backtrace on crash: Wine-dbg>c Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x0649e6e9). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:0649e6e9 ESP:0033cc60 EBP:00000000 EFLAGS:00210206( R- -- I - -P- ) EAX:00000001 EBX:19b871e0 ECX:00000000 EDX:00000000 ESI:23f420b0 EDI:23f4f20c Stack dump: 0x0033cc60: 80004005 19c0e0c0 00000000 19b871e0 0x0033cc70: 00000000 23f420b0 23f4f1f0 19b871e0 0x0033cc80: 00000018 00000040 0000001c 00000000 0x0033cc90: 0a9101df 00000020 00000034 7bc34159 0x0033cca0: 00110064 ffffffff 0033ccd8 7bc34d2d 0x0033ccb0: 00000000 0000000c 00000010 00000001 Backtrace: =>0 0x0649e6e9 in kg3dengine (+0x16e6e9) (0x00000000) 0x0649e6e9: movl 0x0(%eax),%ecx [1] http://jx3.xoyo.com/download [2] http://jx3.client.cdn.kingsoft.com/JXOnline3-v3.0.4.4980/JXOnline3-v3.0.4.4… -- Regards, Qian Hong - http://www.winehq.org

4 11

Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 3)
by Ken Thomases 25 Jul '13

25 Jul '13

On Jul 25, 2013, at 10:49 AM, Charles Davis wrote: > Try 3: Don't advertise WGL_EXT_swap_control if vsync is disabled. Looks good. Thanks, Ken

1 0

Re: [PATCH] winemac.drv: Advertise some legacy WGL extensions in the GL_EXTENSIONS string. (try 2)
by Ken Thomases 25 Jul '13

25 Jul '13

On Jul 24, 2013, at 9:34 PM, Charles Davis wrote: > Try 2: Don't duplicate a constant string; we might need to add more legacy > extensions. (Hopefully not. ;) Thanks for making that change. Looks good to me. Cheers, Ken

1 2

Re: [PATCH 1/6] scrrun: Store reference count inside IFileSystem3 object
by Nikolay Sivov 25 Jul '13

25 Jul '13

On 7/25/2013 16:35, Piotr Caban wrote: > --- > dlls/scrrun/filesystem.c | 163 > +++++++++++++++++++++++++++++++++++------------ > 1 file changed, 123 insertions(+), 40 deletions(-) Why do you need this?

2 1

What to do when an application misuses an API ...
by Michael Casadevall 25 Jul '13

25 Jul '13

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

3 3

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2013