wine-bugs January 2006

wine-bugs@winehq.org

2 participants
1680 discussions

[Bug 3303] native notepad is unable to print
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=3303 wine.dev(a)web.de changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |4342 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 2249] Winword print an incorrect file.
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=2249 wine.dev(a)web.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine.dev(a)web.de -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 4425] Emperor demo multiplayer crashes (_EnterSysLevel)
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=4425 ------- Additional Comments From reif(a)earthlink.net 2006-29-01 15:41 ------- This patch fixes the problem for me: http://www.winehq.org/pipermail/wine-patches/2006-January/023810.html -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 1793] Some apps print backward and upside down
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=1793 wine.dev(a)web.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine.dev(a)web.de ------- Additional Comments From wine.dev(a)web.de 2006-29-01 15:40 ------- Can you give us an Download-URL for an App that has this issue Please -- By by ... Detlef -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 4436] Storage32 regression problem: ECAD app 'Easy-PC' is unable to create new project/design
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=4436 J.A.Gow(a)furrybubble.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 1520] PIAPro only prints lines but not the text.
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=1520 wine.dev(a)web.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine.dev(a)web.de -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 4437] New: Weird Worlds demo fails to run
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=4437 Summary: Weird Worlds demo fails to run Product: Wine Version: 0.9.6. Platform: PC URL: http://www.shrapnelgames.com/digital_eel/weird_worlds/1. htm OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-binary AssignedTo: wine-bugs(a)winehq.org ReportedBy: altkai(a)ml1.net Demo (http://download.shrapnelgames.com/downloads/weirdworlds_demo.exe) installs fine. When loading, a window with the title "SDL_app" briefly appears, and then disappears. Console outputs no message. When I ran winedbg --auto weird.exe (is this the correct usage, btw?) I got: WineDbg starting on pid 0xa In 32 bit mode. 0x7fc676d2: jmp 0x7fc676c1 Modules: Module Address Debug info Name (75 modules) PE 0x00400000-00494000 Deferred weird PE 0x10000000-10041000 Deferred sdl PE 0x64f40000-64f67000 Deferred jpeg ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7de6b000-7de80000 Deferred midimap<elf> \-PE 0x7de70000-7de80000 \ midimap ELF 0x7df98000-7dfb9000 Deferred msacm32<elf> \-PE 0x7dfa0000-7dfb9000 \ msacm32 ELF 0x7dfb9000-7dfd0000 Deferred msacm<elf> \-PE 0x7dfc0000-7dfd0000 \ msacm ELF 0x7dfd0000-7e08c000 Deferred libasound.so.2 ELF 0x7e08c000-7e0ad000 Deferred winealsa<elf> \-PE 0x7e0a0000-7e0ad000 \ winealsa ELF 0x7e0f1000-7e10b000 Deferred imm32<elf> \-PE 0x7e100000-7e10b000 \ imm32 ELF 0x7e10b000-7e128000 Deferred ximcp.so.2 ELF 0x7e128000-7e130000 Deferred libxrender.so.1 ELF 0x7f024000-7f1c1000 Deferred r128_dri.so ELF 0x7f1c1000-7f232000 Deferred winex11<elf> \-PE 0x7f1d0000-7f232000 \ winex11 ELF 0x7f232000-7f252000 Deferred libexpat.so.0 ELF 0x7f252000-7f279000 Deferred libfontconfig.so.1 ELF 0x7f279000-7f28a000 Deferred libz.so.1 ELF 0x7f28a000-7f2fc000 Deferred libfreetype.so.6 ELF 0x7f2fc000-7f312000 Deferred glu32<elf> \-PE 0x7f300000-7f312000 \ glu32 ELF 0x7f3e2000-7f45c000 Deferred libglu.so.1 ELF 0x7f45c000-7f4c9000 Deferred libgl.so.1 ELF 0x7f4c9000-7f596000 Deferred libx11.so.6 ELF 0x7f596000-7f5ae000 Deferred libice.so.6 ELF 0x7f5c2000-7f637000 Deferred opengl32<elf> \-PE 0x7f600000-7f637000 \ opengl32 ELF 0x7f637000-7f653000 Deferred iphlpapi<elf> \-PE 0x7f640000-7f653000 \ iphlpapi ELF 0x7f653000-7f68f000 Deferred rpcrt4<elf> \-PE 0x7f660000-7f68f000 \ rpcrt4 ELF 0x7f68f000-7f700000 Deferred ole32<elf> \-PE 0x7f6a0000-7f700000 \ ole32 PE 0x7f700000-7f7e3000 Deferred openal32 PE 0x7f7f0000-7f802000 Deferred zlib1 ELF 0x7f807000-7f810000 Deferred libxcursor.so.1.0.2 PE 0x7f810000-7f82f000 Deferred libpng13 PE 0x7f830000-7f84a000 Deferred sdl_image ELF 0x7f84b000-7f84f000 Deferred libxrandr.so.2 ELF 0x7f84f000-7f8a8000 Deferred msvcrt<elf> \-PE 0x7f860000-7f8a8000 \ msvcrt ELF 0x7f8a8000-7f8de000 Deferred advapi32<elf> \-PE 0x7f8b0000-7f8de000 \ advapi32 ELF 0x7f8de000-7f95f000 Deferred gdi32<elf> \-PE 0x7f8f0000-7f95f000 \ gdi32 ELF 0x7f95f000-7fa6a000 Deferred user32<elf> \-PE 0x7f980000-7fa6a000 \ user32 ELF 0x7fa6a000-7fae0000 Deferred winmm<elf> \-PE 0x7fa80000-7fae0000 \ winmm ELF 0x7fbf2000-7fc00000 Deferred libxext.so.6 ELF 0x7fc05000-7fcf0000 Export kernel32<elf> \-PE 0x7fc20000-7fcf0000 \ kernel32 ELF 0x7fe00000-7fe03000 Deferred xlcdef.so.2 ELF 0x7fe03000-7fe0c000 Deferred libgcc_s.so.1 ELF 0x7fe0c000-7fe16000 Deferred libnss_files.so.2 ELF 0x7fe16000-7fe20000 Deferred libnss_nis.so.2 ELF 0x7fe20000-7fe35000 Deferred libnsl.so.1 ELF 0x7fe37000-7fe40000 Deferred libsm.so.6 ELF 0x7fe44000-7fe49000 Deferred libxxf86vm.so.1 ELF 0x7fe49000-7fe6c000 Deferred libm.so.6 ELF 0x7fe6c000-7ff62000 Deferred libwine_unicode.so.1 ELF 0x7ff63000-7ff69000 Deferred libxxf86dga.so.1 ELF 0x7ff69000-7ff72000 Deferred libnss_compat.so.2 ELF 0x7ff76000-7ffe0000 Deferred ntdll<elf> \-PE 0x7ff90000-7ffe0000 \ ntdll ELF 0xb7d95000-b7d99000 Deferred libdl.so.2 ELF 0xb7d99000-b7eb3000 Deferred libc.so.6 ELF 0xb7eb3000-b7ec5000 Deferred libpthread.so.0 ELF 0xb7ec6000-b7ee0000 Deferred libwine.so.1 ELF 0xb7ef4000-b7f0b000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a (D) C:\Program Files\Shrapnel Games\Weird Worlds Demo\weird.exe 0000000b 0 <== WineDbg terminated on pid 0xa -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 4436] New: Storage32 regression problem: ECAD app 'Easy-PC' is unable to create new project/design
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=4436 Summary: Storage32 regression problem: ECAD app 'Easy-PC' is unable to create new project/design Product: Wine Version: CVS Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: J.A.Gow(a)furrybubble.co.uk I have some regression problems relating to Wine in a commercial ECAD app 'Easy-PC' version 9.0, available from http://www.numberone.com The application was quite usable on Crossover Office 4.2, with just some minor dialog corruption. Alpha versions of Wine available at the same time (can not exactly remember which ones) could also run it successfully. However, under the latest Wine 0.9.6, Wine CVS and CXO 5.0.1 it does not work. Note that it does not crash, it errors out cleanly with a dialog box message. I have been debugging the problems in this app for some time now. It is a critical app for me as I use it in a production environment, but I do not want to pay Microsoft for the privilege of exposing my machine to malware. I am thus prepared to help debug Wine to get this application running. However, my Windows programming experience is limited to device drivers, not apps (although fluent C/C++ systems programming on other platforms), I have hit a brick wall, possibly due to my limited knowledge of how the Windows API works and I will need some help with this. If anyone would like to help me debug this app (hope springs eternal!), a demo version of the app is available free of charge from the web site address above, and this version exhibits the same problems as the full version. Background ------------- The system: Dual physical processor (not dual core) Opteron running SuSE 10.0 x86_64 SMP. Wine: Latest 0.9.6 release, up to CVS grabbed a week or so ago. The application installs OK and when run, puts up a GUI as expected. However, when you try to create a new PCB or schematic, an error dialog box is displayed indicating that the app can not read the technology file Default.stf (schematic) or Default.ptf (pcb). This is _not_ a permissions problem, all files are actually present and the same install will work under CXO 4.2. I generated and analyzed several hundred MB of logfiles over many days, added extra debug statements to the Wine code and analyzed the application's operation. The problem actually appears to have two causes, and this is what I have come up with so far. Problem 1 ----------- Application calls StgOpenStorage with a grfMode flag of 0x10020 (STGM_TRANSACTED | STGM_SHARE_DENY_WRITE). Immediately afterwards it calls StorageBaseImpl_OpenStream with a grfMode of 0x12 (STGM_SHARE_EXCLUSIVE | STGM_READWRITE). This second call fails with an access denied error code, after which the logs show an easily traced error handling sequence leading to display of the error dialog mentioned above: 0009:Call ole32.StgOpenStorage(59693db0 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf",00000000,00010020,00000000,00000000,5821f850) ret=1022e7f0 ... ... trace:storage:StgOpenStorage <-- 00000000, IStorage 0x5b3465f8 0009:Ret ole32.StgOpenStorage() retval=00000000 ret=1022e7f0 ... ... trace:storage:StorageBaseImpl_OpenStream (0x5b3465f8, L"\0005FileType", (nil), 12, 0, 0x5821f848) fixme:storage:StorageBaseImpl_OpenStream STORAGE ACCESS DENIED - parent 0, this 2 Note that the last fixme is one I added to find out exactly what was going on here. Now, logic would dictate that the grfMode of the OpenStream method call is indeed incompatible with that of its parent storage object. However, I would have thought that the application coders would most likely have hard-coded the grfMode flags in the application. If so, it would seem that the app is buggy, yet this application works on Windows! Either the app is buggy and the Win32 OLE32 implementation behaves differently, or I am missing something here. Ok, so with no obvious solution to this problem, I decided to bypass it. I modified the storage32.c implementation in the following way to bypass the grfMode check: parent_grfMode = STGM_ACCESS_MODE( This->ancestorStorage->base.openFlags ); *if* ( STGM_ACCESS_MODE( grfMode ) > STGM_ACCESS_MODE( parent_grfMode ) ) { FIXME("StorageBase_OpenStream called with grfMode mismatch - parent %d, this %d\n", parent_grfMode,STGM_ACCESS_MODE(grfMode)); ///res = STG_E_ACCESSDENIED;/ ///goto end;/ } Obviously not a viable fix, but a hack to get it working. After implementing this, the OpenStream call succeeded, as did subsequent stream access. However, the app _still_ errored out in exactly the same manner and at the same time. After more log searching, this led to the discovery of the second problem. Problem 2 ----------- During its loading and setup, the application repeatedly calls StgOpenStorage on the .stf/.ptf files in question, calls OpenStream, reads from the stream, and then finally closes the storage. I placed tell-tales in useful locations in the file open/close handlers in the wineserver, and could clearly see the files being opened and subsequently closed. This open/read/close occurs correctly and in sequence up to a certain point. At this point in the execution, the app calls StgOpenStorage on the technology file, with the following call. It is opened correctly, with grfMode of STGM_TRANSACTED | STGM_SHARED_DENY_WRITE | STGM_READWRITE: 0009:Call ole32.StgOpenStorage(5821f754 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf",00000000,00010022,00000000,00000000,5821f7f4) ret=7c17eabc trace:storage:StgOpenStorage (L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.ptf", (nil), 10022, (nil), 0, 0x5821f7f4) ... ... ... trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 1 trace:storage:StgOpenStorage <-- 00000000, IStorage 0x5b3465f8 0009:Ret ole32.StgOpenStorage() retval=00000000 ret=7c17eabc Almost immediately, the app opens three streams in this object and starts to access them, all successfully. There follows a whole slew of logging statements, all of which appear sensible However, what is strange about this access is that soon we seem to be frantically increasing the storage object's reference pointer. This sequence appears frequently in the code, closely spaced but interspersed with what seems quite logical and successful calls to seek functions and memory allocation functions: 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000030) ret=584e498b 0009:Ret ntdll.RtlAllocateHeap() retval=55926480 ret=584e498b trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 9 trace:storage:StorageImpl_ReadProperty storage name: L"\0005SummaryInformation" 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000008) ret=584e7ab3 0009:Ret ntdll.RtlAllocateHeap() retval=5594d108 ret=584e7ab3 The storage object's reference pointer is so incremented up to 19: 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000030) ret=584e498b 0009:Ret ntdll.RtlAllocateHeap() retval=559250f8 ret=584e498b trace:storage:StorageBaseImpl_AddRef (0x5b3465f8) AddRef to 19 trace:storage:StorageImpl_ReadProperty storage name: L"\0005SummaryInformation" 0009:Call ntdll.RtlAllocateHeap(55890000,00000000,00000008) ret=584e7ab3 0009:Ret ntdll.RtlAllocateHeap() retval=55925130 ret=584e7ab3 Finally, the code executes a trace:storage:StgStreamImpl_Destroy (0x5b34b7e0) trace:storage:StorageBaseImpl_Release (0x5b3465f8) ReleaseRef to 18 There follows a lot more log file, mostly concerned with set up and so on. What I am highligting here is that between this point, and the point of actual failure which I am going to describe shortly, there appears to be no attempt to close the Default.ptf file, unlike the attempts further up the logs closer to program start. I am wondering about this: is the reference counter being incorrectly incremented here, preventing the 'Release' function from destroying the storage object and thus closing the file? I am not sufficiently familiar with the COM storage object stuff in Windows to know what _should_ happen here. Anyway. I will now describe the point of failure. Further down the log, there are several more successful opens/closes of the technology file, with the correct mode flags. Then, finally, the app tries to re-open the technology file with a grfMode of STGM_TRANSACTED | STGM_SHARE_DENY_WRITE. This call fails with a sharing violation (remember it had been left open from the previous call) 0009:Call ole32.StgOpenStorage(5971bec8 L"c:\\Program Files\\Number One Systems\\Easy-PC\\Technology\\Default.stf",00000000,00010020,00000000,00000000,5821e69c) ret=1022e7f0 .... .... 0009:Ret kernel32.CreateFileW() retval=ffffffff ret=584edc8b trace:storage:StgOpenStorage <-- 80030020, IStorage (nil) There then follows the same error handling sequence leading to display of the dialog. I then thought about a simple test. I overrode the sharing mode detection in fd.c/check_sharing() in the wineserver (again, not a real solution). Note there are some minor differences in the code - I used a return code so I could easily check it: /// if ((access & FILE_UNIX_READ_ACCESS) && !(existing_sharing & FILE_SHARE_READ))/ /// rc=0;/ /// if ((access & FILE_UNIX_WRITE_ACCESS) && !(existing_sharing & FILE_SHARE_WRITE))/ /// rc=0;/ /// if ((existing_access & FILE_UNIX_READ_ACCESS) && !(sharing & FILE_SHARE_READ)) rc=0;/ /// if ((existing_access & FILE_UNIX_WRITE_ACCESS) && !(sharing & FILE_SHARE_WRITE)) rc=0;/ *if* (fd->closed->unlink[0] && !(existing_sharing & FILE_SHARE_DELETE)) rc=0; *if* (unlink && !(sharing & FILE_SHARE_DELETE)) rc=0; *if*(rc==0) { fprintf(stderr,"FILEDESC - sharing mode invalid\n"); rc=1; } *return* rc; and the application worked! Not only worked, but worked perfectly! The minor dialog corruption of previous versions had completely gone! I would like to thank the hard working people who have been working to correct problems in Wine, and in doing so had fixed this minor dialog problem. The only issue of note then is that the top-right hand buttons of a maximized MDI child window do not appear until you resize the frame. This is a minor issue though, and not of importance here. However, what I did does not represent a real solution - I just hacked around the problem, which itself seems subtle in nature. I looked closely at the Microsoft documentation and the logic in check_sharing(), even writing a program in Windows to check that at the CreateFile level that the sharing logic in Wine is correct. It seems to be. I am now stumped, I would really like to get this app working properly under Wine, without bad hacks. I would appreciate any guidance from those more experienced with the user-land Windows API. If you got this far, many thanks for taking the time to read this long message. I have provided only small excerpts from logs, but I can provide other parts of the files on request if necessary. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 3849] Alpha Centauri 4.0 crashes after first turn
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=3849 ------- Additional Comments From altkai(a)ml1.net 2006-29-01 15:17 ------- (my config: Wine 0.9.6 w/clean .wine directory as created by winecfg. No settings were changed with the exception of using the ALSA driver instead of OSS. All in games setting left at defaults.) Sorry for the delay. I got a different error with the demo. When confirming the last step to starting a new game: err:seh:setup_exception nested exception on signal stack in thread 0009 eip 7ffbd46b esp 7fe5bca0 stack 0x7fb01000-0x7fc10000 The game was unresponsive and never left the starting menu. Using the "Quick Start" option from the main menu, OTOH, proceeded to the main game, but crashed with ~3 seconds, giving the exact same message as above. The full version (1.0), upon pressing quick start, hangs and does not even show the main game: err:seh:setup_exception nested exception on signal stack in thread 0009 eip 7ffbd46b esp 7fe5bca0 stack 0x7fb01000-0x7fc10000 4.0 I didn't try. In answer to your question, I did see that same mailing list message referenced in bug 2252. Someone did report getting the game to work with version 2005something, but I can't find the posting, nor did the poster leave information on their configuration. I'm happy to spend time testing if you point me in the right direction (should I be using winedbg? testing with other wine versions?) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 515] Multiple printers cannot be selected
by Wine Bugs 29 Jan '06

29 Jan '06

http://bugs.winehq.org/show_bug.cgi?id=515 ------- Additional Comments From wine.dev(a)web.de 2006-29-01 15:13 ------- I tested this with 2 printers and "wine notepad" - Change the content for the Value "Location" in: HKLM\System\CurrentControlSet\Contol\Print\Printers\<printername>\ - start wine "notepad" - Menu "File" / "Print" When you change the Printer, the Data for "Location" is updated. (I have no Rights to set "Resolve bug, WORKSFORME") -- By by ... Detlef -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 0

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-bugs January 2006