January 2006 - Wine-Devel - list.winehq.org

Unixfs as ShellFSFolder?
by Michael Jung Jan. 18, 2006

Jan. 18, 2006

Hi all, I guess I'm responsible for a lot of redundant code between the implementations of filesystem shellfolders in shell32/shlfdr_fs.c and shfldr_unixfs.c. While I've always tried to re-use as much code as possible, unixfs by nature has to use posix apis to get hold of the unix filesystem. In current cvs, unixfs can be used as a drop-in replacement for the old CLSID_ShellFSFolder implementation and if you apply the attached small patch, it will be. It would be nice if some people could try this in their local tree and report problems with it. What do people think about getting rid of shfldr_fs.c in the long run, in order to remove the redundancy? Does ReactOS use wine's shell32.dll? I guess it would be a problem for them? ChangeLog: shell32: Use shfldr_unixfs CLSID_ShellFSFolder implementation instead of the one from shfldr_fs dlls/shell32/shellole.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 2

HW address w/o connection in iphlpapi
by most＠museresearch.com Jan. 18, 2006

Jan. 18, 2006

We ran into an obscure problem with iphlpapi that I'd like to get help with. When you boot a linux box without an ethernet connection, and eth0 configuration fails, GetAdaptersInfo does not return MAC address info for eth0. The problem seems to be that enumerateInterfaces (in dlls/iphlpapi/ifenum.c) doesn't create a record for eth0, because SIOCGIFCONF doesn't return one. Then when GetAdaptersInfo (in dlls/iphlpapi/iphlpapi_main.c) is looping through the interfaces, eth0 isn't there so it doesn't call getInterfacePhysicalByIndex to get the MAC address. I verified that if I hack an eth0 entry into the table built by enumerateInterfaces, the call to getInterfacePhysicalByIndex works just fine. So the problem is simply a disconnect between what enumerateInterfaces is scanning and what GetAdaptersInfo is trying to scan. Near as I can tell (and I am no networking guru by any stretch) GetAdaptersInfo is supposed to return MAC info for eth0, even if eth0 has no IP address. Near as I can tell too Windows does return MAC info in this situation. So this looks, again near as I can tell %), like a Wine bug. Is it a wine bug? Any suggestions for a fix? ... mo PS: I cc'd Juan Lang who is noted as the author of the code. I hope that isn't bad etiquette...?

2 3

winspool/tests: a Space before the printername is invalid
by Detlef Riekenberg Jan. 17, 2006

Jan. 17, 2006

Am Dienstag, den 17.01.2006, 13:08 -0600 schrieb Wine Bugs: > ------- Additional Comments From michal.okresa(a)ifne.sk 2006-17-01 13:08 ------- > And to make it complete, space before printer name in customized printing dialog > is still present. > (mayby small bug in ISS?) This Patch validates, that the failure of OpenPrinter is not a wine Problem. Win9x: ERROR_INVALID_PARAMETER WinNT: ERROR_INVALID_PRINTER_NAME Changelog: - winspool/tests: a Space before the printername is invalid -- By By ... ... Detlef

1 0

TaxAct 2005 file problem
by James E. LaBarre Jan. 17, 2006

Jan. 17, 2006

As usual, this year's version of TaxAct has the same defect (or programming screw-up) it's had for years now that prevents it from being usable under Wine. The app installs fine, and will start to run as if it was sufficiently compatible with Wine. The problem with TA is that it *always* tries to first load a default data file (even if you give it a different filename as a command parameter), and the default filename is "2005 Tax Return File.ta5". It seems they are using a faulty or non-standard method of calling the default data file, as it will put up an error dialogue that it was unable to find it's default file, after which it exits. The specific message, captured by running a +msgbox debug switch is: ================================== 1729146:0009:Call kernel32.lstrlenA(7e0a2ea0 "Unable to open \"2005 Tax Return File.ta5\".\n\nPlease verify that C:\\Apps\\TaxACT2005\\2005 Tax Return File.ta5 exists on your hard drive, if it does not you will need to reinstall TaxACT.") ================================== I have a full "WINEDEBUG=+relay,+msgbox" capture of the programme run till failure & exit, but it's 117M uncompressed (1.4M bz2 file). The app is also available as a free "standard" version (in fact, that's what I'm working with); the Deluxe version is merely an unlock code for the free download. https://www.taxact.com/s_taxact/free_taxact.asp?where=Register&product_id=0 5STDW&ad=0&s=Y&sc=051200003 I had tried doing a WINEDLLOVERRIDE for shlwapi, ntdll & kernel32 (various combinations) as these seemed to be the major dlls being loaded. But no success there. Please email me if you'd like more info from the debug file, or the file itself. Not being a developer, I don't frequent this list (just the wine-users list).

1 0

[rpcrt4] Properly created named pipes
by Thomas Weidenmueller Jan. 17, 2006

Jan. 17, 2006

Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise the call to ConnectNamedPipe() will block the server thread if no connection can be established, which causes the rpc server to dead-lock during startup. - Thomas -- P.S.: Please let me know if there's something wrong with this patch or tell me why it was rejected. Otherwise I'm going to assume the fixes aren't appreciated or necessary because the implementation is considered mature and stable. Index: dlls/rpcrt4/rpc_binding.c =================================================================== RCS file: /home/wine/wine/dlls/rpcrt4/rpc_binding.c,v retrieving revision 1.39 diff -u -r1.39 rpc_binding.c --- dlls/rpcrt4/rpc_binding.c 6 Sep 2005 10:26:14 -0000 1.39 +++ dlls/rpcrt4/rpc_binding.c 16 Jan 2006 23:00:15 -0000 @@ -142,7 +142,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection->Endpoint) + 1); strcat(strcpy(pname, prefix), Connection->Endpoint); TRACE("listening on %s\n", pname); - Connection->conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, + Connection->conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname); @@ -166,7 +166,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection->Endpoint) + 1); strcat(strcpy(pname, prefix), Connection->Endpoint); TRACE("listening on %s\n", pname); - Connection->conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, + Connection->conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname);

2 5

dlls/wined3d/device.c GetCreationParameters
by Al Tobey Jan. 17, 2006

Jan. 17, 2006

I'd just post to wine-patches, but I think this needs another set of eyes. According to MSDN, this just sets a pointer to the creation parameters. The attached patch makes this function work, but I'm not sure if returning a pointer to the original parameters is the right approach or if they should be copied first. This patch makes a bunch of the Ogre3d demos work, which are great for testing since you can run the same demo in OpenGL, D3D9, and D3D7 modes. http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c… http://www.ogre3d.org/index.php?option=com_remository&Itemid=57&func=select… http://easynews.dl.sourceforge.net/sourceforge/ogre/OgreDemos-1.0.4.zip I'm currently playing with compiling Ogre3d against winelib and finding it's shaking out a bunch of missing stuff in d3d9 - patches may follow. -Al Tobey

6 15

Re: WINED3D: [02/02] IWineD3DSurfaceImpl_SetContainer & IWineD3DVolumeImpl_SetContainer refcount fixes.
by H. Verbeet Jan. 17, 2006

Jan. 17, 2006

What is wrong with this patch / what can I do to fix it?

1 0

Re: More implementation of IRecordInfo
by Dan Kegel Jan. 17, 2006

Jan. 17, 2006

In March 2005, in message http://www.winehq.com/hypermail/wine-patches/2005/03/0155.html, jacek wrote: > This patch makes IRecordInfo almost complete. > If anyone knows any application using it I could test on, > please let me know. The freely downloadable app TTQV4 fails at the moment; one of the last messages is fixme:ole:IRecordInfoImpl_IsMatchingType (0x7c729280)->(0x7bd04210) stub I think that's in the code you were asking for test cases for... I ran into this on wine-users: http://www.winehq.org/pipermail/wine-users/2006-January/020161.html Here's the text of that message. - Dan ---------- Forwarded message ---------- From: Dan Kegel <dank(a)kegel.com> Date: Jan 12, 2006 10:47 PM Subject: Re: could not load ... as Win32 binary To: wine-users(a)winehq.com, postit(a)weiglwelt.de > > I am using Debian (Etch) und wine 0.9.5-winehq-1. > > When I try to install a Program the installation routine hangs ... > > ... In December it worked already. Now it doesn't any more (after a apt-get > > upgrade with many, many packages). > [The app is] TTQV4 (a GPS and Navigation software) see > http://www.ttqv.de/main.php?content=14 and > http://www.ttqv.de/main.php?content=21&download=13 With a fresh copy of wine from cvs, it installed fine once I copied msvc40.dll into windows/system32. The app started ok, too, but died after putting up the main window, complaining about a type mismatch. It'd probably work better with native COM libraries, but I don't have time to try that right now. For the record, the last two lines on the console were fixme:ole:MSFT_ReadValue BSTR length = -1? fixme:ole:IRecordInfoImpl_IsMatchingType (0x7c729280)->(0x7bd04210) stub ... -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

winspool: What can I do to get my Patches into CVS?
by Detlef Riekenberg Jan. 16, 2006

Jan. 16, 2006

Hi. What can I do to get my Patches into CVS? 2006.01.07: http://www.winehq.org/pipermail/wine-patches/2006-January/023276.html Changelog: - winspool/tests: filter more results 2006.01.08: http://www.winehq.org/pipermail/wine-patches/2006-January/023284.html Changelog: - kernel/tests: report only 99 failures on WinNT 3.51 2006.01.13: http://www.winehq.org/pipermail/wine-patches/2006-January/023420.html Changelog: - Add Function "validate_envW" to validate the user-supplied Printing Environment (respect "Windows Version" - Setting) - Change GetPrinterDriverDirectoryW on top of "validate_envW" to Report the same Path as NT does - 2 Tests are now working in Wine Synced to current git-version with suggestions from Alexandre: Do not compare every allowed Value, use a loop Do not check for "Windows 4.0"-Only on Win9x. 2006.01.13: http://www.winehq.org/pipermail/wine-patches/2006-January/023430.html Changelog: - winspool: added a comment how to add printers from /etc/printcap to wine (registry section: "PPD Files") 2006.01.14: http://www.winehq.org/pipermail/wine-patches/2006-January/023436.html updated after comments from Huw Changelog: - winspool: updated some traces for bug 4268 (when loading the System-Printers) -- By By ... ... Detlef

1 0

[rpcrt4] Properly created named pipes
by Thomas Weidenmueller Jan. 16, 2006

Jan. 16, 2006

Created the named pipes with the FILE_FLAG_OVERLAPPED flag, otherwise the call to ConnectNamedPipe() will block the server thread if no connection can be established, which causes the rpc server to dead-lock during startup. - Thomas Index: dlls/rpcrt4/rpc_binding.c =================================================================== RCS file: /home/wine/wine/dlls/rpcrt4/rpc_binding.c,v retrieving revision 1.39 diff -u -r1.39 rpc_binding.c --- dlls/rpcrt4/rpc_binding.c 6 Sep 2005 10:26:14 -0000 1.39 +++ dlls/rpcrt4/rpc_binding.c 16 Jan 2006 23:00:15 -0000 @@ -142,7 +142,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection->Endpoint) + 1); strcat(strcpy(pname, prefix), Connection->Endpoint); TRACE("listening on %s\n", pname); - Connection->conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, + Connection->conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname); @@ -166,7 +166,7 @@ pname = HeapAlloc(GetProcessHeap(), 0, strlen(prefix) + strlen(Connection->Endpoint) + 1); strcat(strcpy(pname, prefix), Connection->Endpoint); TRACE("listening on %s\n", pname); - Connection->conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX, + Connection->conn = CreateNamedPipeA(pname, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL); HeapFree(GetProcessHeap(), 0, pname);

1 0

Re: Loader Optimization
by Alexandre Julliard Jan. 16, 2006

Jan. 16, 2006

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > Optimize for the case where a DLL with no path is requested and it is > already loaded. This change is correct since RtlDosSearchPath_U did not > change the path being looked at - if libname contains no path then > file_part will be the same as libname. Yes, but the current code checks for the full name first and your patch doesn't, so it will change the behavior if we have two modules with the same base name. This will need some test cases. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: translation of wine/programs/wcmd/Ru.rc
by Phil Krylov Jan. 16, 2006

Jan. 16, 2006

On Mon, 16 Jan 2006 18:00:04 +0300 Roman <murzik_007(a)sertolovo.ru> wrote: > I've translaten most of the messages There are some typos: +из другого bat-файла. При по завершении вывываемого командного файла, управление возвращается\n\ should be: +из другого bat-файла. По завершении вызываемого командного файла управление возвращается\n\ And this: +ECHO ON все последующие команды будут выведены на экран\n\ Should be: +ECHO ON включает вывод всех последующих команд на экран\n\ And this: +ECHO OFF отменяет режим ECHO ON (по-умолчанию ECHO is OFF).\n\ Should be: +ECHO OFF отменяет режим ECHO ON (по умолчанию используется режим ECHO OFF).\n\ And this is not translated at all: +The ECHO OFF command can be prevented from displaying by\n\ preceding it with an @ sign.\n" And this: +"Команда FOR дисползуется для выполнения команд для нескольких файлов.\n\ Should be: +"Команда FOR используется для выполнения команд для нескольких файлов.\n\ And this: +Синтаксис: FOR %переменная IN (set) DO команда\n\ Should be: +Синтаксис: FOR %переменная IN (набор) DO команда\n\ And this is partially untranslated: +но не может содержать пробелов (this is different from other operating\n\ +systems). And lots more. Please check your patch for typos and resend. -- Ph.

1 0

winbase.h dependency problems - dll separation issues
by Mike McCormack Jan. 16, 2006

Jan. 16, 2006

winbase.h shouldn't be included when compiling ntdll, as it is the header for kernel32.dll. The attached patch removes winbase.h from the server call headers, exposing a number of dependency problems in ntdll. wine_server_call_err seems to be misplaced in wine/server.h as it uses kernel32.SetLastError(), and it is the only function which requires winebase.h to be included. Perhaps it should be converted to a macro or only defined when winbase.h is already included, as I have done in this patch? Mike

2 1

Mandriva problems
by Krister Hallergard Jan. 16, 2006

Jan. 16, 2006

Have asked this question to several news groups without getting any response. Was suggested that I submit it to you Krister Hallergard Lytham UK Have problems to install quite a few programs with wine - Mandriva 2006 that I can install without problems with other distros (SuSE10.0, Fedora C4 and Kubuntu 5.10) on other partitions on the same machine. My main interest is to install Excel 97 to be able to acces my old wk4-files (I know I can convert them to xls-files to use with Open Office, but I dont want to do that, as I can install Excel on SuSE. Why is Mandriva so difficult?? Made a fresh Madriva installation and as first thing installed wine 0.9.5. When trying to install Excel 97 I get these error messages QUOTE: [krister(a)localhost disk1]$ wine install.exe wine: Unhandled exception (thread 000a), starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x7faa3b93 UNQUOTE Next I applied the suggestions in Frank´s corner to install Excel 97 and get this long debug message: QUOTE: [krister(a)localhost disk1]$ WINEDLLOVERRIDES="odccp32=n" wine INSTALL.EXE wine: Unhandled page fault on read access to 0x7fdd1a0a at address 0x11df:0x0000001a (thread 000a), starting debugger... WineDbg starting on pid 0x8 fixme:dbghelp:SymLoadModule Should have successfully loaded debug information for image Z:\mnt\cdrom\DISK1\INSTALL.EXE Unhandled exception: page fault on read access to 0x7fdd1a0a in 16-bit code (11df:001a). In 16 bit mode. Register dump: CS:11df SS:11ef DS:11ef ES:11c7 FS:003b GS:0033 IP:001a SP:5964 BP:0000 FLAGS:0202( - 00 - -RI1) AX:0000 BX:2400 CX:0800 DX:0000 SI:0000 DI:11ee Stack dump: 0x11ef:0x5964: 046c 101f 0000 0000 0000 0000 0000 0000 0x11ef:0x5974: 0000 0000 0000 0000 0000 0000 0000 0000 0x11ef:0x5984: 0000 0000 0000 0000 0000 0000 0000 0000 023d: sel=11ef base=7fde0f20 limit=0000619f 16-bit rw- 0238: sel=11c7 base=7fdc1690 limit=0000010f 16-bit rw- Backtrace: =>1 0x11df:0x001a (0x11df:0x001a) 0x11df:0x001a: xorw %bp,%bp Modules: Module Address Debug info Name (69 modules) ELF 0x7be82000-7bf00000 Deferred ntdll<elf> \-PE 0x7be90000-7bf00000 \ ntdll ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7eef7000-7ef2b000 Deferred uxtheme<elf> \-PE 0x7ef00000-7ef2b000 \ uxtheme ELF 0x7ef2b000-7eff9000 Deferred comctl32<elf> \-PE 0x7ef30000-7eff9000 \ comctl32 ELF 0x7eff9000-7f018000 Deferred iphlpapi<elf> \-PE 0x7f000000-7f018000 \ iphlpapi ELF 0x7f018000-7f060000 Deferred rpcrt4<elf> \-PE 0x7f030000-7f060000 \ rpcrt4 ELF 0x7f060000-7f0f9000 Deferred ole32<elf> \-PE 0x7f080000-7f0f9000 \ ole32 ELF 0x7f0f9000-7f158000 Deferred shlwapi<elf> \-PE 0x7f110000-7f158000 \ shlwapi ELF 0x7f158000-7f22b000 Deferred shell32<elf> \-PE 0x7f170000-7f22b000 \ shell32 ELF 0x7f22b000-7f23f000 Deferred lz32<elf> \-PE 0x7f230000-7f23f000 \ lz32 ELF 0x7f36b000-7f380000 Deferred midimap<elf> \-PE 0x7f370000-7f380000 \ midimap ELF 0x7f492000-7f4b6000 Deferred msacm32<elf> \-PE 0x7f4a0000-7f4b6000 \ msacm32 ELF 0x7f4b6000-7f4cf000 Deferred msacm<elf> \-PE 0x7f4c0000-7f4cf000 \ msacm ELF 0x7f4cf000-7f517000 Deferred wineoss<elf> \-PE 0x7f4e0000-7f517000 \ wineoss ELF 0x7f517000-7f59e000 Deferred winmm<elf> \-PE 0x7f520000-7f59e000 \ winmm ELF 0x7f59e000-7f601000 Deferred winedos<elf> \-PE 0x7f5b0000-7f601000 \ winedos ELF 0x7f601000-7f60a000 Deferred libxcursor.so.1 ELF 0x7f60a000-7f627000 Deferred imm32<elf> \-PE 0x7f610000-7f627000 \ imm32 ELF 0x7f627000-7f644000 Deferred ximcp.so.2 ELF 0x7f644000-7f6ae000 Deferred libgl.so.1 ELF 0x7f6ae000-7f77a000 Deferred libx11.so.6 ELF 0x7f77a000-7f792000 Deferred libice.so.6 ELF 0x7f792000-7f81c000 Deferred winex11<elf> \-PE 0x7f7a0000-7f81c000 \ winex11 ELF 0x7f81c000-7f83c000 Deferred libexpat.so.0 ELF 0x7f83c000-7f86c000 Deferred libfontconfig.so.1 ELF 0x7f86c000-7f87f000 Deferred libz.so.1 ELF 0x7f87f000-7f8e8000 Deferred libfreetype.so.6 ELF 0x7f8fd000-7f93f000 Deferred advapi32<elf> \-PE 0x7f910000-7f93f000 \ advapi32 ELF 0x7f93f000-7f9d4000 Deferred gdi32<elf> \-PE 0x7f950000-7f9d4000 \ gdi32 ELF 0x7f9d4000-7fb10000 Deferred user32<elf> \-PE 0x7f9f0000-7fb10000 \ user32 ELF 0x7fc27000-7fc2a000 Deferred iso8859-1.so ELF 0x7fc61000-7fd70000 Deferred kernel32<elf> \-PE 0x7fc80000-7fd70000 \ kernel32 ELF 0x7fe83000-7fe87000 Deferred libxrandr.so ELF 0x7fe87000-7fe90000 Deferred libxrender.so.1 ELF 0x7fe90000-7fe9b000 Deferred libnss_files.so.2 ELF 0x7fe9b000-7feb0000 Deferred winevdm<elf> \-PE 0x7fea0000-7feb0000 \ install ELF 0x7feb0000-7fed5000 Deferred libm.so.6 ELF 0x7fed5000-7ffcb000 Deferred libwine_unicode.so.1 ELF 0x7ffcb000-7ffce000 Deferred xlcdef.so.2 ELF 0x7ffce000-7ffdc000 Deferred libxext.so.6 ELF 0xb7e42000-b7e4b000 Deferred libsm.so.6 ELF 0xb7e4c000-b7e50000 Deferred libdl.so.2 ELF 0xb7e50000-b7f7e000 Deferred libc.so.6 ELF 0xb7f7e000-b7f90000 Deferred libpthread.so.0 ELF 0xb7f91000-b7fab000 Deferred libwine.so.1 ELF 0xb7fab000-b7fb0000 Deferred libxxf86vm.so.1 ELF 0xb7fc1000-b7fd8000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\mnt\cdrom\DISK1\INSTALL.EXE 0000000a 0 <== 00000009 0 WineDbg terminated on pid 0x8 UNQUOTE Can anyone help me!?

1 0

Re: [MSACM] add file name trace to acmDriverAdd
by Alex Villacís Lasso Jan. 16, 2006

Jan. 16, 2006

Robert Reif wrote: > This patch justs adds some debugging information. > > Loading a native acm driver using acmDriverAdd seems to be broken. > Passing the driver name to MSACM_RegisterDriver gets further along > but doesn't fix the problem. > >------------------------------------------------------------------------ > > > > I am currently in the process of posting a working acmDriverAdd[AW] implementation (without any winmm hacks). Is this patch related to the SJphone report earlier? I am currently downloading said software to test it. Alex Villacís Lasso

1 0

Re: MSACM: implement acmDriverPriority with driver priority/enabled saving
by Alex Villacís Lasso Jan. 16, 2006

Jan. 16, 2006

Alex Villacís Lasso wrote: > This patch implements acmDriverPriority(), including saving the > priority order and the enabled/disabled status of each global driver > to HKCU\\Software\\Microsoft\\Multimedia\\Audio Compression > Manager\\Priority v4.00 . Also included the foundation for broadcast > notifications on driver priority reorder, including a counter instead > of a BOOL flag for deferred notifications (as requested by Eric Pouech). > > Changelog: > * Implementation of acmDriverPriority() with registry saving > * Foundation for notification broadcasts with support for deferred > notification. > > Alex Villacís Lasso > Any comments on this patch? Alex Villacís Lasso

1 0

Re: MSACM: local drivers must not contribute to ACM_METRIC_COUNT_DRIVERS count
by Alex Villacís Lasso Jan. 16, 2006

Jan. 16, 2006

Alex Villacís Lasso wrote: > This distinction makes a difference when local drivers can be loaded. > > Changelog: > * Exclude local drivers from count when > acmMetrics(ACM_METRIC_COUNT_DRIVERS) is computed Please disregard this patch, the original behavior was correct. Alex Villacís Lasso

1 0

Re: MSACM: return failure rather than assert with nAvgBytesPerSec == 0
by Alex Villacís Lasso Jan. 16, 2006

Jan. 16, 2006

Alex Villacís Lasso wrote: > This check is necessary until local codec loading is in CVS. Failure > scenario fixed is: app instructs to load local ACM codec, fails, > doesn't notice failure, requests codec info, fails, again doesn't > notice failure, submits zeroed structure to PCM converter --> > assertion failed. > > Changelog: > * Check for nAvgBytesPerSec == 0 in PCM converter instead of allowing > assertion to fail. > > Alex Villacís Lasso > >------------------------------------------------------------------------ > >--- wine-0.9.5-cvs/dlls/msacm/pcmconverter.c 2005-11-28 15:57:25.000000000 -0500 >+++ wine-0.9.5-cvs-patch/dlls/msacm/pcmconverter.c 2006-01-09 21:17:07.000000000 -0500 >@@ -945,12 +945,20 @@ > switch (adss->fdwSize) { > case ACM_STREAMSIZEF_DESTINATION: > /* cbDstLength => cbSrcLength */ >+ if (!adsi->pwfxDst->nAvgBytesPerSec) { >+ ERR("adsi->pwfxDst->nAvgBytesPerSec == %lu\n", adsi->pwfxDst->nAvgBytesPerSec); >+ return MMSYSERR_INVALPARAM; >+ } > adss->cbSrcLength = PCM_round(adss->cbDstLength & dstMask, > adsi->pwfxSrc->nAvgBytesPerSec, > adsi->pwfxDst->nAvgBytesPerSec) & srcMask; > break; > case ACM_STREAMSIZEF_SOURCE: > /* cbSrcLength => cbDstLength */ >+ if (!adsi->pwfxSrc->nAvgBytesPerSec) { >+ ERR("adsi->pwfxSrc->nAvgBytesPerSec == %lu\n", adsi->pwfxSrc->nAvgBytesPerSec); >+ return MMSYSERR_INVALPARAM; >+ } > adss->cbDstLength = PCM_round(adss->cbSrcLength & srcMask, > adsi->pwfxDst->nAvgBytesPerSec, > adsi->pwfxSrc->nAvgBytesPerSec) & dstMask; > > >------------------------------------------------------------------------ > > > > Any comment on this patch? Alex Villacís Lasso

1 0

compilation error: Undefined reference to strncmpW
by Peter Lemenkov Jan. 16, 2006

Jan. 16, 2006

Hello, All! ============================= ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./shlwapi.spec assoc.o clist.o istream.o msgbox.o ordinal.o path.o reg.o regstream.o shlwapi_main.o stopwatch.o string.o thread.o url.o wsprintf.o shlwapi.res -o shlwapi.dll.so -L../../dlls -L../../dlls/oleaut32 -L../../dlls/ole32 -L../../dlls/user32 -L../../dlls/gdi32 -L../../dlls/advapi32 -L../../dlls/kernel32 -L../../dlls/ntdll -loleaut32 -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -Wb,-doleaut32 -L../../libs/wine -lwine -luuid -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port string.o: In function `StrStrW':/home/petro/work/projects/wine/dlls/shlwapi/string.c:531: undefined reference to `strncmpW' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [shlwapi.dll.so] Error 2 make[2]: Leaving directory `/home/petro/work/projects/wine/dlls/shlwapi' make[1]: *** [shlwapi] Error 2 make[1]: Leaving directory `/home/petro/work/projects/wine/dlls' make: *** [dlls] Error 2 [petro(a)Petro wine]$ ============================ -- With best regards, Peter Lemenkov.

2 1

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
by Dan Kegel Jan. 16, 2006

Jan. 16, 2006

On 1/15/06, Ge van Geldorp <gvg(a)reactos.org> wrote: > > The Mozilla ActiveX control download feature is cool and all, > > but until we repackage the sucker to include MSVCP60.DLL to fix > > http://bugs.winehq.org/show_bug.cgi?id=4064 ... > > I could have sworn I saw somebody post a note saying they had > > done said repackaging, but I can't find it now... > > http://www.winehq.org/pipermail/wine-patches/2005-December/022795.html > Instructions on how to repackage can be found at > svn://svn.reactos.org/trunk/tools/MozillaControl/ Thanks! I've updated bug 4064. Now can somebody update winehq.org's copy of the control so we can close that bug? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

(no subject)
by Ananth M Jan. 16, 2006

Jan. 16, 2006

Hi Maintainers, For the recent wine releases , is there any binary rpm's are available ? In the winehq.com I am able to get the following message only.. Binary packages are in the process of being built, but the source is available now. You can find out more about this release in the announcement. Check out our download page for packages for your favorite distribution. Even in the downloads, installation of the RPM's ( otherthan Source RPM ) is giving problems mainly ( dependancy problems ) . One more question : Is development RPM includes all the required S/W ? or Do I need to download other RPMs also ( i386 or i686 ) ? Thank you

2 1

SJphone crashing
by Pavel Troller Jan. 16, 2006

Jan. 16, 2006

Hi! I would like to test a free softphone application called "SJphone" (free download from http://www.sjlabs.com ). I know there is a native Linux version, but it's much less featured than the windows one (mainly missing skin support and generally less options) and because I need to train other users how to use the windows version, I have to try it for myself first :-). Installation is working well, no errors encountered. However, after trying to run the program, its GUI appered for a while with a sandclock cursor and then the following crash occured. I don't have access to real windows so I don't have any windows DLLs available. Would it be possible to fix wine's ones to make the program working ? With regards, Pavel Troller P.S. running CVS wine from 06/01/15 (yesterday). patrol(a)arcus:~/.wine/drive_c/Program Files/SJLabs/SJphone$ wine SJphone.exe err:wave:OSS_WaveOutInit open(/dev/mixer2) failed (No such file or directory) err:wave:OSS_WaveInInit open(/dev/mixer2) failed (No such file or directory) fixme:ole:CoRegisterMessageFilter stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7ff51ee8)->((nil),00000008) fixme:ras:RasEnumConnectionsA (0x7f7b10a0,0x7fc68e34,0x7fc68e40),stub! fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program to use LAN connection/winsock instead! fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7ff64d48)->((nil),00000008) err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 fixme:win:LockWindowUpdate (0x2002a), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:keyboard:RegisterHotKey (0x2002a,1,0x00000006,81): stub fixme:keyboard:RegisterHotKey (0x2002a,2,0x00000006,66): stub fixme:keyboard:RegisterHotKey (0x2002a,3,0x00000006,76): stub fixme:keyboard:RegisterHotKey (0x2002a,4,0x00000006,78): stub fixme:keyboard:UnregisterHotKey (0x2002a,5): stub fixme:keyboard:RegisterHotKey (0x2002a,6,0x00000006,83): stub fixme:keyboard:RegisterHotKey (0x2002a,7,0x00000006,77): stub err:msacm:MSACM_GetRegistryKey No alias needed for registry entry wine: Unhandled page fault on write access to 0x59be0000 at address 0x3f6dbd50 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x59be0000 in 32-bit code (0x3f6dbd50). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:3f6dbd50 ESP:7fc68248 EBP:7fc689ec EFLAGS:00210246( - 00 -RIZP1) EAX:015000d4 EBX:3f6e4e04 ECX:209c0000 EDX:54da0020 ESI:009c7ffc EDI:7fa403d0 Stack dump: 0x7fc68248: 7fc68250 7fa40408 00000078 009c7ffc 0x7fc68258: 015000d4 00d700d6 016e0158 017000da 0x7fc68268: 00dd00dc 00df0162 00e10155 010300e2 0x7fc68278: 013a00e4 00e70107 00e9010d 00eb0119 0x7fc68288: 00ed011b 010f00ee 01440111 00f30148 0x7fc68298: 015100f4 00f700f6 016f0159 017100fa Backtrace: =>1 0x3f6dbd50 in msacm32 (+0xbd50) (0x3f6dbd50) 2 0x3f6dc2d9 MSACM_RegisterDriver+0x139 in msacm32 (0x3f6dc2d9) 3 0x3f6d88fb acmDriverAddA+0x4b in msacm32 (0x3f6d88fb) 4 0x0057dea5 in sjphone (+0x17dea5) (0x0057dea5) 5 0x00000000 (0x00000000) 6 0x005781e0 in sjphone (+0x1781e0) (0x005781e0) 0x3f6dbd50: movl %eax,0x0(%edx,%esi,8) Modules: Module Address Debug info Name (131 modules) PE 0x00400000-0085e000 Export sjphone PE 0x10000000-10006000 Deferred mozctlx ELF 0x20000000-20015000 Deferred ld-linux.so.2 ELF 0x20015000-2002f000 Deferred libwine.so.1 ELF 0x2002f000-20040000 Deferred libpthread.so.0 ELF 0x20040000-20149000 Deferred libc.so.6 ELF 0x20149000-2014c000 Deferred libdl.so.2 ELF 0x2014c000-20169000 Deferred iphlpapi<elf> \-PE 0x20150000-20169000 \ iphlpapi ELF 0x20169000-201af000 Deferred rpcrt4<elf> \-PE 0x20180000-201af000 \ rpcrt4 ELF 0x201af000-20257000 Deferred comctl32<elf> \-PE 0x201c0000-20257000 \ comctl32 ELF 0x20257000-202e3000 Deferred oleaut32<elf> \-PE 0x20270000-202e3000 \ oleaut32 ELF 0x202e3000-202fb000 Deferred version<elf> \-PE 0x202f0000-202fb000 \ version ELF 0x202fb000-20374000 Deferred winex11<elf> \-PE 0x20310000-20374000 \ winex11 ELF 0x20374000-2037a000 Deferred libxxf86dga.so.1 ELF 0x2037a000-20380000 Deferred libxxf86vm.so.1 ELF 0x20380000-20390000 Deferred libxext.so.6 ELF 0x20390000-20393000 Deferred xlcdef.so.2 ELF 0x20393000-203af000 Deferred imm32<elf> \-PE 0x203a0000-203af000 \ imm32 ELF 0x203af000-203b9000 Deferred libxcursor.so.1 ELF 0x203b9000-203ce000 Deferred midimap<elf> \-PE 0x203c0000-203ce000 \ midimap ELF 0x203ce000-203fa000 Deferred libssl.so.0.9.6 ELF 0x203fa000-204b0000 Deferred libcrypto.so.0.9.6 ELF 0x205c0000-205d9000 Deferred rasapi32<elf> \-PE 0x205d0000-205d9000 \ rasapi32 ELF 0x206e9000-20717000 Deferred shdocvw<elf> \-PE 0x20700000-20717000 \ shdocvw PE 0x20720000-20750000 Deferred mozctl PE 0x20750000-207af000 Deferred xpcom PE 0x207b0000-207ce000 Deferred embedcomponents PE 0x207d0000-207dd000 Deferred mozz PE 0x207e0000-207e7000 Deferred xpcom_compat_c PE 0x207f0000-20800000 Deferred chrome PE 0x20800000-2081a000 Deferred rdf PE 0x20820000-20854000 Deferred gkparser PE 0x20860000-20888000 Deferred docshell PE 0x20890000-208a7000 Deferred gkgfx PE 0x209c0000-209cf000 Deferred gsm332 ELF 0x24326000-2433a000 Deferred lz32<elf> \-PE 0x24330000-2433a000 \ lz32 ELF 0x24969000-24999000 Deferred uxtheme<elf> \-PE 0x24970000-24999000 \ uxtheme ELF 0x2542a000-25447000 Deferred mpr<elf> \-PE 0x25430000-25447000 \ mpr ELF 0x28146000-2815d000 Deferred msacm<elf> \-PE 0x28150000-2815d000 \ msacm ELF 0x28bf6000-28c26000 Deferred dmusic<elf> \-PE 0x28c10000-28c26000 \ dmusic PE 0x30000000-30026000 Deferred nspr4 ELF 0x338f8000-33911000 Deferred wsock32<elf> \-PE 0x33900000-33911000 \ wsock32 PE 0x38450000-38460000 Deferred caps PE 0x38900000-3890a000 Deferred jar50 ELF 0x3b28f000-3b297000 Deferred libxrender.so.1 PE 0x3ca40000-3ca61000 Deferred imglib2 PE 0x3cd00000-3cf50000 Deferred gklayout ELF 0x3d9dd000-3d9f6000 Deferred oledlg<elf> \-PE 0x3d9e0000-3d9f6000 \ oledlg ELF 0x3de7a000-3deba000 Deferred wininet<elf> \-PE 0x3de80000-3deba000 \ wininet ELF 0x3e5a7000-3e5bb000 Deferred olepro32<elf> \-PE 0x3e5b0000-3e5bb000 \ olepro32 ELF 0x3e65f000-3e6b3000 Deferred shlwapi<elf> \-PE 0x3e670000-3e6b3000 \ shlwapi ELF 0x3f6c4000-3f6e5000 Export msacm32<elf> \-PE 0x3f6d0000-3f6e5000 \ msacm32 ELF 0x3f879000-3f89b000 Deferred libm.so.6 ELF 0x3f94d000-3fa43000 Deferred libwine_unicode.so.1 ELF 0x3fefe000-3ff86000 Deferred ole32<elf> \-PE 0x3ff10000-3ff86000 \ ole32 ELF 0x43323000-43327000 Deferred libxrandr.so ELF 0x43347000-4334a000 Deferred iso8859-2.so ELF 0x44b24000-44b67000 Deferred wineoss<elf> \-PE 0x44b30000-44b67000 \ wineoss PE 0x45ea0000-45f5a000 Deferred uconv ELF 0x46a3c000-46a45000 Deferred libgcc_s.so.1 ELF 0x4a078000-4a0a0000 Deferred winspool<elf> \-PE 0x4a080000-4a0a0000 \ winspool ELF 0x4ae7a000-4aed7000 Deferred msvcrt<elf> \-PE 0x4ae90000-4aed7000 \ msvcrt ELF 0x4b474000-4b4ae000 Deferred advapi32<elf> \-PE 0x4b480000-4b4ae000 \ advapi32 ELF 0x4c9a7000-4caba000 Deferred user32<elf> \-PE 0x4c9c0000-4caba000 \ user32 PE 0x59bf0000-59c1f000 Deferred xpc3250 PE 0x5aa60000-5aa7e000 Deferred gkwidget PE 0x5edd0000-5eddd000 Deferred xppref32 ELF 0x5f0b0000-5f0b9000 Deferred libnss_files.so.2 PE 0x5f920000-5f928000 Deferred pipboot ELF 0x605d2000-605ed000 Deferred libcups.so.2 PE 0x60f80000-60fa4000 Deferred gkgfxwin PE 0x61130000-61184000 Deferred js3250 ELF 0x61f10000-61f80000 Deferred libfreetype.so.6 PE 0x62eb0000-62ebf000 Deferred profile PE 0x64000000-6402e000 Deferred i18n ELF 0x6594e000-65998000 Deferred dsound<elf> \-PE 0x65960000-65998000 \ dsound PE 0x69540000-69554000 Deferred xpcom_compat PE 0x69ca0000-69ca6000 Deferred embed_lite ELF 0x6a642000-6a6bf000 Deferred libgl.so.1 ELF 0x6a86c000-6a8ea000 Deferred winmm<elf> \-PE 0x6a880000-6a8ea000 \ winmm ELF 0x6ccbc000-6ccc5000 Deferred libsm.so.6 ELF 0x6ccca000-6cce1000 Deferred libice.so.6 ELF 0x6cd7d000-6ce47000 Deferred libx11.so.6 ELF 0x6d252000-6d26e000 Deferred ximcp.so.2 ELF 0x6f831000-6f8ef000 Deferred shell32<elf> \-PE 0x6f850000-6f8ef000 \ shell32 ELF 0x72245000-722d7000 Deferred comdlg32<elf> \-PE 0x72250000-722d7000 \ comdlg32 PE 0x73fb0000-73fb7000 Deferred plc4 PE 0x747b0000-747b6000 Deferred plds4 PE 0x75b70000-75be1000 Deferred necko ELF 0x767a6000-7682a000 Deferred gdi32<elf> \-PE 0x767c0000-7682a000 \ gdi32 PE 0x780c0000-78121000 Deferred msvcp60 PE 0x78ca0000-78cad000 Deferred webbrwsr ELF 0x7b26c000-7b294000 Deferred ws2_32<elf> \-PE 0x7b270000-7b294000 \ ws2_32 ELF 0x7b800000-7b8f7000 Deferred kernel32<elf> \-PE 0x7b820000-7b8f7000 \ kernel32 ELF 0x7bc00000-7bc73000 Deferred ntdll<elf> \-PE 0x7bc10000-7bc73000 \ ntdll ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Program Files\SJLabs\SJphone\SJphone.exe 00000010 0 0000000f 0 0000000e 0 0000000b 0 00000009 0 <== WineDbg terminated on pid 0x8

1 0

Re: shell32: Add the right SHFileOperation flags to fix some failing test on windows
by Mike McCormack Jan. 16, 2006

Jan. 16, 2006

James Hawkins wrote: > Changelog: > * Add the right SHFileOperation flags to fix some failing tests on windows. > * Add a newline to the end of the file to avoid a warning. > > dlls/shell32/tests/shlfileop.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) This causes a number of MessageBoxes to appear during the tests for me: "OverWrite File testdir2\test1.txt?" "OverWrite File testdir2\test2.txt?" "OverWrite File testdir2\test3.txt?" "OverWrite File testdir2\a.txt?" "OverWrite File testdir2\b.txt?" "OverWrite File testdir2\test4.txt\a.txt?" "OverWrite File testdir2\test1.txt?" "OverWrite File testdir2\test4.txt\a.txt?" "OverWrite File testdir2\a.txt?" Answering OK to each one lets the tests pass, but I don't think we want these tests to be interactive. Mike

1 0

Re: shell32: Reimplement a factored SHFileOperation [RESEND]
by Mike McCormack Jan. 16, 2006

Jan. 16, 2006

James Hawkins wrote: > This version initializes all memory so we don't crash when freeing the > file list, as spotted by Mike. I also corrected the return types from > int to HRESULT. > > Changelog: > * Reimplement a factored SHFileOperation. Hey James, Great work, but the tests still fail for me: make[1]: Entering directory `/home/mike/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:707: Test failed: Files and directories are moved to directory shlfileop.c:708: Test failed: The file is moved shlfileop.c:709: Test failed: The directory is moved shlfileop.c:710: Test failed: The file in subdirectory is moved Mike

1 0

Debugging a null pointer dereference
by Christer Palm Jan. 15, 2006

Jan. 15, 2006

Hi! I'm new to this list, but a long time Wine user and regular WWN reader. The other day I decided to try out Semiolog, a free as-in-beer piece of software to create labels from electric equipment manufacturer Hager, under wine. The software can be downloaded from here: http://www.hager.se/files/download/0/482_1/0/SemiologSue40a.exe Unfortunately it doesn't work. So although I haven't been doing any Windows programming in the last 15 years I decided to try to do something useful and try find out why it doesn't work. I figured that this application would be a good thing to try to get to work as it is supposedly rather trivial. So what follows is a description of a newbies attempt at some wine debugging: The application installs and starts up just fine, but when I try to create a new document, I get a null pointer dereference in mfc42.dll. After messing around with with the mfc42 runtime, I managed to get a backtrace with debugging information, which looks like this: =================================================================== wine: Unhandled page fault on read access to 0x0000003c at address 0x5f4056dd (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x0000003c in 32-bit code (0x5f4056dd). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' fixme:dbghelp:sffip_cb NIY on 'C:\hager\Semiolog\Apps\MFC42.PDB' fixme:dbghelp_msc:codeview_parse_type_table Not adding parameters' types to function signature fixme:dbghelp_msc:codeview_parse_type_table Unsupported type-id leaf a fixme:dbghelp_msc:dump 00000000: 06 00 0a 00 01 00 50 f1 ......P. fixme:dbghelp_msc:codeview_get_type Returning NULL symt for type-id 1053 [1000's of codeview_parse_type_table messages snipped] fixme:dbghelp_msc:codeview_snarf No current function for label $L101060 [1000's of codeview_snarf messages snipped] Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:5f4056dd ESP:7fc9d004 EBP:7fc9d0b8 EFLAGS:00010206( - 00 - RIP1) EAX:00000000 EBX:00000001 ECX:00000000 EDX:00000000 ESI:00449180 EDI:00000000 Stack dump: 0x7fc9d004: 004125f2 00000000 7ff38140 00000000 0x7fc9d014: 7ff38140 0042bb1f 00000000 00000001 0x7fc9d024: 004181b3 00000000 7ff38140 00030080 0x7fc9d034: 00418130 5f401e5c 00000001 7ff38140 0x7fc9d044: 00000000 7ff38140 7ff38140 7ff0f300 0x7fc9d054: 201cc2f0 7fc9d728 00000000 7fc9d0e8 0200: sel=1007 base=7ffdc000 limit=00001fff 32-bit rw- Backtrace: =>1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42 (0x5f4056dd) 2 0x5f401b2c CDC::RectVisible+0x3(lpRect=0x5f401ab5) [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:647] in mfc42 (0x5f401b2c) 3 0x5f401ab5 CGdiObject::~CGdiObject+0x32 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:281] in mfc42 (0x5f401ab5) 4 0x5f401a3d CMDIChildWnd::MDIDestroy+0x8 [E:\8168\vc98\mfc\mfc\include\afxwin2.inl:938] in mfc42 (0x5f401a3d) 5 0x5f4019fc AfxGetMainWnd+0x12 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:32] in mfc42 (0x5f4019fc) 6 0x62a6cb2a WINPROC_wrapper+0x1a in user32 (0x62a6cb2a) 7 0x62a6d419 in user32 (+0x9d419) (0x62a6d419) 8 0x62a7336e CallWindowProcW+0x122 in user32 (0x62a7336e) 9 0x62a3ba2e in user32 (+0x6ba2e) (0x62a3ba2e) 10 0x62a3f8c2 SendMessageTimeoutW+0x186 in user32 (0x62a3f8c2) 11 0x62a3f91f SendMessageW+0x50 in user32 (0x62a3f91f) 12 0x62a2d1be in user32 (+0x5d1be) (0x62a2d1be) 13 0x62a2e4f7 DefMDIChildProcW+0x36e in user32 (0x62a2e4f7) 14 0x62a2e801 DefMDIChildProcA+0xf2 in user32 (0x62a2e801) 15 0x5f413511 COleControl::GetMetafileData+0x87(lpFormatEtc=0x22, lpStgMedium=0x0, hAttribDC=0x22, cy=0x0, hMF=0x22) [ctlcore.cpp:827] in mfc42 (0x5f413511) 16 0x5f401ab5 CGdiObject::~CGdiObject+0x32 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:281] in mfc42 (0x5f401ab5) 17 0x5f401a3d CMDIChildWnd::MDIDestroy+0x8 [E:\8168\vc98\mfc\mfc\include\afxwin2.inl:938] in mfc42 (0x5f401a3d) 18 0x5f4019fc AfxGetMainWnd+0x12 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:32] in mfc42 (0x5f4019fc) 19 0x62a6cb2a WINPROC_wrapper+0x1a in user32 (0x62a6cb2a) 20 0x62a6d419 in user32 (+0x9d419) (0x62a6d419) 21 0x62a70f2d CallWindowProcA+0x1b5 in user32 (0x62a70f2d) 22 0x62a3b99f in user32 (+0x6b99f) (0x62a3b99f) 23 0x62a3f674 SendMessageTimeoutA+0x226 in user32 (0x62a3f674) 24 0x62a3f72f SendMessageA+0x50 in user32 (0x62a3f72f) 25 0x59a9462e X11DRV_SetWindowPos+0xf33 in winex11 (0x59a9462e) 26 0x62a6bbe3 SetWindowPos+0xb1 in user32 (0x62a6bbe3) 27 0x62a6c63a BringWindowToTop+0x4d in user32 (0x62a6c63a) 28 0x5f408ae3 COleControlContainer::CreateControl+0x31(pWndCtrl=0x0, clsid=0x0, lpszWindowName=0x0, dwStyle=0x1, ppt=0x0, psize=0x7ff11458, nID=0x10026, pPersist=0x0, bStorage=0x0, bstrLicKey=0x62a086dc, ppNewSite=0x0) [occcont.cpp:175] in mfc42 (0x5f408ae3) 29 0x00000001 (0x00000001) 30 0x00418d70 in semiolog (+0x18d70) (0x00418d70) 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42: movl 0x3c(%ecx),%eax Unable to open file 'oleverb.cpp' Modules: Module Address Debug info Name (83 modules) ELF 0x00165000-00272000 Deferred libcrypto.so.5 [boring load map snipped] Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\hager\Semiolog\Apps\Semiolog.exe 00000009 0 <== WineDbg terminated on pid 0x8 =================================================================== Now, I'm stuck with a couple of problems. 1. Looking at the first couple of lines in the backtrace, I can't really get it to make sense when I compare it to the MFC source code, i.e., I can't see how CDC::RectVisible() would end up calling ~CEnumOleVerb(), etc. 2. I can't get it to run under winedbg. Running "winedbg --auto Semiolog" causes winedbg to croak with the following output before the app even starts: WineDbg starting on pid 0xa In 32 bit mode. 0x00345c6e: movl %edi,0x0(%esp) Modules: Module Address Debug info Name (80 modules) ELF 0x00165000-00272000 Deferred libcrypto.so.5 ELF 0x00165000-00272000 Deferred libcrypto.so.5 PE 0x00240000-00269000 Deferred dzip32 PE 0x00270000-00288000 Deferred mpr ELF 0x0028a000-002a2000 Deferred libgssapi_krb5.so.2 PE 0x00290000-002b7000 Deferred dunzip32 ELF 0x002c5000-002e9000 Deferred libk5crypto.so.3 ELF 0x002c5000-002e9000 Deferred libk5crypto.so.3 ELF 0x002c5000-002e9000 Deferred libk5crypto.so.3 PE 0x002f0000-003ea000 Export kernel32 PE 0x002f0000-003ea000 Export kernel32 PE 0x002f0000-003ea000 Export kernel32 PE 0x00400000-004c3000 Deferred semiolog ELF 0x004c3000-00558000 Deferred gdi32<elf> \-PE 0x004d0000-00558000 \ gdi32 ELF 0x0055e000-0057a000 Deferred ld-linux.so.2 ELF 0x0057a000-005a6000 Deferred winspool<elf> \-PE 0x00580000-005a6000 \ winspool ELF 0x0057a000-005a6000 Deferred winspool<elf> \-PE 0x00580000-005a6000 \ winspool ELF 0x0057c000-006a5000 Deferred libc.so.6 PE 0x005b0000-005c3000 Deferred common PE 0x005d0000-005e6000 Deferred listctrlex ELF 0x00614000-0067a000 Deferred msvcrt<elf> \-PE 0x00620000-0067a000 \ msvcrt ELF 0x006a7000-006cc000 Deferred libm.so.6 ELF 0x006ce000-006d2000 Deferred libdl.so.2 ELF 0x006d2000-0080e000 Deferred user32<elf> \-PE 0x006d4000-006e7000 \ libz.so.1 \-PE 0x006e9000-007bd000 \ libx11.so.6 \-PE 0x006f0000-0080e000 \ user32 ELF 0x00826000-0082c000 Deferred libxxf86dga.so.1 ELF 0x0084a000-00859000 Deferred libxext.so.6 ELF 0x0084a000-00859000 Deferred libxext.so.6 PE 0x00860000-0086f000 Deferred iphlpapi ELF 0x0086f000-0088e000 Deferred ximcp.so.2 ELF 0x00899000-008ab000 Deferred libpthread.so.0 ELF 0x008ab000-00946000 Deferred comdlg32<elf> \-PE 0x008b3000-008d2000 \ libexpat.so.0 \-PE 0x008c0000-00946000 \ comdlg32 \-PE 0x008c0000-00946000 \ comdlg32 \-PE 0x008c0000-00946000 \ comdlg32 ELF 0x0093e000-00968000 Deferred libfontconfig.so.1 PE 0x00960000-00a19000 Deferred shell32 PE 0x00960000-00a19000 Deferred shell32 ELF 0x00a1d000-00a21000 Deferred libxrandr.so.2 ELF 0x00a2d000-00a38000 Deferred libnss_files.so.2 ELF 0x00a38000-00a55000 Deferred imm32<elf> \-PE 0x00a40000-00a55000 \ imm32 ELF 0x00a55000-00a88000 Deferred uxtheme<elf> \-PE 0x00a60000-00a88000 \ uxtheme ELF 0x00a95000-00ad8000 Deferred advapi32<elf> \-PE 0x00aa0000-00ad8000 \ advapi32 ELF 0x00b1a000-00c10000 Deferred libwine_unicode.so.1 ELF 0x00b36000-00bb1000 Deferred libgl.so.1 ELF 0x00b81000-00b9f000 Deferred libcups.so.2 ELF 0x00c10000-00ca9000 Deferred ole32<elf> \-PE 0x00c20000-00ca9000 \ ole32 ELF 0x00cb8000-00d18000 Deferred shlwapi<elf> \-PE 0x00cd0000-00d18000 \ shlwapi ELF 0x00d18000-00d61000 Deferred rpcrt4<elf> \-PE 0x00d1c000-00d26000 \ libxcursor.so.1 \-PE 0x00d28000-00d60000 \ libssl.so.5 \-PE 0x00d30000-00d61000 \ rpcrt4 ELF 0x00d61000-00e29000 Deferred comctl32<elf> \-PE 0x00d70000-00e29000 \ comctl32 \-PE 0x00d70000-00e29000 \ comctl32 \-PE 0x00d70000-00e29000 \ comctl32 \-PE 0x00d70000-00e29000 \ comctl32 ELF 0x00e67000-00ee5000 Deferred ntdll<elf> \-PE 0x00e80000-00ee5000 \ ntdll ELF 0x00ee5000-00f83000 Deferred oleaut32<elf> \-PE 0x00f00000-00f83000 \ oleaut32 ELF 0x00feb000-01073000 Deferred winex11<elf> \-PE 0x01000000-01073000 \ winex11 ELF 0x068a4000-06916000 Deferred libkrb5.so.3 ELF 0x06c20000-06c25000 Deferred libxxf86vm.so.1 PE 0x10000000-1000b000 Deferred hcore PE 0x5f400000-5f4f2000 Deferred mfc42 ELF 0x5fa38000-5fc15000 Deferred i915_dri.so ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000000a (D) C:\hager\Semiolog\Apps\Semiolog.exe 0000000b 0 <== WineDbg terminated on pid 0xa wine client error:b: write: Bad file descriptor [100's of Bad file descriptor errors just like the one above] wine client error:b: err:seh:setup_exception stack overflow 292 bytes in thread 000b eip 0014bb0e esp 7fb80edc stack 0x7fb81000-0x7fc90000 Any clues? Cheers, -- Christer Palm

2 2

Re: Static control [10/10]: Support the Windows XP mode of the static control
by Filip Navara Jan. 15, 2006

Jan. 15, 2006

Michael Kaufmann wrote: > Changelog: > - Detect if the image of the current process has a manifest. If yes, > enable some Windows XP-specific features (as described in MSDN) > - Destruction of the control window: Destroy bitmaps loaded at control > creation time (removed a resource leak) > - Always stretch bitmaps and icons to the whole client area > - Windows XP mode: Different bitmap background, different icon > background. > - Add some notes This doesn't seem right. User32 shouldn't be checking manifests, I would expect the STATIC control to be subclassed in COMCTL32 and the WinXP functionality implemented there. - Filip

2 2

winehq on osx-intel?
by Bob Hunter Jan. 15, 2006

Jan. 15, 2006

Hello, There are winehq binaries for unix except osx unix, being apple mac os. As Apple shifted to intel cpu, winehq has one more platform to go. The old VirtualPC by connectix was purchased by microsoft, and there are no news about its conversion to the new platform. Further, no one really wants to run an emulation of the windows desktop. Are there any plans to extend winehq to osx, possibly for a fee? I would be happy to pay for a copy. Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Problem with older wgl patch
by Tim Savannah Jan. 15, 2006

Jan. 15, 2006

On the newest wine, trying to start opengl programs such as World of Warcraft yields an error such as this: trace:opengl:wine_glCullFace (1029) trace:opengl:wine_glMatrixMode (5889) trace:opengl:wine_glLoadMatrixf (0x7fbafbb8) trace:opengl:wglMakeCurrent (0x368,0x7fd7b7d0) trace:opengl:create_glxpixmap return 1800054 trace:opengl:wglMakeCurrent make current for dis 0x7c01baf8, drawable 0x1800054, ctx 0x7c1c01d8 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 13 (X_GLXCreateGLXPixmap) Serial number of failed request: 412 Current serial number in output stream: 413 I don't know enough about wgl to offer any suggestions to the problem, other than the source seems to be this patch: http://cvs.winehq.org/cvsweb/wine/dlls/opengl32/wgl.c.diff?r1=1.71&r2=1.72&… Reverting that patch and adding + DWORD type = GetObjectType(hdc); where that patch placed it in the file allows opengl to work again.

4 3

Re: user: Implement scrolling in popup menus
by Phil Krylov Jan. 15, 2006

Jan. 15, 2006

Hi, Anything wrong with that patch? (Yes I know that separate arrow bitmaps should be used instead of the scrollbar ones. But I can't draw ;) On Sat, 7 Jan 2006 16:54:15 +0300 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > ChangeLog: > > Added scrolling support to popup menus which don't fit on the desktop. -- Ph.

1 0

Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
by Dan Kegel Jan. 15, 2006

Jan. 15, 2006

The Mozilla ActiveX control download feature is cool and all, but until we repackage the sucker to include MSVCP60.DLL to fix http://bugs.winehq.org/show_bug.cgi?id=4064 it's going to leave a lot of users scratching their heads as to why it keeps asking where its files are. I could have sworn I saw somebody post a note saying they had done said repackaging, but I can't find it now... Can somebody take care of this? It's kind of important. I would, but I'm zooming around getting my CS 130 project going, preparing a couple talks for Scale 4x, chasing after my two year old, and trying to hold down my day job... For the curious, my slids for the cs130 kickoff talk are up at http://kegel.com/wine/sweng/cs130/ I chose "add a feature to riched20.dll " as the basic task the students will be trying to carry out. No idea yet how it'll work out. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 5

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
by Filip Navara Jan. 15, 2006

Jan. 15, 2006

1 0

Re: winetest: Only test d3d9 if it is being built.
by H. Verbeet Jan. 15, 2006

Jan. 15, 2006

On 23/12/05, Yuval Fledel <yuvalfl(a)gmail.com> wrote: > winetest: Only test d3d9 if it is being built. > > -- Yuval Fledel > > diff --git a/programs/winetest/Makefile.in b/programs/winetest/Makefile.in > index 4208b94..8602f66 100644 > --- a/programs/winetest/Makefile.in > +++ b/programs/winetest/Makefile.in > @@ -19,14 +19,15 @@ RC_BINSRC = winetest.rc > RC_BINARIES = wine.ico > > XFILES = ddraw_test.exe$(DLLEXT) > +OPENGLFILES = d3d9_test.exe$(DLLEXT) > > TESTBINS = \ > @XFILES@ \ > + @OPENGLFILES@ \ > advpack_test.exe$(DLLEXT) \ > advapi32_test.exe$(DLLEXT) \ > comctl32_test.exe$(DLLEXT) \ > crypt32_test.exe$(DLLEXT) \ > - d3d9_test.exe$(DLLEXT) \ > dinput_test.exe$(DLLEXT) \ > dsound_test.exe$(DLLEXT) \ > gdi32_test.exe$(DLLEXT) \ Would this prevent the tests from getting built on Windows?

1 0

re: Regression in ntdll/virtual.c
by Dan Kegel Jan. 14, 2006

Jan. 14, 2006

>I mentioned that the setup program of AstroWorld will not work any longer >since a few days. Regression testing resulted in the change of >ntdll/virtual.c between 3.1.06 and 4.1.06. I didn't find any related entry >in wine.patches... Ah, but did you look in the archives of the wine-cvs mailing list? A little google search for the longest line of that change turned up: http://www.winehq.org/pipermail/wine-cvs/2006-January/020072.html - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

IWineD3DSurface::GetDC
by Stefan Dösinger Jan. 14, 2006

Jan. 14, 2006

Hello, I am trying to implement the GetDC method for wine d3d surfaces, as it is used by much d3d7 apps to load the textures. I took the code from ddraw/surface_dib.c and modified it, but I am stuck with a heap corruption. Basically, what I am doing is: 1) Lock the surface 2) Create a DIB section with DIB_CreateDIBSection. Use the currentDesc. {Width / Height} as the dimension and bytesPerPixel * 8 for the bitcount. The memory for the DC is the pBits returned from LockRect() 3) Create a DC, and attach it to the dib section 4) Set the palette, if necessary. In ReleaseDC I release the DC, destroy the DIB section and unlock the surface. Looks nice so far, but it doesn't work. I get a heap corruption eighter when using the DC or when deleting it. An example winedbg output: err:d3d_surface:IWineD3DSurfaceImpl_GetDC (0x7fd8fb08)->(0x7fbafd94): This does not work yet trace:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x7fd8fb08) : rect@(nil) flags(00000000), output lockedRect(a)0x7fbaf4a8, memory@(nil) trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Locked Rect (0x7fd8fb78) = l 0, t 0, r 640, b 480 trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Locking non-power 2 texture trace:d3d_surface:IWineD3DSurfaceImpl_LockRect locking an ordinarary surface trace:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x7fd8fb08) Locking rect trace:d3d_surface:IWineD3DSurfaceImpl_AddDirtyRect (0x7fd8fb08) : Dirty?1, Rect:(0,0,640,480) trace:d3d_surface:IWineD3DSurfaceImpl_GetContainer (0x7fd8fb08) : Relaying to queryInterface 0x7fbaf3fc (nil) trace:d3d_surface:IWineD3DSurfaceImpl_GetContainer (0x7fd8fb08) : Relaying to queryInterface 0x7fbaf454 0xb7effbda trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Surface is standalone, no need to dirty the container trace:d3d_surface:IWineD3DSurfaceImpl_LockRect returning memory(a)0x7dfa0020, pitch(4096) dirtyfied(1) trace:d3d_surface:IWineD3DSurfaceImpl_GetDC Creating dip section 640x480x32. memory at 0x7dfa0020 is 2097152 bytes of size trace:d3d_surface:IWineD3DSurfaceImpl_GetDC returning 0x278 trace:d3d_surface:IWineD3DSurfaceImpl_ReleaseDC (0x7fd8fb08)->(0x278) trace:d3d_surface:IWineD3DSurfaceImpl_ReleaseDC Selecting the object DC First chance exception: page fault on read access to 0x7dfa0000 in 32-bit code (0x7ff99374). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7ff99374 ESP:7fbaf714 EBP:7fbaf718 EFLAGS:00010206( - 00 - RIP1) EAX:7fce0000 EBX:7ffd5540 ECX:7e5c0250 EDX:7dfa0000 ESI:7e5c0248 EDI:7fce0040 Stack dump: 0x7fbaf714: 00000030 7fbaf754 7ff99c0b 7fce0000 0x7fbaf724: 7e5c0248 7f712cd0 00000000 00004f4c 0x7fbaf734: 7ff99294 7fd8fee8 7e5c0248 7ff8dffa 0x7fbaf744: 7f6edf2b 7ffd5540 00000030 00000030 0x7fbaf754: 7fbaf798 7ff9a954 7fce0000 00000030 0x7fbaf764: 7fbaf788 7f70253b 0000027c 00004f4c Backtrace: =>1 0x7ff99374 HEAP_FindSubHeap+0x14(heap=0x7fce0000, ptr=0x7e5c0248) [heap.c:375] in ntdll (0x7ff99374) 2 0x7ff99c0b HEAP_FindFreeBlock+0x7b(heap=0x7fce0000, size=0x30, ppSubHeap=0x7fbaf788) [/usr/src/wine-wined3d/dlls/ntdll/heap.c:390] in ntdll (0x7ff99c0b) 3 0x7ff9a954 RtlAllocateHeap(heap=0x7fce0000, flags=0x2, size=0x30) [/usr/src/wine-wined3d/dlls/ntdll/heap.c:1163] in ntdll (0x7ff9a954) q 4 0x7f263905 X11DRV_GetRegionData+0x55(hrgn=0x27c, hdc_lptodp=0x0) [/usr/src/wine-wined3d/dlls/x11drv/../../include/winbase.h:2250] in winex11 (0x7f263905) 5 0x7f263aa6 X11DRV_SetDeviceClipping+0x56(physDev=0x7fd8fe68, vis_rgn=0x280, clip_rgn=0x0) [/usr/src/wine-wined3d/dlls/x11drv/clipping.c:118] in winex11 (0x7f263aa6) 6 0x7f6c6a1e CLIPPING_UpdateGCRegion+0xae(dc=0x7e1a0028) [clipping.c:80] in gdi32 (0x7f6c6a1e) 7 0x7f6c84fa DC_InitDC+0x9a(dc=0x7e1a0028) [/usr/src/wine-wined3d/dlls/gdi/dc.c:205] in gdi32 (0x7f6c84fa) 8 0x7f6c5c06 BITMAP_SelectObject(handle=0x6c, obj=0x7fce5d20, hdc=0x278) [/usr/src/wine-wined3d/dlls/gdi/bitmap.c:568] in gdi32 (0x7f6c5c06) 9 0x7f6eea05 SelectObject(hdc=0x278, hObj=0x6c) [/usr/src/wine-wined3d/dlls/gdi/gdiobj.c:1164] in gdi32 (0x7f6eea05) 10 0x7f5ecd10 IWineD3DSurfaceImpl_ReleaseDC+0x50(iface=0x7fd8fb08, hDC=0x278) [/usr/src/wine-wined3d/dlls/wined3d/surface.c:1068] in wined3d (0x7f5ecd10) q 11 0x7fa7e0e8 IDirectDrawSurfaceImpl_ReleaseDC+0x38(iface=0x7fd8fa48, hdc=0x278) [/usr/src/wine-wined3d/dlls/ddraw/surface.c:472] in ddraw (0x7fa7e0e8) 12 0x7fbd5fe6 main in ddrawex (0x7fbd5fe6) 13 0x7fbd63a7 __wine_spec_exe_entry(peb=0x7ffdf540) [exe_entry.c:37] in ddrawex (0x7fbd63a7) 14 0x7fc490a0 start_process(arg=0x0) [/usr/src/wine-wined3d/dlls/kernel/process.c:1027] in kernel32 (0x7fc490a0) 15 0xb7f020fb wine_switch_to_stack+0x17 in libwine.so.1 (0xb7f020fb) 0x7ff99374 HEAP_FindSubHeap+0x14 [heap.c:375] in ntdll: movl 0x0(%edx),%ecx Unable to open file 'heap.c' Wine-dbg> I am lost here, can someone help me? Can this code work at all? I've attached my copy of dlls/wined3d/surface.c, so you can see the code(Watch out, it won't compile as such in the CVS tree). The dib member of WineD3DSurface is taken from ddraw: typedef struct wineD3DSurface_DIB { HBITMAP DIBsection; void* bitmap_data; HGDIOBJ holdbitmap; BOOL client_memory; DWORD d3d_data[4]; /* room for Direct3D driver data */ } wineD3DSurface_DIB; Stefan

1 0

Re: x11drv: Allow WM to manage more windows.
by Dmitry Timoshkov Jan. 14, 2006

Jan. 14, 2006

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > @@ -67,6 +67,8 @@ static const char visual_id_prop[] = > inline static BOOL is_window_managed( HWND hwnd ) > { > DWORD style, ex_style; > + char class_name[7]; > + static const char menu_class[] = "#32768"; > + /* menu windows are not managed */ > + if (GetClassNameA(hwnd, class_name, sizeof(class_name)) && > + !memcmp(class_name, menu_class, sizeof(menu_class))) > + return FALSE; This won't work for subclassed or custom (OfficeXP like) menus. -- Dmitry.

2 1

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX
by Aric Cyr Jan. 14, 2006

Jan. 14, 2006

Hi all, Just wanted to chime in with a status update on my porting of wined3d to WGL. Basically, I am in the debug phase, and at this point most bugs have been ironed out. That is, for dx9 stuff. I soon ran into problems/regressions with dx8 or lower (including ddraw!). So I ended up repeating the (almost) exactly same work for d3d8 and ddraw... not a pretty sight, and a pain to debug them all. As a result this conversion has become a fairly large and invasive change affecting all versions of directx... [I can't wait for all these to be completely ported to wined3d]. For testing d3d8 I've been using 3DMark2001SE and some DirectX tutorial/demo apps. For d3d9 I use World of Warcraft (hehe) and more tutorial/demo apps. I forget what I used for d3d7 though... I'll have to double check that. Most of the problems I've come across were GLXContext related... namely due to a problem in wine's wgl which causes an app to think there is a current context, when infact there isn't. (See wglGetCurrentContext in wgl.c, and see what happens when there is no glX context, especially between calls to wglCreateContext and wglMakeCurrent). Another change I made which I'm not sure about and would like feedback for, is to change wgl's process_attach to use wgl functions instead of glX functions. The reason for this is so that the GLXContext that is created will be properly added to the context list so it can be used for other purposes. This should reduce the number of GL contexts by one for all d3d and (behaved) opengl apps. I'm currently in the process of cleaning everything up and then I will post a patch on my site for people to download. Due to the scope of the changes, I really hope that people can help me test this sucker... once that's done I'll chop up the patch into logical pieces and submit them. That's all for now! - Aric P.S. If anyone wants, they can edit http://winehq.org/site/fun_projects and put me down for the "wined3d use wgl" project.

6 10

Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
by Dan Kegel Jan. 14, 2006

Jan. 14, 2006

Rob wrote: >This very much looks like a use-after-free bug. The first two >instructions are probably a COM *_Release call. Judging by the fact that >this is a regression I would also guess that it is a Wine object. This sounds like a job for valgrind! But, er, does valgrind still work with wine? Rob said it did in March: http://www.winehq.com/hypermail/wine-devel/2005/03/0397.html It was too hard for one guy back in July: http://www.winehq.com/hypermail/wine-devel/2005/07/0401.html but that was probably because he didn't see Rob's message from March. Maybe we need to put better instructions on how to use Valgrind with Wine on winehq.org... or, dare I suggest it, bundle valgrind with Wine so anybody could easily use it be setting WINEDEBUG=+valgrind or something like that... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Fwd: Bug 4289: Debugging and dissasembly
by James Trotter Jan. 14, 2006

Jan. 14, 2006

---------- Forwarded message ---------- From: James Trotter <james.trotter(a)gmail.com> Date: Jan 14, 2006 3:22 PM Subject: Re: Bug 4289: Debugging and dissasembly To: Eric Pouech <eric.pouech(a)wanadoo.fr> On 1/14/06, Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: > > James Trotter wrote: > > Hi! > > > > A few days ago I filed this bug: > http://bugs.winehq.org/show_bug.cgi?id=4289 > > > > Alexandre commented that there most likely was some stack corruption, > > and that I should try and disassemble a few instructions before the > > crash and look for API calls. > > > > Now, I haven't used gdb or winedbg that much before, and I'm a bit > > uncertain what to do. I understand that using the disassemble > > [<addr>][,<addr>] command, the debugger will disassemble that address > > space. Given the stack trace as in the bug report, which addresses, > > exactly, should I disassemble? > before 0x007ab8f1 > A+ > > > -- > Eric Pouech > > Sure, but how much before 0x007ab8f1? For instance, Is this helpful? WineDbg starting on pid 0xa In 32 bit mode. 0x7fcfba16 start_process+0xb6 [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/kernel/process.c:996] in kernel32: pushl %edi 996 ExitProcess( entry( peb ) ); Wine-dbg>cont First chance exception: page fault on read access to 0x20202020 in 32-bit code (0x007ab8f1). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:007ab8f1 ESP:7facaba4 EBP:00000000 EFLAGS:00210246( - 00 -RIZP1) EAX:20202020 EBX:00000001 ECX:7facb450 EDX:00000000 ESI:7facb328 EDI:7beb4460 Stack dump: 0x7facaba4: 20202020 00002711 00000000 7facb328 0x7facabb4: 7facabe0 007aaf30 7facb218 7facaf60 0x7facabc4: 00000000 00002711 40c38800 7facb328 0x7facabd4: 7facac90 0084566a 00000007 7fd0e900 0x7facabe4: 0078e3ca 00000000 7facaf60 00400000 0x7facabf4: 7fd39206 7facaf60 00000000 7fd39206 0200: sel=1007 base=b7f81000 limit=00001f97 32-bit rw- Backtrace: =>1 0x007ab8f1 in iwd2 (+0x3ab8f1) (0x00000000) 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg>disassemble 0x007ab800, 0x007ab8f1 0x007ab800: addb %bh,0x0(%ebx) 0x007ab802: int $0x74 0x007ab804: pop %ss 0x007ab805: cmpl %ebx,0x390(%ecx) 0x007ab80b: jz 0x007ab81c 0x007ab80d: addl $0x394,%ecx 0x007ab813: pushl %ecx 0x007ab814: call *%edi 0x007ab816: movl 0x008cf6d8,%ecx 0x007ab81c: movl 0x13c(%esi),%eax 0x007ab822: cmpl %ebp,%eax 0x007ab824: jz 0x007ab838 0x007ab826: movl 0x0(%eax),%ecx 0x007ab828: pushl %eax 0x007ab829: call *0x8(%ecx) 0x007ab82c: movl %ebp,0x13c(%esi) 0x007ab832: movl 0x008cf6d8,%ecx 0x007ab838: cmpl %ebp,%ecx 0x007ab83a: jz 0x007ab84d 0x007ab83c: cmpl %ebx,0x390(%ecx) 0x007ab842: jz 0x007ab84d 0x007ab844: addl $0x394,%ecx 0x007ab84a: pushl %ecx 0x007ab84b: call *%edi 0x007ab84d: leal 0x128(%esi),%ecx 0x007ab853: call 0x007c22d0 0x007ab858: movl %ebp,0x140(%esi) 0x007ab85e: movl 0x008cf6d8,%eax 0x007ab863: cmpl %ebp,%eax 0x007ab865: jz 0x007ab87b 0x007ab867: cmpl %ebx,0x390(%eax) 0x007ab86d: jz 0x007ab87b 0x007ab86f: addl $916,%eax 0x007ab874: pushl %eax 0x007ab875: call *0x8472c8 -> 0x7beb4180 RtlLeaveCriticalSection [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/ntdll/critsection.c:407] in ntdll 0x007ab87b: cmpl %ebp,0x90(%esi) 0x007ab881: jz 0x007ab8a4 0x007ab883: leal 0x84(%esi),%edi 0x007ab889: movl %edi,%ecx 0x007ab88b: call 0x007fbe77 0x007ab890: cmpl %ebp,%eax 0x007ab892: jz 0x007ab89c 0x007ab894: movl 0x0(%eax),%edx 0x007ab896: pushl %ebx 0x007ab897: movl %eax,%ecx 0x007ab899: call *0x4(%edx) 0x007ab89c: cmpl %ebp,0x90(%esi) 0x007ab8a2: jnz 0x007ab889 0x007ab8a4: cmpl %ebp,0xac(%esi) 0x007ab8aa: jz 0x007ab8d8 0x007ab8ac: leal 0xa0(%esi),%ebx 0x007ab8b2: movl %ebx,%ecx 0x007ab8b4: call 0x007fbe77 0x007ab8b9: movl %eax,%edi 0x007ab8bb: movl 0x58(%edi),%eax 0x007ab8be: cmpl %ebp,%eax 0x007ab8c0: jz 0x007ab8cb 0x007ab8c2: movl 0x0(%eax),%ecx 0x007ab8c4: pushl %eax 0x007ab8c5: call *0x8(%ecx) 0x007ab8c8: movl %ebp,0x58(%edi) 0x007ab8cb: cmpl %ebp,0xac(%esi) 0x007ab8d1: jnz 0x007ab8b2 0x007ab8d3: movl $0x1,%ebx 0x007ab8d8: cmpl %ebp,0x4(%esi) 0x007ab8db: jz 0x007ab8f9 0x007ab8dd: movl 0x8(%esi),%eax 0x007ab8e0: cmpl %ebp,%eax 0x007ab8e2: jz 0x007ab8ed 0x007ab8e4: movl 0x0(%eax),%edx 0x007ab8e6: pushl %eax 0x007ab8e7: call *0x8(%edx) 0x007ab8ea: movl %ebp,0x8(%esi) 0x007ab8ed: movl 0x4(%esi),%eax 0x007ab8f0: pushl %eax 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg> Thanks, James

2 3

Re: RFC: implementation of driver functionality in msacm (RESEND)
by Alex Villacís Lasso Jan. 14, 2006

Jan. 14, 2006

Eric Pouech wrote: > Alex Villacís Lasso wrote: > >> Eric Pouech wrote: >> >>>> * Implementation of broadcasts to notification windows on driver >>>> add/remove, enabling/disabling, and priority changes >>> >>> >>> >>> - MSDN seems to state that differed notification is actually a >>> counter, not a simple boolean (whereas enable/disable is a boolean) >> >> >> >> I have just read the MSDN web page, and I see no remark that suggests >> that deferred notification should behave as a counter instead of a >> simple on/off flag. Or maybe I am reading the page incorrectly... > > well... > ACM_DRIVERPRIORITYF_END Calling task wants to reenable change > notification broadcasts. An application must call acmDriverPriority > with ACM_DRIVERPRIORITYF_END for each successful call with the > ACM_DRIVERPRIORITYF_BEGIN flag. Note that hadid must be NULL, > dwPriority must be zero, and only the ACM_DRIVERPRIORITYF_END flag can > be set. > ... then I need new glasses :-) >> >>>> * Fix for implementation quirks of acmDriverMessage() in order to >>>> allow native codecs to display configuration dialogs >>> >>> >>> >>> this seems rather hackish. did you actually tested this on Windows ? >>> Moreover, the size bits look especially suspicious. Where did you >>> get the 16 value from ? >> >> >> >> I tested the native msacm32.dll from Windows 98 SE on Wine, and it >> reported a 16-byte struct size to the winemp3 codec. > > how do you know it's a 16 byte struct? there's nothing in the passed > information that tells you it's 16 bytes AFAICS Yes, there is: (begin MSDN quote) DRV_CONFIGURE Directs the installable driver to display its configuration dialog box and let the user specify new settings for the given installable driver instance. *Parameters* /dwDriverId/ Identifier of the installable driver. This is the same value previously returned by the driver from the *DRV_OPEN* <http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drv_open.asp> message. /hdrvr/ Handle of the installable driver instance. /lParam1/ Handle of the parent window. This window is used as the parent window for the configuration dialog box. /lParam2/ Address of a *DRVCONFIGINFO* <http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drvconfiginfo_s…> structure or NULL. If the structure is given, it contains the names of the registry key and value associated with the driver. DRVCONFIGINFO Contains the registry key and value names associated with the installable driver. |typedef struct tagDRVCONFIGINFO { DWORD dwDCISize; LPCWSTR lpszDCISectionName; LPCWSTR lpszDCIAliasName; } DRVCONFIGINFO; | *Members* *dwDCISize* Size of the structure, in bytes. *lpszDCISectionName* Address of a null-terminated, wide-character string specifying the name of the registry key associated with the driver. *lpszDCIAliasName* Address of a null-terminated, wide-character string specifying the name of the registry value associated with the driver. (end MSDN quote) I examined the DRVCONFIGINFO structure prepared by native msacm32.dll to codecs, in particular the dwDCISize field. Even when the sum of all fields in the structure declaration yields 12 bytes, dwDCISize holds a value of 16 when supplied by native msacm32.dll. So, I used the same value in order to mimic native as close as possible. Alex Villacís Lasso

2 1

Bug 4289: Debugging and dissasembly
by James Trotter Jan. 14, 2006

Jan. 14, 2006

Hi! A few days ago I filed this bug: http://bugs.winehq.org/show_bug.cgi?id=4289 Alexandre commented that there most likely was some stack corruption, and that I should try and disassemble a few instructions before the crash and look for API calls. Now, I haven't used gdb or winedbg that much before, and I'm a bit uncertain what to do. I understand that using the disassemble [<addr>][,<addr>] command, the debugger will disassemble that address space. Given the stack trace as in the bug report, which addresses, exactly, should I disassemble? Thanks, James

1 0

RFC: pch support
by Steven Edwards Jan. 13, 2006

Jan. 13, 2006

Hi, Alexandre did not like the needed changes required to add support for this but I figured I would throw it out for debate anyway in case anyone else can make him change his mind (duck). The issue is he does not like needing a single header per-program or per dll. After doing some research it seems to me that even MSVC does not support multiple PCH files per project so I don't know how it could be fixed in gcc to do it Microsoft has not figured it out. problem: ccache works great for speeding up compiles but seems to still have issue with some header changes. Also the ReactOS guys really want to add pch support to the Wine dlls that are shared so the job falls to me to sell it to Wine. Solution: Below are the benchmarks from my box and a patch. Simply patch your tree and then ./configure and cd to the regedit folder and do a 'time make','make clean','make pch', and 'time make' if you want to see the speedup on your box. I expect we could get a 2x speedup in fresh compiles of Wine with pch support Regedit compile without pch real 0m5.632s user 0m5.000s sys 0m0.524s Regedit compile with pch real 0m2.797s user 0m2.352s sys 0m0.428s -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

8 12

FAQ outdated in one point
by CS Jan. 13, 2006

Jan. 13, 2006

In the FAQ you write under "2.12. When will Wine be finished?": "Right now we are working on releasing Wine 0.9 our schedule has this release around September 30th 2005." maybe that should be updated or removed altogether so there don't need to be updates to this entry in the future. sorry that I can't do more to contribute :-) clem

2 1

re: richedit's RTF writer writes only 8 kBi
by Dan Kegel Jan. 13, 2006

Jan. 13, 2006

In June '05, Tobias Burnus complained in http://www.winehq.com/hypermail/wine-devel/2005/06/0536.html that there seemed to be an 8kB size limit on rich text output from richedit... but nobody replied to his message. Tobias, did you ever resolve that problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Regression in ntdll/virtual.c
by Markus G�mmel Jan. 13, 2006

Jan. 13, 2006

I mentioned that the setup program of AstroWorld will not work any longer since a few days. Regression testing resulted in the change of ntdll/virtual.c between 3.1.06 and 4.1.06. I didn't find any related entry in wine.patches, so here is the diff result: 37a38 > #include <sys/stat.h> 837a839 > struct stat st; 859a862,866 > if (fstat( fd, &st ) == -1) > { > status = FILE_GetNtStatus(); > goto error; > } 860a868 > if (header_size > st.st_size) goto error; 999c1007,1009 < if (map_file_into_view( view, fd, sec->VirtualAddress, file_size, sec->PointerToRawData, --- > end = sec->PointerToRawData + file_size; > if (sec->PointerToRawData >= st.st_size || end > st.st_size || end < > sec->PointerToRawData || > map_file_into_view( view, fd, sec->VirtualAddress, file_size, > sec->PointerToRawData, The program can be downloaded for free at http://www.astroworld.de/ger/. Simply select "AW2001 v.6.2 (English)" in the first selection box and press "Download Demo". With the new version of aw61eng.exe it stuck somewhere at 22% with an error message like "~TMD61.tmp" is not a Win32 binary". With the old version the setup run ok. Thanks and regards Markus Gömmel m.goemmel(a)compulab.de

1 0

Re: winspool: updated some traces for bug 4268
by Huw D M Davies Jan. 13, 2006

Jan. 13, 2006

On Fri, Jan 13, 2006 at 03:51:36PM +0100, Detlef Riekenberg wrote: > Changelog: > > - winspool: updated some traces for bug 4268 > > > -- > By By ... > ... Detlef > diff --git a/dlls/winspool/info.c b/dlls/winspool/info.c > index 9b1771d..a4caa39 100644 > --- a/dlls/winspool/info.c > +++ b/dlls/winspool/info.c > @@ -247,13 +247,16 @@ static BOOL CUPS_LoadPrinters(void) > HKEY hkeyPrinter, hkeyPrinters, hkey; > > cupshandle = wine_dlopen(SONAME_LIBCUPS, RTLD_NOW, NULL, 0); > + TRACE("%p: CUPS loaded (%s)\n", cupshandle, SONAME_LIBCUPS); > if (!cupshandle) > return FALSE; > - TRACE("loaded %s\n", SONAME_LIBCUPS); That's a very confusing TRACE. If wine_dlopen fails then why not print out something like "CUPS not loaded" ? > @@ -439,6 +442,8 @@ PRINTCAP_LoadPrinters(void) { > BOOL had_bash = FALSE; > > f = fopen("/etc/printcap","r"); > + TRACE("%p: using /etc/printcap\n", f); > + > if (!f) > return FALSE; > The same applies to this too. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Linuxtag 2006
by Uwe Bonnes Jan. 13, 2006

Jan. 13, 2006

Hallo, has anybody interest in activly participating in a Wine booth in Linuxtag 2006 (http://www.linuxtag.org/2006/de/home/cfpro.html) in Wiesbaden from May 3 to May 6? Please let me know. Projects should have applied before Feb. 3. 2006. If needed, I can provide a place to sleep here in my flat in Darmstadt. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by James Hawkins Jan. 13, 2006

Jan. 13, 2006

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement LaunchINFSection on top of DoInfInstall > I'm afraid this implementation isn't correct. DoInfInstall calls SetupInstallFromInfSection which only concerns the Install section of an INF file. SetupInstallFromInfSection and consequently DoInfInstall cannot provide enough functionality for LaunchINFSection/Ex. LaunchINFSection/Ex also takes into acount reg and file saves (see Reg/FileSaveRestore), per user sections (see SetPerUserSecValues), registering ocx's, extracting cabinets, and a whole mush of other intricacies. LaunchINFSection/Ex basically combines all the other functions of advpack into a monstrosity of functionality. I'm working my way towards fully implementing LaunchINFSection/Ex, but I've got to finish the lower levels first, so if you'd like to help in this direction, take a look at the stubs I've mentioned in advpack. I appreciate your effort in this implementation, but it will do more harm than good because we'll have to take it out when it comes time to fully implement LaunchINFSection. -- James Hawkins

2 2

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by Markus Amsler Jan. 13, 2006

Jan. 13, 2006

James, I just saw your advpack patches. Only patch 4 (* Add stubs for the file save/restore functions), Makefile.in gets a merge conflict with mine first 1 (Move inf install functions to install.c ). The rest applies fine (some offset warnings), and builds without warning. Should I rediff against yours or you against mine? Is there a better way to coordinate our efforts? My LaunchINFSectionEx patch seems to improve bug 3636. Markus

1 0

New wannabe developer
by Dan Kegel Jan. 13, 2006

Jan. 13, 2006

Zoe wrote: > Hi, I've got nothing better to do at the moment so I was wondering what > the best way to help move things forwards and contribute back to the > project. :-) Glad to meet you :-) I have a page that might help: http://kegel.com/wine/sweng/ Hope it helps. Let me know if there's anything unclear there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: Alexandre Julliard : server: Don't round up the header size for image mappings.
by Michael Jung Jan. 13, 2006

Jan. 13, 2006

Hi, On Wednesday 11 January 2006 21:34, Alexandre Julliard wrote: > http://source.winehq.org/git/?p=wine.git;a=commit;h=b54e9e94e98624acde1bb00 > e10c2055dfed9c2d7 > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Jan 11 20:59:26 2006 +0100 > > server: Don't round up the header size for image mappings. This patch prevents certain executables (at least those generated with Borland C++ 5.02) from being loaded. I've attached a small example. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0