wine-devel September 2005

136 participants
273 discussions

by Ann & Jason Edmeades

Hiya, I've got a weird issue and was wondering if anyone could advise on how to resolve. (Comes from a 16bit windows app, but is a more general debugging issue). The problem is ... 1) If I run the application, it just hangs - no overly helpful information at all. 2) If I add WINEDEBUG +relay trace, it runs ok :-) (Workaround...!) 3) If I add anything else on WINEDEBUG other than relay, it fails 4) Running under winedbg didn't help at all - I could code to stop it before the hang but it wouldn't step through to the failure 5) Attaching to the hung process shows code in 16 bit user app, and winedbg didn't overly help there either So - I've (painstakingly) got to the point of failure with the add of debug tracepoints and comparing the relay with the debug statements. Now the odd bit! If you look at dlls\user\wnd16.c, routine RegisterClass16 the final line is: return RegisterClassEx16( &wcex ); If I change this to fred = RegisterClassEx16( &wcex ); TRACE("Here... %d\n", fred); return fred; it all works.....! How can I debug this further? I was thinking about trying to dump the registers before and after the trace statement, but I really can't think of what could be causing the problem! Does windows guarantee any of the registers across a win16 call which we don't honour? What about i386 flags? Any suggestions please? Jason

18 years, 7 months

Crash in printer setup dialog if no printers in list

by Dan Kegel

I just filed http://bugs.winehq.org/show_bug.cgi?id=3415 describing a repeatable crash in Printer Setup when you have no printers. Affects all apps that have a Printer Setup menu item, I bet.

18 years, 7 months

Trying to track down a failure in a native, non-MS DLL for which I have no source

by David D. Hagood

I'm trying to get the Delorme packages (AAA MapNGo, Street Atlas) running under the latest Wine. They used to work back when Wine used the MS DLLs for DCOM, but then they stopped working when Wine started supplying their own DCOM DLLS. Now, they show an inclination to work but for one thing. Both packages use a DLL supplied with the package, mapsys32.dll, which appears to be the main map drawing code. This DLL appears to attempt to load a file FONT.FNT, which appears to be an ASCII file describing certain vector objects used to draw maps. This DLL is failing to load the FONT.FNT file - and that's pretty much a show-stopper. So, I'd like to try to track down the problem and see if I can fix it. Now, I don't work for Delorme, I don't have the source for the DLL, and I am really not a Windows programmer (fortunately I work on embedded systems and Linux). So, I'd like a few pointers - how can I commence to begin to start on this? I know the following things: The FONT.FNT file is being opened (strace shows it being opened). The mapsys32.dll file is being loaded (WINEDEBUG=+relay shows it) The mapsys32.dll does not implement DllRegisterServer (regsvr32 says so). The problem exists even though I've blown away my entire .wine directory and recreated it from scratch. The problem has been in the code for several months, and as of 19 Sept 2005's CVS it still is. So, how can I see what is going on with mapsys32.dll?

18 years, 7 months

Problem with Magellan DataSend and COM ports

by David D. Hagood

I recently tried to install the Magellan DataSend tool to talk to my GPS, and it almost works. However, I did find one funny with it - the program did not "see" the COM ports until I added the following entries into the registry: [HKEY_LOCAL_MACHINE\hardware\devicemap\serialcomm] "COM2"="COM2" "COM1"="COM1" (these were found via a file on the Magellan install CD named win95com.reg). Perhaps these should be added to the Wine registry? Once added, then the program would run - at least right up to the point where I told it to download the data to the GPS, at which point it threw and exception and died.

18 years, 7 months

fixme:win:LockWindowUpdate

by Esko Woudenberg

There are several parts of a C++ Builder app I am working on that try to call the LockWindowUpdate() WIN32 api call it appears to result in a wine crash with the following error: fixme:win:LockWindowUpdate (0x2002a), partial stub! Where do I go to find out who (if anyone) is working on support for that? (Would this be a horrible place for someone COMPLETELY new to wine to start trying to contribute?) Esko __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

18 years, 7 months

CopyEnhMetaFile() on big endian arch

by Phil Krylov

Hi, My problem is: CopyEnhMetaFile() creates a .wmf file from a HENHMETAFILE by simple dumping of data to the file. On big-endian platforms (in my case - PowerPC) the resulting file is not a valid WMF. To make it valid, we need to convert all binary data to little-endian. I'd like to make it work. Can someone suggest where the byte order should be reversed? Should it be done in the HENHMETAFILE stored in memory, or should rather CopyEnhMetaFile parse the whole metafile and byte-reverse all data that should be dumped to disk? In any case, it seems to be a huge task. If someone is also interested, probably we should cooperate with each other? -- Ph.

18 years, 7 months

build errors

by Phil Krylov

Hi, I can't build current CVS version of Wine: ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./kernel32.spec comm.drv.spec.o krnl386.exe.spec.o stress.spec.o system.drv.spec.o toolhelp.spec.o win87em.spec.o windebug.spec.o atom16.o error16.o kernel16.o registry16.o toolhelp16.o win87em.o actctx.o atom.o change.o comm.o computername.o console.o cpu.o debugger.o dosmem.o editline.o environ.o except.o fiber.o file.o file16.o format_msg.o global16.o heap.o instr.o kernel_main.o lcformat.o local16.o locale.o lzexpand.o module.o ne_module.o ne_segment.o oldconfig.o path.o powermgnt.o process.o profile.o pthread.o relay16.o resource.o resource16.o selector.o snoop16.o stress.o string.o sync.o syslevel.o system.o tape.o task.o thread.o thunk.o time.o toolhelp.o utthunk.o version.o virtual.o volume.o vxd.o windebug.o wowthunk.o relay16asm.o kernel32.dll.dbg.o kernel.res -Wl,--image-base,0x7b800000 -o kernel32.dll.so -L../../dlls -L../../dlls/ntdll -lntdll -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port comm.drv.spec.o(.data.rel.ro+0x1f6): In function `__wine_stub_GETDCB': /home/phil/build/wine/dlls/kernel/comm.drv.spec.c:38: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x1d0): In function `__wine_spec_stress_dll_fini': /home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x1e8):/home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x200):/home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x218):/home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to `__wine_call_from_16_long' stress.spec.o(.data.rel.ro+0x230):/home/phil/build/wine/dlls/kernel/stress.spec.c:297: more undefined references to `__wine_call_from_16_long' follow system.drv.spec.o(.data.rel.ro+0x1d0): In function `__wine_spec_system_drv_fini': /home/phil/build/wine/dlls/kernel/system.drv.spec.c:303: undefined reference to `__wine_call_from_16_word' system.drv.spec.o(.data.rel.ro+0x1e8):/home/phil/build/wine/dlls/kernel/system.drv.spec.c:303: undefined reference to `__wine_call_from_16_word' system.drv.spec.o(.data.rel.ro+0x200):/home/phil/build/wine/dlls/kernel/system.drv.spec.c:303: undefined reference to `__wine_call_from_16_word' Am I the only one? Can you suggest something? -- Ph.

18 years, 7 months

Fwd: Re: riched versions... then comdlg

by wino＠piments.com

Hi Andreas, I have just come accross something that looks very similar to my problem. A wine bug that is over a year old reported on a debian installation of wine and posted as a bug on winehq. the bug has had no follow-ups since it was posted a year ago in August. http://www.winehq.org/hypermail/wine-bugs/2004/08/0084.html Seems that there is a strong chance this one is a wine issue rather than the app I am trying to run. Thanks for you comments. ------- Forwarded message ------- From: wino(a)piments.com To: "Andreas Mohr" <andi(a)rhlx01.fht-esslingen.de> Cc: Subject: Re: riched versions... then comdlg Date: Mon, 26 Sep 2005 13:04:32 +0200 Thanks , picking up on the one again having cleared the riched20 issues. the bz2 is the output of: WINEDEBUG=+dll,+file wine natspeak &>/tmp/msvcrt.log I specified msvcrt.dll as native/builtin but it still throws and error version <unspecified> and says it needs 6.?xxxx the end of the file reads: trace:file:append_entry long L"sx96v32.dll"... short L""... mask L"msvcrt.dll" trace:file:match_filename (L"sx96v32.dll"..., L"msvcrt.dll") trace:file:append_entry long L"sx96.ini"... short L""... mask L"msvcrt.dll" trace:file:match_filename (L"sx96.ini"..., L"msvcrt.dll") trace:file:FindNextFileW returning L"msvcrt.dll" (L"") trace:file:RtlDosPathNameToNtPathName_U (L"c:\\windows\\system\\msvcrt.dll",0x7bacee0c,0x7bacee08,(nil)) trace:file:RtlGetFullPathName_U (L"c:\\windows\\system\\msvcrt.dll" 520 0x7baceb50 0x7bacee08) so it seems to have found it but you will surely make more of this output than I can. TIA. On Sun, 25 Sep 2005 22:09:50 +0200, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote:

18 years, 7 months

Re: Partial solution to the unimplemented API: user32.RealChildWindowFromPoint

by Robert Shearman

Tisheng Chen wrote: >User32.RealChildWindowFromPoint is not implemented >yet. This causes foobar2000 (with foo_ui_columns) to >crash, whenever you right-click on a panel. > >This patch is only a partial solution. It just stop >the crash of programs like foobar2000. But the >functionality is not quite correct. It just uses >ChildWindowFromPointEx to find and return a >childwindow, since I don't really understand the >difference between them. > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… It seems that RealChildWindowFromPoint doesn't recurse into deeper windows, except for HTTRANSPARENT windows, where it recurses deeper than ChildWindowFromPoint to find a window that doesn't return this hit-test (except if it is a static control). What a mess for developers... Two comments on the patch: 1. Please send patches as text attachments. Usually, renaming to .diff or .txt before attaching is enough to make this happen. 2. "+ FIXME("partial stub. HWND: 0x%lx\n", (DWORD) hwndParent);" -> don't cast hwndParent to DWORD, just change the format to %p. Thanks for the patch, >Hope someone else will implement a better one. > > -- Rob Shearman

18 years, 7 months

Re: DDraw: Better flag handling in SetCooperativeLevel

by Lionel Ulmer

On Thu, Sep 08, 2005 at 12:03:52PM +0200, Stefan Dösinger wrote: > Changelog: > *Add handling for DDSCL_SETFOCUSWINDOW in SetCooperativeLevel > *Print a fixme for DDSCL_CREATEDEVICEWINDOW and DDSCL_SETDEVICEWINDOW. Alexandre, any reason why this patch (plus the other about the reference counting) were not applied ? If you were waiting for some DDraw 'guru' to give his blessing, they both look OK to me :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

18 years, 7 months

← Newer
1
2
3
4
5
6
7
8
...
28
Older →

Jump to page:

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 September 2005