Re: avifil32: Removed sign comparison warning (sizeof expresions)

[Andrey Turkin]

On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote:
 IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT)
 is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT)
 falls well inside the number range expressible by a LONG. Logically
 there is no difference between
 formatsize = sizeof(PCMWAVEFORMAT)
 and
 formatsize = 16
 One gives a bogus warning and the other doesn't.

C99 std (para 6.5.3.4.4) states following about sizeof operator:
...its type (an unsigned integer type) is size_t, defined in stddef.h (and 
other headers).

sizeof result is a compile-time constant but, unlike numeric constants, its 
type must always be size_t so gcc does the correct thing here.

Re: kernel32: Enhance EndUpdateResource

[Andrey Turkin]

On Sunday 18 July 2010 00:26:36 Henri Verbeet wrote:
 On 17 July 2010 09:06, Andrey Turkin andrey.tur...@gmail.com wrote:
  +if (nt-OptionalHeader.FileAlignment = 0)
 
 I can't comment much on the changes themselves, but FileAlignment is
 unsigned, so can't be  0.

Original function has this check just before that added line:

if (nt-OptionalHeader.SectionAlignment = 0)
{
  ERR(invalid section alignment %04x\n, 
nt-OptionalHeader.SectionAlignment);
  goto done;
}

So I've added something similar. The point here is to check alignments are 
positive; = works just as well as !=, and is describes not positive 
condition better than !=.

Re: [1/2] imagehlp: Add tests for ImageGetDigestStream

[Andrey Turkin]

On Sunday 18 July 2010 00:26:50 Henri Verbeet wrote:
 On 17 July 2010 09:07, Andrey Turkin andrey.tur...@gmail.com wrote:
  +#ifdef NONAMELESSUNION
  +# define U(x)  (x).u
  +#else
  +# define U(x)  (x)
  +#endif
 
 I think this is already done in wine/test.h?
Right. Some other tests define NONAMELESSUNION and just use u as union name 
- I'll rewrite this to do the same.

 
  +static BOOL WINAPI accumulating_stream_output(DIGEST_HANDLE handle, BYTE
  *pb, + DWORD cb)
 
 pb can probably be const.
No it cannot. accumulating_stream_output is a callback function and its 
signature must be the same as DIGEST_FUNCTION.

Re: [2/2] imagehlp: Implement ImageGetDigestStream

[Andrey Turkin]

On Saturday 17 July 2010 18:19:50 Dan Kegel wrote:
 I was worried that mapping the file will fail if you're
 low on address space and are running this function
 on a large PE file.
 It ought to be possible to write a test to see how
 the function behaves when you've used up oodles
 of address space, though it'd be tricky to make
 the test reliable.
 
 I see that Windows has a similar problem in MapFileAndCheckSum
 (which is said to be a caller of this function)
 http://www.daniweb.com/forums/thread122484.html
 so who knows, maybe Windows also maps the file...

A good question; using mapped file seemed like a good idea (much easier to 
deal with than reading chunks explicitly) and, frankly speaking, I didn't 
thought about possible virtual address space shortage as a side-effect. 
Anyway, I tried ImageGetDigestStream with a big file on Vista and apparently 
it uses whole file map as well - no problem here.

Re: base addresses of kernel32

[Andrey Turkin]

On Sunday 04 July 2010 22:31:49 Dan Kegel wrote:
  the Makefile has:
  EXTRADLLFLAGS = -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b80
 
 Is there a good reason for this?  Otherwise, this opens a security
 vulnerability in Wine that does not exist in Windows
 
 This is the way Windows worked before Vista.
 (Does Vista actually randomize where even ntdll is?)
 
 BTW our CreateRemoteThread conformance test checks whether
 the module has been loaded at a different address, and skips if it
 has...

http://www.nynaeve.net/?p=198 has a pretty good explanation why certain DLLs 
must be loaded at same address; one example why Wine should care is to satisfy 
programs injecting code in different processes.

Re: atl: reuse code of AtlModuleRegisterWndClassInfoW for AtlModuleRegisterWndClassInfoA (try 2)

[Andrey Turkin]

25.05.2010 18:51, André Hentschel wrote:

--- a/dlls/atl/atlwin.h
+++ b/dlls/atl/atlwin.h
@@ -43,7 +43,7 @@ typedef struct _ATL_WNDCLASSINFOW_TAG
  WCHAR m_szAutoName[14];
  } _ATL_WNDCLASSINFOW;

-ATOM WINAPI AtlModuleRegisterWndClassInfoA(_ATL_MODULEW *pm, 
_ATL_WNDCLASSINFOA *wci, WNDPROC *pProc);
+ATOM WINAPI AtlModuleRegisterWndClassInfoA(_ATL_MODULEA *pm, 
_ATL_WNDCLASSINFOA *wci, WNDPROC *pProc);
  ATOM WINAPI AtlModuleRegisterWndClassInfoW(_ATL_MODULEW *pm, 
_ATL_WNDCLASSINFOW *wci, WNDPROC *pProc);

  HDC WINAPI AtlCreateTargetDC(HDC hdc, DVTARGETDEVICE *ptd);
   

Are you sure about this change?

Re: atl: reuse code of AtlModuleRegisterWndClassInfoW for AtlModuleRegisterWndClassInfoA (try 2)

[Andrey Turkin]

25.05.2010 19:58, André Hentschel wrote:

Am 25.05.2010 17:05, schrieb Andrey Turkin:
   

25.05.2010 18:51, André Hentschel wrote:
 

--- a/dlls/atl/atlwin.h
+++ b/dlls/atl/atlwin.h
@@ -43,7 +43,7 @@ typedef struct _ATL_WNDCLASSINFOW_TAG
   WCHAR m_szAutoName[14];
   } _ATL_WNDCLASSINFOW;

-ATOM WINAPI AtlModuleRegisterWndClassInfoA(_ATL_MODULEW *pm,
_ATL_WNDCLASSINFOA *wci, WNDPROC *pProc);
+ATOM WINAPI AtlModuleRegisterWndClassInfoA(_ATL_MODULEA *pm,
_ATL_WNDCLASSINFOA *wci, WNDPROC *pProc);
   ATOM WINAPI AtlModuleRegisterWndClassInfoW(_ATL_MODULEW *pm,
_ATL_WNDCLASSINFOW *wci, WNDPROC *pProc);

   HDC WINAPI AtlCreateTargetDC(HDC hdc, DVTARGETDEVICE *ptd);

   

Are you sure about this change?

 

95 percent. the unicode struct would not make much sense to me.

   
The reason I asked was caused by the fact SDK's header specifies same 
unqualified _ATL_MODULE type for both functions so unless native atl.dll 
was partially unicode and partiall ansi compiled both functions would 
have same type of the argument. So I thought you might have some proof 
of whether this is true.
Ansi version indeed makes more sense here (since most callers who uses 
ansi version of the function would probably have their _Module as ansi 
too) . Anyway, the code of this function doesn't use any of 
unicode-dependant parts of _ATL_MODULE so any type will do.

Re: shdocvw: implement IWebBrowser2::get_LocationName

[Andrey Turkin]

10.05.2010 15:02, Jacek Caban wrote:

Hi Andrey,

On 5/9/10 9:30 PM, Andrey Turkin wrote:

---
 dlls/shdocvw/tests/webbrowser.c |   27 ---
 dlls/shdocvw/webbrowser.c   |   24 ++--
 2 files changed, 46 insertions(+), 5 deletions(-)


+if (This-doc_host.document  SUCCEEDED(IUnknown_QueryInterface(
+This-doc_host.document,IID_IHTMLDocument2, 
(void**)doc))) {

+hres = IHTMLDocument2_get_title(doc, LocationName);
+IHTMLDocument2_Release(doc);


There is no reason to make this MSHTML-specific by using 
IHTMLDocument2 here.


Jacek

If there is more generic way to get HTML title for the document then it 
certainly can be used instead; I just don't know any - hints/suggestions 
would be welcome.

Re: Added check for PROCESS_VM_WRITE, without which, some programs go into an infinite loop Henry Blum henry.b...@gmail.com

[Andrey Turkin]

08.05.2010 9:10, Henry Blum wrote:

---
 dlls/kernel32/process.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c
index 9a1f2f5..6dcad8f 100644
--- a/dlls/kernel32/process.c
+++ b/dlls/kernel32/process.c
@@ -2657,7 +2657,7 @@ HANDLE WINAPI OpenProcess( DWORD access, BOOL 
inherit, DWORD id )

 if (GetVersion()  0x8000) access = PROCESS_ALL_ACCESS;
  status = NtOpenProcess(handle, access, attr, cid);
-if (status != STATUS_SUCCESS)
+if (status != STATUS_SUCCESS || (access  PROCESS_VM_WRITE))
 {
 SetLastError( RtlNtStatusToDosError(status) );
 return NULL;


Wouldn't this pretend operation failed for every request with 
PROCESS_VM_WRITE, even if NtOpenProcess succeeded, and leak a handle? 
Which bug should it fix?

Re: programs/extrac32: The debug channel is not used, remove it.

[Andrey Turkin]

Don't do this please, initial part was just submitted, the channel will 
be used once other parts are in place.


Francois Gouget wrote:

---
 programs/extrac32/extrac32.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/programs/extrac32/extrac32.c b/programs/extrac32/extrac32.c
index 7e8fbed..4e53af9 100644
--- a/programs/extrac32/extrac32.c
+++ b/programs/extrac32/extrac32.c
@@ -21,9 +21,7 @@
 #include windows.h
 
 #include wine/unicode.h

-#include wine/debug.h
 
-WINE_DEFAULT_DEBUG_CHANNEL(extrac32);
 
 int PASCAL wWinMain(HINSTANCE hInstance, HINSTANCE prev, LPWSTR cmdline, int show)

 {
  

Re: programs/extrac32: The debug channel is not used, remove it.

[Andrey Turkin]

Virtually any Wine program uses it (even winemine) so why not?

Jerome Leclanche wrote:

I'm unsure programs themselves should use Wine's debug channels, either way.

J. Leclanche / Adys



On Mon, Oct 26, 2009 at 10:35 AM, Andrey Turkin andrey.tur...@gmail.com wrote:
  

Don't do this please, initial part was just submitted, the channel will be
used once other parts are in place.

Re: [TRY 2] [2/3] extrac32: Add command-line parsing

[Andrey Turkin]

Alexandre Julliard wrote:

Ilya Shpigor shpi...@etersoft.ru writes:

  

+/* Parse options */
+for(i = 0; i  argc; i++)
+{
+if (argv[i][0] == '/')
+{
+for(j = 0; j  sizeof(sFlags) / sizeof(sFlags[0]); j++)
+if (!strcmpiW(argv[i], sFlags[j].wFlag))
+{
+comp |= sFlags[j].nFlag;
+goto next;
+}
+}
+next:
+continue;
+}
+
+if ((comp  CMD_FLAGS) == EFLAGC) /* copy file */
+{
+WINE_FIXME(/C not implemented\n);
+} else if ((comp  CMD_FLAGS) == EFLAGD) /* display CAB archive */
+{
+WINE_FIXME(/D not implemented\n);
+} else if ((comp  CMD_FLAGS) == EFLAGE) /* extract CAB archive */
+{
+WINE_FIXME(/E not implemented\n);
+} else if ((comp  CMD_FLAGS) == 0) /* expand mode */
+{
+WINE_FIXME(Expand mode not implemented\n);
+}



That parsing approach is not really appropriate here, the options are
not just a bunch of flags, there are options with arguments, mutually
exclusive modes, etc. Some sort of switch() statement would be more
natural.
  


Actually they are just a bunch of flags with exception for /L which 
takes an argument - this is covered by Ilya's third patch, and /C, /D 
and /E which are mutually exclusive mode switches - this is covered by 
CMD_FLAGS bitmask. At least Vista's extrac32 don't care for 
inappropriate flags, e.g.:


 md temp
 md temp2
 echo test  test
 extrac32 /Y /A /L temp2 /C test temp|more
Microsoft (R) Cabinet Extraction Tool - Version 6.0.6001.18000
Copyright (c) Microsoft Corporation. All rights reserved..
Extracting test - temp\test

And indeed there is a copied file in temp directory despite erroneous 
/A and /L path flags.

Re: [PATCH 5/6] mshtml: Moved HTMLDocumentNode creating to HTMLWindow_Create.

[Andrey Turkin]

This patch makes some tests (like urlmon's url test) to crash if Gecko isn't
installed (dereference of NULL window-nswindow in update_window_doc called
by HTMLWindow_Create(nswindow==NULL) called by HTMLDocument_Create)

Re: [1/3] programs: initial add extrac32 utility

[Andrey Turkin]

Austin English wrote:

2009/10/21 Ilya Shpigor shpi...@etersoft.ru:

You need to add the program to configure.ac, as well as add Makefile.in
  


No you don't need to (most patches do add some subset of autogenerated 
files for some reason but it is not necessary).

Re: programs: add extrac32 tool

[Andrey Turkin]

extrac32 is not a console program; on Windows it doesn't create a 
console and doesn't write anything to stdout or stderr regardless of 
command line. I agree those FIXMEs you pointed out are not FIXMEs really 
- some of them are errors and some should be warnings. I'll fix them.


Kirill K. Smirnov wrote:

Hi,

+int PASCAL wWinMain ( HINSTANCE hInstance, HINSTANCE prev, LPWSTR cmdline, 
int show )

+{
extrac32 is a console application, isn't it? Why not wmain() instead? And get 
rid of rather complex ParseCmdLine().


+if (!SetupIterateCabinetW( pszCabFile, 0, (PSP_FILE_CALLBACK) 
ExtCabCallback, 0 ))
+WINE_FIXME( Can not extract cab file:%s!!!\n, wine_dbgstr_w( 
pszCabFile ) );

This is an error, not a FIXME

+if(!argv)
+{
+WINE_FIXME(Error!Can not get cmd line\n );
+return 0;
+}
not a FIXME

+if (argc  2)
+{
+WINE_FIXME( No options\n );
+return 1;
+}
not a FIXME

+if (fArgc != 1)
+WINE_FIXME( Invalid usage for /C flag - two filenames 
expected\n );

not a FIXME

--
Kirill

  

Re: server: Wineserver manpage in russian

[Andrey Turkin]

Hi Nikolay,

There are few issues:

 +.BI wineserver\  [options]
 +.SH ОПИСАНИЕ
 +.B wineserver
 +это сервис предоставляющая процессам Wine аналогичные набор функций, который
   
no comma after сервис; it should be предоставляющий; probably should
be набор функций, аналогичный тому, который or something similar.
 +ядро Windows предоставляет в системе Windows.
 +.PP
 +не задано, в качестве значения по умолчанию принимается 1. Оталдочная 
 информация
   
Отладочная.
 +Отображать сервер на переднем плане для более удобной отладки, например при
   
Sounds weird; maybe better would be Не демонизировать сервер or
something similar, or Не переводить wineserver в background для более
удобной отладки?
 +Показать информацию о версию и выйти.
   
о версии
 +.TP
 +.B \-w, --wait
 +Подождать пока текщий запущенный экземпляр
   
comma missing; текущий.
 +If set, the content of this variable is taken as the name of the directory 
 where
 +.B wineserver
 +stores its data (the default is \fI$HOME/.wine\fR). Все процессы
   
not translated.

Re: [1/2] httpapi: add HttpInitialize and HttpTerminate stubs

[Andrey Turkin]

Austin English wrote:
 On Mon, Jan 12, 2009 at 11:33 AM, Andrey Turkin andrey.tur...@gmail.com 
 wrote:
   
 .Net 3.0 installer needs these
 ---
  dlls/httpapi/httpapi.spec   |2 +
  dlls/httpapi/httpapi_main.c |   42 +
  include/http.h  |   48 
 +++
  3 files changed, 92 insertions(+), 0 deletions(-)
  create mode 100644 include/http.h






 

 diff --git a/dlls/httpapi/httpapi.spec b/dlls/httpapi/httpapi.spec
 index aa8fea2..1033eb8 100644
 --- a/dlls/httpapi/httpapi.spec
 +++ b/dlls/httpapi/httpapi.spec
 @@ -18,6 +18,7 @@
  @ stub HttpFilterRawWriteAndAppRead
  @ stub HttpFlushResponseCache
  @ stub HttpGetCounters
 +@ stdcall HttpInitialize(long long ptr)
  @ stub HttpInitialize
  @ stub HttpInitializeServerContext
  @ stub HttpOpenAppPool

 You forgot to remove the stub entry.

 @@ -48,5 +49,6 @@
  @ stub HttpShutdownAppPool
  @ stub HttpShutdownFilter
  @ stub HttpTerminate
 +@ stdcall HttpTerminate(long ptr)
  @ stub HttpWaitForDemandStart
  @ stub HttpWaitForDisconnect

 Same.

   

Nice catch, that was screwed up rebase. I've sent correct version

Re: shell32: add explorer toolbar bitmaps

[Andrey Turkin]

Juan Lang wrote:
 so I just cutted icons from other toolbars' bitmaps;
 

 Which other toolbars, specifically?  You can't grab copyrighted work, you 
 know.
 --Juan

   
Yeah, I know. All bitmaps were from Wine itself (comctl32 etc).

Re: shell32: add explorer toolbar bitmaps

[Andrey Turkin]

Roderick Colenbrander wrote:
 Juan Lang wrote:
 
 so I just cutted icons from other toolbars' bitmaps;
 
 
 Which other toolbars, specifically?  You can't grab copyrighted work,
   
 you know.
 
 --Juan

   
   
 Yeah, I know. All bitmaps were from Wine itself (comctl32 etc).
 

 Why not use icons from the tango project? As I mentioned recently in a thread 
 we (if we contact them) should be able to use icons from their project. The 
 icons look very nice and can make wine look a lot better. Personally I don't 
 like the current icons.

 Roderick
   

I _love_ this idea, and icons look very nice, but here can be some legal
troubles. The icons are under Creative Commons - Share Alike 2.5
license. I'm not a lawyer and not sure if using (probably modified)
icons would be considered as share alike condition - they say alter,
transform or build upon, but probably authors intent was that icons
must stay under CC Share-Alike license. See e.g.
http://lists.freedesktop.org/archives/tango-artists/2006-September/000681.html
. These wars between open source licenses make me sick.

Re: shell32: add explorer toolbar bitmaps

[Andrey Turkin]

James Hawkins wrote:
 On Sat, Jan 3, 2009 at 3:07 PM, Andrey Turkin andrey.tur...@gmail.com wrote:
   
 I _love_ this idea, and icons look very nice, but here can be some legal
 troubles. The icons are under Creative Commons - Share Alike 2.5 license.
 I'm not a lawyer and not sure if using (probably modified) icons would be
 considered as share alike condition - they say alter, transform or build
 upon, but probably authors intent was that icons must stay under CC
 Share-Alike license. See e.g.
 http://lists.freedesktop.org/archives/tango-artists/2006-September/000681.html
 . These wars between open source licenses make me sick.

 

 http://winehq.org/pipermail/wine-devel/2008-December/071145.html

   
That's great! Once they switch the license we definitely should use Tango.

Re: ntoskrnl.exe: Add a redirect for IoGetCurrentProcess

[Andrey Turkin]

I believe this is wrong - IoGetCurrentProcess return pointer to kernel
EPROCESS structure instance, and GetCurrentProcess return constant
(HANDLE)-1 . The structure is declared opaque so drivers must not
dereference it, but some drivers surely won't obey.

2008/12/20 Chris Wulff crwu...@rochester.rr.com

 Redirect for IoGetCurrentProcess to kernel32.GetCurrentProcess

  -- Chris Wulff

Re: [Fwd: mpr: fix NULL pointer dereference in WNetGetResourceInformationW]

[Andrey Turkin]

Yes, the mail is at http://kegel.com/wine/patchwatcher/results/3193.txt and
log is at http://kegel.com/wine/patchwatcher/results/3193.log .
Why, was there any problems with this patch?

Regards,
  Andrey

2008/10/20 James McKenzie [EMAIL PROTECTED]

 Was this ever processed through Patchwatcher?

 James McKenzie

  Original Message 
 Subject:mpr: fix NULL pointer dereference in
 WNetGetResourceInformationW
 Date:   Tue, 07 Oct 2008 20:18:00 +0400
 From:   Andrey Turkin [EMAIL PROTECTED]
 Reply-To:   wine-devel@winehq.org
 To: wine-patches [EMAIL PROTECTED]



 The dereference was spotted by Anastasius Focht in bug 13737; this patch
 fixes this bug.
 ---
  dlls/mpr/wnet.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Re: wordpad: do not pass resource ids to MessageBox

[Andrey Turkin]

Dmitry Timoshkov wrote:
 Andrey Turkin [EMAIL PROTECTED] wrote:

 It seems that automatic loading of string from resources in MessageBox*
 is Wine extension. Useful and logical one but still other platform does
 not support it.

 That's not a Wine extension, looks like the author of that code just
 didn't test it. One need to use MessageBoxEx to make it work.


Sorry, I don't really understand what do you mean. For me, both
MessageBox and MessageBoxEx work identically on Windows - the message
box has no caption and no text.

Re: [try2] advapi32: Implement CredReadDomainCredentials stub and tests

[Andrey Turkin]

James Hawkins wrote:
 On Thu, Oct 9, 2008 at 4:14 PM, Andrey Turkin [EMAIL PROTECTED] wrote:
   
 [now with tests, fixed and reformatted as per James' suggestions]

 Implement CredReadDomainCredentialsA and CredReadDomainCredentialsW
 stubs and few tests for them.  Required for MSN Messenger 7.0
 ---
  dlls/advapi32/advapi32.spec |4 +-
  dlls/advapi32/cred.c|  160 
 +++
  dlls/advapi32/tests/cred.c  |   45 
  include/wincred.h   |   39 +++
  4 files changed, 246 insertions(+), 2 deletions(-)

 

 +*Size = 0;

 +*Credentials = NULL;

 +if (!TargetInformation)

 What if Size or Credentials is NULL?  You should add a test for that
 and handle it appropriately.  If the tests crash, you should comment
 out the tests and note that there is no handling in Windows.

   

Why? Windows does the same thing, tests would crash. Do you really think
somebody need to know this? Is there any application that depends on
this behavior so these assignments must be commented to protect them
from change? I can't see any value in commented out test or
sort-of-meaningless code comment.

Re: [try2] advapi32: Implement CredReadDomainCredentials stub and tests

[Andrey Turkin]

James Hawkins wrote:
 On Fri, Oct 10, 2008 at 3:17 PM, Andrey Turkin [EMAIL PROTECTED] wrote:
   
 Imagine broken application which for some reason, e.g. non-allocated memory,
 supply NULL to this function, and then catch, eat and spew an exception
 somewhere in different place. Joe the Developer start searching for root
 cause - he looks at logs, see first-chance exception, look in
 CredReadDomainCredentials source and see unguarded dereferencing. Is this
 intended or mistake? That should code really do? The comment would be handy
 here (at least for me tests wouldn't be the first place to look at for
 answers in such situation).
 I can see the value and cannot see any harm, and frankly I am reluctant to
 issuing [try4] patch with just another minor comment change.

 

 You just said that the tests crash in Windows.  If the tests crash in
 Windows, then how does this app work there either?  That's the point
 of tests: to verify that our implementation matches native.
   
We know my implementation and Windows implementation behave identically
and this is documented in tests. At this
point you and me both happy about the comment in tests and tests in
general, right?
Now back to the example. In this example something somewhere went wrong
because of Windows/Wine differences,
 e.g. previous memory allocation failed or something. Completely
unrelated to this particular function, and our Joe should
not spend his time trying to understand the function itself - and code
comments do just that. Joe read the comment, understand
that NULL pointer should not be passed in the first place, and continue
his quest. Sounds useful for me, and certainly looks
harmless (apart from causing this thread to go on).

Re: [try2] advapi32: Implement CredReadDomainCredentials stub and tests

[Andrey Turkin]

James Hawkins wrote:
 On Fri, Oct 10, 2008 at 2:51 PM, Andrey Turkin [EMAIL PROTECTED] wrote:
   
 James Hawkins wrote:

 On Fri, Oct 10, 2008 at 12:59 AM, Andrey Turkin [EMAIL PROTECTED]
 wrote:


 I can't see any value in commented out test or sort-of-meaningless code
 comment.



 The tests serve as documentation of the API.  In many cases, that
 documentation is far superior to even msdn.  Just because you know
 that the implementation matches native doesn't mean that someone else
 looking to work on the function knows that.  He'll then waste time
 figuring out what you already know.  Ask yourself the opposite: what's
 the harm in adding such documentation?


 Non-misleading comment obviously cannot make any harm, and I can imagine one
 (unlikely but not impossible)
 case when comment can be helpful so yes, I'll add both commented out tests
 and sort-of-meaningless comment :)
 Hopefully nobody will object them.

 

 Please don't add a comment to the implementation.  The tests are
 documentation enough.  All you need to do is if(0) out the tests that
 crash.

   
Imagine broken application which for some reason, e.g. non-allocated
memory, supply NULL to this function, and then catch, eat and spew an
exception somewhere in different place. Joe the Developer start
searching for root cause - he looks at logs, see first-chance exception,
look in CredReadDomainCredentials source and see unguarded
dereferencing. Is this intended or mistake? That should code really do?
The comment would be handy here (at least for me tests wouldn't be the
first place to look at for answers in such situation).
I can see the value and cannot see any harm, and frankly I am reluctant
to issuing [try4] patch with just another minor comment change.

Re: [1/2] server: fix async read on mailslot

[Andrey Turkin]

2008/7/19 Michael Karcher [EMAIL PROTECTED]:

 Am Freitag, den 18.07.2008, 20:37 +0400 schrieb Andrey Turkin:
  Also, please attach patches with disposition inline, not attachment
  (git can do that) - this make review somehow easier.
 If this is an official wine policy (I do see your point), please update
 http://www.winehq.org/site/sending_patches , it tells to use the
 --attach option in the imap case.

It looks that most of patch authors doesn't follow this guide (from last 16
patches I've seen one with Content-Disposition: Attachment and 15 either
with Content-Disposition: Inline or with inline patches). Anyone, is there
some reason to keep the guide which noone follows?

Re: [1/2] server: fix async read on mailslot

[Andrey Turkin]

Hi Ambroz,

-
FILE_SYNCHRONOUS_IO_NONALERT );
+read_timeout ? 0 : 
FILE_SYNCHRONOUS_IO_NONALERT );
This looks incorrect. You probably want to compare to -1, not zero. Zero 
means reads must not block at all, and -1 means read must wait forever 
(not sure what zero timeout would work as expected with your patch, but 
it didn't anyway and I think it maybe is broken in another place)
Also, please attach patches with disposition inline, not attachment (git 
can do that) - this make review somehow easier.


Regards,
 Andrey


Ambroz Bizjak wrote:

Hi,

Changelog:
server: fix async read on mailslot



  

Re: dlls/ws2_32/tests/sock.c: Wait on thread handles before closing sockets

[Andrey Turkin]

Diff doesn't look in line with the description (I can't see any waits in the
diff :)

2008/7/15 Jon Griffiths [EMAIL PROTECTED]:

 Hi,

 In the socket tests, avoid a race by waiting for the read threads to finish
 before closing the sockets (found during TransmitFile testing).

 Cheers
 Jon

Re: mswsock:Implement 3 functions by calling through SIO_GET_EXTENSION_FUNCTION_POINTER

[Andrey Turkin]

You should mention somewhere (FIXME or TODO or something) what the code 
currently rely on socket being not used by WSAIoctl. IIRC Windows won't 
let you call WSAIoctl(0, ...)
Correct way would be to retrieve both AcceptEx and GetAcceptExSockaddrs 
routine addresses in AcceptEx wrapper and store lpOutputBuffer-fn 
mapping somewhere.


Jon Griffiths wrote:

Hi,

This is part one of a patch set that implements TransmitFile/Transmit packets and 
fixes bug 5048. This first part implements AcceptEx/GetAcceptExSockaddrs  
TransmitFile by calling them from ws2_32 using SIO_GET_EXTENSION_FUNCTION_POINTER. 
Next up is the implementation itself.

Cheers
Jon




  

Re: README: Add Russian translation (4th try)

[Andrey Turkin]

Hi Vladimir,

There are a few punctuation issues still left.

 Wine это программа

 реализует вызовы Windows API
 используя

 В директории содержащей

 решения проблем, прочтите
extra comma here?

 операционные системы перечисленные выше

 У FreeBSD 6.3 есть патч разрешающий
comma missed, and позволяющий seems to be better here

 гарантирует
  что

 Убедитесь что, опции
comma in wrong place

 особенностей файловой системы необходимые некоторым
comma missing

 убедиться что, у вас
comma in wrong place

 Вероятно это лучшая начальная точка
sounds weird

 Вы так же можете отправлять
should be также


Vladimir Pankratov wrote:
 Hello.

 Corrected some wrong strings.
 Added README.ru file.

 Thanks fo help.

Re: patch to fix bug 8246

[Andrey Turkin]

This is not about embedded nulls, this is about possibly not null terminated
strings. If there is zero somewhere in the buffer then we should only
convert string up to that zero; if there isn't any nulls, then we have to
convert full string and null-terminate string. This can be coded prettier,
though:

if (l0)
{
 void *eos = memchr(str, 0, l);
 if (eos)
 l = (LONG)(eos-str);
}

and always zero-pad afterwards

2008/3/11, Alexandre Julliard [EMAIL PROTECTED]:

 Hin-Tak Leung [EMAIL PROTECTED] writes:

  This is the fix to bug 8246 to get HtmlHelpW to work correctly.
  It was first worked on by Andrey Turkin and updated later by me.


 Please add a proper log entry describing the change.

  -static inline LPWSTR strdupAtoW(LPCSTR str)
  +static inline LPWSTR strdupnAtoW(LPCSTR str, LONG l)
   {
   LPWSTR ret;
   DWORD len;
  +BOOL   zero_pad;
 
   if(!str)
   return NULL;
 
  -len = MultiByteToWideChar(CP_ACP, 0, str, -1, NULL, 0);
  +if (l0)
  +{
  +LONG i;
  +zero_pad = TRUE;
  +for (i=0;il;i++)
  +{
  +if (!str[i])
  +{
  +zero_pad = FALSE;
  +l = i+1;
  +break;
  +}
  +}
  +} else {
  +zero_pad = FALSE;
  +}
  +
  +len = MultiByteToWideChar(CP_ACP, 0, str, l, NULL, 0);
  +if (zero_pad)
  +len++;

 This is ugly and unnecessary, MultiByteToWideChar handles embedded nulls
 just fine.


 --
 Alexandre Julliard
 [EMAIL PROTECTED]

Re: slight winsock design change proposal

[Andrey Turkin]

Actually the correct way IMHO is to implement 
AcceptEx/GetAcceptExSockaddrs/TransmitFile in ws2_32.dll, and use 
WSAIoctl(SIO_GET_EXTENSION_FUNCTION_POINTER) to get function addresses 
in mswsock.dll. I believe this is that Windows' mswsock.dll do.


Christopher Harvey wrote:

Dmitry Timoshkov wrote:
  

Christopher Harvey [EMAIL PROTECTED] wrote:



Juan Lang wrote:
  
 I'm giving the mswsock.c file some development time. I need to 
know if

 the winsock API has been inited.

  

The question is, why do you need to know that?  Can't you just
initialize it yourself?  Then you'll know it has been.
--Juan

  

There are some functions that return errors if WSAStartup hasn't been 
called. I think wine should do that too, rather than call it for the 
application.
  

It would really help to at least name those some functions, or even
better to provide a test case.


Alright, I see where I'm going wrong. I was reading the WSAAccept 
function when I thought I was reading the AcceptEx page in MSDN.


Sorry.



  

Re: [PATCH] dbghelp: Implement ImageDirectoryEntryToDataEx

[Andrey Turkin]

Alexandre Julliard wrote:
 Andrey Turkin [EMAIL PROTECTED] writes:

   
 +if (image || addr  nt-OptionalHeader.SizeOfHeaders)
 +{
 +if (section)
 +{
 +PIMAGE_SECTION_HEADER sec = IMAGE_FIRST_SECTION(nt);
 +WORD i;
 +for(i = 0; i  nt-FileHeader.NumberOfSections; i++, sec++)
 +{
 +if (addr = sec-PointerToRawData  (addr - 
 sec-PointerToRawData)  sec-SizeOfRawData)
 +{
 

 It doesn't make sense to check an RVA against PointerToRawData.

   

Oh, yes. I need more coffee :) And I should have been test native -
native doesn't even bother to search section unless it is file mapping
(MSDN is at least not complete, as usual). I'll send new version shortly.

Re: Russian translation of wordpad.

[Andrey Turkin]

Andrey Esin wrote:
 In patch:
 Full translation of wordpad on russian.

 Author: Andrey Esin [EMAIL PROTECTED]

 


You've messed up indentation, and there is a typo in STRING_ALL_FILES.

Re: kernel32: Add an ability to execute 32-bit applications from 16-bit ones using winoldap.dll

[Andrey Turkin]

Dmitry Timoshkov wrote:
 Hello,

 this patch should fix the problem reported in the bug 3620.

 winoldap.mod in Windows is a 16-bit .exe which uses its command line to load
 a 32-bit module and pass the parameters to it. Since winebuild doesn't allow
 to create a 16-bit builtin exe, I decided to create a 16-bit builtin dll
 instead. That adds some complexity due to need to create another thread to
 launch a 32-bit application from, and wait until it finishes.
   
The application mentioned in the bug change current directory to output
dir and then uses WINEXEC with relative filename to start child application.
Thread created by winoldap uses another current directory because of
something, so CreateProcess fails with your patch.

snip


 +if (CreateProcessA( NULL, cmdline, NULL, NULL, FALSE,
 +0, NULL, NULL, startup, info ))
 +{
 +HINSTANCE16 hwinoldap;
 +
 +/* Give 30 seconds to the app to come up */
 +wait_input_idle( info.hProcess, 3 );
 +
 +args-ret = TRUE;
 +SetEvent(args-event);
 +
 +WaitForSingleObject( info.hProcess, INFINITE );
 +
 +CloseHandle( info.hThread );
 +CloseHandle( info.hProcess );
 +
 +/* decrement WINOLDAP usage count to signal that we have finished */
 +hwinoldap = GetModuleHandle16( winoldap );
 +FreeLibrary16( hwinoldap );
 +}
   
Usage count should be decremented regardless of CreateProcess return value.
 +
 +RestoreThunkLock( count );
 +HeapFree( GetProcessHeap(), 0, cmdline );
 +
 +if (!args-ret);
 +SetEvent( args-event );
   
Typo.

Re: [PATCH] Implement BindIoCompletionCallback

[Andrey Turkin]

Alexandre Julliard wrote:
 Robert Shearman [EMAIL PROTECTED] writes:

   
 Andrey Turkin wrote:
 
 Robert Shearman wrote:
   
   
 Andrey Turkin wrote:
 
 
  
 /**

   *BindIoCompletionCallback (KERNEL32.@)
   */
 +extern NTSTATUS WINAPI
 RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG);

   
   
   
 This should go in winternl.h.
 
 
 winternl.h may not depend on winbase.h for some reason, so this would
 mean either changing prototype to (HANDLE,LPVOID,ULONG), which seems
 wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and
 OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication.
   
   
 I think you should guard the function with an #ifdef __WINE_WINBASE_H 
 statement, but I would wait for some other developers to chime in to get 
 a consensus before accepting this though.
 

 It doesn't seem right for an ntdll function to use an OVERLAPPED
 pointer. Shouldn't it take an IO_STATUS_BLOCK instead?

   

It is not used in the function itself, it is only passed to
user-provided callback. So, I see several possibilities:
1) change RtlSetIoCompletionCallback to use another callback prototype,
with LPVOID or ULONG_PTR or something instead of LPOVERLAPPED
2) leave callback prototype as in BindIoCompletionCallback, and protect
RtlSetIoCompletionCallback with #ifdefs as Robert suggested
3) do not implement RtlSetIoCompletionCallback at all and move all code
in kernel32

Re: [PATCH] Implement BindIoCompletionCallback

[Andrey Turkin]

Robert Shearman wrote:
 Andrey Turkin wrote:
  
 /**

   *BindIoCompletionCallback (KERNEL32.@)
   */
 +extern NTSTATUS WINAPI
 RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG);

   

 This should go in winternl.h.
winternl.h may not depend on winbase.h for some reason, so this would
mean either changing prototype to (HANDLE,LPVOID,ULONG), which seems
wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and
OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication.

  BOOL WINAPI BindIoCompletionCallback( HANDLE FileHandle,
 LPOVERLAPPED_COMPLETION_ROUTINE Function, ULONG Flags)
  {
 -FIXME(%p, %p, %d, stub!\n, FileHandle, Function, Flags);
 -SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
 +NTSTATUS status;
 +
 +TRACE((%p, %p, %d)\n, FileHandle, Function, Flags);
 +
 +status = RtlSetIoCompletionCallback( FileHandle, Function, Flags );
 +if (status == STATUS_SUCCESS) return TRUE;
 +SetLastError( RtlNtStatusToDosError(status) );
  return FALSE;
  }   

Re: Possible WIne regression with Warcraft

[Andrey Turkin]

 Let me take a wild guess. /etc/hosts resolves your hostname to a loopback
 address, like 127.0.1.1 or somesuch.

 If that's the case, please change /etc/hosts to make your hostname resolve
 to
 your network card's IP address.

 If that's not the case, please attach a +winsock log to bug 9787.


+winsock,+sync please.
Another wild guess: maybe some out game update or something was recently
rolled out?

Re: Possible WIne regression with Warcraft

[Andrey Turkin]

Hi Michael,

There are http://bugs.winehq.org/show_bug.cgi?id=9787 for this bug

Michael Lothian wrote:
 Hi

 I've noticed a problem in wine recently. When I try and join a network
 game in Warcraft I can see the game but I'm unable to join it.

 These errors are printing out:

 [EMAIL PROTECTED] ~/.wine/drive_c/Program Files/Warcraft III $ wine Frozen\
 Throne.exe
 ALSA lib conf.c:3949:(snd_config_expand) Unknown parameters 0
 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL default:0
 err:ole:CoCreateInstance apartment not initialised
 fixme:advapi:SetSecurityInfo stub
 fixme:win:EnumDisplayDevicesW ((null),0,0x34f3d8,0x), stub!
 fixme:win:EnumDisplayDevicesW ((null),0,0x34f7b0,0x), stub!
 fixme:win:EnumDisplayDevicesW ((null),0,0x34f3bc,0x), stub!
 [EMAIL PROTECTED] ~/.wine/drive_c/Program Files/Warcraft III $
 fixme:winsock:WSAIoctl unsupported WS_IOCTL cmd (980c)
 fixme:mswsock:AcceptEx (listen=8552, accept=8564, 0x31100e8, 0, 32,
 32, 0x34f498, 0x31100b8), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8568, 0x3110170, 0, 32,
 32, 0x34f498, 0x3110140), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8572, 0x31101f8, 0, 32,
 32, 0x34f498, 0x31101c8), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8576, 0x3110280, 0, 32,
 32, 0x34f498, 0x3110250), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8580, 0x3110308, 0, 32,
 32, 0x34f498, 0x31102d8), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8584, 0x3110390, 0, 32,
 32, 0x34f498, 0x3110360), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8588, 0x3110418, 0, 32,
 32, 0x34f498, 0x31103e8), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8592, 0x31104a0, 0, 32,
 32, 0x34f498, 0x3110470), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8596, 0x3110528, 0, 32,
 32, 0x34f498, 0x31104f8), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8600, 0x31105b0, 0, 32,
 32, 0x34f498, 0x3110580), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8604, 0x3110638, 0, 32,
 32, 0x34f498, 0x3110608), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8608, 0x31106c0, 0, 32,
 32, 0x34f498, 0x3110690), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8612, 0x3110748, 0, 32,
 32, 0x34f498, 0x3110718), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8616, 0x31107d0, 0, 32,
 32, 0x34f498, 0x31107a0), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8620, 0x3110858, 0, 32,
 32, 0x34f498, 0x3110828), not implemented
 fixme:mswsock:AcceptEx (listen=8552, accept=8624, 0x31108e0, 0, 32,
 32, 0x34f498, 0x31108b0), not implemented
 fixme:imm:ImmAssociateContextEx (0x30028, (nil), 16): stub


 I'm going to try rolling back to an old version of Wine, I currently
 use the latest git.

 I'll post back if it does work.

 Mike



   

Re: wordpad: (1/6) Split code into set_caption function

[Andrey Turkin]

Alexander Nicolaysen Sørnes wrote:

This will be useful for the file saving code.


Regards,

Alexander N. Sørnes
  


+WCHAR wszCaption[MAX_PATH];
+
+if(wszNewFileName)
+{
+lstrcpyW(wszCaption, wszNewFileName);
+lstrcatW(wszCaption, wszSeparator);
+lstrcatW(wszCaption, wszAppTitle);


Looks like there are possible buffer overflow

Re: gdiplus: added stub implementation of gdiplus.dll

[Andrey Turkin]

James Hawkins wrote:

On 5/25/07, Mounir IDRASSI [EMAIL PROTECTED] wrote:

Hi,
You also have to modify other files in order to integrate your stub
implementation to the wine build chain: Makefile.in, configure and
configure.ac in the wine root directory, Makefile.in in the dlls
directory.



The only file outside of gdiplus that he has to modify is configure.ac.



I thought he should run tools/make_makefiles

Re: kernel32: Implement most of CopyFileEx

[Andrey Turkin]

Sorry for jumping in, but I have some comments as well.
Dan, CopyFileA does not leaks a string (note BOOL flags). Instead first 
call use static TEB-based buffer so this is OK, given that recursion is 
impossible in this case.
Kevin, you are setting file size before copy starts. I'm not sure 
Windows does so; also how would that work if destination file system 
does not support sparse files?


Dan Kegel wrote:

Nice to see somebody filling in the gaps like this.

A few nits based on a superficial reading:

CopyFileA leaks a string.  (I know, it did before your change, too.)

copy_file_open_dest's interface comment has the wrong name.

+for(i = 0; i  sizeof(flags) / sizeof(flags[0]); i++)
+{
+if(for_write) {

Please use the same whitespace conventions as in the
rest of the file (in particular, leave a space after keywords like
for and if).

+if ((h1 = copy_file_open_source(source, copyFlags 
COPY_FILE_OPEN_SOURCE_FOR_WRITE)) == INVALID_HANDLE_VALUE)

That line's too long... try to keep them under 80 chars.

+// FIXME: total_file_size should include the sum of all streams

Use C comments, not C++ comments.

+DWORD result = progressRoutine(total_file_size,
total_bytes_transferred, stream_size, stream_bytes_transferred,
+   stream_number,
CALLBACK_STREAM_SWITCH, h1, h2, appData);

Another instance of line longer than 80 chars.  (You have several.)

You don't have a conformance test, nor was there one for CopyFile.
Maybe you should consider writing one, and making sure it passes
both on Wine and Windows.

Say, what app is this for?
- Dan

Re: Undocumented function syssetup.dll.SetupQueryRegisteredOsComponent

[Andrey Turkin]

It's something like

BOOL SetupQueryRegisteredOsComponent(IN const IID *const pIid, IN OUT 
LPVOID component_data, IN OUT LPVOID exception_data, DWORD reserved1, 
DWORD reserved2);


component_data structure max length is 0xDC, exception_data's is 0x454; 
first argument of both is structure size. I wonder if they defined in 
setupapi.h already.


Dan Kegel wrote:

Any suggestions as to how to discover the prototype
of the apparently undocumented function
syssetup.dll.SetupQueryRegisteredOsComponent ?
It seems to be needed to install mdac-2.8.
( http://bugs.winehq.org/show_bug.cgi?id=5824 )
- Dan

Re: [PATCH] StgOpenStorage patch

[Andrey Turkin]

Mike McCormack wrote:



This is the first time I've submitted a patch, so let me know if this
method of submission is incorrect. See description in the attachment.


It's best to put the description in the body of the mail, and write a 
descriptive subject like ole32: fix StgOpenStorage conformance test 
failure or something like that.


This patch stops StgOpenStorage from creating a file when it does not 
already exist. According to Microsoft's description, StgOpenStorage 
opens an _existing_ root storage object... To create a new file, use the

StorageCreateStorageEx function.

This fixes a bug in Orcad Capture 
(http://bugs.winehq.org/show_bug.cgi?id=7025)


The conformance test file has also been modified to pass this test 
(before it

it was passing in Wine and failing in Windows).


Your patch makes the conformance tests pass on Windows 2000 for me. The 
failing test was added some time ago:


http://www.winehq.org/pipermail/wine-patches/2006-September/030808.html

Maybe Andrey could comment on which version of Windows he was using?

Well, I was using one of Win2K AS, WinXP Pro x64 or Win2K3 Server. I've 
just re-checked test with WinXP pro (non-x64) and Win2K3 and test failed 
on both, so I guess my patch should be taken out as invalid.

Mike

Re: Debugging solidworks 2006

[Andrey Turkin]

First thing to do is to open bug at bugs.winehq.org and describe your 
problem there.

Then, please try to:
1) copy msimtf.dll from Windows to your wine's system32, register it 
with regsvr32 and try if Solid Works issue persists
2) copy atl.dll from Windows to your wine's system32, register it and 
try again with WINEDLLOVERRIDES=atl=n

3) install MS IE6 and try again
Also, maybe +relay debug log will spot a root cause.

Kartik Thakore wrote, on 11/15/06 04:50 MSK:

I am currently trying Solid Works 2006 to work with wine-0.9.25. It
installed with some error, but it finished. The trouble is when it is
run. What is my next step? As this is the first time I am doing
debugging in wine and I have little experience with windows programming.
I am doing this so I can get solidworks working as I really need it. Any
help will be very much appreciated.


fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
fixme:msvcrt:MSVCRT__wsetlocale 4 LC
fixme:msvcrt:MSVCRT__wsetlocale 4 LEnglish_United States.1252
err:wgl:ConvertPixelFormatWGLtoGLX Can't find a matching FBCONFIG_ID for 
VISUAL_ID 0x24!
err:wgl:X11DRV_ChoosePixelFormat Can't find a matching FBCONFIG_ID for 
VISUAL_ID 0x24!
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:toolbar:TOOLBAR_Restore send TBN_GETBUTTONINFO for each button
fixme:shdocvw:PersistStreamInit_InitNew (0x335d3f0)
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
err:shdocvw:get_typeinfo LoadRegTypeLib failed: 8002801d
fixme:shdocvw:navigate_url Unsupported arguments
err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not 
registered
err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} 
could be created for context 0x1
fixme:shdocvw:ClOleCommandTarget_QueryStatus (0x335d48c)-((null) 1 0x33e520 
(nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d48c)-((null) 25 2 0x33e534 (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x335d48c)-((null) 26 2 0x33e534 (nil))
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-709 
{----} 2048 0002 0x33e488 0x33e4d4 (nil) 0x33e498)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5512 
{----} 2048 0002 0x33e448 0x33e494 (nil) 0x33e458)
fixme:shdocvw:ClDispatch_Invoke (0x335d48c)-(-5501 
{----} 2048 0002 0x33e488 

Re: [PATCH] ntdll: round section parameters on 0x200

[Andrey Turkin]

Dmitry Timoshkov wrote:

Andrey Turkin [EMAIL PROTECTED] wrote:

if (map_file_into_view( view, fd, 0, header_size, 0, 
VPROT_COMMITTED | VPROT_READ,

-removable ) != STATUS_SUCCESS) goto error;
+TRUE ) != STATUS_SUCCESS) goto error;


This chunk has nothin to do with the patch description and simply is wrong.
I've hardcoded removevable as TRUE here to force map_file_into_view to 
read data and not mmap it (because mmap will map whole 4k page). Why is 
it wrong? Some packers depend on this. As I said in patch description, 
an alternative would be memset of area beyond header (which would lead 
to mmap, then COW a page and then memset of almost 4k).


-sec-PointerToRawData, (int)pos, 
file_size, map_size,

+(int)start, (int)pos, file_size, map_size,

...

-sec-PointerToRawData, sec-SizeOfRawData,
+(int)start, sec-SizeOfRawData,


Please use a proper format specifier instead of a cast.
Can do (actually I realized that SIZE_T is not so good for start; 
DWORD would be better).

Re: [PATCH] ntdll: round section parameters on 0x200

[Andrey Turkin]

Dmitry Timoshkov wrote:

Andrey Turkin [EMAIL PROTECTED] wrote:

if (map_file_into_view( view, fd, 0, header_size, 0, 
VPROT_COMMITTED | VPROT_READ,
-removable ) != STATUS_SUCCESS) goto 
error;

+TRUE ) != STATUS_SUCCESS) goto error;


This chunk has nothin to do with the patch description and simply is 
wrong.


I've hardcoded removevable as TRUE here to force map_file_into_view 
to read data and not mmap it (because mmap will map whole 4k page). 
Why is it wrong? Some packers depend on this. As I said in patch 
description, an alternative would be memset of area beyond header 
(which would lead to mmap, then COW a page and then memset of almost 
4k).


I reread your explanations and I see now that somehow I misinterpreted 
your
reasoning. What is the file alignment of the problematic PE file? Is 
it 512

(0x200) by any chance?

Yep. However, I've made some quick tests (that is, I've used PE tools to 
rebuild some apps with larger file alignment and then tried to change 
physical offset) and it seems that align cutoff is hard-coded as 0x200.

Re: [PATCH] ntdll: round section parameters on 0x200

[Andrey Turkin]

Some comments inside. Sorry for over-quoting :)

Dmitry Timoshkov wrote, on 11/13/06 10:19 MSK:
 Andrey Turkin [EMAIL PROTECTED] wrote:
 
 What is the file alignment of the problematic PE file? Is it 512
 (0x200) by any chance?

 Yep. However, I've made some quick tests (that is, I've used PE tools
 to rebuild some apps with larger file alignment and then tried to
 change physical offset) and it seems that align cutoff is hard-coded
 as 0x200.
 
 Well, of course larger alignments are always aligned to 0x200.
 
 I took your patch as a base and attached patch make upack 0.39 (latest
 available at its home page http://dwing.51.net/download/WinUpack39.rar)
 executable run under Wine.
 
 diff -up a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c
 --- a/dlls/ntdll/virtual.c2006-11-08 13:55:07.0 +0800
 +++ b/dlls/ntdll/virtual.c2006-11-13 14:57:07.0 +0800
 @@ -133,8 +133,10 @@ static UINT_PTR page_mask;
 #define ROUND_ADDR(addr,mask) \
((void *)((UINT_PTR)(addr)  ~(UINT_PTR)(mask)))
 
 -#define ROUND_SIZE(addr,size) \
 -   (((UINT)(size) + ((UINT_PTR)(addr)  page_mask) + page_mask) 
 ~page_mask)
 +#define ROUND_UP(addr,size,mask) \
 +   (((UINT)(size) + ((UINT_PTR)(addr)  (mask)) + (mask))  ~(mask))
 +
 +#define ROUND_SIZE(addr,size) ROUND_UP(addr,size,page_mask)
 
 #define VIRTUAL_DEBUG_DUMP_VIEW(view) \
 do { if (TRACE_ON(virtual)) VIRTUAL_DumpView(view); } while (0)
 @@ -957,7 +959,7 @@ static NTSTATUS map_image( HANDLE hmappi
 if (!st.st_size) goto error;
 header_size = min( header_size, st.st_size );
 if (map_file_into_view( view, fd, 0, header_size, 0, VPROT_COMMITTED
 | VPROT_READ,
 -removable ) != STATUS_SUCCESS) goto error;
 +TRUE ) != STATUS_SUCCESS) goto error;
 dos = (IMAGE_DOS_HEADER *)ptr;
 nt = (IMAGE_NT_HEADERS *)(ptr + dos-e_lfanew);
 header_end = ptr + ROUND_SIZE( 0, header_size );
 @@ -1031,7 +1033,7 @@ static NTSTATUS map_image( HANDLE hmappi
 
 for (i = pos = 0; i  nt-FileHeader.NumberOfSections; i++, sec++)
 {
 -SIZE_T map_size, file_size, end;
 +SIZE_T map_size, file_size, start, end;
 
 if (!sec-Misc.VirtualSize)
 {
 @@ -1045,6 +1047,7 @@ static NTSTATUS map_image( HANDLE hmappi
 }
 
 /* a few sanity checks */
 +start = (SIZE_T) ROUND_ADDR( sec-PointerToRawData,
 nt-OptionalHeader.FileAlignment - 1 );
I believe this is incorrect with regard to native Windows loader. As I
already said, I've tried to change PointerToRawData field on some files
with big FileAlignment and they load correctly if I or'ed them with some
value in range 0..0x1FF. Files refuses to load if I or'ed
PointerToRawData with 0x200 or 0x3FF!
 end = sec-VirtualAddress + ROUND_SIZE( sec-VirtualAddress,
 map_size );
 if (sec-VirtualAddress  total_size || end  total_size || end
  sec-VirtualAddress)
 {
 @@ -1095,9 +1098,9 @@ static NTSTATUS map_image( HANDLE hmappi
 /* Note: if the section is not aligned properly
 map_file_into_view will magically
  *   fall back to read(), so we don't need to check anything
 here.
  */
 -end = sec-PointerToRawData + file_size;
 -if (sec-PointerToRawData = st.st_size || end  st.st_size ||
 end  sec-PointerToRawData ||
 -map_file_into_view( view, fd, sec-VirtualAddress,
 file_size, sec-PointerToRawData,
 +end = start + file_size;
 +if (start = st.st_size || end  st.st_size || end  start ||
 +map_file_into_view( view, fd, sec-VirtualAddress,
 file_size, start,
 VPROT_COMMITTED | VPROT_READ |
 VPROT_WRITECOPY,
 removable ) != STATUS_SUCCESS)
 {
 @@ -1107,12 +1110,13 @@ static NTSTATUS map_image( HANDLE hmappi
 
 if (file_size  page_mask)
 {
 +start = ROUND_UP( 0, file_size,
 nt-OptionalHeader.FileAlignment - 1 );
I've not checked this, but there's probability that align is 0x200 here too.
 end = ROUND_SIZE( 0, file_size );
 if (end  map_size) end = map_size;
 TRACE_(module)(clearing %p - %p\n,
 -   ptr + sec-VirtualAddress + file_size,
 +   ptr + sec-VirtualAddress + start,
ptr + sec-VirtualAddress + end );
 -memset( ptr + sec-VirtualAddress + file_size, 0, end -
 file_size );
 +memset( ptr + sec-VirtualAddress + start, 0, end - start );
 }
 }
 
 diff -up a/server/mapping.c b/server/mapping.c
 --- a/server/mapping.c2006-11-03 21:34:24.0 +0800
 +++ b/server/mapping.c2006-11-13 14:34:50.0 +0800
 @@ -243,7 +243,7 @@ static int get_image_params( struct mapp
 
 mapping-size= ROUND_SIZE( nt.OptionalHeader.SizeOfImage );
 mapping-base= (void *)nt.OptionalHeader.ImageBase;
 -mapping-header_size = pos + size;
 +mapping-header_size

Re: [PATCH] Implement GetShellSecurityDescriptor and test for it

[Andrey Turkin]

Francois Gouget wrote:

On Mon, 6 Nov 2006, Andrey Turkin wrote:
[...] 
The patch also adds 2 structures definitions to include/shlwapi.h. 
According to MSDN, one of these structures should be placed into 
include/shlobj.h,


The MSDN is wrong: the PSDK does not define any of SHELL_USER_SID, 
SHELL_USER_PERMISSION or GetShellSecurityDescriptor(). So they should be 
defined in a private shlwapi header, not in include/shlobj.h or 
include/shlwapi.h.



Which PSDK version do you have?


but I think it is bad idea to include shlobj.h from 
shlwapi.h (at least at the moment).


It would certainly be a bad idea since the PSDK's shlwapi.h header does 
not include shlobj.h.

Re: [PATCH] Implement GetShellSecurityDescriptor and test for it

[Andrey Turkin]

Please ignore this patch. I'll resubmit corrected version.

Francois, thanks!

Francois Gouget wrote:

On Mon, 6 Nov 2006, Andrey Turkin wrote:
[...]

The MSDN is wrong: the PSDK does not define any of SHELL_USER_SID,
SHELL_USER_PERMISSION or GetShellSecurityDescriptor(). So they should be
defined in a private shlwapi header, not in include/shlobj.h or
include/shlwapi.h.


Which PSDK version do you have?


It seems they all agree on this. For instance Windows 2003 SP2 20060315 
PSDK.

Re: Question: Convert source tarball to GIT repository

[Andrey Turkin]

Mike McCormack wrote, on 10/24/06 00:01 MSK:
 
 Matthew Kehrer wrote:
 
 So what commands are needed to just update it?
 I understand how to set it up from what you have said.
 
 So, assuming you created a Git tree from Wine tarball as follows:
 
 tar jxvf wine-0.9.23.tar.bz2 | sed s/^wine-0.9.23\\///  list
 cd wine-0.9.23
 git init-db
 git update-index --add `cat ../list`
 git commit -m Import of wine-0.9.23
 
 And the initial tree's SHA-1 ID matches:
 
 Committing initial tree c8369ac44e507d96073ca57e9a0a1e77f5ec9511
 
 Download my update script from http://mandoo.dyndns.org/update.sh
 then change into your Wine 0.9.23 Git directory and run the script. ie.
 
 cd wine-0.9.23
 sh update.sh
 
 This should download the latest commits from WineHQ.org via my server.
 The output is something like:
 
 [EMAIL PROTECTED]:~/wine-0.9.23$ sh update.sh
 Last tree is 5e4b428f32db20582941331a37f1cdb9f462da77
 Now querying for a matching commit...
 Matching commit is 2cb378d498b7525eb34bd163fcc77d00fe595335
 Now downloading patches...
 ...
 
 Things to remember:
 
 * You shouldn't commit to this Git tree... clone it first and commit to
 the clone, or branch and switch back to the original branch for updates.
  If you commit to the branch that updates come to, the update script
 won't work.
 
 * It requires an equivalent hacked up gitweb.cgi, which is only on the
 website pointed to by the script at the moment.
 
 * This is hacked together in a few hours.  To get something more
 reliable and that might be acceptable to the Git project will take
 somewhat longer.
 
 Anyway, I'd appreciate any testing anybody is willing to give the
 script, and any feedback.
 
In two words: it works! The script took about 5 Mb of traffic to update
from 0.9.23 to the current head (not too much but binary 0.9.22-0.9.23
delta is about 500 kb). Using curl --compressed when possible (and
configuring your server to support compressed documents) should decrease
traffic volume significantly.
 Mike
 
 
 

Re: small bug in mshtml component

[Andrey Turkin]

Jacek Caban wrote, on 10/20/06 22:13 MSK:
 Hi Andrey,
 
 Andrey Turkin wrote:
 Hi,

 Just found a bug in mshtml component get_body method implementation. If
 one call it right after creation of CLSID_HTMLDocument instance, then it
 would return success and pass NULL as body object. Native would return
 empty body object instead. Native atl.dll library uses this behavior
 and because of this segfaults.
 I'm not acquainted with mshtml code enough to provide bug fix or even
 test patch (I mean proper test). Here is quick-n-dirty test instead:

 void test_for_body(void)
 {
 HRESULT hr;
 IHTMLDocument *doc;
 IHTMLDocument2 *doc2;
 IPersistStreamInit *psi;
 IHTMLElement *body;

 hr = CoCreateInstance(CLSID_HTMLDocument, NULL, CLSCTX_SERVER,
 IID_IHTMLDocument, (void**)doc);
 ok( SUCCEEDED(hr), CoCreateInstance failed:%08x\n, hr);
 hr = IHTMLDocument_QueryInterface(doc, IID_IPersistStreamInit,
 (void**)psi);
 ok( SUCCEEDED(hr), QI PSI failed %08x\n, hr );
 IPersistStreamInit_InitNew( psi );
 IPersistStreamInit_Release( psi );
 hr = IHTMLDocument_QueryInterface(doc, IID_IHTMLDocument2,
 (void**)doc2);
 IHTMLDocument_Release( doc );
 ok( SUCCEEDED(hr), QI HD2 failed %08x\n, hr );
 hr = IHTMLDocument2_get_body( doc2, body);
 IHTMLDocument2_Release( doc2 );
 ok( SUCCEEDED(hr), get_body failed %08x\n, hr );
 ok( body != NULL, get_body returned NULL\n );
 if ( body != NULL )
  IHTMLElement_Release( body );
 }

 I hope a man with good mshtml knowledge would easily turn this test into
 neat small test in few minutes.
   
 Thanks for your work on this. Are you sure you have wine_gecko
Right... I have mozctl installed but it weren't picked up by mshtml. I
should look better in traces before writing tests :( So, actual problem
lies in load_mozctl function in nsembed.c. This function calls
load_xpcom() but then falls down and reports failure. I've added one
word return and things are working now :)
 installed? I'm asking because your test works for me. The correct
 behavior requires quite much work as it depends on a correct
 loading routine, but I'd expect the currentimplementation to be
 enough in your case. The background of this problem is:
 
 - current implementation
 get_body calls Gecko's GetDocument that loads about:blank
 page in case no page is loaded and returns its body.
 
 - correct implementation
 get_body return S_OK and NULL if no page is loaded. However
 IniNew call initializes document so get_body will return a valid
 body object.
 
 The loading routine is the main problem with current MSHTML,
 but I'd expect it to be enough for your case.
 
 Thanks,
 Jacek
 

Re: msi: Update the files' target paths as well, because they may have changed if a parent directory is changed

[Andrey Turkin]

James Hawkins wrote:
 On 7/4/06, Andrey Turkin [EMAIL PROTECTED] wrote:

 Hi James,

 Funny, your patch looks just identical to mine (submitted but rejected
 by some reason) except for comments :)

 
 hmm I haven't seen your patch.  If the code is similar, it's probably
 because we both copied and pasted from ACTION_CostFinalize.
Yeah, you and me found have done identical job here. I've been too busy
to send this fix again :(
 
 !-- beware of if () {} else if () {} else if () ... constructs --
 By the way, does your patch fixes this issue for TARGETPATH? If yes,
 then the patch should remove some todo_wine in tests. If no, then do you
 plan to fix it in another patch? If no, then I will send patch to fix it
 myself later.

 
 I'm not sure what you're asking, if it fixes the issue for TARGETPATH.
 I'm guessing you mean TARGETDIR.  The second part of your patch
You right, I've meant TARGETDIR. I've submitted test for this bug in
case of TARGETDIR; that's why I asked you about it.
 should be sent separately, in any case, becuase there are two fixes.
Yes, I guess that's why my patch was rejected.
 As the note for my patch said, this behavior is expected by several
 installers, specifically the Lotus Notes installer, which works after
 the patch.
 
Ok, so I'll resubmit fix for TARGETDIR later.

Re: msi: Update the files' target paths as well, because they may have changed if a parent directory is changed

[Andrey Turkin]

James Hawkins wrote:
 Hi,
 
 This fixes bug 5595.  The Lotus Notes installer was calling
 MsiSetTargetPath after the CostFinalize action, which is where the
 target paths are originally set for installation files.  Originally,
 the directories were being changed, but that doesn't trickle down to
 the file's target paths, so we have to update those too.  After this
 change, all the Lotus Notes files install in the correct destination
 directory.  Note that this affects other installers as well, but I
 don't remember the numbers off the top of my head.
 
 Changelog:
 * Update the files' target paths as well, because they may have
 changed if a parent directory is changed.
 
 dlls/msi/install.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)
 
 -- 
 James Hawkins
 
 
 
 
 diff --git a/dlls/msi/install.c b/dlls/msi/install.c
 index 5eaf10b..a09782d 100644
 --- a/dlls/msi/install.c
 +++ b/dlls/msi/install.c
 @@ -331,6 +331,7 @@ UINT MSI_SetTargetPathW(MSIPACKAGE *pack
  LPWSTR path = NULL;
  LPWSTR path2 = NULL;
  MSIFOLDER *folder;
 +MSIFILE *file;
  
  TRACE((%p %s %s)\n,package, 
 debugstr_w(szFolder),debugstr_w(szFolderPath));
  
 @@ -374,6 +375,21 @@ UINT MSI_SetTargetPathW(MSIPACKAGE *pack
  path2 = resolve_folder(package, f-Directory, FALSE, TRUE, NULL);
  msi_free(path2);
  }
 +
 +LIST_FOR_EACH_ENTRY( file, package-files, MSIFILE, entry )
 +{
 +MSICOMPONENT *comp = file-Component;
 +LPWSTR p;
 +
 +if (!comp)
 +continue;
 +
 +p = resolve_folder(package, comp-Directory, FALSE, FALSE, NULL);
 +msi_free(file-TargetPath);
 +
 +file-TargetPath = build_directory_name(2, p, file-FileName);
 +msi_free(p);
 +}
  }
  msi_free(path);
  
 
 
 
 
 

Hi James,

Funny, your patch looks just identical to mine (submitted but rejected
by some reason) except for comments :)

!-- beware of if () {} else if () {} else if () ... constructs --
By the way, does your patch fixes this issue for TARGETPATH? If yes,
then the patch should remove some todo_wine in tests. If no, then do you
plan to fix it in another patch? If no, then I will send patch to fix it
myself later.

Re: advapi32: Implement RegisterServiceCtrlHandleExW.

[Andrey Turkin]

Robert Shearman wrote:
 ---
...
 @@ -603,10 +608,18 @@ static BOOL service_handle_control(HANDL
  
  TRACE(received control %ld\n, dwControl);
  
 -if (service_accepts_control(service, dwControl)  service-handler)
 +if (service_accepts_control(service, dwControl))
  {
 -service-handler(dwControl);
 -ret = ERROR_SUCCESS;
 +if (service-extended  service-handler.handler)
 +{
 +service-handler.handler(dwControl);
 +ret = ERROR_SUCCESS;
 +}
 +else if (service-handler.handler_ex)
 +{
 +service-handler.handler_ex(dwControl, 0, NULL, 
 service-context);
 +ret = ERROR_SUCCESS;
 +}
  }
Just wondering why you use Ex handler when service-extended==FALSE and
vice versa.

Re: MSI database _Streams table

[Andrey Turkin]

Dan Kegel wrote:
 In http://www.winehq.org/pipermail/wine-patches/2006-June/027528.html,
 Andrey Turkin wrote:
 
 Some installers depends on _Streams built-in table
 
 Which installers?
 It'd be nice to have a bug in bugzilla to hang your MSI work on.
 Thanks!
 - Dan
 
For example, Microsoft's .NET Framework 1.1 installer. With my MSI fixes
it almost completes install, but fails inside .NET programs (RegSvcs).

Re: user[3/5]: handle special cases for SPI_SETDESKWALLPAPER (FIXED)

[Andrey Turkin]

Andrew Ziem wrote:
Please use this patch instead of previous user3.patch.  Thanks to 
Andrey Turkin for catching the uninitialized variable.


changelog:
user: handle special cases for SPI_SETDESKWALLPAPER

The special cases remove the wallpaper or set it to default.  
Previously, these cases were ignored, so Wine would crash.







 
-if (filename == (LPSTR)-1)

+if ((LPCSTR)SETWALLPAPER_DEFAULT == filename || (LPCSTR)NULL == filename 
|| '\0' == filename[0])
 {
-   GetProfileStringA( desktop, WallPaper, (None), buffer, 256 );
-   filename = buffer;
+   /* set default wallpaper or remove wallpaper*/
+   if (hbitmapWallPaper)
+   DeleteObject( hbitmapWallPaper );
+   return TRUE;
 }
 hdc = GetDC( 0 );


According to MSDN, if
 - pvParam==SETWALLPAPER_DEFAUL || pvParam==NULL, then wallpaper will 
be set to default one

- pvParam[0]=='\0', then wallpaper will be removed.
I cannot see any signs of such distinction in your code :)

Re: user[2/5]: implement A version of SPI_GETDESKWALLPAPER

[Andrey Turkin]

Andrew Ziem wrote:
Previously, SPI_GETDESKWALLPAPER was handled by default: in the 
switch, so the function (an A- function) would return a W string.





5e4b86d689c899fc896d2870efaca9c335f01da0
diff --git a/dlls/user/sysparams.c b/dlls/user/sysparams.c
index 5fed316..fb54b3b 100644
--- a/dlls/user/sysparams.c
+++ b/dlls/user/sysparams.c
@@ -2496,6 +2496,16 @@ BOOL WINAPI SystemParametersInfoA( UINT 
 	break;

 }
 
+case SPI_GETDESKWALLPAPER:  /* 115 */

+{
+WCHAR buffer[MAX_PATH];
+ret = SystemParametersInfoW( SPI_GETDESKWALLPAPER, uiParam, buffer, 
fuWinIni );
+if (!WideCharToMultiByte(CP_ACP, 0, buffer, -1, pvParam, uiParam, 
NULL, NULL))
+   ret = FALSE;
+else
+   pvParam = buffer;
+}
+
 default:
 ret = SystemParametersInfoW( uiAction, uiParam, pvParam, fuWinIni );
 break;

  




  


I think break is needed after case. Also, for what

else pvParam = buffer;

need for?

Re: user[3/5]: handle special cases for SPI_SETDESKWALLPAPER

[Andrey Turkin]

I cannot see where emptyW initialized.

Andrew Ziem wrote:
The special cases remove the wallpaper or set it to default.  
Previously, these cases were ignored, so Wine would crash.



snip

+if (NULL == pvParam || SETWALLPAPER_DEFAULT == pvParam)
+{
+static const WCHAR emptyW[1];
+if (!SetDeskWallPaper( (LPSTR)pvParam ))
+return FALSE;
+SYSPARAMS_Save(SPI_SETDESKWALLPAPER_REGKEY, 
SPI_SETDESKWALLPAPER_VALNAME, emptyW, fWinIni);
+}
+else
+{
+if (!SetDeskWallPaper( (LPSTR) pvParam ))
+   return FALSE;
+}
+break;
  

Re: Wine VM86 exception handling bug?

[Andrey Turkin]

I believe it is better to store binaries as arrays and use temporary 
files than drop many small .com binaries all over the code tree (for now 
I have 3 test programs about 30 bytes each). It is possible to 
comment/disassemble test cases instruction by instruction, if needed.


Also, not everyone can use git, and I believe diff/patch would fail to 
produce patchable diffs with binary files in them.


Mike Hearn wrote:

On 6/5/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
 I'd rather we got out of the habit of doing this seeing as I think 
git can

 deal with binaries better than cvs can.

There is no point in storing the binaries in the *source* tree, besides
tiny .com file which shows the bug shouldn't take more than 100 bytes
of an array in the .c file.


Sure it might be small, but it's still a binary no matter how we store
it. It's not more useful as an array than as a true binary file on
disk. Why obfuscate and expand it by embedding it into a text file?

thanks -mike

Re: Wine VM86 exception handling bug?

[Andrey Turkin]

I used nasm and hiew. There is no point in adding additional tools 
dependencies. Anyway the test codes wouldn't be changed somehow often.

And anyway I'm already submitted patch :)

Detlef Riekenberg wrote:

Am Montag, den 05.06.2006, 11:58 +0100 schrieb Mike Hearn:

On 6/5/06, Robert Shearman [EMAIL PROTECTED] wrote:

It depends whether it's in a convenient form. For a 100-byte COM file,
it is probably already in its most convenient form.

If, like Rob, you are an i386 ninja master who wields a disassembler
as most of us wield a knife and fork then yes maybe :) For the rest of
us source code can be occasionally convenient chuckle


bin86 (BCC, together with as86 and ld86) might help wine.

Bruce Evans C Compiler can create COM-Files
Updates are done by Robert de Bath

Homepage:
http://freshmeat.net/redir/bin86/743/url_homepage/~mayday

Re: Wine VM86 exception handling bug?

[Andrey Turkin]

Dan Kegel wrote:

Andrey wrote:

My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86
would restore vm86 registers correctly. I think i know what is the
problem; however, I lack experience to fix it myself :)
I need help; any hints would be appreciated.


How about writing a conformance test that demonstrates
the problem?  That will help focus discussion and energy
on it, and keep it from coming back.

Thanks!
- Dan



I would be happy to do it. Unfortunely, I cannot imagine how to 
implement such test:
1) DOS code needed - it would need binary or some sort of source to be 
compiled prior to test or some temporary file with a binary

2) method to catch failure inside of ntdll
3) maybe something else...
It is just not seems to be possible to do all this inside of some .c file.

Hmm, is there any test for kernel or winedos at all?

Re: README: Updated to not point users at wineinstall and to mention fontforge

[Andrey Turkin]

Molle Bestefich wrote:

echo =media-gfx/fontforge-20060406  /etc/portage/package.keywords

echo media-gfx/fontforge ~x86  /etc/portage/package.keywords


Latter version is definitely preferable, as otherwise FontForge will
never again be upgraded (right?).



I believe that former version will unmask only given version while 
latter version will unmask all unstable versions of fontforge, forcing 
users to update every time new version is available. So, using former 
version, x86 keyworded systems will be updated to 20060406 version, and 
will stay on it until more recent version will be marked as stable.

Re: [coverity] Don't close uninitialized handle on VXD error path

[Andrey Turkin]

I thought INVALID_HANDLE_VALUE==-1 and not 0. Moreover, I can't see any 
code path leading to ERR where handle is allocated (or assigned to) at 
all so I think there is no need to close it.


Mike Hearn wrote:

Mike Hearn [EMAIL PROTECTED]
Don't close uninitialized handle on VXD error path

diff --git a/dlls/kernel/vxd.c b/dlls/kernel/vxd.c
index 5d16684..2a004a0 100644
--- a/dlls/kernel/vxd.c
+++ b/dlls/kernel/vxd.c
@@ -179,7 +179,7 @@ HANDLE VXD_Open( LPCWSTR filenameW, DWOR
 {
 static const WCHAR dotVxDW[] = {'.','v','x','d',0};
 int i;
-HANDLE handle;
+HANDLE handle = INVALID_HANDLE_VALUE;
 HMODULE module;
 WCHAR *p, name[16];
 
@@ -254,10 +254,14 @@ HANDLE VXD_Open( LPCWSTR filenameW, DWOR

 }
 
 ERR(too many open VxD modules, please report\n );

-CloseHandle( handle );
+
+if (handle)

+{
+CloseHandle( handle );
+handle = 0;
+}
 FreeLibrary( module );
-handle = 0;
-
+
 done:

 RtlLeaveCriticalSection( vxd_section );
 if (!DuplicateHandle( GetCurrentProcess(), handle, GetCurrentProcess(), 
handle, 0,