wine-devel September 2005

wine-devel@winehq.org

136 participants
273 discussions

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

Re: dlls/x11drv/mouse.c
by Alexandre Julliard 09 Sep '05

09 Sep '05

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > We had a XFlush call in X11DRV_SetCursorPos before but it was removed for > some reason. This restores the call and fixes a regression in JInitiator > where the mouse position was being reported incorrectly. This sounds like it's just masking the problem. Do you know precisely why the mouse position is incorrect? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: shell32: correct a failing test
by Saulius Krasuckas 09 Sep '05

09 Sep '05

* On Fri, 2 Sep 2005, Juan Lang wrote: > > This test was failing after the first time on Windows, so (hopefully) > fix it. > > ChangeLog: fix a test failing on Windows. Reported by Katerina Nizhnik. Unfortunately, this code pops up some window: --- wine/dlls/shell32/tests/shellpath.c 2005/08/16 16:00:07 1.11 +++ wine/dlls/shell32/tests/shellpath.c 2005/09/03 09:37:15 1.12 ... + shFileOp.pFrom = modifiedPath; + shFileOp.fFlags = FOF_NOCONFIRMATION | FOF_NOERRORUI | + FOF_SILENT; + SHFileOperationA(&shFileOp); which says: | Favorites is a Windows system folder and is required for Windows to run | properly. It cannot be deleted. And then exception of an access violation is thrown from the SHLWAPI.DLL. This happens on WinME. It seems here the flag FOF_NOERRORUI is ignored. I can't test this on other platforms and am going out of city for a weekend. Anyone feel free to fix it. :-P

1 0

Re: dll/winmm/playsound.c
by Robert Shearman 09 Sep '05

09 Sep '05

Ulrich Czekalla wrote: >fccType may be NULL or contain non-printable characters. Show output as hex >instead of characters. > >ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Display fccType as hex instead of characters in trace output > > >------------------------------------------------------------------------ > >Index: dlls/winmm/playsound.c >=================================================================== >RCS file: /home/wine/wine/dlls/winmm/playsound.c,v >retrieving revision 1.17 >diff -u -p -r1.17 playsound.c >--- dlls/winmm/playsound.c 13 Jul 2005 11:59:15 -0000 1.17 >+++ dlls/winmm/playsound.c 8 Sep 2005 14:42:09 -0000 >@@ -328,7 +328,7 @@ static DWORD WINAPI proc_PlaySound(LPVOI > if (mmioDescend(hmmio, &mmckInfo, &ckMainRIFF, MMIO_FINDCHUNK)) > goto errCleanUp; > >- TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX \n", >+ TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX \n", > (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); > > lpWaveFormat = HeapAlloc(GetProcessHeap(), 0, mmckInfo.cksize); >@@ -349,7 +349,7 @@ static DWORD WINAPI proc_PlaySound(LPVOI > if (mmioDescend(hmmio, &mmckInfo, &ckMainRIFF, MMIO_FINDCHUNK)) > goto errCleanUp; > >- TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX\n", >+ TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX\n", > (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); > > I think these formats should be %04x as fccType is 2 bytes, not 4 bytes. -- Rob Shearman

3 2

Problem detecting libxslt
by Vincent Béron 09 Sep '05

09 Sep '05

Hi Mike, Doing ./configure on a RH8 box I get the following: checking libxslt/transform.h presence... yes configure: WARNING: libxslt/transform.h: present but cannot be compiled configure: WARNING: libxslt/transform.h: check for missing prerequisite headers? configure: WARNING: libxslt/transform.h: see the Autoconf documentation configure: WARNING: libxslt/transform.h: section "Present But Cannot Be Compiled" configure: WARNING: libxslt/transform.h: proceeding with the preprocessor's result configure: WARNING: libxslt/transform.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## The problem looks to come from my transform.h needing xsltInternals.h being included first. I added an #ifdef HAVE_LIBXSLT_PATTERN_H include to the AC_CHECK_HEADERS which defines HAVE_LIBXSLT, as that file does #include "xsltInternals.h". I don't think we should directly include xsltInternals.h. Could you please comment if the attached patch is correct or not? I'll send it to wine-patches if acceptable. Thank you, Vincent

3 2

← Newer
1
...
17
18
19
20
21
22
23
...
28
Older →

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