- Wine-Devel - list.winehq.org

Problem with Magellan DataSend and COM ports
by David D. Hagood Sept. 27, 2005

Sept. 27, 2005

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.

1 0

fixme:win:LockWindowUpdate
by Esko Woudenberg Sept. 27, 2005

Sept. 27, 2005

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

2 1

CopyEnhMetaFile() on big endian arch
by Phil Krylov Sept. 27, 2005

Sept. 27, 2005

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.

1 0

build errors
by Phil Krylov Sept. 27, 2005

Sept. 27, 2005

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.

7 7

Fwd: Re: riched versions... then comdlg
by wino＠piments.com Sept. 27, 2005

Sept. 27, 2005

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:

1 0

Re: Partial solution to the unimplemented API: user32.RealChildWindowFromPoint
by Robert Shearman Sept. 27, 2005

Sept. 27, 2005

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

1 0

Re: DDraw: Better flag handling in SetCooperativeLevel
by Lionel Ulmer Sept. 27, 2005

Sept. 27, 2005

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/

2 1

large file support and GetDiskFreeSpace gets wrong info on > 2GB disks
by Vijay Kiran Kamuju Sept. 27, 2005

Sept. 27, 2005

Hi Alexander We should add the following lines to the configure script to check for large file support in the kernel. As the GetDiskFreeSpace gets wrong information regarding the disk space on disks > 2GB. dnl This test must come as early as possible after the compiler configuration dnl tests, because the choice of the file model can (in principle) affect dnl whether functions and headers are available, whether they work, etc. AC_SYS_LARGEFILE CFLAGS="$CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}" AC_CHECK_SIZEOF(off_t, 64, [ #include <stdio.h> #include <sys/types.h> #include <unistd.h> ]) Thanks Vijay

2 1

Steam broken again
by Ivan Gyurdiev Sept. 26, 2005

Sept. 26, 2005

Is anyone interested in looking at: http://bugs.winehq.org/show_bug.cgi?id=3293 I can provide trace output, if you let me know what you need traced (ole? dbghelp? oleaut?). It would be nice if Steam could be made to work, so Oliver's D3D work can be tested w/ Half Life 2. Steam used to work, but an update has broken it again.

3 4

Re: msvcrt: portable printf integer conversions
by Mike McCormack Sept. 26, 2005

Sept. 26, 2005

Hi Jesse, Jesse Allen wrote: > Here's a patch to start the work on getting our own printf number > conversions done internally. It adds pf_integer_conv, which is > capable of handling d,x,o,u,i. However, a large part of my intent is > to add support for I64 size integers. So I've decided to only foward > I64 sizes to it at this time, and leave the rest intact, as I've only > tested I64. I sent a message to wine-devel last night for comments, > but it seems to have gotten lost. We need to guage how to restructure > the printf code, especially since I've found two bugs in our current > implementation. Code to handle %I64 and %I32 has been missing for a while. Thanks for looking into this. Please make sure to write some test cases, as changing it will probably break something (or even make some of the current test cases pass). If you look at glibc's printf code, you'll realize how messy complete printf handling is... IMO, it would be better to let glibc handle the complexities of printf where possible, and work around the differences as we have done so far. Some comments on the patch: > + if( flags->Format == 'X' ) > + digits = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"; > + else > + digits = "0123456789abcdefghijklmnopqrstuvwxyz"; Do you really need the whole alphabet? > + else if( *(p+1) == '3' && *(p+2) == '2' ) > + { > + FIXME("%%I32 unhandled\n"); > + p += 3; > + } > + else > + { > + FIXME("%%I unhandled\n"); > + p++; Seems like if you have the code to do %I64, then doing %I32 would be easy too... I think that you'll find that %I31 is invalid, but again you'll need a test case to make sure. Mike

2 2