May 2007 - Wine-devel - list.winehq.org

volume names of mounted iso images
by James Hawkins 08 May '07

08 May '07

Hi all, I have a patch ready to go that fixes a problem with the media switching code in msi. According to tests and msdn, the presence of a required media (usually a CD or DVD) is confirmed using only the volume name listed in the Media table of the msi file. The patch simplifies the existing media checking code and also fixes a few installers. The problem is that, on my system at least, the volume name and serial of mounted ISO files (using a loopback device) are not available, and any call to GetVolumeInformation returns an empty string for the volume name. Because of this, I'm hesitant to get the patch committed for fear of restricting installs to only using physical media. That would include me, because my CD drive is borked. Setting the volume name in winecfg doesn't work, probably because of permissions and the fact that the mount is read only. 'Autodetect from Device' is apparently not implemented. Can someone enlighten me on the situation and possible solutions? Thanks, James Hawkins

2 3

[msi OLE automation] Re: msi patches info pls
by Misha Koshelev 08 May '07

08 May '07

On Fri, 2007-03-09 at 17:27 +0100, Alexandre Julliard wrote: > Sorry for the lack of response, I'm currently waiting for our lawyers > to determine if it's ok to use code based on an oleview dump of a > native typelib, as that situation is not clear from a copyright > POV. I'm afraid I can't do more until they come to a conclusion on > that point. > So it looks like I will have some free time soon (hopefully) and will be able to redo the "IDL" file properly (also another Vector NTI/Linux user has offered up his help). However, I wanted to double check the "proper" way to make such a file as I know this is what is important in copyright (the process, such as dirty-clean room, vs the actual end result). From http://www.winehq.org/pipermail/wine-devel/2007-March/054589.html (posted by Rob Shearman) this is what I understand the correct process to be (I would like to understand the process in detail so I don't do something wrong to "taint" the wine copyright): As one is looking at the oleview output of the native IDL file, one starts a blank document and begins to make the wine IDL file. One defines all the appropriate interfaces, etc. using the UUID's, names, etc. from the native interface. All the function names and parameter types are declared the same, as well as function attributes, but I should use different names for the parameters and try to put the attributes in a different order (although if I understand correctly the order of these attributes comes from our oleview implementation and not from the interface per se so there shouldn't be any reason to change their order??). Also, what does one do for enums? It does not seem like there is anything that can be changed in this case, so it is alright just to re-create them verbatim (without copying and pasting, and of course the indentation will be prettier)? Thank you very much for your help. Misha

5 10

Re: ddraw: DllCanUnloadNow
by Stefan Dösinger 08 May '07

08 May '07

Am Dienstag 08 Mai 2007 02:13 schrieb Christian Gmeiner: > Add support for DllCanUnloadNow and eliminates a FIXME As I understand it, all DirectDraw objects also have to be freed, so you have to check the global ddraw object list too.

1 0

RE: [PATCH] Adds NET START to net.exe
by Rolf Kalbermatter 08 May '07

08 May '07

Tim Schwartz [tim(a)sanityinternet.com] wrote: diff --git a/programs/net/net.c b/programs/net/net.c index f77c820..ef08250 100644 --- a/programs/net/net.c +++ b/programs/net/net.c @@ -18,15 +18,66 @@ #include <stdio.h> #include <string.h> +#include <windows.h> + +int net_service(char *operation, char *service_name) { + SC_HANDLE SCManager, serviceHandle; + int result = 0; + unsigned int *buffer_size = NULL; + char *service_display_name = NULL; + + SCManager = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS); + if(!SCManager) + { + printf("Couldn't get handle to SCManager.\n"); + return 0; + } + serviceHandle = OpenService(SCManager, service_name, SC_MANAGER_ALL_ACCESS); + if(!serviceHandle) + { + printf("Couldn't get handle to service.\n"); + CloseServiceHandle(SCManager); + return 0; + } + + GetServiceDisplayName(SCManager, service_name, NULL, buffer_size); + if(!buffer_size) + { Apart from GetServiceDisplayName() currently not being implemented in Wine, this won't work! *buffer_size won't be allocated by the function but has to be provided by the caller and its pointer shouldn't be NULL ever. It should and proabably will just return with an error if it is a NULL pointer. + service_display_name = HeapAlloc(GetProcessHeap(), 0, strlen(service_name)); + strcpy(service_display_name, service_name); + } + else + { + service_display_name = HeapAlloc(GetProcessHeap(), 0, *buffer_size); MSDN says: When the function returns, lpcchBuffer contains the size of the service's display name, excluding the null-terminating character, so your buffer is in fact one character to small. + GetServiceDisplayName(SCManager, service_name, service_display_name, buffer_size); + } Your mail client wrapped the patch again it seems. Sending as an attachment might work better. Rolf Kalbermatter

1 1

Re: [3/4] Add tests for console codepages
by Dmitry Timoshkov 08 May '07

08 May '07

"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > + /* Try to set invalid CP */ > + ok(!SetConsoleCP(0), "Shouldn't succeed\n"); > + ok(GetLastError()==ERROR_INVALID_PARAMETER, "GetLastError: expecting %u got %u\n", ERROR_INVALID_PARAMETER, > GetLastError()); > + ok(!SetConsoleOutputCP(0), "Shouldn't succeed\n"); > + ok(GetLastError()==ERROR_INVALID_PARAMETER, "GetLastError: expecting %u got %u\n", ERROR_INVALID_PARAMETER, > GetLastError()); You need to set last error value to something (usually 0xdeadbeef) before calling an API if you're planning to check last error value after the call. Also keeping code lines in a reasonable limit would be nice. -- Dmitry.

1 0

rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam
by Mounir IDRASSI 08 May '07

08 May '07

Hi, We have found few bugs in the MS Enhanced CSP implementation in wine (rsaenh.dll) and you'll find attached a patch that corrects them. Here is a description of the problems we found: - In RSAENH_CPAcquireContext : when specifying CRYPT_DELETEKEYSET, the function always deletes the container for the local user, while it should check the CRYPT_MACHINE_KEYSET flag to see if it should be deleted on the local machine or for the local user. - In RSAENH_CPGetProvParam: The following mandatory parameters were not supported : PP_UNIQUE_CONTAINER, PP_PROVTYPE, PP_KEYSPEC, PP_KEYSET_TYPE, PP_KEYSTORAGE. In order to support the PP_KEYSTORAGE parameter, we added three defined to wincrypt.h. Cheers, Mounir IDRASSI IDRIX - Cryptography and IT Security Experts http://www.idrix.fr >From a7240539a2e3c83291c7cf206d55f1e4e7e75803 Mon Sep 17 00:00:00 2001 From: Mounir IDRASSI <mounir.idrassi(a)idrix.fr> Date: Sat, 5 May 2007 19:01:57 +0200 Subject: rsaenh: fix bugs in RSAENH_CPAcquireContext and RSAENH_CPGetProvParam --- dlls/rsaenh/rsaenh.c | 32 +++++++++++++++++++++++++++++++- include/wincrypt.h | 5 +++++ 2 files changed, 36 insertions(+), 1 deletions(-) diff --git a/dlls/rsaenh/rsaenh.c b/dlls/rsaenh/rsaenh.c index 2ace2d5..9f55760 100644 --- a/dlls/rsaenh/rsaenh.c +++ b/dlls/rsaenh/rsaenh.c @@ -1473,7 +1473,13 @@ BOOL WINAPI RSAENH_CPAcquireContext(HCRYPTPROV *phProv, LPSTR pszContainer, SetLastError(NTE_BAD_KEYSET_PARAM); return FALSE; } else { - if (!RegDeleteKeyA(HKEY_CURRENT_USER, szRegKey)) { + HKEY hRootKey; + if (dwFlags & CRYPT_MACHINE_KEYSET) + hRootKey = HKEY_LOCAL_MACHINE; + else + hRootKey = HKEY_CURRENT_USER; + + if (!RegDeleteKeyA(hRootKey, szRegKey)) { SetLastError(ERROR_SUCCESS); return TRUE; } else { @@ -2899,6 +2905,7 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv, DWORD dwParam, BYTE *pbData, switch (dwParam) { case PP_CONTAINER: + case PP_UNIQUE_CONTAINER:/* MSDN says we can return the same value as PP_CONTAINER */ return copy_param(pbData, pdwDataLen, (CONST BYTE*)pKeyContainer->szName, strlen(pKeyContainer->szName)+1); @@ -2915,6 +2922,29 @@ BOOL WINAPI RSAENH_CPGetProvParam(HCRYPTPROV hProv, DWORD dwParam, BYTE *pbData, dwTemp = CRYPT_IMPL_SOFTWARE; return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + case PP_PROVTYPE: + dwTemp = PROV_RSA_FULL; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSPEC: + dwTemp = AT_SIGNATURE | AT_KEYEXCHANGE; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSET_TYPE: + dwTemp = pKeyContainer->dwFlags & CRYPT_MACHINE_KEYSET; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + + case PP_KEYSTORAGE: + dwTemp = GetVersion(); + /* for Windows NT, 95,98, Me, return CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR + * for the others, return CRYPT_SEC_DESCR + */ + if(dwTemp < 0x80000000 && ((dwTemp & 0x000000FF) != 0x00000004)) + dwTemp = CRYPT_SEC_DESCR; + else + dwTemp = CRYPT_PSTORE | CRYPT_UI_PROMPT | CRYPT_SEC_DESCR; + return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); + case PP_VERSION: dwTemp = 0x00000200; return copy_param(pbData, pdwDataLen, (CONST BYTE*)&dwTemp, sizeof(dwTemp)); diff --git a/include/wincrypt.h b/include/wincrypt.h index 2219bd5..c897e96 100644 --- a/include/wincrypt.h +++ b/include/wincrypt.h @@ -1613,6 +1613,11 @@ static const WCHAR MS_SCARD_PROV_W[] = { 'M','i','c','r','o','s','o',' #define PP_KEYSPEC 39 #define PP_ENUMEX_SIGNING_PROT 40 +/* Values returned by CryptGetProvParam of PP_KEYSTORAGE */ +#define CRYPT_SEC_DESCR 0x00000001 +#define CRYPT_PSTORE 0x00000002 +#define CRYPT_UI_PROMPT 0x00000004 + /* Crypt{Get/Set}KeyParam */ #define KP_IV 1 #define KP_SALT 2 -- 1.4.4.2

3 5

Re: ddraw: DllCanUnloadNow
by James Hawkins 08 May '07

08 May '07

On 5/7/07, Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > Add support for DllCanUnloadNow and eliminates a FIXME > You need to add (Un)LockModule calls to all the objects in ddraw. See [1] et al. [1] http://www.winehq.org/pipermail/wine-cvs/2005-January/013741.html -- James Hawkins

1 0

Serial port working with +relay but not normal
by Aleš Rom 07 May '07

07 May '07

Hello, again. Two months ago I posted a message http://www.winehq.org/pipermail/wine-devel/2007-March/054710.html to this list. Now I'm using wine-0.9.36, but the serial port problem is still the same. After port initialization (19200,8N1-it's OK I think) no data is received from serial device. (snip) trace:file:get_dos_device L"COM1" -> "/home/romcek/.wine/dosdevices/com1" trace:file:CreateFileW returning 0x13c trace:comm:GetCommState handle 0x13c, ptr 0x34f9b8 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x34f988 4 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x34f98d 3 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x34f970 16 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_CHARS (nil) 0 0x34f982 6 0x34f914 trace:comm:GetCommState OK trace:comm:dump_dcb bytesize=8 baudrate=19200 fParity=0 Parity=0 stopbits=1 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:dump_dcb bytesize=8 baudrate=19200 fParity=0 Parity=0 stopbits=1 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=1 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:io_control 0x13c IOCTL_SERIAL_SET_BAUD_RATE 0x34f988 4 (nil) 0 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_SET_LINE_CONTROL 0x34f98d 3 (nil) 0 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_SET_HANDFLOW 0x34f970 16 (nil) 0 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_SET_CHARS 0x34f982 6 (nil) 0 0x34f914 trace:comm:io_control 0x13c IOCTL_SERIAL_SET_QUEUE_SIZE 0x34f98c 8 (nil) 0 0x34f930 fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented stub trace:comm:io_control 0x13c IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61a236b8 20 0x61a23650 trace:file:ReadFile 0x13c 0x61a2377c 0 0x61a23708 0xede5bc trace:file:WriteFile 0x13c 0xede5d0 18 0x61b327e8 0x61b327d4 trace:file:WriteFile 0x13c 0xede5d0 19 0x61b327e8 0x61b327d4 trace:comm:io_control 0x13c IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61a236b8 20 0x61a23650 trace:file:ReadFile 0x13c 0x61a2377c 0 0x61a23708 0xede5bc trace:comm:io_control 0x13c IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61a236b8 20 0x61a23650 trace:file:ReadFile 0x13c 0x61a2377c 0 0x61a23708 0xede5bc trace:comm:io_control 0x13c IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x61a236b8 20 0x61a23650 Last two lines repeats... The interesting part is that if I run wine with +relay option, I can transfer data from serial device to PC. Has this set_queue_size message anything to do with this problem? Can someone please help and put me to the right direction. Aleš Rom

1 0

Re: Initial Mixer support on Mac OS X (1/7)
by Dmitry Timoshkov 07 May '07

07 May '07

"Emmanuel Maillard" <mahanuu(a)free.fr> wrote: > Changelog : > - inital Mixer support on Mac OS X > - find all lines and initialize controls Could you please while you are working on winecoreaudio.drv make all public entry points (CoreAudio_widMessage, CoreAudio_wodMessage, CoreAudio_midMessage, CoreAudio_modMessage) 64-bit safe (by using a proper DRVCALLBACK prototype for the driver callback, and using proper data types for passing in/out parameters around)? -- Dmitry.

2 1

blizzard conference
by Robert Millan 07 May '07

07 May '07

Sorry for the OT, but I thought this might be of your interest, considering some of the Blizzard game developers will attend: http://www.blizzard.com/press/070412.shtml Maybe someone in California feels like dropping by to do some lobbying about that itchy /etc/hosts bug? :-) -- Robert Millan My spam trap is honeypot(a)aybabtu.com. Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list.

3 2