wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

OpenOffice 2.0 beta 2 installs ok but locks up in File Open dialog with wine-20050830 + 2 patches
by Dan Kegel 14 Sep '05

14 Sep '05

With wine-20050830 and Mike's two MSI patches (thanks, Mike!), http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… installs properly, and the app even appears to come up normally! However, when you use the File Open dialog box, it seems to lock up. Here's a session log: [dank@localhost program]$ wine soffice.exe fixme:advapi:LookupAccountSidW ((null),sid=0x7ad47428,0x7b949ac4,0x7b949bcc(256),0x7b9497c0,0x7b949bc8(256),0x7b949bc4): semi-stub fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x733c,0,(nil)): almost empty stub! fixme:imm:ImmGetContext (0x10030): stub fixme:imm:ImmReleaseContext (0x10030, 0x7bca5658): stub err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x2 to 0x0 err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x2 to 0x0 err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x0 to 0x2 fixme:commdlg:GetFileName95 Flags 0x02800000 not yet implemented That CoInitializeEx error sounds bad. The error is probably very easy to reproduce, perhaps a wine developer should try it out him/herself. Now to go rescue my wife so she can get some sleep. Having a two-year-old son seriously cuts down the amount of time I have for hacking. I'm doing a talk on Open Source this Thursday night. Mike's amazing turnaround time on the two MSI patches will be a nice story to tell during the talk. Is there any hope of continuing the run of good luck, and actually getting Wine to run OOo2.0 by Thursday? I dare not hope... - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

3 3

Stack overflow problem
by Vitaliy Margolen 14 Sep '05

14 Sep '05

Once more I need your help. It seems that wine is not correct with the way it sets guard pages for stack. Here is an example that works fine on windows, and fails on wine. And yes, I do have a program that does something like this: PDWORD p = TEB.Tib.StackLimit; *p = 0; I'm not sure what to do here. It looks like there are several places that we allocate stack, and both of them set first page (last for stack) as a PAGE_GUARD. Could that be that this wasn't what we wanted? Since both places using size of 1. But this looks like sets whole page to be guard page. -- Best regards, Vitaliy

2 1

Re: Fix Animate Control
by Dmitry Timoshkov 14 Sep '05

14 Sep '05

"Robert Shearman" <rob(a)codeweavers.com> wrote: > Initialize unused members of the MMCKINFO structs to 0 to fix chunk detection with mmioDescend. > --- dlls/comctl32/animate.c 30 Aug 2005 10:07:18 -0000 1.68 > +++ dlls/comctl32/animate.c 13 Sep 2005 20:36:03 -0000 > @@ -476,6 +476,7 @@ static BOOL ANIMATE_GetAviInfo(ANIMATE_I > DWORD numFrame; > DWORD insize; > > + memset(&ckMainRIFF, 0, sizeof(ckMainRIFF)); > if (mmioDescend(infoPtr->hMMio, &ckMainRIFF, NULL, 0) != 0) { I don't think that this is a correct fix, mmioDescend works under Windows without a need to initialize ckMainRIFF. -- Dmitry.

1 0

Re: DSOUND: tolerate inexact conversion between different frequencies
by Alex Villacís Lasso 13 Sep '05

13 Sep '05

Robert Reif wrote: > Alex Villacís Lasso wrote: > >> During the winealsa tests, I am frequently annoyed by the following: >> say, in playing a 11050Hz secondary buffer with an 8000Hz primary >> buffer, the number of samples are converted form secondary->primary >> and back. In the process, the number of consumed samples in the >> secondary buffer drifts by a few frames from the actual value, and >> this triggers the warning about "problem with underflow detection". >> This patch allows a tolerance of up to 4 bytes before issuing the >> message. >> >> Alex Villacís Lasso >> > Does this patch help? It should only fix the errors that are off by > one sample (up to 4 bytes). It will not help with the errors greater > than 4 bytes. > > It works by keeping track of the round off error and factoring it back > in. > >------------------------------------------------------------------------ > >Index: dlls/dsound/buffer.c >=================================================================== >RCS file: /home/wine/wine/dlls/dsound/buffer.c,v >retrieving revision 1.51 >diff -p -u -r1.51 buffer.c >--- dlls/dsound/buffer.c 1 Jun 2005 19:57:42 -0000 1.51 >+++ dlls/dsound/buffer.c 10 Sep 2005 02:20:21 -0000 >@@ -416,7 +416,9 @@ DWORD DSOUND_CalcPlayPosition(IDirectSou > pmix /= This->dsound->device->pwfx->nBlockAlign; > TRACE("primary back-samples=%ld\n",pmix); > /* adjust for our frequency */ >- pmix = (pmix * This->freqAdjust) >> DSOUND_FREQSHIFT; >+ pmix = pmix * This->freqAdjust; >+ This->freqRem = pmix & ((1 << DSOUND_FREQSHIFT) - 1); >+ pmix = pmix >> DSOUND_FREQSHIFT; > /* multiply by our own sample size */ > pmix *= This->pwfx->nBlockAlign; > TRACE("this back-offset=%ld\n", pmix); >@@ -426,6 +428,7 @@ DWORD DSOUND_CalcPlayPosition(IDirectSou > if (This->leadin && ((bplay < This->startpos) || (bplay > This->buf_mixpos))) { > /* seems we haven't started playing yet */ > TRACE("this still in lead-in phase\n"); >+ This->freqRem = 0; > bplay = This->startpos; > } > /* return the result */ >@@ -1123,6 +1126,8 @@ HRESULT WINAPI IDirectSoundBufferImpl_Cr > dsb->buf_mixpos = 0; > dsb->state = STATE_STOPPED; > >+ dsb->freqAcc = 0; >+ dsb->freqRem = 0; > dsb->freqAdjust = (dsb->freq << DSOUND_FREQSHIFT) / > ds->device->pwfx->nSamplesPerSec; > dsb->nAvgBytesPerSec = dsb->freq * >Index: dlls/dsound/dsound_private.h >=================================================================== >RCS file: /home/wine/wine/dlls/dsound/dsound_private.h,v >retrieving revision 1.31 >diff -p -u -r1.31 dsound_private.h >--- dlls/dsound/dsound_private.h 12 Jul 2005 19:21:37 -0000 1.31 >+++ dlls/dsound/dsound_private.h 10 Sep 2005 02:20:22 -0000 >@@ -212,7 +212,7 @@ struct IDirectSoundBufferImpl > DSVOLUMEPAN volpan, cvolpan; > DSBUFFERDESC dsbd; > /* used for frequency conversion (PerfectPitch) */ >- ULONG freqAdjust, freqAcc; >+ ULONG freqAdjust, freqAcc, freqRem; > /* used for intelligent (well, sort of) prebuffering */ > DWORD probably_valid_to, last_playpos; > DWORD primary_mixpos, buf_mixpos; >Index: dlls/dsound/mixer.c >=================================================================== >RCS file: /home/wine/wine/dlls/dsound/mixer.c,v >retrieving revision 1.40 >diff -p -u -r1.40 mixer.c >--- dlls/dsound/mixer.c 3 Aug 2005 19:13:58 -0000 1.40 >+++ dlls/dsound/mixer.c 10 Sep 2005 02:20:22 -0000 >@@ -746,10 +746,19 @@ static DWORD DSOUND_MixOne(IDirectSoundB > * there's no telling what the app is thinking anyway */ > } else { > /* adjust for our frequency and our sample size */ >- probably_valid_left = MulDiv(probably_valid_left, >- 1 << DSOUND_FREQSHIFT, >- dsb->pwfx->nBlockAlign * dsb->freqAdjust) * >- dsb->dsound->device->pwfx->nBlockAlign; >+ ULONGLONG left = probably_valid_left / dsb->pwfx->nBlockAlign; >+ left <<= DSOUND_FREQSHIFT; >+ if (dsb->freqRem >= dsb->freqAcc) >+ left += (dsb->freqRem - dsb->freqAcc); >+ else { >+ DWORD sub = dsb->freqAcc - dsb->freqRem; >+ if (sub > left) >+ left = 0; >+ else >+ left -= sub; >+ } >+ probably_valid_left = left / dsb->freqAdjust; >+ probably_valid_left *= dsb->dsound->device->pwfx->nBlockAlign; > /* check whether to clip mix_len */ > if (probably_valid_left < mixlen) { > TRACE("clipping to probably_valid_left=%ld\n", probably_valid_left); > > I tried this patch. Yes, it does remove the messages about buffer underruns, but it also introduces a delay in the playing of many tests, so they fail with the message "sample played for 1504 ms instead of 1000 ms", with varying values for the actual value of the delay. However, all of these problems went away when I modified my modprobe.conf file: alias eth0 via-rhine alias snd-card-0 snd-via82xx alias snd-card-1 snd-via82xx-modem options snd-card-0 index=0 options snd-via82xx index=0 dxs_support=5 remove snd-via82xx { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-via82xx alias usb-controller ehci-hcd alias usb-controller1 uhci-hcd options parport_pc io=0x378,0xe800 irq=7,none options lp parport=1 alias char-major-4 8250-pci alias char-major-29 savagefb I added the dxs_support=5 option to the snd-via82xx module, and now the tests play correctly. The odd thing is that, when the dxs_support option, I can no longer trigger the buffer underrun message, even without the patch. But since the patch did not make anything worse in any of the actual games I have (with or without dxs_support), I kept it applied.

1 0

Re: Perform automatic bitmap font configuration. Take 4
by Alexandre Julliard 13 Sep '05

13 Sep '05

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -313,10 +312,7 @@ void LOCALE_InitRegistry(void) > } > else TRACE( "updating registry, locale changed none -> %08lx\n", lcid ); > > - sprintf( buffer, "%08lx", lcid ); > - /* Note: '9' constant below is strlen(buffer) + 1 */ > - RtlMultiByteToUnicodeN( bufferW, sizeof(bufferW), NULL, buffer, 9 ); > - NtSetValueKey( hkey, &nameW, 0, REG_SZ, bufferW, 9 * sizeof(WCHAR) ); > + /* GDI32 detects locale change as well, it will update the registry */ You can't depend on GDI updating the kernel's key, they need to be independent. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Perform automatic bitmap font configuration. Take 4
by Huw D M Davies 13 Sep '05

13 Sep '05

On Tue, Sep 13, 2005 at 04:45:30PM +0900, Dmitry Timoshkov wrote: > > +static const struct nls_update_font_list > +{ > + UINT ansi_cp; > + const char *oem, *fixed, *system; > + const char *courier, *serif, *small, *sserif; > +} nls_update_font_list[] = Hi Dmitry, I think you also need to take into account the OEM codepage here. For example in the UK the OEM font would be vga850.fon while in the US it would be vgaoem.fon. Huw.

2 3

Looking for bugs in Wine's Microsoft Installer (MSI) implementation
by Mike McCormack 13 Sep '05

13 Sep '05

Hi All, If anybody is aware of any cases of Wine's Microsoft Installer code not working, please log them in Wine's bugzilla (http://bugs.winehq.org/), assign them to me, and I will attempt to fix them. Make sure to set "msi" = "builtin", "*msiexec" = "builtin" when testing your installers, and if possible test with the latest Wine CVS. If the installer is available as a free download, please include a link to it. thanks, Mike

2 1

GetIDsOfNames
by Walt Ogburn 13 Sep '05

13 Sep '05

Hi guys, Eric Tanguy asked on wine-users a while back about getting some geography games (http://olivier.leflon.free.fr/jeux/jeux.htm) to run. These seem to be Visual Basic, so oleaut32 issues come up. We succeeded with the first one (departments of France - font size problem fixed). Next, there is the issue that some of them call GetIDsOfNames on ole font objects (countries of Europe, http://olivier.leflon.free.fr/jeux/europe.htm). OLEFontImpl_GetIDsOfNames is currently a stub. What's needed is basically just to convert the strings "Name", "Size", "Bold", etc. into DISPID_FONT_NAME, etc. In particular, this game only needs "Size." It's not hard to code that, and make the game work. I'm not sure, though, what the proper approach would be for an acceptable patch: 1. Just code in the string comparisons, ignoring the locale. (Google provides no evidence that the property names vary by locale). 2. Call GetTypeInfo to get an ITypeInfo, and call DispGetIDsOfNames on that. I think this means that the information should be extracted from stdole32.tlb. Currently this doesn't find any match for these property names. Do they need to be added to stdole32.tlb somehow? 3. Something else. Any ideas? Thanks, Walter

2 2

Need help debugging a memory corruption bug in shfldr_unixfs.c
by Michael Jung 12 Sep '05

12 Sep '05

Hi, Sometimes while browsing the unixfs namespace in the file dialog wine crashes with the following console output: ============================================================================= wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00004005 in 32-bit code (0x7b24fbf2). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7b24fbf2 ESP:7b8af188 EBP:7b8af1ac EFLAGS:00210202( - 00 - -RI1) EAX:00000000 EBX:7b2e8b70 ECX:78560110 EDX:7b8af258 ESI:7b2e88f6 EDI:00004001 Stack dump: 0x7b8af188: 00000000 000007d0 7b8af298 00000000 0x7b8af198: 00000008 00000001 7b2e8b70 00000000 0x7b8af1a8: 7b8af1f8 7b8af244 7b2696a2 00004001 0x7b8af1b8: 00000015 00000040 00000000 78561a78 0x7b8af1c8: 78561a78 7b4e8448 7b8af298 00000000 0x7b8af1d8: 7b8af204 7b47bfd1 0036003e 0000004e Backtrace: =>1 0x7b24fbf2 DPA_GetPtr+0x32(hdpa=0x4001, nIndex=0x15) [dpa.c:479] in comctl32 (0x7b8af1ac) 2 0x7b2696a2 LISTVIEW_GetItemT(infoPtr=0x78560110, lpLVItem=0x7b8af258, isW=0x1) [/home/mjung/compile/wine/dlls/comctl32/listview.c:5225] in comctl32 (0x7b8af244) 3 0x7b273e7a notify_itemactivate+0x6a(infoPtr=0x78560110, htInfo=0x7b8af308) [/home/mjung/compile/wine/dlls/comctl32/listview.c:791] in comctl32 (0x7b8af2d4) 4 0x7b26fd5f LISTVIEW_LButtonDblClk+0x8f(infoPtr=0x78560110, wKey=0x1, x=0xad, y=0x39) [/home/mjung/compile/wine/dlls/comctl32/listview.c:8103] in comctl32 (0x7b8af334) ... =============================================================================== As you see, the hdpa parameter to DPA_GetPtr is invalid. The relevant code in LISTVIEW_GetItemT is (dlls/comctl32/listview.c, line 5126): /* find the item and subitem structures before we proceed */ hdpaSubItems = (HDPA)DPA_GetPtr(infoPtr->hdpaItems, lpLVItem->iItem); lpItem = (ITEM_INFO *)DPA_GetPtr(hdpaSubItems, 0); assert (lpItem); It's the first call to DPA_GetPtr that crashes. So the structure pointed to by infoPtr seems to be corrupted (infoPtr is a LISTVIEW_INFO *, which represents the listview item and which given as the first parameter to LISTVIEW_GetItemT). As I never saw this with the original shfldr_fs.c code, I assume that shfldr_unixfs.c has a memory corruption bug somewhere. I've tried to figure the problem for some time now, but to now avail. So my questions are: 1) Can someone give me some advice on how to debug such a problem? 2) Did other people see this bug already? 3) Would valgrind be of help to debug this? Thanks, -- Michael Jung mjung(a)iss.tu-darmstadt.de

7 21

Re: winspool: EnumPrinterDrivers
by Detlef Riekenberg 12 Sep '05

12 Sep '05

Am Sonntag, den 07.08.2005, 19:16 +0200 schrieb Detlef Riekenberg: This Patch is not in CVS yet: http://www.winehq.org/pipermail/wine-patches/2005-August/019671.html > Changelog: > Let EnumPrinterDrivers return the number of drivers. > Any comments / suggestions ? -- By By ... ... Detlef

2 2

Re: wine/dlls wininet/wininet.spec uxtheme/uxtheme ...
by Robert Shearman 12 Sep '05

12 Sep '05

Alexandre Julliard wrote: >Log message: > Specify 64-bit integers as double instead of long long in spec files > so that we get the correct number of arguments. > Wouldn't it be better to extend the spec format to allow for a longlong type instead? -- Rob Shearman

3 5

OOo2.0beta2 installer crashes wine-20050830 in MultiByteToWideChar in msi_process_pending_messages
by Dan Kegel 12 Sep '05

12 Sep '05

Here's a log of wine-20050830 crashing while running the setup.exe in the directory created by unpacking http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… (This is on FC3, with wine-20050830 compiled from source tarball, with Mike's patch to fix the ACTION_VerifyComponentForAction crash.) ... fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"StartServices" fixme:msi:ACTION_RegisterProduct Flesh out more information fixme:msi:ACTION_RegisterProduct Write real Estimated Size when we have it fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MsiPublishAssemblies" fixme:msi:ACTION_PublishProduct Need to write more keys to the user registry wine: Unhandled exception (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x62840730 in 32-bit code (0x7bbb0953). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7bbb0953 ESP:7b92f2f8 EBP:7b92f304 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7bbf75dc ECX:ffffffff EDX:00000000 ESI:ffffffff EDI:62840730 Stack dump: 0x7b92f2f8: 7b5b32a8 7b92f388 62840730 7b92f36c 0x7b92f308: 7b58b3a8 00000000 00000000 62840730 0x7b92f318: ffffffff 00000000 00000000 7bed88d6 0x7b92f328: 00000005 7bef1e18 7b92f6e8 7b92f37c 0x7b92f338: 7b92f408 7bed8a13 00000002 7b92f37c 0x7b92f348: 00000000 002d0043 7b58a73f 7b5b32a8 Backtrace: =>1 0x7bbb0953 MultiByteToWideChar+0x16f(page=0x0, flags=0x0, src=0x62840730, srclen=0xffffffff, dst=0x0, dstlen=0x0) [/home/dank/wine-20050830/dlls/kernel/locale.c:1527] in kernel32 (0x7b92f304) 2 0x7b58b3a8 WINPROC_MapMsg32ATo32W+0x270(hwnd=0x30024, msg=0x1a, pwparam=0x7b92f388, plparam=0x7b92f38c) [/home/dank/wine-20050830/dlls/user/winproc.c:668] in user32 (0x7b92f36c) 3 0x7b58f4e4 CallWindowProcA+0xa0(func=0x7b5e9226, hwnd=0x30024, msg=0x1a, wParam=0x2a, lParam=0x62840730) [/home/dank/wine-20050830/dlls/user/winproc.c:2952] in user32 (0x7b92f39c) 4 0x7b564d5c call_window_proc+0xd0(wparam=0x2a, lparam=0x62840730, unicode=0x0, same_thread=0x0) [/home/dank/wine-20050830/dlls/user/message.c:1520] in user32 (0x7b92f3fc) 5 0x7b56539b peek_message+0x26f(first=0x0, last=0xffffffff, flags=0x1) [/home/dank/wine-20050830/dlls/user/message.c:2053] in user32 (0x7b92f794) 6 0x7b5693de PeekMessageW(msg_out=0x7b92f7fc, hwnd=0x0, first=0x0, last=0x0, flags=0x1) [/home/dank/wine-20050830/dlls/user/message.c:2694] in user32 (0x7b92f7e0) 7 0x7b7f9812 msi_process_pending_messages+0x2a [/home/dank/wine-20050830/dlls/msi/dialog.c:1807] in msi (0x7b92f828) 8 0x7b7f990b msi_dialog_check_messages+0x4b(handle=0x0) [/home/dank/wine-20050830/dlls/msi/dialog.c:1835] in msi (0x7b92f838) 9 0x7b7e79fd ITERATE_Actions(row=0x7a77c6c0, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/action.c:683] in msi (0x7b92f850) 10 0x7b806998 MSI_IterateRecords(view=0x7a77c730, count=0x0, func=0x7b7e7998, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f878) 11 0x7b7e7486 ACTION_ProcessExecSequence+0xc6 [/home/dank/wine-20050830/dlls/msi/action.c:744] in msi (0x7b92f8ac) 12 0x7b7ede17 ACTION_ExecuteAction(package=0x7bcc44a8) [/home/dank/wine-20050830/dlls/msi/action.c:3783] in msi (0x7b92f8dc) 13 0x7b7e772d ACTION_HandleStandardAction(rc=0x7b92f920, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f90c) 14 0x7b7e78e5 ACTION_PerformUIAction+0x3d(package=0x7bcc44a8, action=0x7bd26018) [/home/dank/wine-20050830/dlls/msi/action.c:887] in msi (0x7b92f930) 15 0x7b7e79f2 ITERATE_Actions(row=0x7bd23690, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/action.c:677] in msi (0x7b92f94c) 16 0x7b806998 MSI_IterateRecords+0x70(view=0x7bd22d68, count=0x0, func=0x7b7e7998, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f974) 17 0x7b7e8035 ACTION_DoTopLevelINSTALL+0x41d(package=0x7bcc44a8, szPackagePath=0x7bcc3c3e, szCommandLine=0x0, msiFilePath=0x7b92fa1c) [/home/dank/wine-20050830/dlls/msi/action.c:773] in msi (0x7b92f9f4) 18 0x7b8043b0 MsiInstallProductW+0x138(szPackagePath=0x7bcc3c3e, szCommandLine=0x0) [/home/dank/wine-20050830/dlls/msi/msi.c:233] in msi (0x7b92fe48) 19 0x7b94cbc4 main(argc=0x3, argv=0x7bc604f8) [/home/dank/wine-20050830/programs/msiexec/msiexec.c:298] in msiexec (0x7b92ff10) 20 0x7b94d785 __wine_spec_exe_entry(peb=0x7beff8c0) [/home/dank/wine-20050830/dlls/winecrt0/exe_entry.c:34] in msiexec (0x7b92ff2c) 21 0x7bbbf827 start_process+0xc3(arg=0x0) [/home/dank/wine-20050830/dlls/kernel/process.c:995] in kernel32 (0x7b92fff4) 22 0xf6fde6a1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x7bbb0953 MultiByteToWideChar+0x16f [/home/dank/wine-20050830/dlls/kernel/locale.c:1527] in kernel32: repne scasb %es:(%edi) 1527 if (srclen < 0) srclen = strlen(src) + 1; -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 2

GetOutlineTextMetrics on terminal without X
by FirmOS 12 Sep '05

12 Sep '05

Hi, we have a pdf generator running with wine, started on an X Server the results are as we expected. Running on a terminal without X, the fonts are rendered useless and acrobat complains about the file. I found out, that GetOutlineTextMetrics delivers very different results with our test programm: On an X Term: Font Arial, 20, PixperInch 96 Font:Arial OTM SIZE:246 OTM HEIGHT:1117 OTM ASCEND:905 OTM DESCEND:212 OTM INTLEAD:117 OTM EXTLEAD:33 OTM ACWIDTH:441 OTM MAXCW:2693 OTM WEIGHT:400 OTM OHANG:0 OTM DIGASPX:300 OTM DIGASPY:300 OTM ITALIC:0 OTM UL:0 OTM STRUCKO:0 OTM PFAMILY:39 OTM CSET:0 FILLER:0 FS SEL:64 FS TYPE:0 CSLOPERISE:1 CSLOPERUN:0 IT ANGLE:0 EMSQUARE:2048 ASCEND:728 DESENT:-210 LINEGAP:150 CAP EM HEIGHT:0 XHEIGHT:0 FONTBOX L:-665 FONTBOX T:1037 FONTBOX R:2028 FONTBOX B:-325 On a terminal without X: Font:Arial OTM SIZE:212 OTM HEIGHT:1 OTM ASCEND:0 OTM DESCEND:0 OTM INTLEAD:0 OTM EXTLEAD:0 OTM ACWIDTH:1 OTM MAXCW:1 OTM WEIGHT:500 OTM OHANG:0 OTM DIGASPX:1 OTM DIGASPY:1 OTM ITALIC:0 OTM UL:0 OTM STRUCKO:0 OTM PFAMILY:9 OTM CSET:0 FILLER:0 FS SEL:0 FS TYPE:0 CSLOPERISE:0 CSLOPERUN:0 IT ANGLE:0 EMSQUARE:0 ASCEND:0 DESENT:0 LINEGAP:0 CAP EM HEIGHT:0 XHEIGHT:0 FONTBOX L:0 FONTBOX T:0 FONTBOX R:0 FONTBOX B:0 Values are useless running without X. Is there any solution to this problem ? Setting fonts, etc ? You can get the test application from me. Thanks a lot, Franz Schober franz.schober(a)firmos.at

1 0

Re: hhctrl: Load the default Url in the HTML Pane [take 2]
by James Hawkins 12 Sep '05

12 Sep '05

On 9/9/05, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Cleaned some smudges spotted by Jacek. > > Changelog > * Add the WebBrowser implementation. > * Load the default Url in the HTML Pane. > Is there anything wrong with this patch? -- James Hawkins

1 0

OOo2.0beta2 installer crashes wine-20050830 in ACTION_VerifyComponentForAction
by Dan Kegel 12 Sep '05

12 Sep '05

Here's a log of wine-20050830 crashing while running the setup.exe in the directory created by unpacking OOo_2.0beta2_Win32Intel_install.zip. (This is on FC3, with wine-20050830 compiled from source tarball.) Is this fixed in CVS, perhaps? ... fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MoveFiles" fixme:msi:ACTION_InstallFiles Write DiskPrompt wine: Unhandled exception (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x00000510 in 32-bit code (0x7b800327). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7b800327 ESP:7b92f700 EBP:7b92f700 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7b82a720 ECX:00000000 EDX:00000003 ESI:7b05ef18 EDI:7c228a70 Stack dump: 0x7b92f700: 7b92f748 7b7fc52f 7bcc51d8 00000000 0x7b92f710: 00000003 7b82edc8 7b82edc8 7b82edc8 0x7b92f720: 00000018 7b82edc8 7bcc5204 4d430002 0x7b92f730: 7b05efdc 00000000 7c097368 7b82a720 0x7b92f740: 7b05f000 00000012 7b92f778 7b7e772d 0x7b92f750: 7bcc51d8 004900d0 7b82edc8 00000001 Backtrace: =>1 0x7b800327 ACTION_VerifyComponentForAction+0xb(package=0x7bcc51d8, comp=0x0, check=0x3) [/home/dank/wine-20050830/dlls/msi/helpers.c:752] in msi (0x7b92f700) 2 0x7b7fc52f ACTION_InstallFiles(package=0x7bcc51d8) [/home/dank/wine-20050830/dlls/msi/files.c:676] in msi (0x7b92f748) 3 0x7b7e772d ACTION_HandleStandardAction+0x251(rc=0x7b92f78c, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f778) 4 0x7b7e77fe ACTION_PerformAction+0x3e(package=0x7bcc51d8, action=0x7b05efe8, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:866] in msi (0x7b92f79c) 5 0x7b7e8c35 execute_script [/home/dank/wine-20050830/dlls/msi/action.c:1279] in msi (0x7b92f7cc) 6 0x7b7ed9bc ACTION_InstallFinalize+0x20(package=0x7bcc51d8) [/home/dank/wine-20050830/dlls/msi/action.c:3599] in msi (0x7b92f7dc) 7 0x7b7e772d ACTION_HandleStandardAction(rc=0x7b92f820, force=0x0) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f80c) 8 0x7b7e77fe ACTION_PerformAction+0x3e(package=0x7bcc51d8, action=0x7b05f5d0, force=0x0) [/home/dank/wine-20050830/dlls/msi/action.c:866] in msi (0x7b92f830) 9 0x7b7e7a59 ITERATE_Actions(row=0x7bd2d9b8, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/action.c:679] in msi (0x7b92f850) 10 0x7b806990 MSI_IterateRecords+0x70(view=0x7bd28478, count=0x0, func=0x7b7e7998, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f878) 11 0x7b7e7486 ACTION_ProcessExecSequence+0xc6 [/home/dank/wine-20050830/dlls/msi/action.c:744] in msi (0x7b92f8ac) 12 0x7b7ede17 ACTION_ExecuteAction(package=0x7bcc51d8) [/home/dank/wine-20050830/dlls/msi/action.c:3783] in msi (0x7b92f8dc) 13 0x7b7e772d ACTION_HandleStandardAction(rc=0x7b92f920, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f90c) 14 0x7b7e78e5 ACTION_PerformUIAction+0x3d(package=0x7bcc51d8, action=0x7bd255f8) [/home/dank/wine-20050830/dlls/msi/action.c:887] in msi (0x7b92f930) 15 0x7b7e79f2 ITERATE_Actions(row=0x7bd243c0, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/action.c:677] in msi (0x7b92f94c) 16 0x7b806990 MSI_IterateRecords+0x70(view=0x7bd23a98, count=0x0, func=0x7b7e7998, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f974) 17 0x7b7e8035 ACTION_DoTopLevelINSTALL+0x41d(package=0x7bcc51d8, szPackagePath=0x7bcc496e, szCommandLine=0x0, msiFilePath=0x7b92fa1c) [/home/dank/wine-20050830/dlls/msi/action.c:773] in msi (0x7b92f9f4) 18 0x7b8043a8 MsiInstallProductW+0x138(szPackagePath=0x7bcc496e, szCommandLine=0x0) [/home/dank/wine-20050830/dlls/msi/msi.c:233] in msi (0x7b92fe48) 19 0x7b94cbc4 main(argc=0x3, argv=0x7bc604f8) [/home/dank/wine-20050830/programs/msiexec/msiexec.c:298] in msiexec (0x7b92ff10) 20 0x7b94d785 __wine_spec_exe_entry(peb=0x7beff8c0) [/home/dank/wine-20050830/dlls/winecrt0/exe_entry.c:34] in msiexec (0x7b92ff2c) 21 0x7bbbf827 start_process+0xc3(arg=0x0) [/home/dank/wine-20050830/dlls/kernel/process.c:995] in kernel32 (0x7b92fff4) 22 0xf6fde6a1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x7b800327 ACTION_VerifyComponentForAction+0xb [/home/dank/wine-20050830/dlls/msi/helpers.c:752] in msi: cmpl %edx,0x510(%ecx) 752 if (comp->Installed == check) -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 2

Re: DDraw: Better flag handling in SetCooperativeLevel
by Stefan Dösinger 11 Sep '05

11 Sep '05

Hello, This patch was still not applied. Is anything wrong with it? Does anyone have improvement suggestions? http://www.winehq.org/pipermail/wine-patches/2005-September/020551.html Thanks, Stefan Dösinger

1 0

Re: patches
by Ivan Leo Puoti 11 Sep '05

11 Sep '05

Eric Pouech wrote: > Ivan Leo Puoti a écrit : > >> Is anything wrong with these? >> http://www.winehq.com/pipermail/wine-patches/2005-September/020521.html >> http://www.winehq.com/pipermail/wine-patches/2005-September/020550.html > > > DDK isn't public information. Do we want Wine tree to be tainted by > non cleanly reversed engineered information ? > A+ > Excuse my language but WTF? The EULA of the DDK is very similar to that of the SDK, it's freely available for the cost of shipping and handling, and we can write our own DDK headers just as we can write the SDK ones. Ivan.

3 7

subauth.h
by Luke Kenneth Casson Leighton 11 Sep '05

11 Sep '05

oh maaan, that's really sad: i know what the stuff in subauth.h is all about, aaaaagh! it is incredibly similar to the MSRPC "NETLOGON" stuff that's implemented in cli_nt_login_interactive, cli_nt_login_network and cli_nt_login_generic in rpc_client/cli_login.c joy. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 2

lib/netapi32/access.c and friends
by Luke Kenneth Casson Leighton 10 Sep '05

10 Sep '05

these are standard smbclient-related and/or rpcclient-related functions. NetUserGetInfo grabs the information from a NET_USER_INFO_3 structure which is "cached" from the MSV1_0.DLL access token for example (it's a really long story). NetShareEnum() is a LANMAN function, whoopeee what fun. in nt, there are _stacks_ of functions that tie pretty much directly into samba source code. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

CreateProcess - wine is not doing it right
by Vitaliy Margolen 10 Sep '05

10 Sep '05

Now I really need you help people. Ok, here is the problem: LdrInitializeThunk is called from within start_process - the first thing to be executed in the new process's context. But this is not right. All what I found so far indicates, that LdrInitializeThunk should be queued as an APC, so it executes first no matter what. To complicate matters more, LdrInitializeThunk calling wineserver to stop the process if it's created with CREATE_SUSPENDED flag set. This is wrong. New process should never make it to it's main thread yet. And even worse, none of this happens where it should be - in ntdll. Functions such as NtCreateProcess and NtCreateThread are stubs. So when I'm looking on-line for any information, they all refer to these ntdll functions. I'm looking at this code and can't figure out what part of it belongs where. In kernel we have: 1. CreateProcessW that figures out what the executable is and calls the one of the other functions. That's talk about PE for now (create_process). 2. create_process: I'm not sure what the first part does (something about child). It looks to me that most of the first part including new_process wineserver call should be a part of NtCreateProcess. Everything else from create_process should go into NtCreateThread. 3. THREAD_InitStack shoul probably stay, except all the memory allocation goes to NtCreateThread. 4. start_process should stay the way it is, except delete call to LdrInitializeThunk. 5. LdrInitializeThunk - have no clue what should stay, and what should go somewhere else. Then we have a wineserver's init_process_done. Some parts of it looks like should go into create_process. But I'm not sure here ether. -- Best regards, Vitaliy

2 2

Re: patch for bug 2830 "MSFT_GetTdesc fails on methods with >= 30 params"
by Robert Shearman 10 Sep '05

10 Sep '05

White Snake wrote: >Hallo, >patch goes in typelib.c and is attached as a diff file against >typelib.c 1.167. > >Patch is divided in 3 parts: >1) in MSFT_DoFuncs: "reclength" of the function information record is stored >in a 16 bit int and not in a 8 bit int as previously supposed, using a 0x1ff >mask. Upper 16 bits contains the ordinal number of the function. Allocation of >the "recbuf" must be modified, to support larger data. > >2) Supporting a larger number of parameters means that the function "_invoke" >must be updated too. Maybe there is a smarter way than the one i've found. > >3) This is a "new" bug I discovered: in ITypeInfo_fnInvoke, after >_invoke, when you copy data back to pVarResult, you must not always do it. >Sometimes pVarResult is passet to the called function, so data is already in the exit >buffer. Check the comment few lines above "If pointer to variant, pass >reference it." > > Hi, As these are 3 different bug fixes, can you submit patches separately for each? -- Rob Shearman

1 0

listbox APIs
by Ivan Leo Puoti 10 Sep '05

10 Sep '05

I installed the R2 upgrade for win2k3 today, and the listbox tests don't pass anymore, as shown here http://test.winehq.com/data/200509101000/#2003 R2 is the one on the right. Ivan.

1 0

Possible solution for bug 3028
by Karsten Elfenbein 10 Sep '05

10 Sep '05

Hi, after a lot of trail & error I found out that in dlls/kernel/file.c line 1483-1484 the filename/mask is removed. After removing those two codelines the mask was handed over to wine_nt_to_unix_file_name (dlls/ntdll/directory.c) In the wine_nt_to_unix_file_name function it exits at the invalid char check in line 1418-1419 because a "*" is in the file name. If I comment out that loop the updated test case is producing the same error codes as windows xp. Does anyone have a better solution to solve this? (why is the mask removed in dlls/kernel/file.c? why is the "*" an illegal char in dlls/ntdll/directory.c check?) Karsten http://bugs.winehq.org/show_bug.cgi?id=3028

1 0

Re: Relax Marlett LOGFONT specification
by Huw Davies 10 Sep '05

10 Sep '05

On Fri, Sep 09, 2005 at 12:46:10PM +0100, Richard Cohen wrote: > Index: dlls/user/uitools.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/uitools.c,v > retrieving revision 1.7 > diff -u -p -r1.7 uitools.c > --- dlls/user/uitools.c 7 Jul 2005 18:24:12 -0000 1.7 > +++ dlls/user/uitools.c 9 Sep 2005 11:41:49 -0000 > @@ -926,9 +926,9 @@ static BOOL UITOOLS95_DrawFrameCaption(H > return FALSE; > } > > - hf = CreateFontW(-SmallDiam, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, > - SYMBOL_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, > - DEFAULT_QUALITY, FIXED_PITCH|FF_DONTCARE, glyphFontName); > + hf = CreateFontW(-SmallDiam, 0, 0, 0, FW_DONTCARE, FALSE, FALSE, FALSE, > + DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, > + DEFAULT_QUALITY, DEFAULT_PITCH|FF_DONTCARE, glyphFontName); > alignsave = SetTextAlign(dc, TA_TOP|TA_LEFT); > bksave = SetBkMode(dc, TRANSPARENT); > clrsave = GetTextColor(dc); We shouldn't need to do this. Fixing marlett.ttf would be the right thing to do. I'll try to look at this next week (but feel free to beat me to it!). Huw.

2 1

patches
by Ivan Leo Puoti 10 Sep '05

10 Sep '05

Is anything wrong with these? http://www.winehq.com/pipermail/wine-patches/2005-September/020521.html http://www.winehq.com/pipermail/wine-patches/2005-September/020550.html Ivan

1 0

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