wine-devel January 2008

wine-devel@winehq.org

126 participants
290 discussions

Valgrinding large win32 app worked!
by Dan Kegel 17 Jan '08

17 Jan '08

This script, http://kegel.com/wine/valgrind/valgrind-330-build.sh builds a copy of valgrind-3.3.0 with John Reiser's forward port of the Wine support patch. With that, I can run Picasa for Windows under Wine under Valgrind. It takes 40 seconds to start up on my 1.3GHz Athlon 64, which is right in line with Valgrind's legendary ~10x overhead. It seemed to find lots of little problems, but since there were lots of numeric addresses without symbolic info in the valgrind log, it wasn't directly useful to the Picasa developers. The next step, I suppose, is to find a way to make the valgrind log contain symbolic identifiers for the functions in the Windows app. I looked at that for a few minutes; here are some notes that might provide a starting point. http://www.debuginfo.com/articles/gendebuginfo.html is the best overview I've seen so far on how to tell Visual C++ to generate debugging info; for most apps, the preferred debug info format will be .pdb. http://www.debuginfo.com/articles/dbghelptypeinfo.html has an example win32 app that will dump all public symbols from a win32 app. It runs fine on Windows XP, and can dump symbols for Picasa (generating a 9MB text file). (I happen to have the .pdb file for Picasa handy since I are an honorary Picasa developer.) Sadly, that symbol dumper crashes on Wine, see http://bugs.winehq.org/show_bug.cgi?id=11211 Also, the unresolved error addresses in the valgrind trace were mostly in the 0x400000 - 0x420000 range, whereas the symbols dumped by that dumper app were all in the range 0x1000000 - 0x1080000... maybe the base load address is different between the two OS's. I haven't tried valgrinding a toy app yet, but that's probably the easiest way to figure out how to match the symbols up. - Dan

4 6

bugzilla component and keyword cleanup
by Jan Zerebecki 17 Jan '08

17 Jan '08

I'm done with one step of the changes. See the following URLs for how things currently look: http://bugs.winehq.org/describekeywords.cgi http://bugs.winehq.org/describecomponents.cgi?product=Wine Improvement suggestions are welcome. Does anyone know how the CVS/GIT version is marked so that it gets selected on the new bug page and if that is also possible for the component? Now for further improvements: Changes which IMHO should not be done: wine-help -> hhctrl - Help viewer implementation help is currently not for the various help APIs but for user that want help. We should obsolete this component. We can create a new component for the help APIs if there is demand. (new) -> vdm - Wine 16-bit compatibility layer (new) -> win16 - Wine 16-bit compatibility layer vdm is part of the component dos, right? A win16 keyword is probably useful as win16 support is intertwined in quite some other DLLs and thus components. Components that are marked as obsolete now, but where it's not sure how to replace them: multimedia Should we really replace this? Replace it with what? An mci and winmm component? console I didn't really made my mind up about this one yet... files ipc ports winelib Possibly replace each with a keyword, see below. Changes to the keywords: conformance (delete) Delete this keyword, because it fits probably most wine bugs. testcase (new) Bugs that have a testcase attached, in source form but not necessarily integrated into the Wine test suite. win16 (new) Bugs in the win16 parts of Wine. dotnet (new) Bugs that appear in applications using dotNet and that are related to this dotNet useage. winelib (new) Bugs during winelib useage but not during useage through windows native executables. ports (new) Bugs regarding porting to specific platforms or OSs. FIXME needs clarification tasklet needs clarification tasklist needs clarification Abandoned? -> needmoreinfo This is currently discussed in another thread. filesystem (new) Do we want such a component? Is it maybe related with console? What exactly should it cover? Only things that possibly can destroy data? console (new) I didn't really made my mind up about this one yet... Jan

3 4

Re: kernel32: Intialise 16-bit stack to zero.
by Alexandre Julliard 17 Jan '08

17 Jan '08

Robert Shearman <rob(a)codeweavers.com> writes: > --- > dlls/kernel32/kernel_main.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Otherwise dbghelp could sometimes get confused and think it should > switch to 16-bit mode. > This results in messages such as the following when warn or tracing > for the heap channel is turned on: > fixme:dbghelp:Failed to linearize address ????:55555555 ... Initializing the first frame should be enough. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: ntdll: Do not perform base relocation if an image is not a DLL. Take 2
by Paul Chitescu 17 Jan '08

17 Jan '08

Dmitry, IMHO it doesn't worth to the to relocate EXEs since virtually none are providing relocation records. Any operating system that can't allocate memory at low virtual addresses won't be able to run any Windows application newer than about 13 years (that is, all of interess). EXEs were relocated only in Win32s where all applications were sharing a single address space. Since Visual C 4 the linker default is to not generate relocations for EXE files. Paul Chitescu On Thu, 17 Jan 2008, Dmitry Timoshkov wrote: > Hello, > > this patch fixes the problem reported in the bug 11170. It appears that > LoadLibrary in Windows doesn't attempt to relocate .exe files. > > Alexandre noticed that previous version of the patch may break relocation of > the main exe. This version addresses that. However, this appears to be not > compatible with what Windows (does not) do: in order to force a relocation > of main under XP I set its base address to match the ntdll.dll (0x7c900000), > and XP just refused to load the exe with an error message "The system cannot > execute the specified program." But we may need to relocate main exe due to > environment limitations (some native .so file may be mapped at that address). > > Changelog: > [...]

1 0

Time to create a stub wmvcore.dll?
by Dan Kegel 17 Jan '08

17 Jan '08

There seem to be a large number of apps that don't start unless a wmvcore.dll is present: TVersity Phatnoise Lost Planet The Bard's Tale WMA Workshop MixMeister ... So, how 'bout it? Should we create a stub for wmvcore.dll and friends? - Dan

2 1

Easy usage of native DLLs in Linux programs
by Radovan Skolnik 17 Jan '08

17 Jan '08

Hello! I have found this old thread dealing exactly with what I need: http://www.winehq.org/pipermail/wine-devel/2006-April/046779.html It basically proposes a work to be done to allow loading native Windows DLLs into Linux binaries (for example loading WinAmp plugins into xine/mplayer/gst/...). I am in the need to use a small DLL (no GUI, just few APIs that are all already implemented) which I have no source code to. Has this initiative progressed to something? If not can anybody advise on how I shoudl proceed wrapping native DLL into .so? I have looked over the mplayer code to load Windows codecs but I couldn't really grasp the idea - the are no comments with the code :-( Thank you and best regards Radovan Skolnik

2 1

Getting Mozy to work
by Christopher 17 Jan '08

17 Jan '08

3 3

Re: Request for patch removal
by Dmitry Timoshkov 17 Jan '08

17 Jan '08

"Federico Vecchiarelli" <fedev(a)gmx.net> wrote: > Ok, to the point. The patch mentioned below prohibits wine from running > any application which is inside someone else's folder, even if you have > access to it. In my case, I wanted to make one unique installation > available to several users. Because of this patch, there is no > workaround that could be implemented, forcing me to either run a script > changing the owner of the folders for every user as they want to use the > application or I have to make several copies of the software which will > put me in a difficult legal situation. All the details about this problem you can find here: http://bugs.winehq.org/show_bug.cgi?id=11112 -- Dmitry.

6 6

valgrind and +heap not getting along?
by Dan Kegel 17 Jan '08

17 Jan '08

I'm seeing fun traces like ==17177== Invalid write of size 1 ==17177== at 0x4022D5A: memset (mc_replace_strmem.c:492) ==17177== by 0x46E914A: mark_block_free (heap.c:148) ==17177== by 0x46E6950: HEAP_CreateFreeBlock (heap.c:493) ==17177== by 0x46E6B78: HEAP_ShrinkBlock (heap.c:575) ==17177== by 0x46E7F47: RtlAllocateHeap (heap.c:1228) ==17177== by 0x46EC10A: get_builtin_fullname (winnt.h:1989) ==17177== by 0x46EC2B8: load_builtin_callback (loader.c:1320) ==17177== by 0x402C3BF: wine_dll_set_callback (loader.c:480) ==17177== by 0x46EF3A7: __wine_process_init (loader.c:2529) ==17177== by 0x402C7D5: wine_init (loader.c:645) ==17177== by 0x7BF01263: main (main.c:111) ==17177== Address 0x7f000140 is not stack'd, malloc'd or (recently) free'd when running with +heap under valgrind. Is something off by one somewhere? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Shader compiler GL error
by Markus 16 Jan '08

16 Jan '08

Hi, while trying to fix the bug I posted a few days ago, the game's developer pointed out on request that the ingame shader issues are not related to the graphics card detection but more likely to a failing shader compilation. They are using d3d9_33.dll for development and recommended to try with this version. I've thus removed all other versions of the library and also deleted the game's cached shaders. The game now crashes on startup with the following error: fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 If I use d3d9_31.dll instead, the shaders are compiled and the game starts but the water is again looking like a low-end fallback. Any ideas on this? Regards, -- Markus

2 4

← Newer
1
...
10
11
12
13
14
15
16
...
29
Older →

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 January 2008