November 2014 - Wine-Devel - list.winehq.org

RE: [PATCH] reg.exe: Modernise print functions

by Hugh McMaster

On Monday, 10 November 2014, Jonathan Vollebregt wrote: >> WCHAR msg_buffer[1024]; >No easy way to get the expected size and dynamically allocate the output I take it? >I looked into it before but besides _vscprintf (In msvcrt, which we're >not allowed to use) there doesn't seem to be a way to get the expected >output size besides perhaps growing the buffer over and over again until >it fits (Which seems inefficient for a simple printing function) One possible way would be to avoid using vsnprintfW() and pass everything through to output_vprintf(). static void __cdecl reg_printfW(const WCHAR* msg, ...) { __ms_va_list va_args; __ms_va_start(va_args, msg); output_vprintf(msg, va_args); __ms_va_end(va_args); } This would have the advantage of using FormatMessage() to allocate memory. But we would have to replace all format specifiers (four or five?) with their FormatMessage() equivalents. static const WCHAR unhandled[] = {'U','n','h','a','n','d','l','e','d',' ','T','y','p','e',' ','0','x','%','x',' ',' ','d','a','t','a',' ','%','s','\n',0}; becomes static const WCHAR unhandled[] = {'U','n','h','a','n','d','l','e','d',' ','T','y','p','e',' ','0','x','%','1','!','x','!',' ',' ','d','a','t','a',' ','%','2','\n',0};

Nov. 10, 2014

Re: user32: Move IME Window Procedure to user32

by Piotr Caban

On 11/10/14 12:27, Alexandre Julliard wrote: > Piotr Caban <piotr.caban(a)gmail.com> writes: > >> On 11/10/14 12:02, Alexandre Julliard wrote: >>> In which case does it make a difference to load it this way? >> It makes it possible to load and unload imm32.dll. On the other hand >> it leaves user32 dll in broken state, that leads to crashes while >> calling some user32 functions on windows (tested on Windows 7 and XP). > > Yes, but is there really an app that depends on being able to unload > imm32? No. >>> But the real bad part is passing a function pointer through the magic >>> DWORD. There has to be a better way. >> Do you think that adding additional export to wine's imm32 is acceptable? > > It's not great, but it's less offensive, if there's no other way. I was trying to find how native does it. It works completely different on windows. There's an undocumented window message sent on every keyboard layout change. I guess native passes some internal structures there. Because we don't have such notifications I didn't want to implement similar (but not compatible) mechanism.

Nov. 10, 2014

Re: [PATCH] reg.exe: Modernise print functions

by Jonathan Vollebregt

> WCHAR msg_buffer[1024]; No easy way to get the expected size and dynamically allocate the output I take it? I looked into it before but besides _vscprintf (In msvcrt, which we're not allowed to use) there doesn't seem to be a way to get the expected output size besides perhaps growing the buffer over and over again until it fits (Which seems inefficient for a simple printing function)

Nov. 10, 2014

RE: [PATCH v3 04/10] reg: Add sane_path function to do preliniary key validation

by Hugh McMaster

On Monday, 10 Nov 2014 12:23:39 +0100, Jonathan Vollebregt wrote: > Yes, they're in 6: path/key functions > > Stefan suggested to leave that validation out of sane_path since > path_get_rootkey will error out if it starts with a slash anyway Okay, I see it now. Always listen to Stefan. :)

Nov. 10, 2014

Re: user32: Move IME Window Procedure to user32

by Piotr Caban

On 11/10/14 12:02, Alexandre Julliard wrote: > Piotr Caban <piotr.caban(a)gmail.com> writes: > >> Hi, >> >> could you please give me any hints related to this patch? >> >> The way how imm32 is loaded or not is quite strange in it. It's >> generally matching native behavior but I'm not sure if it's needed >> here. I also don't see a nice way of testing it inside wine test >> suite. > > In which case does it make a difference to load it this way? It makes it possible to load and unload imm32.dll. On the other hand it leaves user32 dll in broken state, that leads to crashes while calling some user32 functions on windows (tested on Windows 7 and XP). > But the real bad part is passing a function pointer through the magic > DWORD. There has to be a better way. Do you think that adding additional export to wine's imm32 is acceptable? Thanks, Piotr

Nov. 10, 2014

Re: user32: Move IME Window Procedure to user32

by Alexandre Julliard

Piotr Caban <piotr.caban(a)gmail.com> writes: > On 11/10/14 12:02, Alexandre Julliard wrote: >> In which case does it make a difference to load it this way? > It makes it possible to load and unload imm32.dll. On the other hand > it leaves user32 dll in broken state, that leads to crashes while > calling some user32 functions on windows (tested on Windows 7 and XP). Yes, but is there really an app that depends on being able to unload imm32? >> But the real bad part is passing a function pointer through the magic >> DWORD. There has to be a better way. > Do you think that adding additional export to wine's imm32 is acceptable? It's not great, but it's less offensive, if there's no other way. -- Alexandre Julliard julliard(a)winehq.org

Nov. 10, 2014

Re: [PATCH v3 04/10] reg: Add sane_path function to do preliniary key validation

by Jonathan Vollebregt

Yes, they're in 6: path/key functions Stefan suggested to leave that validation out of sane_path since path_get_rootkey will error out if it starts with a slash anyway On 11/10/2014 12:18 PM, Hugh McMaster wrote: > On Saturday, 8 Nov 2014 11:26:45 +0100, Jonathan Vollebregt wrote: > >> +static LSTATUS sane_path(const WCHAR *key) >> +{ >> + if (key[0] == '\\' && key[1] == '\\' && key[2] != '\\') >> + return ERROR_NO_REMOTE; >> + >> + return ERROR_SUCCESS; >> +}Where are you handling (invalid) keys beginning with backslashes, e.g.: \\HKEY_CURRENT_USER\\Console? Windows only allows two consecutive backslashes at the beginning of a key. > >> + if (key[0] == '\\' && key[1] == '\\' && key[2] != '\\') > HKEY... --> ERROR_SUCCESS > \HKEY... --> ERROR_SUCCESS !!! > \\HKEY... --> ERROR_NO_REMOTE > \\\HKEY... --> ERROR_SUCCESS !!! > > Those two marked with !!! need to be handled. Do you do this in a later patch? > > -- > Hugh McMaster > >

Nov. 10, 2014

RE: [PATCH v3 04/10] reg: Add sane_path function to do preliniary key validation

by Hugh McMaster

On Saturday, 8 Nov 2014 11:26:45 +0100, Jonathan Vollebregt wrote: >+static LSTATUS sane_path(const WCHAR *key) >+{ >+ if (key[0] == '\\' && key[1] == '\\' && key[2] != '\\') >+ return ERROR_NO_REMOTE; >+ >+ return ERROR_SUCCESS; >+}Where are you handling (invalid) keys beginning with backslashes, e.g.: \\HKEY_CURRENT_USER\\Console? Windows only allows two consecutive backslashes at the beginning of a key. >+ if (key[0] == '\\' && key[1] == '\\' && key[2] != '\\') HKEY... --> ERROR_SUCCESS \HKEY... --> ERROR_SUCCESS !!! \\HKEY... --> ERROR_NO_REMOTE \\\HKEY... --> ERROR_SUCCESS !!! Those two marked with !!! need to be handled. Do you do this in a later patch? -- Hugh McMaster

Nov. 10, 2014

RE: [PATCH v3 03/10] reg: Add system error printing function

by Hugh McMaster

On Saturday, 8 Nov 2014 11:26:44 +0100, Jonathan Vollebregt wrote: +static void reg_print_error(LSTATUS error_code) +{ + switch (error_code) + { + case ERROR_SUCCESS: + return; + case ERROR_BAD_COMMAND: + reg_message(STRING_INVALID_CMDLINE); + return; + default: + { + static const WCHAR error_string[] = {'%','0','5','d',':',' ','%','s',0}; + WCHAR *message = NULL; + FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_ALLOCATE_BUFFER, NULL, + error_code, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (WCHAR *)&message, 0, NULL); + + reg_message(STRING_ERROR); + reg_printfW(error_string, error_code, message); + LocalFree(message); + return; + } + } +}This seems like a step backwards to me. It would be much better to add the required functionality -- e.g. FormatMessage() -- and fix reg.exe printf-style functions in one go. See http://source.winehq.org/patches/data/107578 for what I mean. Also, mixing reg_message() and reg_printfW() just seems wrong. A clear resource string incorporating your formatting above would suffice, I expect. -- Hugh McMaster

Nov. 10, 2014

Re: Sourceforge says 1.5.22 is the latest version

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > On Fri, Nov 07, 2014 at 03:13:54PM -0600, Rosanne DiMesio wrote: >> Not really sure whose bug this is, but a user just pointed out that >> http://sourceforge.net/projects/wine/files/Source/ (which the source >> link at the bottom of our Downloads page leads to) has a line >> stating "Looking for the latest version? Download >> wine-1.5.22.tar.bz2 (21.2 MB)." The main project page, >> http://sourceforge.net/projects/wine/, also has a big green Download >> button for 1.5.22.tar.bz2. > > This is something that can be selected in the upload frontend. > > Not sure how Alexandre uploads the tarball. It's uploaded from a script with rsync, so I never touch the upload frontend. If someone knows a way to set the latest version from a script please let me know... -- Alexandre Julliard julliard(a)winehq.org

Nov. 10, 2014