August 2008 - Wine-Devel - list.winehq.org

Storesonline, Ecommerce hosting solution - how to avoid mistakes that put your business at risk
by Mister Nice Guy Aug. 14, 2008

Aug. 14, 2008

*Storesonline, Ecommerce hosting solution - how to avoid mistakes that put your business at risk* Building an e-business inevitably requires a dedicated ecommerce hosting solution that can support the infrastructures. There are plenty of areas to take care of. Depending on your business types, you will need to consider the technical areas that support the e-business transactions. Then * Storesonline* is the right fit for you. You also need to have strong customer support from the website provider. Reputation and security are critical factors which sustain your business. In order to avoid pitfalls due to an inferior host, this article reveals the mentioned areas and helps you determine the steps to proceed further. *Storesonline* does avoid these pitfalls and it's working really well. Unlike hosting an ordinary website, running an ecommerce website such as an online store can demand a high technical focus. For instance, you may need a shopping cart and a payment processor. Other than these, you may also wish to have regular backup service, site monitoring or digital certificates that can protect your valuable business. If so, you have to choose an ecommerce web site hosting plan that fits your needs. But it is really dependent on the business size. If you sell a few products, a simple ecommerce web hosting will be sufficient. *Storesonline* can handle the smallest mom and pop site to the biggest on the planet. However, for a business site of much larger scale, you need to consider the server usage and bandwidth. In such case, a fast and stable server with bigger memories may be necessary.

2 1

re: [appwiz.cpl]New Korean Resource
by Dan Kegel Aug. 14, 2008

Aug. 14, 2008

Hi Hwang, Thank you for helping localize Wine in Korean! According to our automated patch checker, http://kegel.com/wine/patchwatcher/results/ your patches did not apply easily. You should probably repost them with all filenames as if you were one level above the wine tree. e.g. instead of --- dlls/appwiz.cpl/appwiz.rc 2008-07-26 09:24:56.000000000 +0900 +++ appwiz.rc 2008-07-28 09:48:00.000000000 +0900 you'd want --- a/dlls/appwiz.cpl/appwiz.rc 2008-07-26 09:24:56.000000000 +0900 +++ b/dlls/appwiz.cpl/appwiz.rc 2008-07-28 09:48:00.000000000 +0900 and instead of --- /dev/null 2008-07-28 09:27:06.210506864 +0900 +++ Ko.rc 2008-07-28 09:48:00.000000000 +0900 you'd want --- /dev/null 2008-07-28 09:27:06.210506864 +0900 +++ b/dlls/appwiz.cpl/Ko.rc 2008-07-28 09:48:00.000000000 +0900 The best way to generate patches is by using something like git diff or git format-patch as described at http://www.winehq.org/site/sending_patches as that always gets the directories right. Can you regenerate your patches properly, verify that your patches apply cleanly when in the top level of wine using the -p1 flag, e.g. cd ~/wine-git patch -p1 < ~/foo.patch and then resend the fixed patches? Thanks, Dan

1 0

Re: [TRY 4] Add tests for checking the parent notification for editcontrol
by Dmitry Timoshkov Aug. 13, 2008

Aug. 13, 2008

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > Best regards > Ilya Shpigor. This version of the patch hasn't changed anything since my previous comments. -- Dmitry.

1 0

No GIT changes since 7 days?
by thacrazze Aug. 13, 2008

Aug. 13, 2008

Hello, why are no GIT changes since 7 days? Exists a right problem with Microsoft? And what's with the planned 1.1.3? Best regards, thacrazze

3 2

dplayx tests hanging
by Dan Kegel Aug. 12, 2008

Aug. 12, 2008

Hi Ismael, have a look at http://test.winehq.org/data/tests/dplayx:dplayx.html Since your commits on the 4th of Aug, the dplayx tests have been hanging. This is getting in the way of my regression testing. Can you have a look? Thanks, Dan

4 10

Patchwatcher online
by Dan Kegel Aug. 12, 2008

Aug. 12, 2008

For the moment, the results only go to a web page, http://kegel.com/wine/patchwatcher/results/ Most of the results there right now are just test messages so you can see how it will look when real patches with various problems are received. The scripts are a bit ugly, so expect problems to linger for the next week or so while I work out the kinks.

8 26

patchwatcher online
by celticht32＠aol.com Aug. 12, 2008

Aug. 12, 2008

couldn't you instead when the patchwatcher takes the patch it assigns it a patch # and require if there is a patch dependency? that the person put into a comment REQ_PATCH: 123456,15456, etc.. ? That way when a diff is done for the patch it would appear in the patch diff? Then patchwatcher would make sure thats in the tree if its accepted and if that req. patch was not accepted then the new patch is automatically rejected? Chris

3 3

Re: [advapi32] - Add stub for ConvertToAutoInheritPrivateObjectSecurity
by Dmitry Timoshkov Aug. 12, 2008

Aug. 12, 2008

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > +BOOL WINAPI ConvertToAutoInheritPrivateObjectSecurity( > + PSECURITY_DESCRIPTOR ParentDescriptor, > + PSECURITY_DESCRIPTOR CreatorDescriptor, > + PSECURITY_DESCRIPTOR* NewDescriptor, > + GUID* ObjectType, > + BOOL IsDirectoryObject, > + PGENERIC_MAPPING GenericMapping ) > +{ > + FIXME("%p %p %p %p %d %p - stub\n", ParentDescriptor, CreatorDescriptor, > + NewDescriptor, ObjectType, IsDirectoryObject, GenericMapping); > + > + return FALSE; > +} It would be better to not copy variable names from MSDN/PSDK and come up with your own naming. Say, (parent, creator, new, type, is_directory, mapping) would work. > --- a/include/winbase.h > +++ b/include/winbase.h > @@ -1373,6 +1373,7 @@ WINBASEAPI HANDLE WINAPI CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,D > #define CreateNamedPipe WINELIB_NAME_AW(CreateNamedPipe) > WINBASEAPI BOOL WINAPI CreatePipe(PHANDLE,PHANDLE,LPSECURITY_ATTRIBUTES,DWORD); > WINADVAPI BOOL WINAPI > CreatePrivateObjectSecurity(PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR*,BOOL,HANDLE,PGENERIC_MAPPING); > +WINADVAPI BOOL WINAPI > ConvertToAutoInheritPrivateObjectSecurity(PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR*,GUID*,BOOL,PGENERIC_MAPPING); > WINBASEAPI BOOL WINAPI > CreateProcessA(LPCSTR,LPSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCSTR,LPSTARTUPINFOA,LPPROCESS_INFORMATION); > WINBASEAPI BOOL WINAPI > CreateProcessW(LPCWSTR,LPWSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCWSTR,LPSTARTUPINFOW,LPPROCESS_INFORMATION); > #define CreateProcess WINELIB_NAME_AW(CreateProcess) Please keep the entries alphabetically sorted. -- Dmitry.

2 1

Re: [TRY 3] Add tests for checking the parent notification for editcontrol
by Dmitry Timoshkov Aug. 12, 2008

Aug. 12, 2008

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: What is the difference between wpParent1 and wpParent2 besides slightly different indentation and 1 superfluous 'break' statement? > > - /* why do we notify to es->hwndParent, and we send this one to GetParent()? */ > > + /* All notifies are send to es->hwndParent > > + * except the WM_CTLCOLORSTATIC and WM_CTLCOLOREDIT. > > + * Its are send to the current parent. > > + */ > > hbrush = (HBRUSH)SendMessageW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > > if (!hbrush) > > hbrush = (HBRUSH)DefWindowProcW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > > This tests confirming my statement in the comment. If we change > GetParent(es->hwndSelf) to es->hwndParent the tests will be failed. I don't see the tests confirming the comment. Why are you adding the whole new message handling code to edit.c (which complicates things a lot, and makes it less clear what you are trying to do) while msg.c already has everything required, and it already contains the edit message tests? -- Dmitry.

1 0

Re: [TRY 2] Add tests for checking the parent notification for editcontrol
by Dmitry Timoshkov Aug. 12, 2008

Aug. 12, 2008

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > - /* why do we notify to es->hwndParent, and we send this one to GetParent()? */ > + /* All notifies are send to es->hwndParent > + * except the WM_CTLCOLORSTATIC and WM_CTLCOLOREDIT. > + * Its are send to the current parent. > + */ > hbrush = (HBRUSH)SendMessageW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > if (!hbrush) > hbrush = (HBRUSH)DefWindowProcW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); My question regarding this part left unanswered. Are there the tests confirming your statement in the comment? Also, please avoid adding not related message tests. If you are trying to show which parent receives the notification you need to create your own parent window procs or somehow tell an existing one to mark the notifications, so that it would be easy to distinguish the source of a notification. -- Dmitry.

1 0

Patch formatting question: how picky should the robot be?
by Dan Kegel Aug. 12, 2008

Aug. 12, 2008

So, git generates patches like this: diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c index da66e2e..4569997 100644 --- a/dlls/ddraw/tests/dsurface.c +++ b/dlls/ddraw/tests/dsurface.c and that's the way we like it. And sometimes people generate patches with cvs, like http://winehq.org/pipermail/wine-patches/2008-August/059403.html diff -u -3 -p -r1.57 vga.c --- dlls/winedos/vga.c 14 Jul 2008 10:57:58 -0000 1.57 +++ dlls/winedos/vga.c 27 Jul 2008 23:13:08 -0000 (That even used to be the way we liked it.) That's ok, too, isn't it? If so, I'll make sure my patch robot can handle it. But what about patches like http://winehq.org/pipermail/wine-patches/2008-August/059404.html --- dlls/appwiz.cpl/appwiz.rc 2008-07-26 09:24:56.000000000 +0900 +++ appwiz.rc 2008-07-28 09:48:00.000000000 +0900 ... --- /dev/null 2008-07-28 09:27:06.210506864 +0900 +++ Ko.rc 2008-07-28 09:48:00.000000000 +0900 The patch robot should probably complain about those, right? - Dan

3 3

Crashing tests for WinHttp
by Zac Brown Aug. 11, 2008

Aug. 11, 2008

Hi all, Dan Kegel pointed out to me a couple of tests for WinHttp were reported as crashing in Wine, build 520ab5c26170 (the latest). Would the owners of machines "2000 wine-1.1.2" and "XP th" please shoot me an email. I'd like to see if I can reproduce the crash in wine. For better reference, its the machines in the first and last column on this page: http://test.winehq.org/data/520ab5c261706f6118a85a82ba84213932ba76e7/#group… Thanks, Zac

1 0

Is Wine portable to ARM arch?
by Tomasz Czapiewski Aug. 11, 2008

Aug. 11, 2008

I wonder if someone has done successfull port of Wine for mobile/PDA Linux distributions on hardware with ARM processors. Is it possible? If no then are there any plans for multiplatform code in Wine? There are many Linux users of such hardware (like Neo FreeRunner etc.) which would like to use Windows applications on their portable ARM-based devices. Kind Regards, Tom

4 3

RE: [PATCH 04/10] ddraw/dsurface_thunks: Add typesafe inline conversion functions.
by Stefan Dösinger Aug. 11, 2008

Aug. 11, 2008

> Do you see a chance to get such a change committed? It's hard to tell; I think you should ask Alexandre once he's back from vacation

1 0

Re: rpcrt4: Dynamically load iphlpapi
by Rob Shearman Aug. 11, 2008

Aug. 11, 2008

2008/8/5 Juan Lang <juan.lang(a)gmail.com>: > This has a similar motivation to the last patch I sent. In rpcrt4's > case, iphlpapi is needed at most once per process, so dynamically load > it rather than keeping it around all the time. > @@ -304,18 +304,23 @@ #define ADDRESS_BYTES_NEEDED 6 > > static RPC_STATUS RPC_UuidGetNodeAddress(BYTE *address) > { > + static const WCHAR iphlpapi[] = { 'i','p','h','l','p','a','p','i',0 }; > int i; > DWORD status = RPC_S_OK; > > ULONG buflen = sizeof(IP_ADAPTER_INFO); > PIP_ADAPTER_INFO adapter = HeapAlloc(GetProcessHeap(), 0, buflen); > + HMODULE lib = LoadLibraryW(iphlpapi); > + DWORD (WINAPI *pGetAdaptersInfo)(PIP_ADAPTER_INFO, PULONG) = NULL; Hi Juan, Why manually load iphlpapi here instead of using the automatic delayed import mechanism like you used for ws2_32? I assume it was because you reasoned that a hard dependency was unnecessary because the code has a fallback path, but I think you needed to make this clear in the changelog. -- Rob Shearman

2 2

RE: [PATCH 04/10] ddraw/dsurface_thunks: Add typesafe inline conversion functions.
by Stefan Dösinger Aug. 11, 2008

Aug. 11, 2008

I think it is better to replace the whole macros in ddcomimpl.h with inline functions. This is also what Alexandre asked for some time ago, but I was too lazy to implement it > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Michael Karcher > Sent: Sunday, August 10, 2008 4:20 PM > To: wine-patches(a)winehq.org > Subject: [PATCH 04/10] ddraw/dsurface_thunks: Add typesafe inline > conversion functions. > > These are going to replace the CONVERT/CONVERT_REV macros. > --- > dlls/ddraw/surface_thunks.c | 54 > +++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 54 insertions(+), 0 deletions(-)

1 0

RE: [PATCH 03/10] ddraw/surface: Made IDirectDrawSurfaceImpl methods non-static.
by Stefan Dösinger Aug. 11, 2008

Aug. 11, 2008

I think you should put the things from surface_impl.h into ddraw_private.h > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Michael Karcher > Sent: Sunday, August 10, 2008 4:20 PM > To: wine-patches(a)winehq.org > Subject: [PATCH 03/10] ddraw/surface: Made IDirectDrawSurfaceImpl > methods non-static. > > This allows direct calls from surface_thunks.c. IMHO there is no point > in letting the call from the thunk to the implementation go through the > vtable again, unless we are going to use dynamic vtables. > --- > dlls/ddraw/surface.c | 85 +++++++++--------- > dlls/ddraw/surface_impl.h | 207 > +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 250 insertions(+), 42 deletions(-) create mode > 100644 dlls/ddraw/surface_impl.h

1 0

Re: [AppDB] db_filter_ui: Use first filter option as default
by Winandy Hubert Aug. 11, 2008

Aug. 11, 2008

Alexander Nicolaysen Sørnes schrieb: > Should be a little more user-friendly. > > > Alexander N. Sørnes > > > > __________ NOD32 3344 (20080810) Information __________ > > Diese E-Mail wurde vom NOD32 antivirus system geprüft > http://www.nod32.com > > ------------------------------------------------------------------------ > > Kann Anhang nicht öffnen Danke Winandy Hubert > > > > __________ NOD32 3344 (20080810) Information __________ > > Diese E-Mail wurde vom NOD32 antivirus system geprüft > http://www.nod32.com

1 0

Re: [Bug 14810] WinHttp needs to be implemented
by James Hawkins Aug. 11, 2008

Aug. 11, 2008

On Sun, Aug 10, 2008 at 6:43 PM, <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=14810 > > > --- Comment #4 from Erich Hoover <ehoover(a)mines.edu> 2008-08-10 18:43:16 --- > This whole DLL has a total of 27 functions, 14 of which are currently exposed, > and only 1 is "implemented". I put some work into implementing enough of the > DLL to get RA3 to authenticate and found that it needs 9 of the functions to > operate properly. I think it is reasonable to say that implementing the rest > of the functions for WinHttp would not be too difficult. I do not think that > this particular issue is anywhere close to a broad-spectrum "Win32 API needs to > be implemented". > Of course it's not the same scale as all of the Win32 API. It was an analogy illustrating why the bug is superfluous. On the other hand, you're vastly underestimating the amount of work needed to properly implement winhttp. You might want to chat with Zac Brown who is working on implementing winhttp right now. Also, please don't post in closed bugs. -- James Hawkins

4 9

Re: rpcrt4: [1/2] Improve stub for I_RpcBindingInqTransportType, with test
by Dmitry Timoshkov Aug. 10, 2008

Aug. 10, 2008

Detlef Riekenberg <wine.dev(a)web.de> wrote: > @@ -848,6 +848,10 @@ RPC_STATUS WINAPI I_RpcBindingInqTransportType( RPC_BINDING_HANDLE Binding, unsi > { > > FIXME( "(%p,%p): stub\n", Binding, Type); > + > + /* NT: RPC_S_NO_CONTEXT_AVAILABLE, 9x: RPC_S_NO_CALL_ACTIVE */ > + if (!Binding) return RPC_S_NO_CONTEXT_AVAILABLE; According to your test this should be if (!Binding || !Type) return RPC_S_NO_CONTEXT_AVAILABLE; Also the comment doesn't belong here, it's ok to have in the test though. -- Dmitry.

2 1

Re: dplayx tests hanging
by Dan Kegel Aug. 10, 2008

Aug. 10, 2008

On Sun, Aug 10, 2008 at 11:42 AM, Ismael Barros <razielmine(a)gmail.com> wrote: > You probably have installed in your wine prefix a windows native > dpwsockx.dll, and dplay gets that one instead of wine's builtin > dpwsockx. Seems to be (perhaps I did winetricks directx9). Removing ~/.wine seems to have helped. Don't know if that explains the two timeout reports on wine at test.winehq.org, but it seems likely. Sorry for not trying a clean .wine before writing. - Dan

1 0

Re: [6/11] ole32 : basic inprocess handler implentation
by Rob Shearman Aug. 10, 2008

Aug. 10, 2008

2008/8/7 <f.dorin(a)free.fr>: > diff --git a/dlls/ole32/proxystub_obj.c b/dlls/ole32/proxystub_obj.c > new file mode 100644 > index 0000000..c229ad2 > --- /dev/null > +++ b/dlls/ole32/proxystub_obj.c > ... > +HRESULT __RPC_STUB IStorage_OpenStream_Stub( > + IStorage* This, > + LPCOLESTR pwcsName, > + unsigned long cbReserved1, > + byte *reserved1, > + DWORD grfMode, > + DWORD reserved2, > + IStream **ppstm) > +{ > + TRACE("(%p)->(%s, %d, %p, %x, %x, %p)\n", This, debugstr_w(pwcsName), (int)cbReserved1, reserved1, grfMode, reserved2, ppstm); > + return IStorage_OpenStream(This, pwcsName, reserved1, grfMode, reserved2, ppstm); > +} These should go into usrmarshal.c. However, Dan Hipschman as already done some work in this area so you might want to search for his patches on generating proxy/stub code for oleidl.idl and objidl.idl so that you don't do any more work than you have to. -- Rob Shearman

2 1

Re: [1/11] ole32 : basic inprocess handler implentation
by Rob Shearman Aug. 10, 2008

Aug. 10, 2008

Hi François, I appreciate the work you've put into this and the other patches. However, I have a few comments: 2008/8/7 <f.dorin(a)free.fr>: > @@ -78,4 +83,11 @@ ole2nls.spec.o: ole2nls.spec version16.res > version16.res: version16.rc > $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/version16.rc > > +objidl_p.c: ../../include/objidl.idl > + $(WIDL) -p ../../include/objidl.idl > + > +oleidl_p.c: ../../include/oleidl.idl > + $(WIDL) -p ../../include/oleidl.idl > + sed -i '14i#include "winuser.h"' oleidl_p.c > + Custom make rules, such as these, are discouraged as they are a pain to maintain because they need to be changed all over the source tree instead of just in Make.rules.in. In this case they should be unnecessary as you can simply create IDL files in the ole32 directory (c.f. dlls/oleaut32/oleaut32_oaidl.idl) that include each of these (and in the second case, add the necessary include file). Also, it's a moot point but I don't think "sed -i" is portable. -- Rob Shearman

1 0

Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
by James Mckenzie Aug. 10, 2008

Aug. 10, 2008

Juan Lang <juan.lang(a)gmail.com> on Aug 9, 2008 8:27 PM (PNT) wrote additionally in reply to Question: Why are EM_FORMATRANGE Tests 'To Do' > >> Thank you for the clarification. Thus, I can run the pre-built executable on WindowsXP and there should be no richedit errors, correct? > >That's the theory :) The test don't run without error on my XP system, so YMMV. Then I should end up with errors on my WindowsXP system that match yours. I don't have time tonight to do so, but my find time tomorrow to run them. James McKenzie

2 1

Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
by James Mckenzie Aug. 10, 2008

Aug. 10, 2008

Juan Lang <juan.lang(a)gmail.com> on Aug 9, 2008 6:41 PM wrote about Question: Why are EM_FORMATRANGE Tests 'To Do' in reply to James McKenzie's question on this subject. > >Hi James, > >> Title states it all. I would like to compile tests to run against WindowsXP to see if the test will function. Could I un'to-do' this test and compile it with MinGW? > >todo_wine tests are always run, whether or not the todo_wine flag is >there. The only difference is how the results are interpreted: if >running on Wine (which the standalone tests assume they are not), the >test is assumed to fail, and an error reported if the test does not >fail as expected on Wine. If not running on Wine, they run as normal. Thank you for the clarification. Thus, I can run the pre-built executable on WindowsXP and there should be no richedit errors, correct? James McKenzie

2 1