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. 13, 2008

Aug. 13, 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