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

Crash while starting Corel Draw 11
by Roland Kaeser Jan. 4, 2007

Jan. 4, 2007

Hello I just trying to install (and run) Corel Draw 11 on wine 0.9.28 (self compiled) on SuSE 10.2. It requires some native dlls just to start. Can somebody give me a hint about it. It crashed with every windows version set (98-XP). Native Dlls I used: ole32*.dll msv*.dll(msvcrt.dll/msvcrt20,msvcrt40,msvcirt) Roland err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=0,scanCode=0,keycode=8,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=0,scanCode=0,keycode=8,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FEF9 (Pointer_EnableKeys) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=90,scanCode=45,keycode=4D,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE03 (ISO_Level3_Shift) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=E1,scanCode=60,keycode=71,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE03 (ISO_Level3_Shift) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=E1,scanCode=60,keycode=71,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE03 (ISO_Level3_Shift) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=E9,scanCode=64,keycode=7C,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE03 (ISO_Level3_Shift) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=E9,scanCode=64,keycode=7C,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=FC,scanCode=0,keycode=0,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=FC,scanCode=0,keycode=0,state=1) err:x11drv:X11DRV_CreateWindow invalid window height -25 err:x11drv:X11DRV_CreateWindow invalid window height -25 fixme:ole:CoRegisterMessageFilter message filter has been registered, but will not be used fixme:mmio:MMIO_InstallIOProc Global procedures not implemented fixme:wintab32:X11DRV_WTInfoA WTI_INTERFACE unhandled index 7 wine: Unhandled page fault on write access to 0x007d204e at address 0x253447a7 (thread 0058), starting debug ger... Unhandled exception: page fault on write access to 0x007d204e in 32-bit code (0x253447a7). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:253447a7 ESP:0033ef28 EBP:0033f4ac EFLAGS:00210206( - 00 - RIP1) EAX:00000c00 EBX:007d204e ECX:00000000 EDX:00000001 ESI:011d3848 EDI:00c348a0 Stack dump: 0x0033ef28: 00000001 011d3810 0000000d 7efb0aee 0x0033ef38: 00000064 7eb2dff4 0033ef60 7eb2dff4 0x0033ef48: fffffff4 b7e05ff4 0033ef98 00000001 0x0033ef58: 0033ef74 b7d04dbd 00000000 00000000 0x0033ef68: 0033efb4 7ee82ff4 0033f064 0033f044 0x0033ef78: 7ee5b338 0033ef98 00000001 4d430002 Backtrace: =>1 0x253447a7 in crlutl110 (+0x647a7) (0x0033f4ac) 2 0x20be7fe0 in coreldrw110 (+0x227fe0) (0x0033ff08) 3 0x7ee49198 start_process+0xe3() in kernel32 (0x0033ffe8) 4 0xb7e54e93 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x253447a7: movl %eax,0x0(%ebx) Modules: Module Address Debug info Name (221 modules) PE 350000-374000 Deferred fn3api PE 400000-411000 Deferred coreldrw PE 950000-9bd000 Deferred iuiintl PE ad0000-b18000 Deferred kodakcms PE 1180000-1191000 Deferred threeptcurvetool110 PE 4470000-4501000 Deferred dao350 PE 10000000-1015f000 Deferred cdrrip110 PE 209c0000-2138d000 Export coreldrw110 PE 214e0000-21d3a000 Deferred drawintl PE 22ac0000-22ee5000 Deferred cdrcore110 PE 23830000-23acb000 Deferred cdrprnintl110 PE 23af0000-23ced000 Deferred cdrprn110 PE 23d50000-23f23000 Deferred cdrtra110 PE 244d0000-24619000 Deferred drwbasetoolcore110 PE 24680000-247c3000 Deferred cdrtxt110 PE 24ab0000-24bb4000 Deferred crlfrmwk110 PE 24d30000-24e04000 Deferred crlfom110 PE 24f60000-25025000 Deferred crlcui110 PE 25120000-251c7000 Deferred drwextrudetool110 PE 25200000-252a5000 Deferred crlctl110 PE 252e0000-25388000 Export crlutl110 PE 25510000-25595000 Deferred crlfomui110 PE 25720000-257a2000 Deferred crlcuiintl110 PE 257d0000-25851000 Deferred cdrtxtui110 PE 25870000-258f0000 Deferred crliui110 PE 25920000-2599e000 Deferred crlfx110 PE 25cb0000-25d1c000 Deferred crlcmnres110 PE 25dd0000-25e32000 Deferred drwfilltool110 PE 25ec0000-25f20000 Deferred crlclr110 PE 25fb0000-26005000 Deferred drwblendtool110 PE 26090000-260e2000 Deferred cdrflt110 PE 26380000-263c9000 Deferred cdrfnt110 PE 26500000-26544000 Deferred drwcontourtool110 PE 265c0000-26602000 Deferred drwartisticmediatool110 PE 266d0000-2670d000 Deferred drwenvpersptool110 PE 26770000-267a9000 Deferred drwtransparencytool110 PE 267c0000-267f8000 Deferred crllshape110 PE 26900000-26933000 Deferred drwdropshadowtool110 PE 26950000-26984000 Deferred drwzoompantool110 PE 26a40000-26a72000 Deferred drwdimensiontool110 PE 26b00000-26b30000 Deferred crlfxcontrols110 PE 26bc0000-26bec000 Deferred cdrsty110 PE 26c00000-26c2c000 Deferred drwdistortiontool110 PE 26c40000-26c6a000 Deferred drwerasertool110 PE 26cc0000-26ce8000 Deferred drwbezierfreehandtoolcore110.dl PE 26d00000-26d29000 Deferred cdrpdfui110 PE 26d80000-26da7000 Deferred drwpicktool110 PE 26e00000-26e28000 Deferred crlfrmwkintl110 PE 26e40000-26e68000 Deferred crlfxintl PE 26e80000-26ea6000 Deferred drwliveshapetool110 PE 26fa0000-26fc4000 Deferred drwpolygontool110 PE 27000000-27022000 Deferred cdrcpr110 PE 27030000-27052000 Deferred cdrpdfintl110 PE 27060000-27081000 Deferred drwrectangletool110 PE 270c0000-270e1000 Deferred crlweb110 PE 27150000-27171000 Deferred smudgetool110 PE 271a0000-271c0000 Deferred symboltool110 PE 271d0000-271f0000 Deferred cdrcrv110 PE 27230000-2724f000 Deferred drwroughentool110 PE 27290000-272af000 Deferred drwmeshfilltool110 PE 272c0000-272de000 Deferred drwellipsetool110 PE 272f0000-2730f000 Deferred crlutlintl110 PE 27320000-2733e000 Deferred drwfilltoolcore110 PE 27380000-2739d000 Deferred drwspiraltool110 PE 273b0000-273cc000 Deferred drweyedroppertool110 PE 27410000-2742c000 Deferred drwoutlinetool110 PE 27440000-2745b000 Deferred drwconnectortool110 PE 27470000-2748a000 Deferred drwnodeedittool110 PE 274a0000-274ba000 Deferred drwartisticmediatoolcore110 PE 274d0000-274ea000 Deferred threeptellipsetool110 PE 27500000-2751a000 Deferred crlinet PE 27530000-27547000 Deferred drwblendtoolcore110 PE 27550000-27567000 Deferred drwnodeedittoolcore110 PE 27590000-275a7000 Deferred drwfhtransformtool110 PE 27610000-27624000 Deferred drwgraphpapertool110 PE 27630000-27643000 Deferred drwknifetool110 PE 27670000-27683000 Deferred drwbrushtoolcore110 PE 27690000-276a4000 Deferred cdrtxtintl110 PE 276b0000-276c2000 Deferred threeptrecttool110 PE 276f0000-27701000 Deferred drwfreehandtool110 PE 27730000-27742000 Deferred pentool110 PE 27770000-27782000 Deferred cdrpdfcmp110 PE 277d0000-277e1000 Deferred polylinetool110 PE 27860000-2786e000 Deferred crli18n110 PE 278c0000-278cd000 Deferred cdrautosense110 PE 278e0000-278ec000 Deferred drwbeziertool110 PE 27900000-2790d000 Deferred drwpicktoolcore110 PE 27940000-2794c000 Deferred drwconnectortoolcore110 PE 27950000-2795c000 Deferred crlppd110 PE 27970000-2797b000 Deferred drwtexttool110 PE 27980000-2798b000 Deferred drwtransparencytoolcore110 PE 279b0000-279ba000 Deferred drwpolygontoolcore110 PE 279c0000-279ca000 Deferred drwoutlinetoolcore110 PE 279d0000-279da000 Deferred cdrfntintl110 PE 279f0000-279fb000 Deferred crlctlintl110 PE 27a00000-27a0a000 Deferred drwdimensiontoolcore110 PE 27a30000-27a39000 Deferred drwmeshfilltoolcore110 PE 27a60000-27a69000 Deferred crltwain110 PE 27a70000-27a78000 Deferred drwspiraltoolcore110 PE 27aa0000-27aa8000 Deferred drweyedroppertoolcore110 PE 27ab0000-27ab8000 Deferred drwzoompantoolcore110 PE 27ac0000-27ac8000 Deferred crlclrintl110 PE 27ad0000-27ad7000 Deferred drwknifetoolcore110 PE 27ae0000-27ae7000 Deferred drwgraphpapertoolcore110 PE 27af0000-27af7000 Deferred drwrectangletoolcore110 PE 27b00000-27b07000 Deferred polylinetoolcore110 PE 27b10000-27b17000 Deferred drwliveshapetoolcore110 PE 27b20000-27b27000 Deferred drwerasertoolcore110 PE 27b30000-27b37000 Deferred drwellipsetoolcore110 PE 27b40000-27b47000 Deferred threepttoolcore110 PE 27b80000-27b86000 Deferred componentintl PE 27bc0000-27bc4000 Deferred crlfxcontrolsintl PE 61dc0000-61dce000 Deferred mfc42loc PE 73d30000-73e2e000 Deferred mfc42 PE 780a0000-780b6000 Deferred msvcirt PE 780c0000-78121000 Deferred msvcp60 ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7c150000-7c159000 Deferred libxi.so.6 ELF 7c159000-7c179000 Deferred wintab32<elf> \-PE 7c160000-7c179000 \ wintab32 ELF 7d5c3000-7d5ec000 Deferred msvcrt40<elf> \-PE 7d5d0000-7d5ec000 \ msvcrt40 ELF 7db41000-7db4a000 Deferred libkrb5support.so.0 ELF 7db4a000-7db4e000 Deferred libcom_err.so.2 ELF 7db4e000-7db74000 Deferred libk5crypto.so.3 ELF 7db74000-7dbf0000 Deferred libkrb5.so.3 ELF 7dbf0000-7dc08000 Deferred libsasl2.so.2 ELF 7dc08000-7dc31000 Deferred libgssapi_krb5.so.2 ELF 7dc31000-7dc3f000 Deferred liblber-2.3.so.0 ELF 7dc3f000-7dc77000 Deferred libldap-2.3.so.0 ELF 7dc77000-7dc96000 Deferred libnss_ldap.so.2 ELF 7dc96000-7dcac000 Deferred libnsl.so.1 ELF 7dcac000-7dcdf000 Deferred libcrypt.so.1 ELF 7dcdf000-7de12000 Deferred libcrypto.so.0.9.8 ELF 7de12000-7de4f000 Deferred libssl.so.0.9.8 ELF 7de4f000-7de7f000 Deferred libcups.so.2 ELF 7de91000-7dea9000 Deferred usp10<elf> \-PE 7dea0000-7dea9000 \ usp10 ELF 7deaa000-7dec1000 Deferred midimap<elf> \-PE 7deb0000-7dec1000 \ midimap ELF 7dee8000-7df01000 Deferred msacm32<elf> \-PE 7def0000-7df01000 \ msacm32 ELF 7df01000-7df41000 Deferred wineoss<elf> \-PE 7df10000-7df41000 \ wineoss ELF 7df61000-7df95000 Deferred uxtheme<elf> \-PE 7df70000-7df95000 \ uxtheme ELF 7e01c000-7e025000 Deferred libxrender.so.1 ELF 7e025000-7e142000 Deferred libx11.so.6 ELF 7e142000-7e151000 Deferred libxext.so.6 ELF 7e151000-7e16a000 Deferred libice.so.6 ELF 7e16a000-7e206000 Deferred winex11<elf> \-PE 7e180000-7e206000 \ winex11 ELF 7e310000-7e331000 Deferred libexpat.so.1 ELF 7e331000-7e35c000 Deferred libfontconfig.so.1 ELF 7e35c000-7e36f000 Deferred libz.so.1 ELF 7e36f000-7e3db000 Deferred libfreetype.so.6 ELF 7e3dc000-7e3e4000 Deferred libnss_compat.so.2 ELF 7e3e4000-7e3ee000 Deferred libnss_files.so.2 ELF 7e3f6000-7e3fc000 Deferred libxfixes.so.3 ELF 7e3fc000-7e406000 Deferred libxcursor.so.1 ELF 7e406000-7e41b000 Deferred olepro32<elf> \-PE 7e410000-7e41b000 \ olepro32 ELF 7e41b000-7e430000 Deferred lz32<elf> \-PE 7e420000-7e430000 \ lz32 ELF 7e430000-7e44a000 Deferred version<elf> \-PE 7e440000-7e44a000 \ version ELF 7e44a000-7e46c000 Deferred oledlg<elf> \-PE 7e450000-7e46c000 \ oledlg ELF 7e46c000-7e49b000 Deferred ws2_32<elf> \-PE 7e470000-7e49b000 \ ws2_32 ELF 7e49b000-7e4b6000 Deferred wsock32<elf> \-PE 7e4a0000-7e4b6000 \ wsock32 ELF 7e4b6000-7e4e9000 Deferred winspool<elf> \-PE 7e4c0000-7e4e9000 \ winspool ELF 7e4e9000-7e58a000 Deferred comdlg32<elf> \-PE 7e4f0000-7e58a000 \ comdlg32 ELF 7e58a000-7e629000 Deferred oleaut32<elf> \-PE 7e5a0000-7e629000 \ oleaut32 ELF 7e629000-7e649000 Deferred mpr<elf> \-PE 7e630000-7e649000 \ mpr ELF 7e649000-7e6d7000 Deferred winmm<elf> \-PE 7e650000-7e6d7000 \ winmm ELF 7e6d7000-7e7a9000 Deferred comctl32<elf> \-PE 7e6e0000-7e7a9000 \ comctl32 ELF 7e7a9000-7e802000 Deferred shlwapi<elf> \-PE 7e7c0000-7e802000 \ shlwapi ELF 7e802000-7e8f3000 Deferred shell32<elf> \-PE 7e810000-7e8f3000 \ shell32 ELF 7e8f3000-7e906000 Deferred libresolv.so.2 ELF 7e907000-7e90c000 Deferred libxrandr.so.2 ELF 7e90c000-7e910000 Deferred libxinerama.so.1 ELF 7e910000-7e914000 Deferred libxau.so.6 ELF 7e914000-7e931000 Deferred imm32<elf> \-PE 7e920000-7e931000 \ imm32 ELF 7e931000-7e950000 Deferred iphlpapi<elf> \-PE 7e940000-7e950000 \ iphlpapi ELF 7e950000-7e9a4000 Deferred rpcrt4<elf> \-PE 7e960000-7e9a4000 \ rpcrt4 ELF 7e9a4000-7ea40000 Deferred ole32<elf> \-PE 7e9b0000-7ea40000 \ ole32 ELF 7ea40000-7eb83000 Deferred user32<elf> \-PE 7ea60000-7eb83000 \ user32 ELF 7eb83000-7ebca000 Deferred advapi32<elf> \-PE 7eb90000-7ebca000 \ advapi32 ELF 7ebca000-7ec5e000 Deferred gdi32<elf> \-PE 7ebe0000-7ec5e000 \ gdi32 ELF 7ec5e000-7ecc5000 Deferred msvcrt<elf> \-PE 7ec70000-7ecc5000 \ msvcrt ELF 7edd7000-7eef4000 Export kernel32<elf> \-PE 7edf0000-7eef4000 \ kernel32 ELF 7ef29000-7ef4f000 Deferred libm.so.6 ELF 7ef51000-7ef5b000 Deferred libsm.so.6 ELF 7ef7a000-7f000000 Deferred ntdll<elf> \-PE 7ef90000-7f000000 \ ntdll ELF b7cd0000-b7cd6000 Deferred libxdmcp.so.6 ELF b7cd8000-b7cdc000 Deferred libdl.so.2 ELF b7cdc000-b7e0a000 Deferred libc.so.6 ELF b7e0a000-b7e22000 Deferred libpthread.so.0 ELF b7e25000-b7e2b000 Deferred libxxf86vm.so.1 ELF b7e4d000-b7f5f000 Export libwine.so.1 ELF b7f60000-b7f7d000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000057 (D) C:\Programme\Corel\Corel Graphics 11\Programs\CorelDrw.exe 0000004a 0 00000049 0 00000048 0 0000001c 0 0000001d 0 00000014 0 00000012 0 00000015 0 00000016 0 00000013 0 0000000f 0 0000000d 0 00000010 0 00000011 0 0000000e 0 0000000a 0 00000008 0 0000000b 0 0000000c 0 00000009 0 00000047 0 00000046 0 00000045 0 00000044 0 00000043 0 00000042 0 00000041 0 00000040 0 0000003f 0 0000003e 0 0000003d 0 0000003c 0 0000003b 0 0000003a 0 00000039 0 00000038 0 00000037 0 00000036 0 00000035 0 00000034 0 00000033 0 00000032 0 00000031 0 00000030 0 0000002f 0 0000002e 0 0000002d 0 0000002c 0 0000002b 0 0000002a 0 00000029 0 00000028 0 00000027 0 00000026 0 00000025 0 00000024 0 00000023 0 00000022 0 00000021 0 00000020 0 0000001f 0 00000067 0 00000066 0 00000065 0 00000064 0 00000063 0 00000062 0 00000061 0 00000060 0 0000005d 0 0000005e 0 0000001e 0 0000005b 0 0000005c 0 0000005a 0 00000059 0 00000058 0 <== 00000019 0000001b 0 0000001a 0 00000017 00000018 0 __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com

1 0

Re: Reinhard Karcher : user32: Speed improvement for 16bit comm support.
by Francois Gouget Jan. 4, 2007

Jan. 4, 2007

On Wed, 3 Jan 2007, Alexandre Julliard wrote: [...] > Commit: dff43b732b10e603f3aee38db2f684dc7404aa4e [...] > user32: Speed improvement for 16bit comm support. [...] > stol = (unsigned char *)COM[cid].unknown + COMM_MSR_OFFSET; > COMM_MSRUpdate( ptr->handle, stol ); > > - if (lpStat) { > - lpStat->status = 0; > - > + if (lpStat) { > + lpStat->status = 0; > SleepEx(1,TRUE); > > lpStat->cbOutQue = comm_outbuf(ptr); As far as I can see this patch only contains whitespace changes (and I'm not sure they are correct). How can it improve performance? Probably something got lost in the way... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

2 2

Re: [5/8] WineD3D: Readd the strided data trace
by Ivan Gyurdiev Jan. 4, 2007

Jan. 4, 2007

Stefan Dösinger wrote: > I removed that call accidentally in one of my former patches, but I > think it is still a good idea to trace the final strided sources used > by drawprim > You removed it from a d3d8 fixed function FVF-only codepath, and are adding it back into a shared codepath. That function doesn't work properly with vertex declarations, it will only work with FVFs, which have different strided layout. FVFs use fixed semantic index [u.s.position], vdecl asks the shader for an index [u.s.input[idx]]. Furthermore, the trace isn't needed for declarations, because they have their own (better) traces.

2 1

Re: [3/10] WineD3D: Move decoding the vertex declaration to the vertexshader state handler
by Ivan Gyurdiev Jan. 4, 2007

Jan. 4, 2007

> Regarding the concern of storing the decoded strided data after > finishing drawing: This is intentional, the decoded vertex declaration > will remain valid after the draw is finished and the arrays loaded. > Future draws can use it, if the state is not dirtified again. > This sounds like a good idea... > Wrt the upward references: When we have multithreading with multiple > contexts we will need a per-context tracking of most of the stuff we > have in the device now(last_was_rhw, ...). This structure does not > exist yet, and I do not see a point in passing the device impl to > every function when we can get it from the stateblock too. I still think this caching stuff needs to go into its own structure [ maybe device->cache or something like that ]. I can see how it's a bit different from the standard stateblock data, since it's just a cache, rather than something that's set/get by the application - cache state vs configured state. It's not so clear to me that this is all per-thread data - the strided streams are directly tied to the vertex declaration and stream data, which is in turn shared across threads as part of the stateblock. =========== Note: you just made drawPrimitiveTraceDataLocations into dead code. (previously called in d3d8 fixed function code path). I don't care much for this function, but please remove it if getting rid of its callers.

3 3

So, what apps require BITS?
by Dan Kegel Jan. 4, 2007

Jan. 4, 2007

Which apps require BITS? I'm collecting them as depending on bug http://bugs.winehq.org/show_bug.cgi?id=6194 So for I know of two, Visual C++ 2005, and Google Pack. There's also a third-party app which is just a file transfer front end on top of BITS; it's called WinBITS, and is at http://www.darvin.de/english/ I wonder if it's time to start implementing the parts of BITS that real apps use... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

automatic gecko download failing
by Bill Medland Jan. 4, 2007

Jan. 4, 2007

Is it obvious to anyone where the error is in this? (trace ole, urlmon and mshtml) trace:ole:DllMain 0x60550000 0x8 (nil) trace:ole:DllMain (0x60750000,8,(nil)) trace:ole:DllMain 0x60550000 0x1 0x1 trace:ole:DllMain (0x60750000,1,0x1) trace:ole:OleInitialize ((nil)) trace:ole:CoInitializeEx ((nil), 2) trace:ole:CoInitializeEx () - Initializing the COM libraries trace:ole:RunningObjectTableImpl_Initialize trace:ole:apartment_construct creating new apartment, model=2 trace:ole:apartment_construct Created apartment on OXID 800000009 trace:ole:apartment_get_or_create Created main-threaded apartment with OXID 800000009 trace:ole:OleInitialize () - Initializing the OLE libraries trace:ole:OLEClipbrd_Initialize () trace:ole:CoRegisterMessageFilter (0x16eb60, (nil)) trace:ole:CoLockObjectExternal pUnk=0x1898f2, fLock=TRUE, fLastUnlockReleases=FALSE trace:ole:get_stub_manager_from_object not found for object 0x1898f2 trace:ole:new_stub_manager Created new stub manager (oid=1) at 0x18a6c0 for object with IUnknown 0x1898f2 trace:ole:stub_manager_ext_addref added 1 refs to 0x18a6c0 (oid 1), rc is now 1 trace:ole:stub_manager_int_release after 1 trace:ole:RegisterDragDrop (0x1002e,0x1898f2) trace:ole:CoLockObjectExternal pUnk=0x189388, fLock=TRUE, fLastUnlockReleases=FALSE trace:ole:get_stub_manager_from_object not found for object 0x189388 trace:ole:new_stub_manager Created new stub manager (oid=2) at 0x190138 for object with IUnknown 0x189388 trace:ole:stub_manager_ext_addref added 1 refs to 0x190138 (oid 2), rc is now 1 trace:ole:stub_manager_int_release after 1 trace:ole:RegisterDragDrop (0x10040,0x189388) trace:ole:CoLockObjectExternal pUnk=0x18941c, fLock=TRUE, fLastUnlockReleases=FALSE trace:ole:get_stub_manager_from_object not found for object 0x18941c trace:ole:new_stub_manager Created new stub manager (oid=3) at 0x191268 for object with IUnknown 0x18941c trace:ole:stub_manager_ext_addref added 1 refs to 0x191268 (oid 3), rc is now 1 trace:ole:stub_manager_int_release after 1 trace:ole:RegisterDragDrop (0x10044,0x18941c) trace:ole:CoCreateInstance (rclsid= {25336920-03f9-11cf-8fd0-00aa00686f13}, pUnkOuter=(nil), dwClsContext=00000005, riid={00000000-0000-0000-c000-000000000046}, ppv=0x33f6b4) trace:ole:CoGetClassObject CLSID: {25336920-03f9-11cf-8fd0-00aa00686f13}, IID: {00000001-0000-0000-c000-000000000046} trace:ole:WINE_StringFromCLSID 0x44bb30- >{25336920-03F9-11CF-8FD0-00AA00686F13} trace:urlmon:DllMain 0x60e00000 0x8 (nil) trace:urlmon:DllMain 0x60e00000 0x1 (nil) trace:urlmon:CoInternetGetSession (0 0x33ed20 0) trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b9c {79eac9e7- baf9-11ce-8c82-00aa004ba90b} L"file" 0 (nil) 0) trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b94 {79eac9e3- baf9-11ce-8c82-00aa004ba90b} L"ftp" 0 (nil) 0) trace:urlmon:InternetSession_RegisterNameSpace (0x60e22b8c {79eac9e2- baf9-11ce-8c82-00aa004ba90b} L"http" 0 (nil) 0) trace:urlmon:InternetSession_Release () trace:ole:COMPOBJ_DLLList_Add trace:mshtml:DllGetClassObject (CLSID_HTMLDocument {00000001-0000-0000- c000-000000000046} 0x33f680) trace:mshtml:ClassFactory_AddRef (0x1957c0) ref = 1 trace:mshtml:HTMLDocument_Create ((nil) {00000000-0000-0000- c000-000000000046} 0x33f6b4) trace:mshtml:HTMLDocument_QueryInterface (0x195db8)->(IID_IUnknown, 0x33f6b4) trace:mshtml:HTMLDocument_AddRef (0x195db8) ref = 1 trace:mshtml:load_gecko () trace:mshtml:check_version unknown version trace:mshtml:load_xpcom (L"c:\\Program Files\\wine_gecko") warn:mshtml:load_xpcom Could not load XPCOM: 126 trace:mshtml:load_mozctl Could not find Mozilla ActiveX Control trace:mshtml:load_mozilla Could not open key L"Software\\mozilla.org\ \GRE" trace:ole:DllMain 0x60550000 0x2 (nil) trace:urlmon:CreateURLMoniker ((nil), L"http://source.winehq.org/winegecko.php", 0x7ed40a4c) trace:urlmon:URLMonikerImpl_Construct (0x1984d0, (null),L"http://source.winehq.org/winegecko.php") trace:urlmon:parse_canonicalize_url (L"http://source.winehq.org/winegecko.php" 00010000 0x1a9a98 2084 0x7ed409f0) trace:urlmon:parse_schema (L"http://source.winehq.org/winegecko.php" 00000000 0x7ed408f0 64 0x7ed408ec) warn:urlmon:CF_QueryInterface (0x60e22b8c)->({79eac9ec- baf9-11ce-8c82-00aa004ba90b},0x7ed408e8),not found trace:urlmon:CF_CreateInstance (0x60e22b8c)->((nil),{79eac9ec- baf9-11ce-8c82-00aa004ba90b},0x7ed408e8) trace:urlmon:HttpProtocol_Construct ((nil) 0x7ed408a8) warn:urlmon:HttpProtocol_QueryInterface not supported interface {79eac9ec-baf9-11ce-8c82-00aa004ba90b} (*** IInternetProtocolInfo ***) *** HUH ??? *** trace:urlmon:HttpProtocol_Release (0x1983f0) ref=0 trace:ole:__CLSIDFromString L"{79EAC9E2-BAF9-11CE-8C82-00AA004BA90B}" -> 0x7ed40810 trace:ole:CoGetClassObject CLSID: {79eac9e2-baf9-11ce-8c82-00aa004ba90b}, IID: {00000000-0000-0000-c000-000000000046} err:ole:CoGetClassObject apartment not initialised *** HUH ??? *** TIA Bill Medland

1 0

Re: wined3d: Make CreateFakeGLContext thread safe. [try 2]
by Robert Shearman Jan. 4, 2007

Jan. 4, 2007

Jan Zerebecki wrote: > > + LeaveCriticalSection(&wined3d_fake_gl_context_cs); > + LEAVE_GL(); > ... > LEAVE_GL(); > + LeaveCriticalSection(&wined3d_fake_gl_context_cs); > return FALSE; > } You can't lock or unlock in different orders as this will create subtle races that could result in deadlocks. -- Rob Shearman

1 0

compiling simple windows app
by xie jason Jan. 4, 2007

Jan. 4, 2007

hi all, I was trying to compile a simple windows application using winelib. it crashs and returns: err:seh:setup_exception stack overflow 12 bytes in thread 0009 eip 60169224 esp 00230ff4 stack 0x231000-0x340000 I first convert a .dll, which contains a simple add function (int add(int a, int b)) to be .dll.so. And then I compile a simple program which calls this function. I am able to compile it properly. but when i run it, it shows above error message. -----------------.h is ------------------------------ int __stdcall add(int a, int b); ----------------.c is---------------------------- HMODULE hDLL=0; /* DLL to call */ #ifdef __i386__ #define GET_THIS(t,p) t p;\ __asm__ __volatile__ ("movl %%ecx, %0" : "=m" (p)) #endif BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { TRACE("(0x%p, %ld, %p)\n",hinstDLL,fdwReason,lpvReserved); if (fdwReason == DLL_WINE_PREATTACH) return FALSE; /* prefer native version */ if (fdwReason == DLL_PROCESS_ATTACH) { hDLL = LoadLibraryA( "libjason.dll" ); printf("load dll\n"); TRACE(":Forwarding DLL (libJason.dll) loaded (%ld)\n",(LONG)hDLL); } else if (fdwReason == DLL_PROCESS_DETACH) { FreeLibrary( hDLL ); TRACE(":Forwarding DLL (libJason.dll) freed\n"); } return TRUE; } int add(int a, int b) { int (*pFunc)(int, int); int retVal; pFunc=(void*)GetProcAddress(hDLL,"vgMath"); TRACE("((int)%ld,(int)%ld): forward\n",(LONG)a,(LONG)b); retVal = pFunc(a,b); TRACE("Returned (%ld)\n",(LONG)retVal); return retVal; } ------------------------.spec is -------------------- 1 stdcall add( long long ) vgMath can any one help me? thanks Send instant messages to your online friends http://au.messenger.yahoo.com

2 1

Re: [2/2] WineD3D: Re-download dirty GL surfaces
by Stefan Dösinger Jan. 3, 2007

Jan. 3, 2007

Am 03.01.2007 um 02:48 schrieb Phil Costin: > This patch enables the forced re-downloading of dirty GL surfaces. > > It requires [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface > Download and is the first step toward supporting gamma-corrected > (sRGB) > texture sampling support. > > Thanks to Stefan Dösinger for his advice in IRC during the > implementation of > these 2 patches. > <surfacedownload.diff> > You will have to bind the surface's texture to gl to be able to download the surface. If the texture name in glDescription is 0 you don't have to download. Select a proper texture unit(e.g. 0) before binding and mark that sampler dirty to force drawprim to restore it later.

2 1

Re: [1/2] WineD3D: Mark GL Surface Clean after Fresh Surface Download
by Peter Oberndorfer Jan. 3, 2007

Jan. 3, 2007

On Wednesday 03 January 2007 02:48, Phil Costin wrote: > This patch resets the SFLAG_GLDIRTY flag for a surface once the GL surface > data has been refreshed in surface_download_data(). > > Thanks to Stefan Dösinger for his advice in IRC during the implementation of > these 2 patches. > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 031d320..5cb9bf6 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -142,6 +142,8 @@ static void surface_download_data(IWineD > } > } > } > + /* No longer dirty */ > + This->Flags &= SFLAG_GLDIRTY; I think there is a ~ missing here, else everything but the dirty flag will be cleared. > } > } Greetings Peter

2 1

Re: crtdll: Declare some variables static
by Marcus Meissner Jan. 3, 2007

Jan. 3, 2007

On Wed, Jan 03, 2007 at 03:45:28PM +0000, Andrew Talbot wrote: > Changelog: > crtdll: Declare some variables static. Err, why? They are clearly exported from the .spec file and you just killed the exports? They likely are used by Windows programs. Ciao, Marcus

3 3

Re: Oleview: correct representation of unions
by Francois Gouget Jan. 3, 2007

Jan. 3, 2007

On Thu, 28 Dec 2006, Konstantin Kondratyuk wrote: > Hello, > > this patch corrects representation of unions for old compilers (gcc 2.95) > For example: > (union).field - is not supported by gcc 2.95 > union.field - is supported This is strange. I compile Wine with gcc 2.95 weekly but never encountered this problem. Also note that the U(x) macro would need to be fixed in other places too (include/wine/test.h for instance). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

1 0

Re: [PATCH] [DbgHelp]: implemented 64 bit versions of EnumerateLoadedModules
by Alexandre Julliard Jan. 3, 2007

Jan. 3, 2007

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > +BOOL WINAPI EnumerateLoadedModulesW64(HANDLE hProcess, > + PENUMLOADED_MODULES_CALLBACKW64 E= > numLoadedModulesCallback, > + PVOID UserContext) > +{ > + struct enum_load_mod64_W64 x; > + > + x.cb =3D EnumLoadedModulesCallback; > + x.user =3D UserContext; > + > + return EnumerateLoadedModules64(hProcess, enum_load_mod64_W64, &x); You should make the A function call the W one, not the other way around. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Reinhard Karcher : user32: Speed improvement for 16bit comm support.
by Robert Shearman Jan. 3, 2007

Jan. 3, 2007

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: dff43b732b10e603f3aee38db2f684dc7404aa4e > URL: http://source.winehq.org/git/wine.git/?a=commit;h=dff43b732b10e603f3aee38db… > > Author: Reinhard Karcher <rkarcher(a)frey.de> > Date: Mon Jan 1 17:45:06 2007 +0100 > > user32: Speed improvement for 16bit comm support. > > --- > > dlls/user32/comm16.c | 5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/dlls/user32/comm16.c b/dlls/user32/comm16.c > index 9329c82..0164196 100644 > --- a/dlls/user32/comm16.c > +++ b/dlls/user32/comm16.c > @@ -719,9 +719,8 @@ INT16 WINAPI GetCommError16(INT16 cid,LP > stol = (unsigned char *)COM[cid].unknown + COMM_MSR_OFFSET; > COMM_MSRUpdate( ptr->handle, stol ); > > - if (lpStat) { > - lpStat->status = 0; > - > + if (lpStat) { > + lpStat->status = 0; > SleepEx(1,TRUE); > > lpStat->cbOutQue = comm_outbuf(ptr); This patch doesn't seem to do what it says it does. -- Rob Shearman

2 1

Re: wined3d: state_pointsprite should apply to all texture units
by Tomas Carnecky Jan. 3, 2007

Jan. 3, 2007

Chris Robinson wrote: > + for (i = 0; i < GL_LIMITS(texture_stages); i++) { > + /* Note the WINED3DRS value applies to all textures, but GL has one > + * per texture, so apply it now ready to be used! > + */ > + if (GL_SUPPORT(ARB_MULTITEXTURE)) { > + GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB + i)); > + checkGLcall("glActiveTextureARB"); > + } else if (i>0) { > + FIXME("Program using multiple concurrent textures which this opengl implementation doesn't support\n"); > + } I'd do that '} else if (i == 1) {', otherwise you'll print a whole lot FIXME's, and maybe add a 'break', since it doesn't make sense to call glTexEnvi() over and over for the same texture. tom

2 1

Re: wined3d: state_pointsprite should apply to all texture units
by H. Verbeet Jan. 3, 2007

Jan. 3, 2007

On 03/01/07, Chris Robinson <chris.kcat(a)gmail.com> wrote: > Updated with the change suggested by Tomas. > Does this work when there's no texture bound to the unit?

2 1

ppviewer.exe MSI failure (PowerPoint 2k3): HowTo assemble a lynch mob?
by Andreas Mohr Jan. 3, 2007

Jan. 3, 2007

Hi all, http://www.microsoft.com/downloads/details.aspx?familyid=428D5727-43AB-4F24… failed to install with some nice MSI failures when I tried it last week on a current Wine version (Ubuntu package 0.9.28, I think). Does that mean that I'm entitled to assemble a capable lynch mob for the guys who were supposed to fix any and all MSI installer issues at CodeWeavers? ;) IMHO ppviewer.exe is important since those people who receive some scripted PowerPoint file (yes, that's even some "games"!) won't have much luck with OpenOffice Impress, so they're fully dependant on getting ppviewer.exe to work. Andreas Mohr

4 4

Re: quartz: add implementations for AmpFactorToDB and DBToAmpFactor
by Roderick Colenbrander Jan. 3, 2007

Jan. 3, 2007

Hi, Why are you using a lookup table and not just a log10(x) and 10^(x) for the gain <-> dB conversions? That's how it should be done I think like 10x corresponding to 20dB (assuming signal gain). In your tests it is just: 2000*log10(gain) - 9630 for going to that dB-like scale. Regards, Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

3 2

Re: Uniscribe improvements
by Hans Leidekker Jan. 3, 2007

Jan. 3, 2007

On Tuesday 02 January 2007 19:42, * * wrote: > StringAnalysis should have a cache object, not save the HDC directly. I agree, although you shouldn't free the cache in ScriptStringFree, the caller is responsible for that. > One of the important things about the cache, which wine currently > doesn't do, is that the caller is free to select a different font into > the HDC after calling ScriptStringAnalyse and Uniscribe is supposed to > use the right one. Yes, cache handling is still very basic. If the font changes the cache should be invalidated. It also needs to be ref counted and locked. -Hans

3 4

What to do about apps that require 256-color mode?
by Dan Kegel Jan. 3, 2007

Jan. 3, 2007

My son got a cd-rom game for xmas, so of course I tried it in Wine. It installs fine, but the app just hangs unless you started X with -depth 8. (And even then the colors are all wrong, but that's a different problem.) X's randr extension was originally going to allow switching screen resolutions, but they pulled that feature (see http://keithp.com/~keithp/talks/randr/protocol.txt ) So what's Wine to do? Can we somehow tell Wine to emulate 256 color mode for particular apps? That seems to be what the X folks want us to do, guessing by the randr paper. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 3

RFC: Patch better support for DevMode
by Nick Burns Jan. 2, 2007

Jan. 2, 2007

After looking at the behavior on xp and wine for EnumDisplaySettingsA and EnumDisplaySettingsW before and after a window has been created (I wrote a little program to dump the devmodes), I noticed that the devmode structs that wine gives back are lacking some fields. Attached is a patch that fills out the devmode structs out quite a bit more (similar to how XP does it). This does not fix the issue that when you do not create a window you get different behavior if you have an emulated desktop (i would like soem help with this part). Also attached is log_dev_pfd.zi_ -- it is a zip file (sorry about this but the log files are too big) ogl_fullscreen.cpp: source for the app that I used to test EnumDisplaySettings{A,W} wine_log_dev_pfd.txt: wine log from app (using an emulated desktop) nv34_log_dev_pfd.txt: log from nv34 using xp driver rv250_log_dev_pfd.txt: log from rv250 using xp driver I would like some help with the behavior difference before and after window creation (visible in wine_log_dev_pfd.txt -- the fullscreen modes that are supported should not change) And would like any comments on the patch Also -- I would like to get the correct driver names in there and not just -- desktop/NoRes - Nick

1 1

Re: atl: Declare some items static
by Robert Shearman Jan. 2, 2007

Jan. 2, 2007

Andrew Talbot wrote: > -HRESULT WINAPI AtlModuleLoadTypeLib(_ATL_MODULEW *pM, LPCOLESTR lpszIndex, > - BSTR *pbstrPath, ITypeLib **ppTypeLib) > +static HRESULT WINAPI AtlModuleLoadTypeLib(_ATL_MODULEW *pM, LPCOLESTR lpszIndex, > + BSTR *pbstrPath, ITypeLib **ppTypeLib) > Did you try compiling & linking this? WINAPI is usually only applied to exported functions. -- Rob Shearman

2 1

Re: systray icon questions
by Kirill K. Smirnov Jan. 2, 2007

Jan. 2, 2007

> Unfortunately, yes. The way the helper window is currently implemented, > if you remove the WS_CAPTION style, the icon won't be centered when it > gets docked (in GNOME at least.) I tried that when I put together the > systray tooltips patch. Ultimately it caused more problems than it > solved, so I gave up on it. But, it would be really great if you could > figure it out. :) I've tried kde, fluxbox and xfce4 (and fvwm, but it lacks systray). Now I can see that xfce4 suffers from it. I did not noticed that before. So, I suppose a new patch (attached). Does it work correct with GNOME? In xfce is OK. Thanks for pointing the path! -- Kirill K. Smirnov

2 1

Re: Uniscribe improvements
by Marcus Meissner Jan. 2, 2007

Jan. 2, 2007

On Tue, Jan 02, 2007 at 12:42:25PM -0600, * * wrote: Please use your real name. To avoid problems with ligitation later on we need it for tracking. Ciao, Marcus

1 0

Re: [PATCH] [ImageHlp]: MapAndLoad
by Alexandre Julliard Jan. 2, 2007

Jan. 2, 2007

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > @@ -199,7 +204,10 @@ BOOL WINAPI MapAndLoad(LPSTR pszImageNam > ((LPBYTE) &pNtHeader->OptionalHeader + > pNtHeader->FileHeader.SizeOfOptionalHeader); > pLoadedImage->NumberOfSections =3D pNtHeader->FileHeader.NumberOfSec= > tions; > - pLoadedImage->SizeOfImage =3D pNtHeader->OptionalHeader.SizeOfI= > mage; > + /* we need to return the size of image which has been mapped */ > + pLoadedImage->SizeOfImage =3D pNtHeader->OptionalHeader.SizeOfH= > eaders; > + for (i =3D 0; i < pLoadedImage->NumberOfSections; i++) > + pLoadedImage->SizeOfImage +=3D pLoadedImage->Sections[i].SizeOf= > RawData; There's no reason that the SizeOfRawData fields would add up to the size of the mapping. You have to use GetFileSize() if you need the true size. -- Alexandre Julliard julliard(a)winehq.org

1 0