April 2017 - Wine-Devel - list.winehq.org

Re: [v2 PATCH 3/3] odbccp32: Implement SQLConfigDriver/W

by Huw Davies

On Wed, Mar 22, 2017 at 10:06:29PM +0000, Alistair Leslie-Hughes wrote: > v2 - No Changes > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/odbccp32/odbccp32.c | 125 +++++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 115 insertions(+), 10 deletions(-) > > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index d95a110..f327817 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -63,6 +63,9 @@ static const WCHAR odbc_error_out_of_mem[] = {'O','u','t',' ','o','f',' ','m','e > static const WCHAR odbc_error_invalid_param_sequence[] = {'I','n','v','a','l','i','d',' ','p','a','r','a','m','e','t','e','r',' ','s','e','q','u','e','n','c','e',0}; > static const WCHAR odbc_error_invalid_param_string[] = {'I','n','v','a','l','i','d',' ','p','a','r','a','m','e','t','e','r',' ','s','t','r','i','n','g',0}; > > +static BOOL (WINAPI *pConfigDriverW)(HWND hwnd, WORD request, const WCHAR *driver, const WCHAR *args, const WCHAR *msg, WORD msgmax, WORD *msgout); > +static BOOL (WINAPI *pConfigDriverA)(HWND hwnd, WORD request, const char *driver, const char *args, const char *msg, WORD msgmax, WORD *msgout); > + > /* Push an error onto the error stack, taking care of ranges etc. */ > static void push_error(int code, LPCWSTR msg) > { > @@ -248,22 +251,124 @@ BOOL WINAPI SQLConfigDataSource(HWND hwndParent, WORD fRequest, > return TRUE; > } > > -BOOL WINAPI SQLConfigDriverW(HWND hwndParent, WORD fRequest, LPCWSTR lpszDriver, > - LPCWSTR lpszArgs, LPWSTR lpszMsg, WORD cbMsgMax, WORD *pcbMsgOut) > +BOOL WINAPI SQLConfigDriverW(HWND hwnd, WORD request, LPCWSTR driver, > + LPCWSTR args, LPWSTR msg, WORD msgmax, WORD *msgout) > { > + static WCHAR reg_driver[] = {'d','r','i','v','e','r',0}; > + long ret; > + HMODULE hmod; > + HKEY hkey; > + WCHAR *filename = NULL; > + DWORD size = 0, type; > + BOOL funcret = FALSE; > + > clear_errors(); > - FIXME("(%p %d %s %s %p %d %p)\n", hwndParent, fRequest, debugstr_w(lpszDriver), > - debugstr_w(lpszArgs), lpszMsg, cbMsgMax, pcbMsgOut); > - return TRUE; > + TRACE("(%p %d %s %s %p %d %p)\n", hwnd, request, debugstr_w(driver), > + debugstr_w(args), msg, msgmax, msgout); > + > + if ((ret = RegOpenKeyW(HKEY_CURRENT_USER, odbcini, &hkey)) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if ((ret = RegOpenKeyW(hkey, driver, &hkeydriver)) == ERROR_SUCCESS) > + { > + ret = RegGetValueW(hkeydriver, NULL, reg_driver, RRF_RT_REG_SZ, &type, NULL, &size); > + if(ret == ERROR_MORE_DATA) > + { > + filename = HeapAlloc(GetProcessHeap(), 0, size); > + if(!filename) > + { > + RegCloseKey(hkeydriver); > + RegCloseKey(hkey); > + return ODBC_ERROR_OUT_OF_MEM; > + } > + ret = RegGetValueW(hkeydriver, NULL, driver, RRF_RT_REG_SZ, &type, filename, &size); > + } > + > + RegCloseKey(hkeydriver); > + } > + > + RegCloseKey(hkey); > + } > + > + if(ret != ERROR_SUCCESS) > + { > + HeapFree(GetProcessHeap(), 0, filename); > + return ODBC_ERROR_INVALID_DSN; > + } > + > + hmod = LoadLibraryW(filename); > + HeapFree(GetProcessHeap(), 0, filename); This function is supposed to return a BOOL, so either that's actually not the case, or these errors should be set using SetLastError(). I suggest you try writing a helper that could be used by both A and W versions. Something like: HMODULE load_driver(const WCHAR *driver) (or DWORD load_driver(const WCHAR *driver, HMODULE *mod) if you need to return the error code.) Feel free to pick a better function name. Huw.

April 4, 2017

Re: [v2 PATCH 2/3] odbccp32: Implement SQLRemoveTranslator/W

by Huw Davies

On Wed, Mar 22, 2017 at 10:06:18PM +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/odbccp32/odbccp32.c b/dlls/odbccp32/odbccp32.c > index 7b2f020..d95a110 100644 > --- a/dlls/odbccp32/odbccp32.c > +++ b/dlls/odbccp32/odbccp32.c > @@ -1229,20 +1229,75 @@ BOOL WINAPI SQLRemoveDSNFromIni(LPCSTR lpszDSN) > return FALSE; > } > > -BOOL WINAPI SQLRemoveTranslatorW(LPCWSTR lpszTranslator, LPDWORD lpdwUsageCount) > +BOOL WINAPI SQLRemoveTranslatorW(const WCHAR *translator, DWORD *usage_count) > { > + HKEY hkey; > + DWORD usagecount = 1; > + > clear_errors(); > - FIXME("%s %p\n", debugstr_w(lpszTranslator), lpdwUsageCount); > - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > - return FALSE; > + TRACE("%s %p\n", debugstr_w(translator), usage_count); > + > + if (RegOpenKeyW(HKEY_LOCAL_MACHINE, odbcini, &hkey) == ERROR_SUCCESS) > + { > + HKEY hkeydriver; > + > + if (RegOpenKeyW(hkey, translator, &hkeydriver) == ERROR_SUCCESS) > + { > + DWORD size, type; > + DWORD count; > + > + size = sizeof(usagecount); > + RegGetValueA(hkeydriver, NULL, "UsageCount", RRF_RT_DWORD, &type, &usagecount, &size); > + TRACE("Usage count %d\n", count); I think you mean usagecount here. It makes me wonder whether you actually need two variables to represent the same thing. Huw.

April 4, 2017

Re: [v2 PATCH 1/3] odbccp32: Implement SQLInstallTranslator

by Huw Davies

On Wed, Mar 22, 2017 at 10:06:05PM +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/odbccp32/tests/misc.c b/dlls/odbccp32/tests/misc.c > index 4fdf584..e977e91 100644 > --- a/dlls/odbccp32/tests/misc.c > +++ b/dlls/odbccp32/tests/misc.c > @@ -473,6 +473,67 @@ void test_SQLInstallDriverEx(void) > ok(cnt == 0, "SQLRemoveDriver failed %d\n", cnt); > } > > +void test_SQLInstallTranslatorEx(void) > +{ > + char path[MAX_PATH]; > + char syspath[MAX_PATH]; > + WORD size = 0; > + BOOL ret, sql_ret; > + DWORD cnt, error_code = 0; > + HKEY hkey; > + LONG res; > + > + GetSystemDirectoryA(syspath, MAX_PATH); > + > + ret = SQLInstallTranslatorEx("WINE ODBC Translator\0Translator=sample.dll\0Setup=sample.dll\0\0", NULL, path, MAX_PATH, &size, ODBC_INSTALL_COMPLETE, NULL); The string will be terminated in three '\0's, I suspect you only need two. Also, 160 chars is a little long for a line - There are other cases in this series where line-length is excessive. > + sql_ret = SQLInstallerErrorW(1, &error_code, NULL, 0, NULL); > + if (sql_ret && error_code == ODBC_ERROR_WRITING_SYSINFO_FAILED) > + { > + win_skip("not enough privileges\n"); > + return; > + } > + ok(sql_ret && error_code == SQL_SUCCESS, "SQLInstallDriverEx failed %d, %u\n", sql_ret, error_code); > + ok(!strcmp(path, syspath), "invalid path %s\n", path); You should test size here. Does it include the '\0' or not, msdn is vague. Huw.

April 4, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Stas Sergeev

04.04.2017 05:05, Ricardo Neri пишет: > On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote: >> 30.03.2017 08:14, Ricardo Neri пишет: >>>>>>>> You know the wine's >>>>>>>> requirements now - they are very small. And >>>>>>>> dosemu doesn't need anything at all but smsw. >>>>>>>> And even smsw is very rare. >>>>>>> But emulation is still needed for SMSW, right? >>>>>> Likely so. >>>>>> If you want, I can enable the logging of this command >>>>>> and see if it is used by some of the DOS programs I have. >>>>> It would be great if you could do that, if you don't mind. >>>> OK, scheduled to the week-end. >>>> I'll let you know. >>> Thanks! >> OK, done the testing. >> It appears smsw is used in v86 by windows-3.1 and dos4gw >> at the very least, and these are the "major" apps. So doing >> without a fixup in v86 will not go unnoticed. Unfortunately >> this also means that KVM-vm86 should be properly tested. >> I have also found a weird program that does SGDT under >> v86. This causes "ERROR: SGDT not implemented" under >> dosemu, but the prog still works fine as it obviously does >> not care about the results. This app can easily be broken >> of course, if that makes any sense (likely not). > Thanks for inputs! Then it seems that we will need emulation for sgdt > and smsw. I wouldn't claim we need an emulation of sgdt. One or 2 exotic apps do not count much, considering the overall small usage of dosemu and an easiness of re-adding them to dosemu itself. So if it makes any sense to not add it for vm86, then please leave it omitted. However it seems Andy wants an overall completeness here, lot let me just say I'll be fine with either option. > Perhaps sidt? If only for overall completeness. If it makes any sense to, please leave it omitted. > sldt and str will not need emulation in either > protected mode or virtual-8086 mode. At a later stage I can look into > working in the syscall as Andy proposes. > > I will also look into the kvm-v86 path for dosemu2. > > It seems we have an agreement :) Do we? Yes, fine with me.

April 4, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Alexandre Julliard

Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> writes: > On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote: >> Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> writes: >> >> > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: >> >> 30.03.2017 08:14, Ricardo Neri пишет: >> >> In fact, smsw has an interesting property, which is that >> >> no one will ever want to disable its in-kernel emulation >> >> to provide its own. >> >> So while I'll try to estimate its usage, emulating it in kernel >> >> will not be that problematic in either case. >> > >> > Ah good to know! >> > >> >> As for protected mode, if wine only needs sgdt/sidt, then >> >> again, no one will want to disable its emulation. Not the >> >> case with sldt, but AFAICS wine doesn't need sldt, and so >> >> we can leave sldt without a fixups. Is my understanding >> >> correct? >> > >> > This is my understanding as well. I could not find any use of sldt in >> > wine. Alexandre, would you mind confirming? >> >> Some versions of the Themida software protection are known to use sldt >> as part of the virtual machine detection code [1]. The check currently >> fails because it expects the LDT to be zero, so the app is already >> broken, but sldt segfaulting would still cause a crash where there >> wasn't one before. >> >> However, I'm only aware of one application using this, and being able to >> catch and emulate sldt ourselves would actually give us a chance to fix >> this app in newer Wine versions, so I'm not opposed to having it >> segfault. > > Great! Then this is in line with what we are aiming to do with dosemu2: > not emulate str and sldt. >> >> In fact it would be nice to be able to make sidt/sgdt/etc. segfault >> too. I know a new syscall is a pain, but as far as Wine is concerned, >> being able to opt out from any emulation would be potentially useful. > > I see. I guess for now there should not be a problem with emulating > sidt/sgdt/smsw, right? In this way we don't break current versions of > winehq and programs using it. In a phase two we can introduce the > syscall so that kernel fixups can be disabled. Does this make sense? Yes, that makes sense. -- Alexandre Julliard julliard(a)winehq.org

April 4, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Ricardo Neri

On Sat, 2017-04-01 at 16:08 +0300, Stas Sergeev wrote: > 30.03.2017 08:14, Ricardo Neri пишет: > >>>>>> You know the wine's > >>>>>> requirements now - they are very small. And > >>>>>> dosemu doesn't need anything at all but smsw. > >>>>>> And even smsw is very rare. > >>>>> But emulation is still needed for SMSW, right? > >>>> Likely so. > >>>> If you want, I can enable the logging of this command > >>>> and see if it is used by some of the DOS programs I have. > >>> It would be great if you could do that, if you don't mind. > >> OK, scheduled to the week-end. > >> I'll let you know. > > Thanks! > OK, done the testing. > It appears smsw is used in v86 by windows-3.1 and dos4gw > at the very least, and these are the "major" apps. So doing > without a fixup in v86 will not go unnoticed. Unfortunately > this also means that KVM-vm86 should be properly tested. > I have also found a weird program that does SGDT under > v86. This causes "ERROR: SGDT not implemented" under > dosemu, but the prog still works fine as it obviously does > not care about the results. This app can easily be broken > of course, if that makes any sense (likely not). Thanks for inputs! Then it seems that we will need emulation for sgdt and smsw. Perhaps sidt? sldt and str will not need emulation in either protected mode or virtual-8086 mode. At a later stage I can look into working in the syscall as Andy proposes. I will also look into the kvm-v86 path for dosemu2. It seems we have an agreement :) Do we? Thanks and BR, Ricardo

April 4, 2017

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

by Ricardo Neri

On Fri, 2017-03-31 at 16:11 +0200, Alexandre Julliard wrote: > Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> writes: > > > On Thu, 2017-03-30 at 13:10 +0300, Stas Sergeev wrote: > >> 30.03.2017 08:14, Ricardo Neri пишет: > >> >>>> But at least dosemu implements it, so probably it is needed. > >> >>> Right. > >> >>> > >> >>>> Of course if it is used by one of 100 DOS progs, then there > >> >>>> is an option to just add its support to dosemu2 and pretend > >> >>>> the compatibility problems did not exist. :) > >> >>> Do you mean relaying the GP fault to dosemu instead of trapping it and > >> >>> emulating it in the kernel? > >> >> Yes, that would be optimal if this does not severely break > >> >> the current setups. If we can find out that smsw is not in > >> >> the real use, we can probably do exactly that. > >> >> But other > >> >> instructions are not in real use in v86 for sure, so I > >> >> wouldn't be adding the explicit test-cases to the kernel > >> >> that will make you depend on some particular behaviour > >> >> that no one may need. > >> >> My objection was that we shouldn't > >> >> write tests before we know exactly how we want this to work. > >> > OK, if only SMSW is used then I'll keep the emulation for SMSW only. > >> In fact, smsw has an interesting property, which is that > >> no one will ever want to disable its in-kernel emulation > >> to provide its own. > >> So while I'll try to estimate its usage, emulating it in kernel > >> will not be that problematic in either case. > > > > Ah good to know! > > > >> As for protected mode, if wine only needs sgdt/sidt, then > >> again, no one will want to disable its emulation. Not the > >> case with sldt, but AFAICS wine doesn't need sldt, and so > >> we can leave sldt without a fixups. Is my understanding > >> correct? > > > > This is my understanding as well. I could not find any use of sldt in > > wine. Alexandre, would you mind confirming? > > Some versions of the Themida software protection are known to use sldt > as part of the virtual machine detection code [1]. The check currently > fails because it expects the LDT to be zero, so the app is already > broken, but sldt segfaulting would still cause a crash where there > wasn't one before. > > However, I'm only aware of one application using this, and being able to > catch and emulate sldt ourselves would actually give us a chance to fix > this app in newer Wine versions, so I'm not opposed to having it > segfault. Great! Then this is in line with what we are aiming to do with dosemu2: not emulate str and sldt. > > In fact it would be nice to be able to make sidt/sgdt/etc. segfault > too. I know a new syscall is a pain, but as far as Wine is concerned, > being able to opt out from any emulation would be potentially useful. I see. I guess for now there should not be a problem with emulating sidt/sgdt/smsw, right? In this way we don't break current versions of winehq and programs using it. In a phase two we can introduce the syscall so that kernel fixups can be disabled. Does this make sense? Thanks and BR, Ricardo

April 4, 2017

Re: [PATCH] d2d1: Support text clipping with D2D1_DRAW_TEXT_OPTIONS_CLIP

by Nikolay Sivov

On 03.04.2017 9:06, Henri Verbeet wrote: > On 1 April 2017 at 21:01, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >> + clip_rect.left = origin.x + layout_metrics.left; >> + clip_rect.top = origin.y + layout_metrics.top; >> + clip_rect.right = clip_rect.left + layout_metrics.layoutWidth; >> + clip_rect.bottom = clip_rect.top + layout_metrics.layoutHeight; >> + ID2D1RenderTarget_PushAxisAlignedClip(iface, &clip_rect, D2D1_ANTIALIAS_MODE_ALIASED); > > Does this do the right thing wrt. rendertarget transforms? > No, this will only work if rotation angle is multiple of 90 degrees. Please ignore.

April 3, 2017

Re: APPDB Intro email

by Austin English

On Mon, Mar 27, 2017 at 4:27 PM, Bijie Zhu <bijizhu(a)yahoo.com> wrote: > Hi, > My name is Bijie Zhu and I am currently a computer science student studying > at City University of New York - Queens College. This is my first time > participate in an open source project, and I hope I can get some guidance > and feedback for the outreach project application process. > I want to apply for improving APPDB website project. And I want to improve > the app voting system. I would like to design an evaluation metric system > for the app voting. So when people votes, we know why they vote for the app. > People now can not only search for the most voted app, but also search for > the app with the most desired attributes. > > Thank you, > Bijie Zhu Hi Bijie, Thanks for your interest. Could you tell us a bit about your experience with PHP? Have you worked on something similar before? Keep in mind you'll want to formally apply on the GSOC website. You'll also need to submit a patch (preferably one for the AppDB) to be considered. -- -Austin GPG: 14FB D7EA A041 937B

April 3, 2017

Re: [PATCH] ntoskrnl.exe: add KeBugCheck/KeBugCheckEx stubs

by Austin English

On Mon, Apr 3, 2017 at 1:46 PM, Michael Müller <michael(a)fds-team.de> wrote: > Am 03.04.2017 um 20:25 schrieb Austin English: >> Mentioned in https://bugs.winehq.org/show_bug.cgi?id=42744 and >> https://bugs.winehq.org/show_bug.cgi?id=42746. > > Does it really make sense to add such a stub? Windows is supposed to > show a BSOD when you call the function and I guess it is not supposed to > return back to the caller. I would either leave it as a stub or at least > unload the driver / terminate the process with an error. I see few reports of it, so it's hard to know what the app really needs. Anyway, I think it's better to handle it in some way than to crash on an unimplemented function, even if it's a stub. I don't think Wine needs to implement a BSOD. At least not until 2018/04/01 ;) -- -Austin GPG: 14FB D7EA A041 937B

April 3, 2017