November 2005 - Wine-Devel - list.winehq.org

Re: [ntdll] fix GetProcAddress on mapped modules as data

by Vitaliy Margolen

Monday, November 28, 2005, 4:34:08 PM, Raphael wrote: > On Tuesday 29 November 2005 00:03, Vitaliy Margolen wrote: >> Monday, November 28, 2005, 3:29:51 PM, Raphael wrote: >> > Hi, >> > fix crash on Corel 9 start >> > (http://bugs.winehq.org/show_bug.cgi?id=2884) >> > Changelog: >> > - don't crash on GetProcAddress when input mapped modules as data >> >> I think you need to make some tests of this. It shouldn't be to hard to >> load some dll as a resource and try to get proc address. Also check if >> you can do that for already loaded dll (like kernel32.dll). > I don't have a windows install to test. Still you need to make tests and send them first then >> Now the patch: >> > + if ((ULONG_PTR)module & 1) >> > + { >> > + module = (HMODULE)((ULONG_PTR)module & ~1); >> > + } >> >> Check is some-what redundant. Just use: >> module = (HMODULE)((ULONG_PTR)module & ~1); > I use the same (and more readable) test as RtlImageDirectoryEntryToData What to test? If you resetting that bit, when it's set, and not resetting it when it's not set result is the same. So dropping the test will make it more clear actually. >> > - void *proc = name ? find_named_export( module, exports, >> > exp_size, name->Buffer, -1 ) - : >> > find_ordinal_export( module, exports, exp_size, ord - exports->Base ); + >> > void *proc = NULL; >> > + if (name) >> > + { >> > + proc = find_named_export( module, exports, exp_size, >> > name->Buffer, -1 ); + } >> > + else >> > + { >> > + proc = find_ordinal_export( module, exports, exp_size, ord - >> > exports->Base ); + } >> >> Any reason for this? It's the same no matter how you write it only 7 >> lines longer <g> > Because i found it more readable. > using call functions in ternary operator make code unreadable. Well that depends <g> But shouldn't it be a separate patch? As it has nothing to do with the change-log? Vitaliy

Nov. 28, 2005

Re: powerpoint: images upside down

by Cihan Altinay

Quoting Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de>: > >>>>> "Cihan" == Cihan Altinay <cihan(a)uq.edu.au> writes: > > Cihan> Hi, When using MS Powerpoint 2003 images are drawn upside down in > Cihan> fullscreen (presentation) mode but not in design mode. Also, > Cihan> text is drawn correctly as seen on the attachments. > > Cihan> I would appreciate a hint on what traces/logs to provide for more > Cihan> info as the dc & win output is quite long. > > Is the error reproducable with the downloadable powerpoint viewer? Unfortunately, Powerpoint Viewer 2003 presents a black screen to me (see bug #3905 which is apparently fixed, but not for me...). > Can you perhaps put a small powerpoint file online, showing that error? > This will make things easier for others to pick up. Also perhaps pit these > files and description in the bugs database. Thanks for the hints. Fortunately this gets fixed applying the patch Huw mentioned. Should I still open a bug report and mention the patch? Cihan

Nov. 28, 2005

Re: [msvcrt] how to handle msvcr*.dll ?

by Robert Shearman

Uwe Bonnes wrote: >>>>>>"Raphael" == Raphael <fenix(a)club-internet.fr> writes: >>>>>> >>>>>> > > Raphael> On Monday 28 November 2005 19:46, Daniel Remenak wrote: > >> > >> <snip>. Windows does not and will not distribute them, and neither > >> should wine. > >What about winelib on non-X86? > > msvcr*.dll = Microsoft Visual C Runtime version * Winelib should use the C runtime of whatever compiler is being used and I don't think Microsoft support ELF targets, yet... -- Rob Shearman

Nov. 28, 2005

Re: [ntdll] fix GetProcAddress on mapped modules as data

by Raphael

On Tuesday 29 November 2005 00:03, Vitaliy Margolen wrote: > Monday, November 28, 2005, 3:29:51 PM, Raphael wrote: > > Hi, > > fix crash on Corel 9 start > > (http://bugs.winehq.org/show_bug.cgi?id=2884) > > Changelog: > > - don't crash on GetProcAddress when input mapped modules as data > > I think you need to make some tests of this. It shouldn't be to hard to > load some dll as a resource and try to get proc address. Also check if > you can do that for already loaded dll (like kernel32.dll). I don't have a windows install to test. > Now the patch: > > + if ((ULONG_PTR)module & 1) > > + { > > + module = (HMODULE)((ULONG_PTR)module & ~1); > > + } > > Check is some-what redundant. Just use: > module = (HMODULE)((ULONG_PTR)module & ~1); I use the same (and more readable) test as RtlImageDirectoryEntryToData > > - void *proc = name ? find_named_export( module, exports, > > exp_size, name->Buffer, -1 ) - : > > find_ordinal_export( module, exports, exp_size, ord - exports->Base ); + > > void *proc = NULL; > > + if (name) > > + { > > + proc = find_named_export( module, exports, exp_size, > > name->Buffer, -1 ); + } > > + else > > + { > > + proc = find_ordinal_export( module, exports, exp_size, ord - > > exports->Base ); + } > > Any reason for this? It's the same no matter how you write it only 7 > lines longer <g> Because i found it more readable. using call functions in ternary operator make code unreadable. > > Vitaliy Margolen Regards, Raphael

Nov. 28, 2005

Re: powerpoint: images upside down

by Cihan Altinay

Quoting Huw D M Davies <h.davies1(a)physics.ox.ac.uk>: > On Mon, Nov 28, 2005 at 05:58:50PM +1000, Cihan Altinay wrote: > > Hi, > > > > When using MS Powerpoint 2003 images are drawn upside down in fullscreen > > (presentation) mode but not in design mode. > > Also, text is drawn correctly as seen on the attachments. > > > > I would appreciate a hint on what traces/logs to provide for more info > > as the dc & win output is quite long. > > It's because there's no implementation of SetBitmapBits for dib > sections. Alexandre committed this patch to the CrossOver tree, I'm > not sure why it didn't make it into WineHQ. Wow, with this patch everything displays perfectly, thanks! I, too, wonder why it isn't in wine yet?! > Huw. Thanks again, Cihan

Nov. 28, 2005

Re: [msvcrt] how to handle msvcr*.dll ?

by Uwe Bonnes

>>>>> "Raphael" == Raphael <fenix(a)club-internet.fr> writes: Raphael> On Monday 28 November 2005 19:46, Daniel Remenak wrote: >> >> <snip>. Windows does not and will not distribute them, and neither >> should wine. What about winelib on non-X86? Raphael> I know that but many application expect they are already there Raphael> (and they are usually installed with microsoft Raphael> patches/packages/...) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Nov. 28, 2005

Re: msvcrt incompatibility in Origin 6.0 when saving documents

by Uwe Bonnes

>>>>> "Olaf" == Olaf Leidinger <leidola(a)newcon.de> writes: Olaf> Hello List! I'm testing Origin 6.0 using wine-0.9.1 and Olaf> everything is really fine except saving documents. I'm getting a Olaf> crash here. Just before that crash there is a dialog telling me: Olaf> "File not saved. Please ensure that the disk isn't full" (roughly Olaf> translated). Using a native version of msvcrt everything works Olaf> fine. So I suppose that the problem lies in the builtin msvcrt ;-) Olaf> Running origin60.exe using +relay, I also get the message dialog, Olaf> but the app doesn't crash. (Timing problem?) Olaf> Perhaps anybody could tell me where to start looking for the Olaf> problem. Going trough the +relay-logs I can't find anything Olaf> suspect. But I'm not very familliar with the win32 api ;-( Try running the application with the debugger and builtin msvcrt. Perhaps you get a backtrace of the crash. Otherwise try in the relay trace (builtin msvcrt, showing the messagebox but not the crash) to find where the messagebox is called. You can seach for the message text. Now work up the log and try to find why the program decides to emit the messagebox. Hope this helps! -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Nov. 28, 2005

Re: [ntdll] fix GetProcAddress on mapped modules as data

by Vitaliy Margolen

Monday, November 28, 2005, 3:29:51 PM, Raphael wrote: > Hi, > fix crash on Corel 9 start > (http://bugs.winehq.org/show_bug.cgi?id=2884) > Changelog: > - don't crash on GetProcAddress when input mapped modules as data I think you need to make some tests of this. It shouldn't be to hard to load some dll as a resource and try to get proc address. Also check if you can do that for already loaded dll (like kernel32.dll). Now the patch: > + if ((ULONG_PTR)module & 1) > + { > + module = (HMODULE)((ULONG_PTR)module & ~1); > + } Check is some-what redundant. Just use: module = (HMODULE)((ULONG_PTR)module & ~1); > - void *proc = name ? find_named_export( module, exports, exp_size, name->Buffer, -1 ) > - : find_ordinal_export( module, exports, exp_size, ord - exports->Base ); > + void *proc = NULL; > + if (name) > + { > + proc = find_named_export( module, exports, exp_size, name->Buffer, -1 ); > + } > + else > + { > + proc = find_ordinal_export( module, exports, exp_size, ord - exports->Base ); > + } Any reason for this? It's the same no matter how you write it only 7 lines longer <g> Vitaliy Margolen

Nov. 28, 2005

Re: Question about X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0)

by Raphael

On Monday 28 November 2005 20:37, L. Lenders wrote: > Hi,thanks for looking into this. Appearantly this bug > is different from the ones you're writing the patch > for. I found that when i run it like this: > WINEDEBUG=+relay,seh wine doom3.exe 2>/dev/null > the app comes up just fine. Somehow it needs to be > slowed down a bit. I'll do some more digging to see if > i can find anything useful. The bug must not be > closed, as doom3 _does_ crash when i run it with > current cvs in a normal way. Hi, can you try to provide a WINEDEBUG=+tid,+opengl,seh wine doom3.exe log ? seems a race problem Regards, Raphael

Nov. 28, 2005

Re: [msvcrt] how to handle msvcr*.dll ?

by Raphael

On Monday 28 November 2005 19:46, Daniel Remenak wrote: > On 11/27/05, Raphael <fenix(a)club-internet.fr> wrote: > > Hi, > > > > since visual studio .net (2002,3,5) MS provides newer versions of > > msvcrt: - msvcr70.dll > > - msvcr71.dll > > - msvcr80.dll > > ... > > (and same equivalents for msvcp*.dll) > > > > how we will handle that on wine: > > - creating new dll forlders and using forwards to current msvcrt.dll > > or > > - creating only new .spec files on msvcrt folder > > ? > > > > Regards, > > Raphael > > See: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html >/_crt_c_run.2d.time_libraries.asp Particularly the section "What is the > difference between msvcrt.dll and msvcr71.dll?" > ><snip>. >Windows does not and will not distribute them, and neither should wine. I know that but many application expect they are already there (and they are usually installed with microsoft patches/packages/...) > --Daniel Remenak Regards, Raphael

Nov. 28, 2005