wine-devel February 2015

wine-devel@winehq.org

58 participants
166 discussions

Re: setupapi: fix string conversion in SetupGetInfInformationA()
by Jacek Caban 08 Feb '15

08 Feb '15

Hi Pierre, On 02/08/15 19:59, Pierre Schweitzer wrote: > inf = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (!inf) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; You don't need to call SetLastError here. It's already set by HeapAlloc on failure. Jacek

2 2

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog() (try 2)
by Nikolay Sivov 07 Feb '15

07 Feb '15

This one is clearly broken regarding critical section usage.

1 0

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog()
by Nikolay Sivov 07 Feb '15

07 Feb '15

Hi, Pierre. Some comments for your patch. > --- a/dlls/setupapi/Makefile.in > +++ b/dlls/setupapi/Makefile.in > @@ -11,6 +11,7 @@ C_SRCS = \ > diskspace.c \ > fakedll.c \ > install.c \ > + log.c \ > misc.c \ > parser.c \ > query.c \ I'm not sure you need a new file for that. It depends on how much will be possibly added in the future, but general rule I think is to try to find a room in existing files. > +#include "wine/debug.h" > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "winreg.h" > +#include "setupapi.h" > +#include "winnls.h" Looks like you don't need all of those. > +HANDLE setupact = INVALID_HANDLE_VALUE; > +HANDLE setuperr = INVALID_HANDLE_VALUE; Should be static. > + LPWSTR msg = (LPWSTR)MessageString; I see what you want to do, but it's a bit ugly imho. > + if (MessageString) > + { > + len = lstrlenA(MessageString) + 1; > + msg = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + MultiByteToWideChar(CP_ACP, 0, MessageString, -1, msg, len); > + } Please check for memory allocation failure. > + ret = WriteFile(setupact, MessageString, lstrlenW(MessageString) * sizeof(WCHAR), NULL, NULL); > + ret = WriteFile(setuperr, MessageString, lstrlenW(MessageString) * sizeof(WCHAR), NULL, NULL); You can probably do strlenW() once. > + GetWindowsDirectoryW(path, MAX_PATH); Same, you need to get this path once. > + if (setupact != INVALID_HANDLE_VALUE) > + { > + CloseHandle(setupact); > + setupact = INVALID_HANDLE_VALUE; > + } > + > + if (setuperr != INVALID_HANDLE_VALUE) > + { > + CloseHandle(setuperr); > + setuperr = INVALID_HANDLE_VALUE; > + } You can just CloseHandle() unconditionally. I think it also makes sense to SetupCloseLog() on PROCESS_DETACH, but that's easy to test. Another thing to test is to see what happens in multithreaded case, if it works correctly on windows you need to protect those handles in SetupOpenLog/SetupCloseLog, maybe somewhere else too.

2 1

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog()
by Marvin 07 Feb '15

07 Feb '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11472 Your paranoid android. === wvistau64 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w2008s64 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w7u (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w8 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === wvistau64 (64 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w2008s64 (64 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87

1 0

Re: server: Filter WM_QUIT message in PeekMessage call if PM_QS_POSTMESSAGE was not specified
by Marvin 06 Feb '15

06 Feb '15

2 1

Re: ntdll load_dll broken WoW behavior
by Patrick Rudolph 06 Feb '15

06 Feb '15

Am 2015-02-06 12:07, schrieb Nikolay Sivov: > On 06.02.2015 14:02, Patrick Rudolph wrote: >> Am 2015-02-06 09:22, schrieb Nikolay Sivov: >>> On 06.02.2015 11:12, Patrick Rudolph wrote: >>>> Hi guys, >>>> I tried WoW as it seems to be in a good shape, but run into same >>>> issues. >>>> I hope you can clarify. >>>> I've got an game that has two executables, 32bit and 64bit. It >>>> places a >>>> 32bit version of xinput1_3.dll in the same folder on startup. >>>> Trying to start the 32bit version works fine, however starting the >>>> 64bit >>>> version doesn't work. >>>> For me it looks like the ntdll load_dll is the fault. >>>> It searches for builtin xinput1_3 and finds the 32bit dll in the >>>> game >>>> folder. It fails to open it (wrong ARCH) and that's it. >>>> Instead of trying other directories it tries to load native. >>>> Again it opens the first file found in the given path, it's the same >>>> file again, it fails to open it and the application terminates. >>>> >>>> Why doesn't it check for correct ARCH ? >>>> Why doesn't it walk all directories / all path given, instead of >>>> just >>>> using the first file found ? >>> >>> What do you mean by that? It doesn't check usual System32 dir for 64 >>> bit dll, is that what you expect? >>> >> Why doesn't it check for files in syswow64 ? > > Because syswow64 is a directory for 32bit system dlls/exes. So for > 64bit process it doesn't make much sense to look for dependencies > there. So system32 contains 64bit libraries and syswow64 32bit libraries... OK. then why doesn't it look into system32 for the correct dll ? > >>> >>>> Does Windows 64bits behave the same ? >>> >>> Does this game work in Windows with same conditions? Or any minimal >>> test case for that matter, like 64bit exe + 32bit dll with >>> appropriate >>> name, is that what you see? >>> >> I guess it is working, why should a vendor release a non functional >> game ? >> But I cannot test it, as I do not own a Windows. > > Maybe you just need 64bit version of xinput then? I can't place it in the same folder as there's already a 32bit version. Why doesn't it take the 64bit version in system32. > >>> >>>> Regards >>>> >>>> >>

3 2

Re: ntdll load_dll broken WoW behavior
by Patrick Rudolph 06 Feb '15

06 Feb '15

Am 2015-02-06 09:22, schrieb Nikolay Sivov: > On 06.02.2015 11:12, Patrick Rudolph wrote: >> Hi guys, >> I tried WoW as it seems to be in a good shape, but run into same >> issues. >> I hope you can clarify. >> I've got an game that has two executables, 32bit and 64bit. It places >> a >> 32bit version of xinput1_3.dll in the same folder on startup. >> Trying to start the 32bit version works fine, however starting the >> 64bit >> version doesn't work. >> For me it looks like the ntdll load_dll is the fault. >> It searches for builtin xinput1_3 and finds the 32bit dll in the game >> folder. It fails to open it (wrong ARCH) and that's it. >> Instead of trying other directories it tries to load native. >> Again it opens the first file found in the given path, it's the same >> file again, it fails to open it and the application terminates. >> >> Why doesn't it check for correct ARCH ? >> Why doesn't it walk all directories / all path given, instead of just >> using the first file found ? > > What do you mean by that? It doesn't check usual System32 dir for 64 > bit dll, is that what you expect? > Why doesn't it check for files in syswow64 ? > >> Does Windows 64bits behave the same ? > > Does this game work in Windows with same conditions? Or any minimal > test case for that matter, like 64bit exe + 32bit dll with appropriate > name, is that what you see? > I guess it is working, why should a vendor release a non functional game ? But I cannot test it, as I do not own a Windows. > >> Regards >> >>

2 1

How WINE implements BitBlt function?
by John Found 06 Feb '15

06 Feb '15

This question arouse when I have made some tests in assembly language. I have wrote a program that to allocate some memory bitmap, fill it with some image and then draw it on a window. The in-memory processing is pretty fast so the main time consuming operation is the drawing of the bitmap on the window. The code is the same for the Windows and Linux version of the program and only the code that draws the bitmap on the window differs. In the Windows version it uses DIB and BitBlt function and in the Linux version it uses XImage bitmap and XPutImage function from XLib. I expected to have some similar performance of both programs, but was surprised, that in WINE, the Windows version performs approximately by 50% faster (150fps) than the Linux version (90..100fps) and the Linux version loads the CPU much higher than the Windows one. So, the question: How in WINE is implemented BitBlt function in order to have so high performance and so low CPU load? -- John Found <johnfound(a)asm32.info>

4 11

ntdll load_dll broken WoW behavior
by Patrick Rudolph 06 Feb '15

06 Feb '15

Hi guys, I tried WoW as it seems to be in a good shape, but run into same issues. I hope you can clarify. I've got an game that has two executables, 32bit and 64bit. It places a 32bit version of xinput1_3.dll in the same folder on startup. Trying to start the 32bit version works fine, however starting the 64bit version doesn't work. For me it looks like the ntdll load_dll is the fault. It searches for builtin xinput1_3 and finds the 32bit dll in the game folder. It fails to open it (wrong ARCH) and that's it. Instead of trying other directories it tries to load native. Again it opens the first file found in the given path, it's the same file again, it fails to open it and the application terminates. Why doesn't it check for correct ARCH ? Why doesn't it walk all directories / all path given, instead of just using the first file found ? Does Windows 64bits behave the same ? Regards

2 1

Re: include: add msasn1.h
by Charles Davis 05 Feb '15

05 Feb '15

> On Feb 5, 2015, at 1:20 PM, Austin English <austinenglish(a)gmail.com> wrote: > +typedef unsigned long ASN1uint32_t; > +typedef signed long ASN1int32_t; This won’t do what you (apparently) expect on 64-bit. At the very least, you should use ULONG/DWORD and LONG here. > +#ifndef WINAPI > +#define WINAPI __stdcall > +#endif This is most certainly wrong for Wine. I think you should include “windef.h” if you need WINAPI. I’m beginning to wonder if you copied this header (as well as <hidpi.h>) directly from Microsoft’s SDKs. You’ve been around long enough to know that that’s a big no-no around here. Chip

2 3

Jump to page:

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 February 2015