January 2008 - Wine-devel - list.winehq.org

Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
by Alexandre Julliard 18 Jan '08

18 Jan '08

"Jason Green" <jave27(a)gmail.com> writes: > + > +#ifdef TRACE_SYMBOL_LIST > + TRACE("\n\n***** sorting the table {count = %d}\n\n", module->num_sorttab); > +#endif > + > + qsort(module->addr_sorttab, module->num_sorttab, sizeof(struct symbol_entry), symt_cmp_addr_and_size); > + > + generateSymbolChains(module); > + > + > +#ifdef TRACE_SYMBOL_LIST > + if (0){ > + ULONG64 prevAddr = 0; Please don't add ifdef'ed out code, it should either be compiled always, or removed completely. > + sizeof(SYMBOL_INFO), Symbol->SizeOfStruct, > + (intptr_t)&Symbol->SizeOfStruct - (intptr_t)Symbol, > + (intptr_t)&Symbol->TypeIndex - (intptr_t)Symbol, > + (intptr_t)&Symbol->Reserved[0] - (intptr_t)Symbol, Don't use stdint.h types, there are Win32 types for that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: qmgr [1/3]: Implement IClassFactory methods.
by Alexandre Julliard 18 Jan '08

18 Jan '08

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > I split the last patch into three. This is essentially the same as the last > one Roy sent, but cleaned up a bit. This adds the IClassFactory methods for > BITS. When sending a patch written by someone else, please include a From: line with the proper attribution in your message. -- Alexandre Julliard julliard(a)winehq.org

1 0

appdb hosed
by Dan Kegel 18 Jan '08

18 Jan '08

The left nav bars are broken, can't approve any new test data.

2 3

re: add HKLM/System/MountedDevices to be added by default
by Dan Kegel 18 Jan '08

18 Jan '08

c.f. wrote: > this is suggested on quite some places in appdb to make seucrom based games come a litle further Discussed at http://bugs.winehq.org/show_bug.cgi?id=7065#c58 Looks like something of this sort is already in, you must have blinked :-)

1 0

add HKLM/System/MountedDevices to be added by default
by Christoph Frick 17 Jan '08

17 Jan '08

this is suggested on quite some places in appdb to make seucrom based games come a litle further --- tools/wine.inf | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf b/tools/wine.inf index c3cb89c..f63fb23 100644 --- a/tools/wine.inf +++ b/tools/wine.inf @@ -362,6 +362,8 @@ HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-99 HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"IsInstalled",2,1 HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"Locale",2,"*" HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"Version",2,"4,74,9273,0" +; SecuROM needs this key +HKLM,System\MountedDevices,,,"" [Nls] HKLM,System\CurrentControlSet\Control\Nls\Codepage,"37",,"" -- 1.5.3.7

2 2

Re: [PATCH] support for synchronous and non-buffered I/O
by Dave Hansen 17 Jan '08

17 Jan '08

On Tue, 2008-01-15 at 23:10 -0800, Dave Hansen wrote: > I have a little Eye-Fi card (http://www.eye.fi) The software to > control it is a windows application that writes to control files which > appear in a DOS filesystem on the SD card. (you can read more > information here: http://dave-hansen.blogspot.com/) > > However, the application does not quite work under wine. The > application writes to the card, but doesn't get the results it expects. > It loops doing read()s of the files looking for results until it times > out. Do me a favor and don't apply this quite yet. I'll repost when it's ready. -- Dave

1 0

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