wine-devel

wine-devel@winehq.org

2 participants
84470 discussions

Re: MSACM: implement honouring of driver priority and enabled status at load time
by Mike McCormack 12 Jan '06

12 Jan '06

Alex Villacís Lasso wrote: > + } > + } > + } > + } > + } > + } > + } > + } > +} Hmm. A 100 line function with 10 levels of indent... Any chance of rewriting this to reduce the level of indent? Try using some helper functions or return early. You might understand it all well, but this kind of code is difficult to follow and maintain. Mike

1 0

crash in GetKerningPairs
by Piotr Pawłow 12 Jan '06

12 Jan '06

Hello, Wine's implementation of GetKerningPairs in dlls/gdi/font.c behaves incorrectly (crashes) if lpkrnpair is NULL and nNumPairs is not zero. Test program: ---------- #include <windows.h> int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { HDC hdc = GetDC(NULL); int kp = GetKerningPairs(hdc, 1, NULL); char msg[200]; sprintf(msg, "GetKerningPairs returns: %d\n", kp); MessageBox(NULL, msg, "success", MB_OK); return 0; } ---------- On Windows (tested on XP SP2) this program displays a message box and exits cleanly. On Wine it causes a page fault trying to write to address 0x00000004. It's probably a trivial problem, but unfortunately I don't have time right now to investigate the issue and make a patch against current CVS. Best regards, -- Piotr Pawłow mailto:pp@siedziba.pl

2 1

Symbol fonts bug
by David Moore 12 Jan '06

12 Jan '06

Hi, I submitted a patch (attached) on the 15th of December. Without my patch, Solar Fire is broken on Wine, as it can't display its symbol font (codepage 42) correctly. As far as I can tell, according to this documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unico…, my patch does the right thing in freetype.c to make sure UTF7, UTF8 and Symbol fonts will be displayed properly after going through the affected function call. My patch has not been included yet. I was wondering whether this had anything to do with the format of the patch, the coding style or something else I can fix to get the patch included. This patch is very important to me, so I'm happy to take suggestions to fix it if necessary. thanks, David Moore

1 0

Re: Static control [06/10]: STN_ENABLE and STN_DISABLE notifications
by James Hawkins 12 Jan '06

12 Jan '06

On 1/11/06, Michael Kaufmann <hallo(a)michael-kaufmann.ch> wrote: > > > --- static-old.c 2006-01-11 22:43:23.000000000 +0100 > +++ static.c 2006-01-11 22:44:20.000000000 +0100 > @@ -31,10 +31,6 @@ Think you forgot the changelog. -- James Hawkins

2 1

Still need help fixing deadlock (GDI/metafile)
by Cihan Altinay 12 Jan '06

12 Jan '06

Hi, I am still trying to finding the reason for PowerPoint 2000 causing a deadlock if a file is opened that contains a preview which itself contains a bitmap >90x90 pixels (ie. on the first slide). After inserting some traces I feel I am pretty close but I'm stuck since before the holidays. The problem is connected to GDI's and/or metafile's StretchBlt (bitblt.c). It calls MFDRV_StretchBlt and then the trouble begins as can be seen from the output: <snip> trace:bitblt:StretchBlt --Start-- trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 trace:dc:DC_GetDCPtr trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 PixYPM=3780 Caps=96 trace:bitmap:GetDIBits trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 </snip> Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. There is a comment "FIXME: there is a race condition here". Could that be the cause for the deadlock? Btw. this might be the same problem as bug #3125 as both refer to the preview and both cause a deadlock. Can somebody give me a hint on how to tackle this? It is really important for us... If you need more output please let me know. Thanks a lot, Cihan

2 3

Regression caused by "ntdll: Check file size when mapping image sections to avoid SIGBUS errors."
by Troy Rollo 11 Jan '06

11 Jan '06

On Wed, 4 Jan 2006 08:21, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 67f29999a36ce3725a52b79ed618964244cc96ae ... > status = STATUS_INVALID_IMAGE_FORMAT; /* generic error */ > + if (header_size > st.st_size) goto error; > if (map_file_into_view( view, fd, 0, header_size, 0, VPROT_COMMITTED | ... This change prevents Wine from loading Win32 executables that are less than 64K long. header_size is 65536, but st.st_size is less than that. -- Troy Rollo - wine(a)troy.rollo.name

2 3

Re: ntdll/tests: Load test on win95 again
by Alexandre Julliard 11 Jan '06

11 Jan '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > Changelog: > > - ntdll/tests: Load test on win95 again > (kernel32,CreateWaitableTimerA not present) A better fix would be to avoid the call completely, the ntdll tests shouldn't need to use kernel32 functions. -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: A modest proposal
by gslink 11 Jan '06

11 Jan '06

The whole point of what I am proposing is a collaboration with RH so that new features are in the distributed Wine. If they are willing to undertake one of the tasks that Wine HQ is now doing then we should let them. At least they are supposed to know RH so they should be capable of the task. This would free manpower for some sorely needed other tasks.

1 0

Re: modifying _fullpath test
by Alexandre Julliard 11 Jan '06

11 Jan '06

Aric Stewart <aric(a)codeweavers.com> writes: > ChangeLog: > modify msvcrt dir test to create its own directory to ensure the directory > exists for the test. It would be better to use something like GetTempPath instead of hardcoding the directory name. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: modifying _fullpath test
by Dmitry Timoshkov 11 Jan '06

11 Jan '06

"Aric Stewart" <aric(a)codeweavers.com> wrote: > ChangeLog: > modify msvcrt dir test to create its own directory to ensure the directory > exists for the test. > - SetCurrentDirectory("C:\\Windows\\System\\"); > + free1=free2=TRUE; > + rc = CreateDirectory("C:\\msvcrt-test\\",NULL); > + if (!rc && GetLastError()==ERROR_ALREADY_EXISTS) > + free1=FALSE; > + rc = CreateDirectory("C:\\msvcrt-test\\nextlevel\\",NULL); > + if (!rc && GetLastError()==ERROR_ALREADY_EXISTS) > + free2=FALSE; > + SetCurrentDirectory("C:\\msvcrt-test\\nextlevel\\"); Drive C: root directory is not the best place to create temporary directories, I'd suggest to use GetTempPath (and maybe GetTempFileName) to get a more appropriate starting point. -- Dmitry.

1 0

Re: advpack: Implement ExtractFiles
by Mike McCormack 11 Jan '06

11 Jan '06

James Hawkins wrote: > What is the policy about attaching changes to tests that pass because > of a patch sent in? Should I also diff the tests? There's a higher level policy of "all changes should be atomic", which requires Wine to be in a working state before and after each change, so yes, you should update tests that pass with the patch that makes them pass. If you're adding new tests, it makes sense to send them in a seperate patch after the patch that implements functionality to make the new tests pass. Mike

1 0

Need help to fix a failing test
by Kai Blin 10 Jan '06

10 Jan '06

Hi folks, As far as I can see, secur32 tests are failing on all windows platforms right now. (http://test.winehq.org/data/200601101000/) Now, this seems to be due to the following: main.c:475: Test failed: cbMaxToken for NTLM is 1904, not 12000. I'm pretty sure that I got the 12000 from my win2k system when I compiled the test code there using the platform sdk that was current this july. Now, I have no clue where the 1904 comes from, but if windows really uses a cbMaxToken of 1904, I need to fix that in my code (I couldn't use the 12000 I thought I had to implement before due to implementation restrictions. I can easily work with 1904, if those are correct.) Still, I'm sure I didn't pull the 12000 out of my sleeve. Could I ask someone who runs msvc and a platform sdk to build the secur32 tests, run them on any windows box and send the results to me? Thanks in advance, Kai -- Kai Blin, (blin at gmx dot net) Are you mentally here at Pizza Hut??

1 0

Re: RESEND: winecfg: Added "Use PRIMARY selection" option
by Alexandre Julliard 10 Jan '06

10 Jan '06

Phil Krylov <phil(a)newstar.rinet.ru> writes: > ChangeLog: > > Added support for "Use PRIMARY selection" clipboard option. I don't think we want a new property sheet page for that, it should go with the other X11 options. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: WineDbg: Implemented harware assisted breakpoints.
by Eric Pouech 10 Jan '06

10 Jan '06

Eric Pouech wrote: > one can now set a hardware breakpoint in winedbg (it will not insert an > INT 3 command in the code, but rather use the x86 debug registers). > handy for debugging trashed code for example > > all the syntaxic forms of the 'break' command can be used for this new > hbreak command. > (only works on x86 for now) > > ChangeLog: > Implemented harware assisted breakpoints > merci de ne pas appliquer tel quel. J'ai une nouvelle version moins buggée. A+ -- Eric Pouech

1 0

RFC: implementation of driver functionality in msacm (RESEND)
by Alex Villacís Lasso 10 Jan '06

10 Jan '06

(resent because previous attempt never appeared in wine-devel) This patch is the preliminary result of some work I have been doing in order to add missing functionality to builtin msacm32.dll. I am submitting this to wine-devel rather than wine-patches, and in one big patch rather than several because I would like comments on some choices I made while adding features. The following is the list of features added by the patch: * Implementation of acmDriverAddW(), and delegation of acmDriverAddA() to acmDriverAddW() * Working implementation of modes of operation of acmDriverAdd[AW]: add driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND) * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. Alex Villacís Lasso

2 2

Starter projects for new Wine contributors?
by Dan Kegel 10 Jan '06

10 Jan '06

Hi all! I'm looking for suggestions for starter projects for new contributors that would take something like a week to do, and wouldn't require much knowledge of Wine ahead of time. http://wiki.winehq.org/TodoList is the place we've gathered that stuff, but nothing there really grabs me. I suppose the tasks http://wiki.winehq.org/CrossCallsWtoA http://wiki.winehq.org/ConstifyData http://wiki.winehq.org/SpecDiscrepencies might qualify. Do they still need doing? http://winehq.org/site/fun_projects has some cool stuff on it, particularly the idea of using Mono's libgdiplus to implement gdi+ in Wine. (That's probably more than a week's worth of work, though.) http://wiki.winehq.org/SummerOfCode has very cool stuff in it, but that's all about 100x times harder than what I'm looking for. And then there's riched20. It's missing quite a few little features; see the 11 open bugs here: http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-richedit&bug… Might some of those be doable in a couple days? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 4

static COM VTables?
by Stefan Dösinger 10 Jan '06

10 Jan '06

Hello, I just read the "constify data" todo, and I thought it would be good to make the VTables in my ddraw implementation const. The old ddraw implementation also declares them static. Is there any advantage in it? My C book just says that they can only be referenced from the local module, which is correct. But are there any other effects? Stefan

2 1

RFC: implementation of driver functionality in msacm
by Alex Villacís Lasso 10 Jan '06

10 Jan '06

This patch is the preliminary result of some work I have been doing in order to add missing functionality to builtin msacm32.dll. I am submitting this to wine-devel rather than wine-patches, and in one big patch rather than several because I would like comments on some choices I made while adding features. The following is the list of features added by the patch: * Implementation of acmDriverAddW(), and delegation of acmDriverAddA() to acmDriverAddW() * Working implementation of modes of operation of acmDriverAdd[AW]: add driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND) * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. Alex Villacís Lasso

1 0

test exploit for WMF / SETABORTPROC vulnerability
by Marcus Meissner 10 Jan '06

10 Jan '06

Hi, If someone needs an exploit for the WMF / SETABORTPROC vulnerability that works under WINE (<0.9.5) to verify fixed packages, feel free to mail me offline. Ciao, Marcus

1 0

Re: COMCTL32: Invalidate the entire progress bar any time it changes.
by Dmitry Timoshkov 10 Jan '06

10 Jan '06

"Mike McCormack" <mike(a)codeweavers.com> wrote: > This is an old patch, but the code that is in comctl32 now is wrong. > This fixes it, and there's no known regressions. Unfortunately there's > no way to fix this "efficiently". > > Mike > > > ChangeLog: > Invalidate the entire progress bar any time it changes. > Fixes the progress bar so it paints properly in InstallShield. My (old) tests show that native comctl32 invalidates the entire progress bar once it changes, so that change is OK. But it's smart enough to not invalidate the background if new bar position is larger than an old one, that reduces the flicker. -- Dmitry.

1 0

Loader Optimization Benchmarks
by Robert Shearman 10 Jan '06

10 Jan '06

Hi, I thought it would be good to post some benchmarks for the patch I just sent to wine-patches: http://www.winehq.org/pipermail/wine-patches/2006-January/023323.html I tested the loader code using the following in both cases: int i; DWORD dwTicksAfter; DWORD dwTicksBefore = GetTickCount(); for (i = 0; i < 1000; i++) LoadLibrary("ole32"); dwTicksAfter = GetTickCount(); trace("time taken = %ld ms\n", dwTicksAfter - dwTicksBefore); Before the patch: time taken = 658 ms time taken = 661 ms time taken = 661 ms time taken = 658 ms time taken = 659 ms After the patch was applied: time taken = 12 ms time taken = 12 ms time taken = 12 ms time taken = 13 ms time taken = 12 ms So it should be obvious that there are some very real gains from using this patch in the test case. You might think that an application loading a DLL 1000 times is very unlikely, but bear in mind that the ole32 marshal tests load ole32 76 times. It is therefore conceivable that something more complex like InstallShield could load ole32 over 100 times. -- Rob Shearman

1 0

(no subject)
by Curro Amores 10 Jan '06

10 Jan '06

I get this error when trying to install j2se with wine, i think is has something to do with windows installer, but ihave installed InstMSIA.exe manually with wine ( i dont get any error or see any installation box with "wine InstMSI.exe"). Has somebody tried to install JAva with wine? This is the output WINEDBG=+loaddll wine jdk-1_5_0_06-windows-i586-p.exe wine: Unhandled page fault on read access to 0x80002b1c at address 0x4d5d5b (thread 000c), starting debugger... WineDbg starting on pid 0x9 Unhandled exception: page fault on read access to 0x80002b1c in 32-bit code (0x004d5d5b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:004d5d5b ESP:7fc8fd24 EBP:7fc8fd64 EFLAGS:00010282( - 00 - RIS1) EAX:00000009 EBX:00000000 ECX:80002b08 EDX:0000000c ESI:80002b08 EDI:00000000 Stack dump: 0x7fc8fd24: 00000048 004d5b8f 00000000 004d17c6 0x7fc8fd34: 7fec0b40 004d15a4 00bfd1b0 00911f7c 0x7fc8fd44: 7fc8fd64 00911fa2 7fc8fd34 7fc8f8e0 0x7fc8fd54: 7fc8ff2c 004d53e8 00514a70 ffffffff 0x7fc8fd64: 7fc8fd84 00bcc611 004d0000 00000001 0x7fc8fd74: 00000001 00000001 00000001 00bfd1b0 0200: sel=1007 base=7befc000 limit=00001fff 32-bit rw- Backtrace: =>1 0x004d5d5b in rpcrt4 (+0x5d5b) (0x004d5d5b) 2 0x00bcc611 call_dll_entry_point+0x15 in ntdll (0x00bcc611) 3 0x00bcd252 MODULE_InitDLL+0x12a [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:816] in ntdll (0x00bcd252) 4 0x00bcda98 process_attach+0x98 [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:891] in ntdll (0x00bcda98) 5 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 6 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 7 0x00bcfe19 LdrInitializeThunk+0x319(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:2001] in ntdll (0x00bcfe19) 8 0x005eff1f start_process+0x8b(arg=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/kernel/process.c:1017] in kernel32 (0x005eff1f) 9 0x0033185b _IO_vfprintf_internal in libc.so.6 (0x0033185b) 0x004d5d5b: cmpl 0x14(%esi),%eax Modules: Module Address Debug info Name (43 modules) ELF 0x0025f000-00299000 Deferred advapi32<elf> \-PE 0x00270000-00299000 \ advapi32 ELF 0x002c8000-002cd000 Deferred libxxf86vm.so.1 ELF 0x002d2000-002ee000 Deferred ld-linux.so.2 ELF 0x002ee000-0031c000 Deferred libfontconfig.so.1 ELF 0x002ee000-0031c000 Deferred libfontconfig.so.1 ELF 0x002f4000-0041e000 Export libc.so.6 ELF 0x00346000-0043c000 Deferred libwine_unicode.so.1 ELF 0x00420000-00426000 Deferred libxxf86dga.so.1 ELF 0x00420000-00426000 Deferred libxxf86dga.so.1 ELF 0x00446000-0044a000 Deferred libdl.so.2 ELF 0x0044a000-004cb000 Deferred gdi32<elf> \-PE 0x0044c000-0045f000 \ libz.so.1 \-PE 0x00460000-004cb000 \ gdi32 \-PE 0x00460000-004cb000 \ gdi32 PE 0x004d0000-00522000 Deferred rpcrt4 ELF 0x00537000-00549000 Deferred libpthread.so.0 ELF 0x0054b000-0055a000 Deferred libxext.so.6 ELF 0x0055c000-00565000 Deferred libsm.so.6 ELF 0x00567000-00581000 Deferred libice.so.6 ELF 0x00583000-005a2000 Deferred libexpat.so.0 ELF 0x00583000-005a2000 Deferred libexpat.so.0 PE 0x005b0000-0067e000 DIA kernel32 PE 0x005b0000-0067e000 DIA kernel32 PE 0x005b0000-0067e000 DIA kernel32 PE 0x00680000-0086c000 Deferred msi ELF 0x0086c000-0097a000 Deferred user32<elf> \-PE 0x00890000-0097a000 \ user32 \-PE 0x00890000-0097a000 \ user32 ELF 0x00975000-009f0000 Deferred libgl.so.1 ELF 0x00975000-009f0000 Deferred libgl.so.1 PE 0x009f0000-00a59000 Deferred winex11 ELF 0x00b2d000-00b4c000 Deferred ximcp.so.2 ELF 0x00b4c000-00b67000 Deferred imm32<elf> \-PE 0x00b50000-00b67000 \ imm32 ELF 0x00b99000-00c09000 Stabs ntdll<elf> \-PE 0x00bb0000-00c09000 \ ntdll ELF 0x00ea3000-00ea5000 Deferred xlcutf8load.so.2 ELF 0x00ef1000-00f07000 Deferred msiexec<elf> \-PE 0x00f00000-00f07000 \ msiexec ELF 0x00fed000-00ff8000 Deferred libnss_files.so.2 PE 0x65f00000-65fc2000 Deferred ole32 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000009 (D) C:\windows\system32\MSIEXEC.EXE 0000000c 0 <== 00000047 00000008 0 0000001e 00000026 2 0000001f 0 WineDbg terminated on pid 0x9

4 4

A modest proposal
by gslink 10 Jan '06

10 Jan '06

I noticed that for FC4 Red Hat is providing a copy of Wine in extras. This is something that THEY are producing and it is in a different form from the one put out by Wine HQ. It appears to me that there is no reason for Wine HQ to duplicate their effort and suggest some sort of collaboration. The version posted by RH seems to be later than what is posted by Wine HQ. I think this should be investigated.

2 1

daily winetest generation
by Saulius Krasuckas 09 Jan '06

09 Jan '06

I may perfectly repeat someones else question, but why in the world winetest-200YmmDD1000-paul-mingw.exe files aren't being generated if the patches arrives too late during partical day? I think compiled EXEs should be released regardless of their generation date. No?

3 5

Regression in Icewind Dale II
by James Trotter 09 Jan '06

09 Jan '06

I've been trying to run the game Icewind Dale II under wine 0.9.4, but it crashes before the game starts. In earlier versions of wine it worked fine. I've found that the regression was caused by this patch: http://cvs.winehq.org/patch.py?id=17222 Here's the output from running the game in wine 0.9.4: james@james:~/Wine/Games/Icewind Dale II$ wine IWD2.exe BEGIN LOGGING SESSION wine: Unhandled page fault on read access to 0x31303635 at address 0x7ab8f1 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x31303635 in 32-bit code (0x007ab8f1). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:007ab8f1 ESP:7fabab94 EBP:00000000 EFLAGS:00210246( - 00 -RIZP1) EAX:31303635 EBX:00000001 ECX:7fabb444 EDX:00000000 ESI:7fabb31c EDI:7beb3820 Stack dump: 0x7fabab94: 31303635 00002711 00000000 7fabb31c 0x7fababa4: 7fababd4 007aaf30 7fabb20c 7fabaf54 0x7fababb4: 00000000 00002711 40c38800 7fabb31c 0x7fababc4: 7fabac84 0084566a 00000007 7fcf0690 0x7fababd4: 7fcf0690 0078e3ca 00000000 7fabaf54 0x7fababe4: 00400000 7fd12606 7fabaf54 00010000 0200: sel=1007 base=7fec4000 limit=00001fff 32-bit rw- Backtrace: =>1 0x007ab8f1 in iwd2 (+0x3ab8f1) (0x007ab8f1) 0x007ab8f1: movl 0x0(%eax),%ecx Modules: Module Address Debug info Name (95 modules) PE 0x00400000-00a21000 Export iwd2 ELF 0x7391a000-73922000 Deferred libxrender.so.1 ELF 0x7be8c000-7bf00000 Deferred ntdll<elf> \-PE 0x7bea0000-7bf00000 \ ntdll ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7c9b5000-7ca01000 Deferred libgcrypt.so.11 ELF 0x7ca01000-7ca11000 Deferred libtasn1.so.2 ELF 0x7ca11000-7ca73000 Deferred libgnutls.so.11 ELF 0x7ca73000-7ca90000 Deferred libcups.so.2 ELF 0x7db8b000-7dbbb000 Deferred uxtheme<elf> \-PE 0x7db90000-7dbbb000 \ uxtheme ELF 0x7dbbb000-7dbd0000 Deferred midimap<elf> \-PE 0x7dbc0000-7dbd0000 \ midimap ELF 0x7dce6000-7dd08000 Deferred msacm32<elf> \-PE 0x7dcf0000-7dd08000 \ msacm32 ELF 0x7dd08000-7dd1f000 Deferred msacm<elf> \-PE 0x7dd10000-7dd1f000 \ msacm ELF 0x7dd1f000-7ddd2000 Deferred libasound.so.2 ELF 0x7ddd2000-7ddfa000 Deferred winealsa<elf> \-PE 0x7dde0000-7ddfa000 \ winealsa ELF 0x7de18000-7de21000 Deferred libxcursor.so.1 ELF 0x7de2c000-7de48000 Deferred ximcp.so.2 ELF 0x7de48000-7de50000 Deferred librt.so.1 ELF 0x7df0a000-7e64d000 Deferred fglrx_dri.so ELF 0x7e64d000-7e6ec000 Deferred libgl.so.1 ELF 0x7e6ec000-7e769000 Deferred winex11<elf> \-PE 0x7e700000-7e769000 \ winex11 ELF 0x7e769000-7e788000 Deferred libexpat.so.1 ELF 0x7e788000-7e7b6000 Deferred libfontconfig.so.1 ELF 0x7e7b6000-7e7ca000 Deferred libz.so.1 ELF 0x7e7ca000-7e834000 Deferred libfreetype.so.6 ELF 0x7e834000-7e85c000 Deferred winspool<elf> \-PE 0x7e840000-7e85c000 \ winspool ELF 0x7e85c000-7e90b000 Deferred comctl32<elf> \-PE 0x7e870000-7e90b000 \ comctl32 ELF 0x7e90b000-7e960000 Deferred shlwapi<elf> \-PE 0x7e920000-7e960000 \ shlwapi ELF 0x7e960000-7ea1f000 Deferred shell32<elf> \-PE 0x7e980000-7ea1f000 \ shell32 ELF 0x7ea1f000-7eab1000 Deferred comdlg32<elf> \-PE 0x7ea30000-7eab1000 \ comdlg32 ELF 0x7eab1000-7eada000 Deferred ws2_32<elf> \-PE 0x7eac0000-7eada000 \ ws2_32 ELF 0x7eada000-7eaf5000 Deferred imm32<elf> \-PE 0x7eae0000-7eaf5000 \ imm32 ELF 0x7eaf5000-7eb09000 Deferred lz32<elf> \-PE 0x7eb00000-7eb09000 \ lz32 ELF 0x7eb09000-7eb21000 Deferred version<elf> \-PE 0x7eb10000-7eb21000 \ version ELF 0x7eb21000-7eb25000 Deferred libxdmcp.so.6 ELF 0x7eb25000-7ebe5000 Deferred libx11.so.6 ELF 0x7ebe5000-7ebf2000 Deferred libxext.so.6 ELF 0x7ebf2000-7ebf7000 Deferred libxxf86vm.so.1 ELF 0x7ebf7000-7ec10000 Deferred libice.so.6 ELF 0x7ec10000-7ec88000 Deferred ddraw<elf> \-PE 0x7ec30000-7ec88000 \ ddraw ELF 0x7ec88000-7ecd3000 Deferred dsound<elf> \-PE 0x7eca0000-7ecd3000 \ dsound ELF 0x7ecd3000-7ecf1000 Deferred iphlpapi<elf> \-PE 0x7ece0000-7ecf1000 \ iphlpapi ELF 0x7ecf1000-7ed35000 Deferred rpcrt4<elf> \-PE 0x7ed00000-7ed35000 \ rpcrt4 ELF 0x7ed35000-7edbb000 Deferred ole32<elf> \-PE 0x7ed50000-7edbb000 \ ole32 ELF 0x7edbb000-7edf7000 Deferred advapi32<elf> \-PE 0x7edd0000-7edf7000 \ advapi32 ELF 0x7eedd000-7f7dd000 Deferred gdi32<elf> \-PE 0x7ef20000-7f7dd000 \ gdi32 ELF 0x7f7dd000-7f8f6000 Deferred user32<elf> \-PE 0x7f800000-7f8f6000 \ user32 ELF 0x7f8f6000-7f977000 Deferred winmm<elf> \-PE 0x7f900000-7f977000 \ winmm ELF 0x7f977000-7f9b0000 Deferred dplayx<elf> \-PE 0x7f990000-7f9b0000 \ dplayx ELF 0x7fac0000-7fac5000 Deferred libxxf86dga.so.1 ELF 0x7fac5000-7fad0000 Deferred libgcc_s.so.1 ELF 0x7fc74000-7fd70000 Deferred kernel32<elf> \-PE 0x7fc90000-7fd70000 \ kernel32 ELF 0x7fe81000-7fe88000 Deferred libsm.so.6 ELF 0x7fe88000-7fe92000 Deferred libnss_files.so.2 ELF 0x7fe92000-7fe9b000 Deferred libnss_nis.so.2 ELF 0x7fe9b000-7feb0000 Deferred libnsl.so.1 ELF 0x7feb0000-7feb9000 Deferred libnss_compat.so.2 ELF 0x7feba000-7febe000 Deferred libgpg-error.so.0 ELF 0x7febe000-7fec2000 Deferred libxfixes.so.3 ELF 0x7fec2000-7fec4000 Deferred xlcutf8load.so.2 ELF 0x7fec7000-7fee9000 Deferred libm.so.6 ELF 0x7fee9000-7ffe0000 Deferred libwine_unicode.so.1 ELF 0xb7e00000-b7e03000 Deferred libxrandr.so.2 ELF 0xb7e11000-b7e14000 Deferred libdl.so.2 ELF 0xb7e14000-b7f42000 Deferred libc.so.6 ELF 0xb7f42000-b7f54000 Deferred libpthread.so.0 ELF 0xb7f54000-b7f6e000 Deferred libwine.so.1 ELF 0xb7f6e000-b7f71000 Deferred libxau.so.6 ELF 0xb7f7c000-b7f92000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Games\Icewind Dale II\IWD2.exe 00000009 0 <== WineDbg terminated on pid 0x8

4 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel