Wine device drivers proposal
Hi I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas. Basically, many Windows device drivers are really trivial, but required for many apps. A scanner driver typically just accepts commands from a user-space app, does minimal processing, and forwards that to Windows. I've already hacked up Wine to get the same functionality, and it works - partially. I propose adding a driver loading system to Wine that works as follows: -CreateFile() gets a device filename, like (in my case) \\.\MiiScan0 -Currently, Wine's behaviour for such a filename is to try load a VXD. -In the case of VXD loading failure, a search is performed in (Wine's) C:\Windows\System32\Drivers (or somewhere else?) for a matching driver. The driver is then loaded and used for (at least): ReadFile() WriteFile() DeviceIoControl() CloseHandle() The problem is, how is a handle mapped to the appropriate driver? I've thought about it, and come up with 3 solutions. The first 3 don't require changes to the wineserver but aren't pretty. 1. Make the driver a true Linux kernel mode driver, and the handle its device file handle. Since ReadFile() and WriteFile() just do read() and write() system calls, this can be done. The problem is, DeviceIoControl() has to be implemented using ioctl(), and that's dangerous (sending the right codes to the wrong device can be catastrophic). Also, it's not portable to other OS's, and requires writing a kernel module (which isn't fun). 2. The driver is a file giving a process to start and some IPC method to use. Wine starts the process and uses the IPC method to communicate with the driver. This is good as far as Wine's current ReadFile() and WriteFile() go, since they don't have to know they're not writing to an actual file. The problem here is, which IPC method supports both read() and write() on the same file descriptor, preserves message boundaries, and carries out-of-band data for DeviceIoControl()? I was thinking TCP sockets, but they don't preserve message boundaries. 3. KERNEL32.DLL and / or NTDLL.DLL keep their own handle table so they know which handles are driver handles and deal with those appropriately. Having to look up these tables for every call to ReadFile(), WriteFile() and DeviceIoControl() might be very inefficient, though. 4. Use an in-process solution, like a winelib DLL that has exports for dealing with ReadFile(), WriteFile() and DeviceIoControl(). This could be the most efficient, but then again, you need an efficient way to test a handle for being a driver handle, find the appropriate driver, and call the right exported function, which likely means the wineserver needs to have knowledge of these drivers and provide functionality for testing a handle for being a driver handle and have a way to find the driver. Let me know what you think. Bye Damjan __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: Two small scrollbar fixes
Rein Klazes [EMAIL PROTECTED] writes: dlls/user : scroll.c dlls/user/tests : win.c - GetScrollRange should return an empty range, both upper and lower limit zero, if the window has no scrollbars (msdn); - GetScrollInfo's return value is FALSE if the window has no scrollbars; This breaks the message test: msg.c:2761: Test failed: GetScrollInfo error 5 msg.c:2761: Test failed: GetScrollInfo error 5 -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine device drivers proposal
Damjan Jovanovic wrote: I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas. Drivers belong in the kernel. If there's no Linux driver for a device, then Wine cannot support it. In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware. The interface from user space to kernel space should be done via standard Linux mechanisms, such as ioctl. The Video4Linux API already offers such an interface. You can't load a Windows driver that accesses hardware in Wine, as Wine is a user-space application with no I/O privileges. Mike
Re: Wine device drivers proposal
On Mon, Mar 28, 2005 at 07:52:48PM +0900, Mike McCormack wrote: Damjan Jovanovic wrote: I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas. Drivers belong in the kernel. If there's no Linux driver for a device, then Wine cannot support it. In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware. The interface from user space to kernel space should be done via standard Linux mechanisms, such as ioctl. The Video4Linux API already offers such an interface. You can't load a Windows driver that accesses hardware in Wine, as Wine is a user-space application with no I/O privileges. Actually for still imaging devices the Linux side uses libgphoto2, which is in userspace and uses libusb to access the kernel. I would really suggest to implement STI on top of libgphoto2 and try loading kernel drivers later. Ciao, Marcus pgp36ahV8gAZ0.pgp Description: PGP signature
Re: Dragon Naturally Speaking - working.
I got NS7 working on Debian Sid, after running Sidenet setup on Wine 20050310. It took me a while to figure out that I need to raise the Capture level, not just the Mic volume on ALSA. Without it, it looked like NS (and Wine) didn't not pick up the mic even though I could hear myself on the speakers. Also, sometimes not all buttons are clickable even through they should be, so try Ctrl-S during the user setup. -- Konstantin Goudkov
Re: Wine device drivers proposal
--- Mike McCormack [EMAIL PROTECTED] wrote: Damjan Jovanovic wrote: I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas. Drivers belong in the kernel. If there's no Linux driver for a device, then Wine cannot support it. In that case, the first step is to write a Linux device driver for it, which has the added advantage that other native linux applications can use the hardware. The interface from user space to kernel space should be done via standard Linux mechanisms, such as ioctl. The Video4Linux API already offers such an interface. You can't load a Windows driver that accesses hardware in Wine, as Wine is a user-space application with no I/O privileges. I am not trying to _load_ a Windows driver (that either requires kernel support for the Windows DDK, like ndiswrapper has, or emulation of an entire x86, like bochs does). What I am trying to do is _replace_ a Windows driver with equivalent libusb functionality, getting, in effect, something like this: Application (eg. the Gimp) | v special SANE backend | v SANE to TWAIN converter | v Windows user-space TWAIN driver (by manufacturer) | v STI | v Wine (with drivers) | v Wine (user-space) driver | v libusb | v kernel Mike Damjan __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: wine/ windows/scroll.c dlls/x11drv/scroll.c dl ...
On Sun, 27 Mar 2005 11:34:12 -0500, you wrote: On Fri, Mar 25, 2005 at 11:11:04AM -0600, Alexandre Julliard wrote: Modified files: windows: scroll.c dlls/x11drv: scroll.c dlls/user/tests: win.c msg.c Log message: Rein Klazes [EMAIL PROTECTED] ScrollDC and X11DRV_SCROLLDC should scroll only pixels coming from within the visible region, clipped to the clipping region if that exists. Add the destination of pixels coming from the outside of this region to the update region. With tests that depend on this. Patch: http://cvs.winehq.org/patch.py?id=16854 Unfortunately, this patch doesn't fix bug 1091: http://bugs.winehq.org/show_bug.cgi?id=1091 If I get this correctly, your bug#1091 has to do with scrolling a window that already has an invalidated region before the scroll. None of my patches would affect that (making your deduction more likely true). Attached is a patch that solves Micha's scroll problem, also discussed under bug #1091. It also does not change the handling of an existing invalidated region. Changelog: windows : scroll.c dlls/user/tests : msg.c ScrollWindow should call ScrollWindowEx with the SW_ERASE flag set. With conformance test. Rein. --- wine/windows/scroll.c 2005-03-25 20:54:05.0 +0100 +++ mywine/windows/scroll.c 2005-03-28 13:48:11.0 +0200 @@ -182,7 +182,7 @@ BOOL WINAPI ScrollWindow( HWND hwnd, INT return (ERROR != ScrollWindowEx( hwnd, dx, dy, rect, clipRect, 0, NULL, (rect ? 0 : SW_SCROLLCHILDREN) | -SW_INVALIDATE )); +SW_INVALIDATE | SW_ERASE )); } /* --- wine/dlls/user/tests/msg.c 2005-03-25 20:52:38.0 +0100 +++ mywine/dlls/user/tests/msg.c2005-03-28 13:54:47.0 +0200 @@ -5471,6 +5471,14 @@ static void test_scrollwindowex(void) while (PeekMessage( msg, 0, 0, 0, PM_REMOVE )) DispatchMessage( msg ); ok_sequence(ScrollWindowPaint1, ScrollWindowEx, 0); +/* now scroll with ScrollWindow() */ +trace(start scroll with ScrollWindow\n); +ScrollWindow( hwnd, 5, 5, NULL, NULL); +trace(end scroll\n); +flush_sequence(); +while (PeekMessage( msg, 0, 0, 0, PM_REMOVE )) DispatchMessage( msg ); +ok_sequence(ScrollWindowPaint1, ScrollWindow, 0); + ok(DestroyWindow(hchild), failed to destroy window\n); ok(DestroyWindow(hwnd), failed to destroy window\n); flush_sequence();
Re: wine/ windows/scroll.c dlls/x11drv/scroll.c dl ...
On Mon, Mar 28, 2005 at 02:14:44PM +0200, Rein Klazes wrote: Attached is a patch that solves Micha's scroll problem, also discussed under bug #1091. It also does not change the handling of an existing invalidated region. Nice, at least you nailed one :). As for the initial problem that I've reported (http://www.winehq.org/hypermail/wine-devel/2002/09/0748.html), you are correct, it's about interaction with the invalidated region. I've figured that while you have your hands wet in that code, maybe you can take a stab at it. Thanks for taking a look! -- Dimi.
Re: Add a stdole2 typelib
On Sun, Mar 27, 2005 at 11:43:34PM -0500, Vincent Béron wrote:
Robert, Huw: Do you have something else to add before this one goes in,
or is Wine ready for it?
Huw: I had to name the enum at line 181, else I'd get a SIGSEGV in widl.
Would you mind trying to make it accept
typedef enum {
foo
} BAR;
instead of
typedef enum BAR {
foo
} BAR;
please?
Hi Vincent,
Sorry I got distracted with other things before I had a chance to
finish off the work on stdole2. I'll see if I can knock up something
to get these typedefs to work.
One remaining issue is the dispinterface FontEvents that is part of
coclass StdFont and yet is not defined until right at the end of the
typelib. There isn't a clean way to do this in idl and still maintain
the original order of the typeinfos - it's clear that the native
stdole2 is generated by a program rather than from idl. I guess we
could introduce a Wine specific attribute that allows us to hack
around this...
Huw.
Re: Two small scrollbar fixes
On 28 Mar 2005 12:48:11 +0200, you wrote:
Rein Klazes [EMAIL PROTECTED] writes:
dlls/user : scroll.c
dlls/user/tests : win.c
- GetScrollRange should return an empty range, both upper and lower
limit zero, if the window has no scrollbars (msdn);
- GetScrollInfo's return value is FALSE if the window has no scrollbars;
This breaks the message test:
msg.c:2761: Test failed: GetScrollInfo error 5
msg.c:2761: Test failed: GetScrollInfo error 5
I see, SB_CTL is treated different. Attached is an upgraded patch.
Changelog:
dlls/user : scroll.c
dlls/user/tests : win.c
- GetScrollRange should return an empty range, both upper and lower
limit zero, if the window has no scrollbars (msdn);
- GetScrollInfo's return value is TRUE is nBar is SB_CTL or if anything
is filled in the SCROLLINFO structure, otherwise the return value is
FALSE.
Rein.
--- wine/dlls/user/scroll.c 2005-03-25 20:52:36.0 +0100
+++ mywine/dlls/user/scroll.c 2005-03-28 15:08:45.0 +0200
@@ -1330,8 +1330,6 @@ static INT SCROLL_GetScrollPos(HWND hwnd
static BOOL SCROLL_GetScrollRange(HWND hwnd, INT nBar, LPINT lpMin, LPINT
lpMax)
{
LPSCROLLBAR_INFO infoPtr = SCROLL_GetInternalInfo(hwnd, nBar, FALSE);
-if (!infoPtr)
-return FALSE;
if (lpMin) *lpMin = infoPtr ? infoPtr-minVal : 0;
if (lpMax) *lpMax = infoPtr ? infoPtr-maxVal : 0;
@@ -1741,6 +1739,8 @@ done:
*
* RETURNS
* TRUE if SCROLLINFO is filled
+ * ( if nBar is SB_CTL, GetScrollInfo returns TRUE even if nothing
+ * is filled)
*/
BOOL WINAPI GetScrollInfo(HWND hwnd, INT nBar, LPSCROLLINFO info)
{
@@ -1748,11 +1748,11 @@ BOOL WINAPI GetScrollInfo(HWND hwnd, INT
/* Refer SB_CTL requests to the window */
if (nBar == SB_CTL)
+{
SendMessageW(hwnd, SBM_GETSCROLLINFO, (WPARAM)0, (LPARAM)info);
-else
-SCROLL_GetScrollInfo(hwnd, nBar, info);
-
-return TRUE;
+return TRUE;
+}
+return SCROLL_GetScrollInfo(hwnd, nBar, info);
}
--- wine/dlls/user/tests/win.c 2005-03-26 08:11:50.0 +0100
+++ mywine/dlls/user/tests/win.c2005-03-27 18:59:14.0 +0200
@@ -2650,6 +2650,43 @@ void test_scrollvalidate( HWND parent)
DestroyWindow( hwnd2);
}
+/* couple of tests of return values of scrollbar functions
+ * called on a scrollbarless window */
+void test_scroll()
+{
+BOOL ret;
+INT min, max;
+SCROLLINFO si;
+HWND hwnd = CreateWindowExA(0, Static, Wine test window,
+WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_POPUP,
+100, 100, 200, 200, 0, 0, 0, NULL);
+/* horizontal */
+ret = GetScrollRange( hwnd, SB_HORZ, min, max);
+ok( ret, GetScrollRange returns FALSE\n);
+ok( min == 0, minimum scroll pos is %d (should be zero)\n, min);
+ok( max == 0, maximum scroll pos is %d (should be zero)\n, min);
+si.cbSize = sizeof( si);
+si.fMask = SIF_PAGE;
+si.nPage = 0xdeadbeef;
+ret = GetScrollInfo( hwnd, SB_HORZ, si);
+ok( !ret, GetScrollInfo returns %d (should be zero)\n, ret);
+ok( si.nPage == 0xdeadbeef, unexpected value for nPage is %d\n,
si.nPage);
+/* vertical */
+ret = GetScrollRange( hwnd, SB_VERT, min, max);
+ok( ret, GetScrollRange returns FALSE\n);
+ok( min == 0, minimum scroll pos is %d (should be zero)\n, min);
+ok( max == 0, maximum scroll pos is %d (should be zero)\n, min);
+si.cbSize = sizeof( si);
+si.fMask = SIF_PAGE;
+si.nPage = 0xdeadbeef;
+ret = GetScrollInfo( hwnd, SB_VERT, si);
+ok( !ret, GetScrollInfo returns %d (should be zero)\n, ret);
+ok( si.nPage == 0xdeadbeef, unexpected value for nPage is %d\n,
si.nPage);
+/* clean up */
+DestroyWindow( hwnd);
+}
+
+
START_TEST(win)
{
pGetAncestor = (void *)GetProcAddress( GetModuleHandleA(user32.dll),
GetAncestor );
@@ -2709,6 +2746,7 @@ START_TEST(win)
test_validatergn(hwndMain);
test_nccalcscroll( hwndMain);
test_scrollvalidate( hwndMain);
+test_scroll();
UnhookWindowsHookEx(hhook);
Re: [dlls/msi/*] Strncpy elimination.
Good thing you sent these patches. I was just thinking, should I dig in? :-) Peter Berg Larsen wrote: I have been checking the usage of strncpy, replacing where apropriate with a memcpy or lstrcpyn[AW]. The first raw diff was 100kb, so there is bound to be one or two slips. These are the first batch which I found to be obvious, correct, and didnt need a special comment. Note with correct I mean if there was a \0 bug before then it still there. Changelog: Janitorial Task: Check the usage of strncpy/strncpyW. Index: dlls/msi/action.c === RCS file: /home/wine/wine/dlls/msi/action.c,v retrieving revision 1.104 diff -u -r1.104 action.c --- dlls/msi/action.c 24 Mar 2005 21:01:38 - 1.104 +++ dlls/msi/action.c 26 Mar 2005 09:40:49 - @@ -922,7 +922,7 @@ while (*ptr == ' ') ptr++; len = ptr2-ptr; prop = HeapAlloc(GetProcessHeap(),0,(len+1)*sizeof(WCHAR)); -strncpyW(prop,ptr,len); +memcpy(prop,ptr,len*sizeof(WCHAR)); prop[len]=0; ptr2++; @@ -942,7 +942,7 @@ len -= 2; } val = HeapAlloc(GetProcessHeap(),0,(len+1)*sizeof(WCHAR)); -strncpyW(val,ptr2,len); +memcpy(val,ptr2,len*sizeof(WCHAR)); val[len] = 0; if (strlenW(prop) 0) Index: dlls/msi/dialog.c === RCS file: /home/wine/wine/dlls/msi/dialog.c,v retrieving revision 1.9 diff -u -r1.9 dialog.c --- dlls/msi/dialog.c 24 Mar 2005 15:09:31 - 1.9 +++ dlls/msi/dialog.c 26 Mar 2005 09:40:51 - @@ -131,7 +131,7 @@ ret = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); if( !ret ) return ret; -strncpyW( ret, p, len ); +memcpy( ret, p, len*sizeof(WCHAR) ); ret[len-1] = 0; return ret; } Index: dlls/msi/format.c === RCS file: /home/wine/wine/dlls/msi/format.c,v retrieving revision 1.8 diff -u -r1.8 format.c --- dlls/msi/format.c 16 Mar 2005 11:31:35 - 1.8 +++ dlls/msi/format.c 26 Mar 2005 09:40:51 - @@ -252,7 +252,7 @@ *key = HeapAlloc(GetProcessHeap(),0,i*sizeof(WCHAR)); /* do not have the [] in the key */ i -= 1; -strncpyW(*key,(*mark)[1],i); +memcpy(*key,(*mark)[1],i*sizeof(WCHAR)); (*key)[i] = 0; TRACE(Found Key %s\n,debugstr_w(*key));
Re: OLE32, compositemoniker: remove function prototypes, make functions static
On Mon, 28 Mar 2005 14:48:40 +0900, Mike McCormack [EMAIL PROTECTED] wrote: There's more work like this to be done. Anybody want to help out? Mike ChangeLog: * remove function prototypes, make functions static Candidate for a janitorial project? :) -- James Hawkins
Re: Implementation of EnumMoniker and Partial impl on MkParseDisplayName
Hi Jeff,
Jeff Latimer wrote:
This is the first installment of the implementation of
MkParseDisplayName. I would like feed back on style and usage.
I think the implementation of the EnumMoniker interface looks ok.
Comments appreciated.
I like that you've taken the time to write a test case! I don't know
alot about monikers, but seeing that you've tested it gives me confidence...
The following comments are a crash course in Wine programming...
+/***
+ *EnmumMoniker_Next
+ */
+HRESULT WINAPI EnumMonikerImpl_Next(IEnumMoniker* iface, ULONG celt,
IMoniker** rgelt, ULONG * pceltFetched)
+{
+//DWORD i;
+//ULONG ref;
We avoid C++ comments in Wine code to keep compatability with older
compilers.
+EnumMonikerImpl *This = (EnumMonikerImpl *)iface;
+TRACE((%p) currentPos %d Tablastindx %d\n,This, (int)This-currentPos,
(int)This-TabLastIndx);
+ULONG i;
You declared i above, but commented it out. Try avoid putting dead
code in comments. If code isn't compiled, it will become stale and
confuse people.
+rc = CoGetMalloc(1, (LPMALLOC *) ppMalloc);
if (!(IsValidInterface((LPUNKNOWN) pbc)))
return E_INVALIDARG;
+usernamelen = (int) lstrlenW(szUserName); // overall string len
+
+if (szUserName[char_cnt] == (WCHAR) '@') { // This is a progid not a file name
That's alot of casts. I don't think you really need that many, do you?
+/* retrieve the requested number of moniker from the current position */
+for(i=0;((This-currentPos This-TabLastIndx) (i celt));i++)
+ rgelt[i]=(IMoniker*)This-TabMoniker[This-currentPos++].pmkObj;
Better to avoid tabs... and too many brackets. A space or two extra in
the for( i=0; (This-... might make things look better.
+ if (szUserName[char_cnt] == '/' ||
+ szUserName[char_cnt] == '?' ||
+ szUserName[char_cnt] == '' ||
+ szUserName[char_cnt] == '' ||
+ szUserName[char_cnt] == '*' ||
+ szUserName[char_cnt] == '|' ||
+ szUserName[char_cnt] == ':')
Maybe that can be shortened to :
if (strchr(/?*|:,szUserName[char_cnt]))
+todo_wine { ok(hr==0x800401e4, MkParseDisplayName - Progid not implemented hr=%08x\n, (int) hr); }
0x800401e4 is defined as MK_E_SYNTAX. It would be clearer to use the
define rather than a number.
%08lx is probably what you want instead of casting hr to (int) to get
rid of the printf parameter type warning.
+
+IBindCtx_Release(pbc);
+
+/* A bad drive */
+static const WCHAR wszDisplayName2[] = {'1',':','s','i','d',':',
'2','0','D','0','4','F','E','0','-','3','A','E','A','-','1','0','6','9','-','A','2','D','8','-','0','8','0','0','2','B','3','0','3','0','9','D',':',0};
Again, for compatability, we avoid inline declarations, even though gcc
can deal with them fine.
Mike
Re: [libs/wine/*] Strncpy elimination.
On 28 Mar 2005, Alexandre Julliard wrote: Janitorial Task: Check the usage of strncpy/strncpyW. You can't use lstrcpynA in the libs/ directory, you have to stick to Unix APIs. Ok, I just compiled and wine seemed to work. Peter -- E-Mail: [EMAIL PROTECTED] Real name:Peter Berg Larsen Where:Department of Computer Science, Copenhagen Uni., Denmark
Re: OLE32, compositemoniker: remove function prototypes, make functions static
James Hawkins wrote: Candidate for a janitorial project? :) Well, it may be a little bit complex to describe for Janitorial ... but by looking at my patches you can see what I'm trying to do. This was Juan's idea in the first place though :) Mike
dbghelp: small fixes
this patch fixes a couple of bugs in dbghelp
A+
--
Eric Pouech
Name: dbghelp19
ChangeLog:
- PDB: better checking for error conditions
- Fixed name demangling (when activated) when searching for a symbol
License: X11
GenDate: 2005/03/28 16:17:32 UTC
ModifiedFiles: dlls/dbghelp/msc.c dlls/dbghelp/symbol.c
AddedFiles:
RemovedFiles:
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/dbghelp/msc.c,v
retrieving revision 1.12
diff -u -u -r1.12 msc.c
--- dlls/dbghelp/msc.c 15 Mar 2005 19:32:14 - 1.12
+++ dlls/dbghelp/msc.c 18 Mar 2005 19:58:05 -
@@ -4,7 +4,7 @@
*
* Copyright (C) 1996, Eric Youngdale.
* Copyright (C) 1999-2000, Ulrich Weigand.
- * Copyright (C) 2004, Eric Pouech.
+ * Copyright (C) 2004-2005, Eric Pouech.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -496,11 +496,10 @@
{
struct symt_udt*symt;
const unsigned char*ptr = list;
-int value, leaf_len, vpoff, vplen;
+int value, leaf_len;
const struct p_string* p_name;
const char* c_name;
struct symt*subtype;
-const unsigned short int* p_vboff;
symt = symt_new_udt(module, NULL, 0, UdtStruct /* don't care */);
while (ptr - list len)
@@ -534,6 +533,8 @@
case LF_VBCLASS_V1:
case LF_IVBCLASS_V1:
{
+const unsigned short int* p_vboff;
+int vpoff, vplen;
leaf_len = numeric_leaf(value, type-vbclass_v1.vbpoff);
p_vboff = (const unsigned short int*)((const char*)type-vbclass_v1.vbpoff + leaf_len);
vplen = numeric_leaf(vpoff, p_vboff);
@@ -547,6 +548,8 @@
case LF_VBCLASS_V2:
case LF_IVBCLASS_V2:
{
+const unsigned short int* p_vboff;
+int vpoff, vplen;
leaf_len = numeric_leaf(value, type-vbclass_v2.vbpoff);
p_vboff = (const unsigned short int*)((const char*)type-vbclass_v2.vbpoff + leaf_len);
vplen = numeric_leaf(vpoff, p_vboff);
@@ -1156,7 +1159,8 @@
{
const union codeview_symbol* sym = (const union codeview_symbol*)(root + i);
length = sym-generic.len + 2;
-if (length 3) FIXME(unpadded len %u\n, length + 2);
+if (i + length size) break;
+if (length 3) FIXME(unpadded len %u\n, length);
switch (sym-generic.id)
{
Index: dlls/dbghelp/symbol.c
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/dbghelp/symbol.c,v
retrieving revision 1.16
diff -u -u -r1.16 symbol.c
--- dlls/dbghelp/symbol.c 28 Mar 2005 14:17:52 - 1.16
+++ dlls/dbghelp/symbol.c 28 Mar 2005 14:36:40 -
@@ -532,7 +532,7 @@
if (sym_info-MaxNameLen)
{
if (sym-tag != SymTagPublicSymbol || !(dbghelp_options SYMOPT_UNDNAME) ||
-(sym_info-NameLen = UnDecorateSymbolName(sym_info-Name, sym_info-Name,
+(sym_info-NameLen = UnDecorateSymbolName(name, sym_info-Name,
sym_info-MaxNameLen, UNDNAME_COMPLETE) == 0))
{
sym_info-NameLen = min(strlen(name), sym_info-MaxNameLen - 1);
Re: Implementation of EnumMoniker and Partial impl on MkParseDisplayName
Jeff Latimer wrote:
This is the first installment of the implementation of
MkParseDisplayName. I would like feed back on style and usage.
Ok, I'll happily add comments on the patch.
I think the implementation of the EnumMoniker interface looks ok.
Comments appreciated.
Jeff Latimer
Index: moniker.c
===
RCS file: /home/wine/wine/dlls/ole32/moniker.c,v
retrieving revision 1.38
diff -u -r1.38 moniker.c
--- moniker.c 13 Dec 2004 21:19:02 - 1.38
+++ moniker.c 28 Mar 2005 12:06:51 -
@@ -29,7 +29,6 @@
#include assert.h
#include stdarg.h
-#include string.h
#define COBJMACROS
@@ -38,6 +37,7 @@
#include winbase.h
#include winuser.h
#include wtypes.h
+#include wine/unicode.h
#include wine/debug.h
#include ole2.h
@@ -50,11 +50,11 @@
/* define the structure of the running object table elements */
typedef struct RunObject{
-IUnknown* pObj; /* points on a running object*/
-IMoniker* pmkObj; /* points on a moniker who identifies this object */
+IUnknown* pObj; /* points on a running object*/
+IMoniker* pmkObj; /* points on a moniker who identifies
this object */
FILETIME lastModifObj;
-DWORD identRegObj; /* registration key relative to this object */
-DWORD regTypeObj; /* registration type : strong or weak */
+DWORD identRegObj;/* registration key relative to this object */
+DWORD regTypeObj; /* registration type : strong or weak */
}RunObject;
/* define the RunningObjectTableImpl structure */
@@ -106,6 +106,55 @@
RunningObjectTableImpl_EnumRunning
};
+/* define the EnumMonikerImpl structure */
+typedef struct EnumMonikerImpl{
+
+IEnumMonikerVtbl *lpVtbl;
+ULONG ref;
+
+RunObject* TabMoniker;/* pointer to the first object in the table */
+DWORD TabSize; /* current table size */
+DWORD TabLastIndx; /* first free index element in the table. */
Since you asked for feedback on style, I'll say that you should try to
keep the naming conventions consistent.
+DWORD runObjTabRegister; /* registration key of the next registered object */
+DWORD currentPos;/* enum position in the list */
+
+} EnumMonikerImpl;
+
+
+/* IEnumMoniker prototype functions : */
+/* IUnknown functions*/
+static HRESULT WINAPI EnumMonikerImpl_QueryInterface(IEnumMoniker* iface,REFIID riid,void** ppvObject);
+static ULONG WINAPI EnumMonikerImpl_AddRef(IEnumMoniker* iface);
+static ULONG WINAPI EnumMonikerImpl_Release(IEnumMoniker* iface);
+/* IEnumMoniker functions */
+static HRESULT WINAPI EnumMonikerImpl_Next(IEnumMoniker* iface, ULONG celt, IMoniker** rgelt, ULONG* pceltFetched);
+static HRESULT WINAPI EnumMonikerImpl_Skip(IEnumMoniker* iface, ULONG celt);
+static HRESULT WINAPI EnumMonikerImpl_Reset(IEnumMoniker* iface);
+static HRESULT WINAPI EnumMonikerImpl_Clone(IEnumMoniker* iface, IEnumMoniker** ppenum);
If you put the vtable after the implementations of the functions then
you don't need to declare the prototypes here.
+
+/* Local functions*/
+HRESULT WINAPI EnumMonikerImpl_Initialize(void);
+HRESULT WINAPI EnumMonikerImpl_CreateEnumROTMoniker(RunObject* runObjTab,
+ ULONG TabSize,
+ ULONG TabLastIndx,
+ ULONG currentPos,
+ IEnumMoniker ** ppenumMoniker);
+HRESULT WINAPI EnumMonikerImpl_UnInitialize(void);
+HRESULT WINAPI EnumMonikerImpl_Destroy(void);
+HRESULT WINAPI EnumMonikerImpl_GetObjectIndex(EnumMonikerImpl* This,DWORD identReg,IMoniker* pmk,DWORD *indx);
Presumably, these should all be static since they are not used outside
the file.
+
+/* Virtual function table for the IEnumMoniker class. */
+static IEnumMonikerVtbl VT_EnumMonikerImpl =
+{
+EnumMonikerImpl_QueryInterface,
+EnumMonikerImpl_AddRef,
+EnumMonikerImpl_Release,
+EnumMonikerImpl_Next,
+EnumMonikerImpl_Skip,
+EnumMonikerImpl_Reset,
+EnumMonikerImpl_Clone
+};
+
/***
*RunningObjectTable_QueryInterface
*/
+/***
+ *EnumMonikerImpl_CreateEnumROTMoniker
+ *Used by EnumRunning to create the structure and EnumClone
+ * to copy the structure
+ */
+HRESULT WINAPI EnumMonikerImpl_CreateEnumROTMoniker(RunObject* TabMoniker,
+ ULONG TabSize,
+ ULONG TabLastIndx,
+ ULONG currentPos,
+ IEnumMoniker ** ppenumMoniker)
+{
+int i;
+if (currentPos TabSize)
+ return E_INVALIDARG;
+
+if (ppenumMoniker == 0)
+return
Re: [dlls/msi/*] Strncpy elimination.
On Mon, 28 Mar 2005, Jakob Eriksson wrote: Good thing you sent these patches. I was just thinking, should I dig in? :-) You could recheck them? I tend to get code blind, when having so many cases that nearly are identical. As I said there are probably one two places where I didnt get the sematic of the code. Especially look for off-by-one (\0) when the replacement is a memcpy. I tend to do this, because of codestyle, like: +++ dlls/msi/dialog.c26 Mar 2005 09:40:51 - @@ -131,7 +131,7 @@ ret = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); if( !ret ) return ret; -strncpyW( ret, p, len ); +memcpy( ret, p, len*sizeof(WCHAR) ); ret[len-1] = 0; return ret; } This memcpyies one element more than needed.. but seemed much nicer than memcpy( ret, p, (len - 1)*sizeof(WHCAR); I probably should have subtracted one from len, making it obvious that this is a strdupW, like: ret = HeapAlloc( GetProcessHeap(), 0, (len+1)*sizeof(WCHAR) ); memcpy( ret, p, len*sizeof(WCHAR) ); ret[len] = 0; Peter
Re: dbghelp: better module support
Eric Pouech a écrit :
minidumps now contain more accurate information about modules,
especially information that will allow when reloading a minidump in a
debugger to check whether we're using the right modules (ELF PE)
implemented also check for this information in SymFindFileInPath
A+
Please use this version instead (the previous had an un-wanted statement)
A+
--
Eric Pouech
Name: dbghelp18
ChangeLog:
- various improvements for minidump module information
. added timestamp checksum in PE module
. added size checksum in ELF module
. wine loader now appears with its pathname
- Implemented PE ELF timestamp checksum validation in SymFindFileInPath
License: X11
GenDate: 2005/03/28 16:36:41 UTC
ModifiedFiles: dlls/dbghelp/dbghelp_private.h dlls/dbghelp/elf_module.c dlls/dbghelp/minidump.c dlls/dbghelp/module.c
dlls/dbghelp/path.c dlls/dbghelp/pe_module.c include/dbghelp.h
AddedFiles:
RemovedFiles:
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/dbghelp/dbghelp_private.h,v
retrieving revision 1.14
diff -u -u -r1.14 dbghelp_private.h
--- dlls/dbghelp/dbghelp_private.h 1 Mar 2005 10:39:49 - 1.14
+++ dlls/dbghelp/dbghelp_private.h 28 Mar 2005 11:28:25 -
@@ -249,6 +249,7 @@
DMT_UNKNOWN,/* for lookup, not actually used for a module */
DMT_ELF,/* a real ELF shared module */
DMT_PE, /* a native or builtin PE module */
+DMT_PDB,/* PDB file */
};
struct module
@@ -295,6 +296,7 @@
/* elf_module.c */
typedef BOOL (*elf_enum_modules_cb)(const char*, unsigned long addr, void* user);
extern BOOL elf_enum_modules(HANDLE hProc, elf_enum_modules_cb, void*);
+extern BOOL elf_fetch_file_info(const char* name, DWORD* base, DWORD* size, DWORD* checksum);
struct elf_file_map;
extern BOOL elf_load_debug_info(struct module* module, struct elf_file_map* fmap);
extern struct module*
@@ -324,6 +326,8 @@
extern struct module*
module_get_containee(const struct process* pcs,
const struct module* inner);
+extern enum module_type
+module_get_type_by_name(const char* name);
extern void module_reset_debug_info(struct module* module);
extern BOOL module_remove(struct process* pcs,
struct module* module);
@@ -334,6 +338,7 @@
const IMAGE_SECTION_HEADER* sectp, DWORD nsect,
const IMAGE_DEBUG_DIRECTORY* dbg, int nDbg);
/* pe_module.c */
+extern BOOL pe_load_nt_header(HANDLE hProc, DWORD base, IMAGE_NT_HEADERS* nth);
extern struct module*
pe_load_module(struct process* pcs, char* name,
HANDLE hFile, DWORD base, DWORD size);
Index: dlls/dbghelp/elf_module.c
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/dbghelp/elf_module.c,v
retrieving revision 1.17
diff -u -u -r1.17 elf_module.c
--- dlls/dbghelp/elf_module.c 23 Mar 2005 13:15:20 - 1.17
+++ dlls/dbghelp/elf_module.c 28 Mar 2005 12:00:09 -
@@ -81,12 +81,14 @@
#define ELF_INFO_DEBUG_HEADER 0x0001
#define ELF_INFO_MODULE 0x0002
+#define ELF_INFO_NAME 0x0004
struct elf_info
{
unsignedflags; /* IN one (or several) of the ELF_INFO constants */
unsigned long dbg_hdr_addr; /* OUT address of debug header (if ELF_INFO_DEBUG_HEADER is set) */
struct module* module; /* OUT loaded module (if ELF_INFO_MODULE is set) */
+const char* module_name;/* OUT found module name (if ELF_INFO_NAME is set) */
};
#define NO_MAP ((const void*)0x)
@@ -139,7 +141,8 @@
return NO_MAP;
/* align required information on page size (we assume pagesize is a power of 2) */
ofst = fmap-sect[sidx].shdr.sh_offset ~(pgsz - 1);
-size = (fmap-sect[sidx].shdr.sh_offset + fmap-sect[sidx].shdr.sh_size + pgsz - 1) ~(pgsz - 1);
+size = (fmap-sect[sidx].shdr.sh_offset +
+fmap-sect[sidx].shdr.sh_size + pgsz - 1) ~(pgsz - 1);
fmap-sect[sidx].mapped = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fmap-fd, ofst);
if (fmap-sect[sidx].mapped == NO_MAP) return NO_MAP;
return fmap-sect[sidx].mapped + (fmap-sect[sidx].shdr.sh_offset (pgsz - 1));
@@ -188,7 +191,8 @@
if (memcmp(fmap-elfhdr.e_ident,
elf_signature, sizeof(elf_signature))) return FALSE;
-fmap-sect = HeapAlloc(GetProcessHeap(), 0, fmap-elfhdr.e_shnum * sizeof(fmap-sect[0]));
+fmap-sect = HeapAlloc(GetProcessHeap(), 0,
+ fmap-elfhdr.e_shnum * sizeof(fmap-sect[0]));
if (!fmap-sect) return FALSE;
lseek(fmap-fd, fmap-elfhdr.e_shoff, SEEK_SET);
@@
Re: DDRAW: Surface locking patch, take 2
Matthew Mastracci [EMAIL PROTECTED] writes: I'm just pinging the list ot see if there's any reason why this patch hasn't been applied yet. AFAIK, it takes into account all the feedback received so far. If you think you have taken into account the feedback then you should resubmit the patch. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [libs/wine/*] Strncpy elimination.
Peter Berg Larsen [EMAIL PROTECTED] writes: On 28 Mar 2005, Alexandre Julliard wrote: You can't use lstrcpynA in the libs/ directory, you have to stick to Unix APIs. Ok, I just compiled and wine seemed to work. Yes, that's because they are declared inline, but we don't want to rely on that since the compiler is allowed to not inline them. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [dlls/msi/*] Strncpy elimination.
Peter Berg Larsen [EMAIL PROTECTED] writes: This memcpyies one element more than needed.. but seemed much nicer than memcpy( ret, p, (len - 1)*sizeof(WHCAR); I probably should have subtracted one from len, making it obvious that this is a strdupW, like: ret = HeapAlloc( GetProcessHeap(), 0, (len+1)*sizeof(WCHAR) ); memcpy( ret, p, len*sizeof(WCHAR) ); ret[len] = 0; If it's really a strdup it's cleaner to copy one more char and get rid of the ret[len] = 0. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [dlls/msi/*] Strncpy elimination.
On 28 Mar 2005, Alexandre Julliard wrote: This memcpyies one element more than needed.. but seemed much nicer than memcpy( ret, p, (len - 1)*sizeof(WHCAR); I probably should have subtracted one from len, making it obvious that this is a strdupW, like: ret = HeapAlloc( GetProcessHeap(), 0, (len+1)*sizeof(WCHAR) ); memcpy( ret, p, len*sizeof(WCHAR) ); ret[len] = 0; If it's really a strdup it's cleaner to copy one more char and get rid of the ret[len] = 0. Yes, and I would have done that, but in this case p is not \0 terminated. I probably left it like that because I didnt understand why it copied one byte to much in the strncpy case. That is exactly the reason for sending the patches one dll at the time: For authers/maintainers have a quick look at the replaces code. As I said in the in the beginning; if there was a bug, then it still there (but more obvious). Peter
Re: msi:Fix Typelib Registration
On Mon, Mar 28, 2005 at 10:39:48AM -0600, Aric Stewart wrote:
make sure the GUID of the typelib we are registering matches the guid
requested from MSI. if not search the given typelib file to find the
typelib requested to register.
Index: dlls/msi/action.c
===
RCS file: /home/wine/wine/dlls/msi/action.c,v
retrieving revision 1.105
diff -u -r1.105 action.c
--- dlls/msi/action.c 28 Mar 2005 14:17:52 - 1.105
+++ dlls/msi/action.c 28 Mar 2005 16:33:23 -
@@ -4097,7 +4101,39 @@
continue;
}
+guid = load_dynamic_stringW(row,1);
res = LoadTypeLib(package-files[index].TargetPath,ptLib);
+ITypeLib_GetLibAttr(ptLib, attr);
+CLSIDFromString(guid, clsid);
+if (!IsEqualGUID(clsid,attr-guid))
+{
+static const WCHAR fmt[] = {'%','s','\\','%','i',0};
+int i;
+int sz;
+
+TRACE(Initial match failure\n);
+
+sz = strlenW(package-files[index].TargetPath)+4;
+sz *= sizeof(WCHAR);
+
+for (i = 2; i 10; i++)
+{
+path = HeapAlloc(GetProcessHeap(),0,sz);
+sprintfW(path,fmt,package-files[index].TargetPath, i);
+TRACE(trying %s\n, debugstr_w(path));
+res = LoadTypeLib(path,ptLib);
+ITypeLib_GetLibAttr(ptLib, attr);
+CLSIDFromString(guid, clsid);
+if (IsEqualGUID(clsid,attr-guid))
+break;
+HeapFree(GetProcessHeap(),0,path);
+res = E_FAIL;
+
+}
+}
+else
+path = strdupW(package-files[index].TargetPath);
+
if (SUCCEEDED(res))
{
LPWSTR help;
This doesn't look right. Maybe you need to enumerate through the
typelib resources here. What information are you actually given?
You're also leaking ITypeLibs and TLIBATTRs
Huw.
advapi: remove signature checking code.
Hi,
Microsoft signs it's cryptographic service provider (csp) dlls with a private
key. advapi32 will only load csp dlls with a valid signature. We will never
be able to implement this, since this would mean having access to Microsoft's
private keys. Above this, Microsofts scheme doesn't give real security, since
there are instructions on the web to replace advapi32's _NSAKEY with an
arbitrary private key (this is if you have write access to advapi32.dll),
allowing you to load a csp signed by yourself.
I would like to remove the (stubbed) signature checking code from advapi32.
This would clean up advapi32 somewhat and remove a FIXME message, which
bothers me for some time and which confused wine users in at least two
occurences.
Comments anyone?
Bye,
--
Michael Jung
[EMAIL PROTECTED]
Index: dlls/advapi32/crypt.c
===
RCS file: /home/wine/wine/dlls/advapi32/crypt.c,v
retrieving revision 1.61
diff -u -r1.61 crypt.c
--- dlls/advapi32/crypt.c 21 Dec 2004 14:34:18 - 1.61
+++ dlls/advapi32/crypt.c 28 Mar 2005 21:49:47 -
@@ -22,7 +22,6 @@
* TODO:
* - Reference counting
* - Thread-safing
- * - Signature checking
*/
#include time.h
@@ -255,7 +254,6 @@
PCRYPTPROV pProv = NULL;
HKEY key;
PSTR imagepath = NULL, keyname = NULL, provname = NULL, temp = NULL;
- BYTE* signature;
DWORD keytype, type, len;
ULONG r;
@@ -378,74 +376,19 @@
SetLastError(NTE_PROV_TYPE_ENTRY_BAD);
goto error;
}
-
- r = RegQueryValueExA(key, Signature, NULL, keytype, NULL, len);
- if ( r == ERROR_SUCCESS keytype == REG_BINARY )
- {
- if (!(signature = CRYPT_Alloc(len)))
- {
- RegCloseKey(key);
- SetLastError(ERROR_NOT_ENOUGH_MEMORY);
- goto error;
- }
- r = RegQueryValueExA(key, Signature, NULL, NULL, signature, len);
- if ( r != ERROR_SUCCESS )
- {
- TRACE(error %ld reading 'Signature'\n, r );
- CRYPT_Free(signature);
- RegCloseKey(key);
- SetLastError(NTE_PROV_TYPE_ENTRY_BAD);
- goto error;
- }
- }
- else
- {
- r = RegQueryValueExA(key, SigInFile, NULL, keytype, NULL, len);
- if (r != ERROR_SUCCESS)
- {
- TRACE(error %ld reading size of 'SigInFile'\n, r );
- RegCloseKey(key);
- SetLastError(NTE_PROV_TYPE_ENTRY_BAD);
- goto error;
- }
- else
- {
- /* FIXME: The presence of the SigInFile value indicates the
- * provider's signature is in its resources, so need to read it.
- * But since CRYPT_VerifyImage is stubbed, provide any old thing
- * for now.
- */
- if (!(signature = CRYPT_Alloc(1)))
- {
-RegCloseKey(key);
-SetLastError(ERROR_NOT_ENOUGH_MEMORY);
-goto error;
- }
- }
- }
RegCloseKey(key);
len = ExpandEnvironmentStringsA(temp, NULL, 0);
if ( !(imagepath = CRYPT_Alloc(len)) )
{
- CRYPT_Free(signature);
SetLastError(ERROR_NOT_ENOUGH_MEMORY);
goto error;
}
if (!ExpandEnvironmentStringsA(temp, imagepath, len))
{
- CRYPT_Free(signature);
/* ExpandEnvironmentStrings will call SetLastError */
goto error;
}
-
- if (!CRYPT_VerifyImage(imagepath, signature))
- {
- CRYPT_Free(signature);
- SetLastError(NTE_SIGNATURE_FILE_BAD);
- goto error;
- }
pProv = CRYPT_LoadProvider(imagepath);
- CRYPT_Free(signature);
if (!pProv) {
/* CRYPT_LoadProvider calls SetLastError */
goto error;
Re: Dragon Naturally Speaking - working.
Great news. Could you give more details on your alsa setup? I have not managed to get alsa working with wine appart from putting oss in the wine config and using alsa-oss Regards, On Mon, 28 Mar 2005 13:50:08 +0200, Konstantin Goudkov [EMAIL PROTECTED] wrote: I got NS7 working on Debian Sid, after running Sidenet setup on Wine 20050310. It took me a while to figure out that I need to raise the Capture level, not just the Mic volume on ALSA. Without it, it looked like NS (and Wine) didn't not pick up the mic even though I could hear myself on the speakers. Also, sometimes not all buttons are clickable even through they should be, so try Ctrl-S during the user setup. -- Konstantin Goudkov -- Opera 7 mail on Linux
Re: KERNEL: Implement undocumented SetCPGlobal API call
On Tue, 29 Mar 2005 11:37:43 +1100, Troy Rollo [EMAIL PROTECTED] wrote: SetCPGlobal is the undocumented partner of GetACP - it is used to set the current ANSI code page. ChangeLog: Implement SetCPGlobal (an undocumented Win32 API) A patch would be good :) -- James Hawkins
Re: KERNEL: Implement undocumented SetCPGlobal API call
On Tue, 29 Mar 2005 11:37:43 +1100, Troy Rollo [EMAIL PROTECTED] wrote: SetCPGlobal is the undocumented partner of GetACP - it is used to set the current ANSI code page. ChangeLog: Implement SetCPGlobal (an undocumented Win32 API) A patch would be good :) -- James Hawkins
Re: version: Use proper type for third parameter of VerQueryValue
James Hawkins [EMAIL PROTECTED] wrote: Changelog * Use proper type for third parameter of VerQueryValue -DWORD WINAPI VerQueryValueA(LPVOID,LPCSTR,LPVOID*,UINT*); -DWORD WINAPI VerQueryValueW(LPVOID,LPCWSTR,LPVOID*,UINT*); +BOOL WINAPI VerQueryValueA(const LPVOID,LPCSTR,UINT*,UINT*); +BOOL WINAPI VerQueryValueW(const LPVOID,LPCWSTR,UINT*,UINT*); Where did you get it? PSDK agrees with current Wine definition on the 3rd param type. Also the 2nd param should not be 'const'. -- Dmitry.
Re: KERNEL: Implement undocumented SetCPGlobal API call
Troy Rollo [EMAIL PROTECTED] wrote: SetCPGlobal is the undocumented partner of GetACP - it is used to set the current ANSI code page. ChangeLog: Implement SetCPGlobal (an undocumented Win32 API) What app does depend on it? -- Dmitry.
Re: version: Use proper type for third parameter of VerQueryValue
On Tue, 29 Mar 2005 14:02:03 +0900, Dmitry Timoshkov [EMAIL PROTECTED] wrote: James Hawkins [EMAIL PROTECTED] wrote: Changelog * Use proper type for third parameter of VerQueryValue -DWORD WINAPI VerQueryValueA(LPVOID,LPCSTR,LPVOID*,UINT*); -DWORD WINAPI VerQueryValueW(LPVOID,LPCWSTR,LPVOID*,UINT*); +BOOL WINAPI VerQueryValueA(const LPVOID,LPCSTR,UINT*,UINT*); +BOOL WINAPI VerQueryValueW(const LPVOID,LPCWSTR,UINT*,UINT*); Where did you get it? PSDK agrees with current Wine definition on the 3rd param type. Also the 2nd param should not be 'const'. My PSDK (Server 2003) has this definition: BOOL VerQueryValue( const LPVOID pBlock, LPTSTR lpSubBlock, PUINT lplpBuffer, PUINT puLen ); And msdn agrees with it: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/versioninformation/versioninformationreference/versioninformationfunctions/verqueryvalue.asp I wrote this patch to keep up with the PSDK, but if we want to keep the original definition, then that's cool too. I can fix the error when compiling visual studio another way. What are some thoughts about this? -- James Hawkins
Re: version: Use proper type for third parameter of VerQueryValue
Dmitry == Dmitry Timoshkov [EMAIL PROTECTED] writes: Dmitry James Hawkins [EMAIL PROTECTED] wrote: Changelog * Use proper type for third parameter of VerQueryValue -DWORD WINAPI VerQueryValueA(LPVOID,LPCSTR,LPVOID*,UINT*); -DWORD WINAPI VerQueryValueW(LPVOID,LPCWSTR,LPVOID*,UINT*); +BOOL WINAPI VerQueryValueA(const LPVOID,LPCSTR,UINT*,UINT*); +BOOL WINAPI VerQueryValueW(const LPVOID,LPCWSTR,UINT*,UINT*); Dmitry Where did you get it? PSDK agrees with current Wine definition Dmitry on the 3rd param type. Also the 2nd param should not be 'const'. MSDN (look with Google for VerQueryValue and use the first hit) has (const LPVOID ..., LPTSTR ..., PUINT ..., PUINT ...) Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
