- Wine-Devel - list.winehq.org

Re: OLEAUT32 (resend) Floating point locale, no negative zero
by Alex Villacís Lasso May 30, 2005

May 30, 2005

Alexandre Julliard wrote: > Alex Villacis Lasso <a_villacis(a)palosanto.com> writes: > > > >> Changelog: >> * Force Single|Double conversion to BSTR to use the decimal separator >> defined by the current locale, because that is what native oleaut32 >> does, and to be consistent with later parsing of floating-point >> numbers, which uses current locale. Failure to apply this patch causes >> vartype test to fail in non-US locales with a decimal separator other >> than a period. >> * The number form "-0" is *not* allowed to be returned in a >> Single|Double conversion to BSTR in case of numeric undeflow, use >> unsigned zero instead. Some applications depend on this. Test included. >> > > > That's ugly, I think we really want to do our own formatting instead > of using the system printf and hacking the string afterwards. > > > By "our own formatting", do you mean to reimplement the %f and %lf functionality of the system printf() in a Wine-specific function? It can be done, of course, but I thought there was a good reason for the original code to rely on the system printf() for the floating-point formatting. Then there is the question of whether the potential patch is still allowed to use GetNumberFormatW for the (dwFlags & LOCALE_USE_NLS) case. This function seems to relay on the decimal separator being a period (as built by sprintfW). A more recent patch I sent used GetNumberFormatW for the non-NLS case to achieve the substitution of the period for whatever the decimal separator was in the current locale. However, GetNumberFormatW() cannot do anything about the negative zero issue, so that was still handled in the VARIANT_BstrFromReal() function of vartype.c. How much formatting should the new formatting function do? Is it enough to handle the negative zero and the decimal separator, and use sprintfW() for the LOCALE_USE_NLS case (as the current code does), or does it have to reimplement the functionality currently delegated to GetNumberFormatW()? I will start making a patch assuming the first scenario (use new function just for non-NLS case). Please answer if anybody thinks it should be done otherwise. Alex Villacís Lasso

1 0

CryptUnprotectData undeclared - cannot compile
by Pavel Troller May 30, 2005

May 30, 2005

Hi! For some time, about 10 - 14 days, I cannot compile wine from CVS anymore. The reason is as follows: make[3]: Entering directory `/usr/src/emul/wine/dlls/crypt32/tests' ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole protectdata.o testlist.o -o crypt32_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../libs -lcrypt32 -s -L/opt/ungif/lib protectdata.o(.text+0x3b5): In function `test_cryptunprotectdata': /usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:114: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x42f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:120: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x4b9):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:129: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x54f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:140: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x702):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:160: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x782):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:167: more undefined references to `CryptUnprotectData' follow collect2: ld returned 1 exit status The same reported another user on the user's list, but nobody noticed it. It would be nice to fix this problem to be able to compile wine again. With regards, Pavel Troller

4 7

Hint for Wine + Type1 + FrameMaker / Update for the Font HOWTO
by Dag Wieers May 30, 2005

May 30, 2005

Hi Avi, Having spend endless hours looking for how to make Wine and Type1 fonts working together. I finally decided to convert my Type1 fonts to Truetype (after a hint by someone that Wine does not have Type1/Adobe support). Note: I'm not sure if this is true since there is a wine [afmdirs] section in the wine config. Wine still had troubles with (at least) some of the files. Converting Type1 fonts to Truetype fonts was easy and Framemaker actually has a hidden feature to find out which fonts are missing. When you load your FrameMaker document and you have missing fonts, it wants to reformat your file. After you allow that, just look at the available fonts, suddenly you have a few extra ones in the list that have been disabled. These are the fonts FrameMaker requires and couldn't find. Note down the names as they appear in the list, quit the document without saving (!), then go look for the Type1 fonts that match the name using grep. Open them in fontforge (http://fontforge.sourceforge.net/) if necessary change the Family Name to what you wrote down and safe it as a Truetype font. If you do that for all the files involved, everything works fine. I added this explanation to my document bits (for google) http://dag.wieers.com/howto/bits/wine-framemaker-type1.php So fontforge should definitely be part of the Font HOWTO and maybe something about Wine and Type1 support (and FrameMaker) too ? PS I included the Wine list too, as I looked there for answers first. I bet some more people will do the same and come across this thread. Hope this helps and thanks for a great resource, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]

1 0

Re: tab: Shift selected tab text up instead of down
by Vitaliy Margolen May 30, 2005

May 30, 2005

Sunday, May 29, 2005, 2:17:12, Vitaliy Margolen wrote: > Hi, > Changelog > * Shift selected tab text up instead of down. >- drawRect->>bottom += 3; >+ drawRect->>bottom -= 3; This does not shift tab up. This will shrink tab text area instead of growing it. Also you missed note above about keeping TAB_DrawItem in sync with this part. All these numbers had been verified against native, including custom drawn tabs (see WM_DRAWITEM message). Vitaliy.

3 2

Re: [DSOUND]multiple DIRECTSOUND object support
by Alexandre Julliard May 30, 2005

May 30, 2005

Robert Reif <reif(a)earthlink.net> writes: > Add multiple DIRECTSOUND object support (multiple sound cards can play > at the same time). > Fix CoCreateInstance when no sound card is present. > Fix create bug found by Mike Hearn. This is causing major trouble with make test for me: ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so ds3d.c && touch ds3d.ok wine: Unhandled exception (thread 003c), starting debugger... WineDbg starting on pid 0x3a Unhandled exception: page fault on read access to 0x88d9a3d0 in 32-bit code (0x779a6b3b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:779a6b3b ESP:7292809c EBP:729280ac EFLAGS:00010a13( - 00 ROIA1C) EAX:11154d54 EBX:779bfc58 ECX:0063006c EDX:3bad4fe3 ESI:779bfb48 EDI:77c453e0 Stack dump: 0x7292809c: 00000020 779bfc58 00000019 77c453e0 0x729280ac: 729280c8 779a7349 77c453e0 ff9cff99 0x729280bc: 77978600 00008000 779a71d4 729280f0 0x729280cc: 7795c80b 00008000 000003bd 77c453e0 0x729280dc: 77c45500 00000000 72ad5e00 000003bd 0x729280ec: 72ad8b40 72928120 72ab84d8 779a71d4 Backtrace: =>1 0x779a6b3b DSOUND_WaveQueue+0x9b(device=0x77c453e0, mixq=0xff9cff99) [/home/julliard/wine/wine/dlls/dsound/mixer.c:931] in dsound (0x729280ac) 2 0x779a7349 DSOUND_callback+0x175(hwo=0x8000, msg=0x3bd, dwUser=0x77c453e0, dw1=0x77c45500, dw2=0x0) [/home/julliard/wine/wine/dlls/dsound/mixer.c:1168] in dsound (0x729280c8) 3 0x7795c80b DriverCallback+0x1a3(dwCallBack=0x779a71d4, uFlags=0x3, hDev=0x8000, wMsg=0x3bd, dwUser=0x77c453e0, dwParam1=0x77c45500, dwParam2=0x0) [/home/julliard/wine/wine/dlls/winmm/driver.c:521] in winmm (0x729280f0) 4 0x72ab84d8 wodNotifyClient(wwo=0x72ad8b40, wMsg=0x3bd, dwParam1=0x77c45500, dwParam2=0x0) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1330] in wineoss.drv (0x72928120) 5 0x72ab8a16 wodPlayer_NotifyCompletions+0xea(wwo=0x72ad8b40, force=0x1) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1561] in wineoss.drv (0x72928144) 6 0x72ab8aa2 wodPlayer_Reset(wwo=0x72ad8b40, reset=0x1) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1610] in wineoss.drv (0x7292817c) 7 0x72ab8d3e wodPlayer_ProcessMessages(wwo=0x72ad8b40) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1701] in wineoss.drv (0x729281b0) 8 0x72ab8fe5 wodPlayer(pmt=0x0) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1795] in wineoss.drv (0x729281dc) 9 0x77bd8867 THREAD_Start(ptr=0x77c45500) [/home/julliard/wine/wine/dlls/kernel/thread.c:107] in kernel32 (0x729282a8) 10 0x77ee09aa start_thread+0x142(info=0x77c45520) [/home/julliard/wine/wine/dlls/ntdll/thread.c:204] in ntdll (0x72928ad8) 11 0xb7fb1b63 start_thread+0x93 in libpthread.so.0 (0x72928b4c) 12 0xb7f5018a __clone+0x5a in libc.so.6 (0x00000000) 0x779a6b3b DSOUND_WaveQueue+0x9b [/home/julliard/wine/wine/dlls/dsound/mixer.c:931] in dsound: pushl 0x29c(%eax,%edi,1) 931 waveOutWrite(device->hwo, device->pwave[device->pwwrite], sizeof(WAVEHDR)); -- Alexandre Julliard julliard(a)winehq.org

1 0

CRYPTPROTECT_LOCAL_MACHINE in CryptProtectData
by Michael Jung May 30, 2005

May 30, 2005

Hi Kees, rsaenh uses your Crypt[Un]ProtectData functions for protecting the user's private keys, which are stored in the registry. For machine key pairs (which are keys that belong to the machine instead of a certain user), rsaenh needs support for the CRYPTPROTECT_LOCAL_MACHINE flag. On possible implementation would be to derive the key from the computer name (GetComputerName) instead of from the user's login name, if the flag is set. Would you mind implementing something like this? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: Make more of the OLE interface vtables const
by Andreas Mohr May 30, 2005

May 30, 2005

Hi, On Sun, May 29, 2005 at 07:05:49PM +0900, Dmitry Timoshkov wrote: > Hello, > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Make more of the OLE interface vtables const. You do know that those will *not* end up const? filemoniker.c:static const IClassFactoryVtbl FileMonikerCFVtbl = objdump -x ole32.dll.so: 0008efb0 l O .data 00000014 FileMonikerCFVtbl My suspicion is that this is due to winegcc compile, all other binaries with normal compile (e.g. winedump, ...) have all their const data in .rodata segment... So, does anybody know what seems to be wrong with winegcc or why it chose to do that? BTW, I already completely constified programs/ and tools/, will send a patch soon. Andreas

4 3

Re: rundll32.exe shell32.dll,SHHelpShortcuts_RunDLL
by Dmitry Timoshkov May 30, 2005

May 30, 2005

"Detlef Riekenberg" <wine.dev(a)web.de> wrote: > Changelog: > Partial Implementation of shell32/SHHelpShortcuts_RunDLL > Connect and Disconnect: Forwarded to mpr.dll > AddPrinter: Forwarded to printui.dll > +static int shrundll_compare(const void *p1, const void *p2) > +{ > + struct shrundll_entry *e1 = (struct shrundll_entry *) p1; > + struct shrundll_entry *e2 = (struct shrundll_entry *) p2; > + > +/* > + TRACE("(%p:%p (%ld:%ld) %s:%s)\n",e1, e2, (e1 == NULL) ? 0 : e1->my_id, (e2 == NULL) ? 0 : e2->my_id, debugstr_w((e1 == NULL) ? NULL : e1->name), debugstr_w((e2 == NULL) ? NULL : e2->name)); > +*/ > + > + if((e1 == NULL) | (e2 == NULL)) > + { > + return -1; > + } > + > + return StrCmpW(e1->name, e2->name); I strongly suspect that this comparison should be case insensitive. -- Dmitry.

2 1

Re: question about standalone tests
by Dan Kegel May 30, 2005

May 30, 2005

The STANDALONE stuff is my creation; apologies to anyone offended by it. It does fill a real need, but belongs in wine/test.h, not in each test, I agree. I was being lazy. Now, on to Alexandre's claim: On Tue, May 24, 2005 at 05:24:11PM +0200, Alexandre Julliard wrote: > You should be able to build by simply copying over wine/test.h Tried that. $ wget -O lzexpand_main.c 'http://cvs.winehq.org/cvsweb/~checkout~/wine/dlls/lzexpand/tests/lzexpand_m…' $ mkdir wine $ wget -O wine/test.h 'http://cvs.winehq.org/cvsweb/~checkout~/wine/include/wine/test.h?rev=1.14' $ cl -I. -DWINETEST_WANT_MAIN -D_X86_ lzexpand_main.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. lzexpand_main.c h:\demo\x\wine\test.h(128) : error C2065: 'stdout' : undeclared identifier ... Adding #include <stdio.h> to wine/test.h fixes that first problem, but leaves h:\demo\x\wine\test.h(264) : error C2065: 'winetest_testlist' : undeclared identifier ... So including wine/test.h isn't enough at the moment. Maybe there needs to be a #ifdef STANDALONE ... #endif section in wine/test.h that defines winetest_testlist, etc. I just looked, and it's probably easy to do, but somewhat beyond what I want to do at 2 in the morning. (Besides, I'm not supposed to be typing, my wrists are sore.) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

3 3

Re: UT2003 Regression - Patch at last :-))
by Alexandre Julliard May 29, 2005

May 29, 2005

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes: > Index: painting.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/painting.c,v > retrieving revision 1.29 > diff -u -r1.29 painting.c > --- painting.c 13 May 2005 14:03:06 -0000 1.29 > +++ painting.c 20 May 2005 20:26:24 -0000 > @@ -344,7 +344,7 @@ > if ((hrgn = send_ncpaint( child, NULL, &erase_flags ))) > send_erase( child, erase_flags, hrgn, NULL, NULL ); > > - prev = 0; > + break; The problem is that this will cause children to be skipped too. What you really need is to repaint every window only once, but still recurse for children. Unfortunately that's a bit tricky to do with a stateless interface... -- Alexandre Julliard julliard(a)winehq.org

4 5