Re: msi: Fix use of uninitialized variable (Coverity) (Try 2)
Andrew Talbot wrote: James Hawkins wrote: Please don't check env for NULL; RegCloseKey will just fail harmlessly if env is NULL. We spent a lot of time removing such checks. OK, I shall re-post my first effort as Try 3. But then why don't you just set env to NULL and leave the rest as is. The only thing that will change is the lasterror probably if you don't check for NULL. Cheers, Paul.
Re: msi: Fix use of uninitialized variable (Coverity) (Try 3)
On 6/23/07, Andrew Talbot [EMAIL PROTECTED] wrote:
[Reverting to Plan A:]
This patch should fix Coverity bug CID-562. Additionally, I have pinpointed
another suspected use-before-initialization bug, for future consideration.
-- Andy.
---
Changelog:
msi: Fix use of uninitialized variable (Coverity).
diff -urN a/dlls/msi/action.c b/dlls/msi/action.c
--- a/dlls/msi/action.c 2007-06-18 17:52:27.0 +0100
+++ b/dlls/msi/action.c 2007-06-23 22:19:03.0 +0100
@@ -4668,7 +4668,7 @@
res = env_set_flags(name, deformatted, flags);
if (res != ERROR_SUCCESS)
- goto done;
+ goto done2;
value = deformatted;
@@ -4676,8 +4676,14 @@
root = HKEY_LOCAL_MACHINE;
res = RegOpenKeyExW(root, environment, 0, KEY_ALL_ACCESS, env);
+/*
+* FIXME: RegCloseKey() should not be called with an invalid handle.
+* So should we simply goto done2 here, if res != EXIT_SUCCESS,
+* or does RegOpenKeyEx() have any failure modes in which env does
+* get initialized?
+*/
if (res != ERROR_SUCCESS)
-goto done;
+goto done1;
if (flags ENV_ACT_REMOVE)
FIXME(Not removing environment variable on uninstall!\n);
@@ -4686,14 +4692,14 @@
res = RegQueryValueExW(env, name, NULL, type, NULL, size);
if ((res != ERROR_SUCCESS res != ERROR_FILE_NOT_FOUND) ||
(res == ERROR_SUCCESS type != REG_SZ))
-goto done;
+goto done1;
if (res != ERROR_FILE_NOT_FOUND)
{
if (flags ENV_ACT_SETABSENT)
{
res = ERROR_SUCCESS;
-goto done;
+goto done1;
}
data = msi_alloc(size);
@@ -4705,12 +4711,12 @@
res = RegQueryValueExW(env, name, NULL, type, (LPVOID)data, size);
if (res != ERROR_SUCCESS)
-goto done;
+goto done1;
if (flags ENV_ACT_REMOVEMATCH (!value || !lstrcmpW(data, value)))
{
res = RegDeleteKeyW(env, name);
-goto done;
+goto done1;
}
size = (lstrlenW(value) + 1 + size) * sizeof(WCHAR);
@@ -4719,7 +4725,7 @@
if (!newval)
{
res = ERROR_OUTOFMEMORY;
-goto done;
+goto done1;
}
if (!(flags ENV_MOD_MASK))
@@ -4749,7 +4755,7 @@
if (!newval)
{
res = ERROR_OUTOFMEMORY;
-goto done;
+goto done1;
}
lstrcpyW(newval, value);
@@ -4758,8 +4764,9 @@
TRACE(setting %s to %s\n, debugstr_w(name), debugstr_w(newval));
res = RegSetValueExW(env, name, 0, type, (LPVOID)newval, size);
-done:
+done1:
RegCloseKey(env);
+done2:
msi_free(deformatted);
msi_free(data);
msi_free(newval);
This is uglier than the other patch. The only change needed in this
entire function is to set env to NULL initially. There's nothing
wrong with calling RegCloseKey(NULL-var) and it's done everywhere in
the code base.
--
James Hawkins
Re: Slackware 11: After Wine update applications crash if WINEDEBUG not set
On Saturday 23 June 2007 09:06, Victor wrote:
After upgrading wine (from 0.9.37 to 0.9.38 or from 0.9.38 to 0.9.39 - I'm
not sure) many graphical applications started crashing if WINEDEBUG+=all or
WINEDEBUG+=relay not set.
I was able to find where crash occurs, but didn't yet find why this happens.
I've used one of my own ddraw test applications (written for windows) that
produces same result - crashes if WINEDEBUG+=relay is not set, and works if
it is set. Source code is at the end of message. (If someone need it, I can
send a windows executable since it is 3584 bytes big.)
For Wine - 0.9.39:
When initializing DirectDraw by using DirectDrawCreateEx, DDRAW_Create calls
LoadLibraryA with argument wined3d. Crash occurs during LoadLibraryA call,
not in wined3d, but in ntdll/loader.c, in get_modref() function, at
the return cached_modref = CONTAINING_RECORD(mod, WINE_MODREF, ldr); line.
It looks like (somewhere between LoadLibraryA and get_modref()) there is a
problem with a if (TRACE_ON()), but I'm not sure if this so, and where
should I look for this problem. And I still don't know why it worked before
and suddenly stopped working. Any suggestions about location of this bug?
With best regards, Victor Eremin.
--Test application source code (C++)--
#include windows.h
#include ddraw.h
#include GFSrel.h
//#include _smallapp.h
#define WNDCLASSNAME TEXT(DDrawDraft)
#define WNDCAPTION TEXT(DDraw draft application)
#define HRC(hr, msg) if (FAILED(hr)){MessageBox(0, TEXT(Error!),
TEXT(Error!)/*TEXT(msg)*/, MB_ICONERROR|MB_OK);
OutputDebugString(TEXT(msg)); return;}
static bool g_bRunning = true;
LPDIRECTDRAW7 g_lpDDraw = 0;
LPDIRECTDRAWSURFACE7 g_lpPrimary = 0;
LRESULT WINAPI WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam){
switch(Msg){
case (WM_DESTROY):{
g_bRunning = false;
PostQuitMessage(0);
return 0;
}
default:
return DefWindowProc(hWnd, Msg, wParam, lParam);
}
}
//int WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR, int){
//void WinMainCRTStartup(void){
void entry_point(void){
HINSTANCE hInst = GetModuleHandle(0);
WNDCLASS wc = {
CS_VREDRAW|CS_HREDRAW,
WndProc, 0, 0,
hInst,
LoadIcon(0, IDI_APPLICATION),
LoadCursor(0, IDC_ARROW),
0,//(HBRUSH)GetStockObject(LTGRAY_BRUSH),
0,
WNDCLASSNAME
};
RegisterClass(wc);
HWND hWnd =
CreateWindow(
WNDCLASSNAME,
WNDCAPTION,
WS_POPUP,//OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
0, 0, hInst, 0
);
UpdateWindow(hWnd);
ShowWindow(hWnd, SW_SHOW);
HRESULT hr = DirectDrawCreateEx(0, (LPVOID*)g_lpDDraw,
IID_IDirectDraw7, 0);
HRC(hr, DirectDrawCreateEx);
hr = g_lpDDraw-SetCooperativeLevel(hWnd,
DDSCL_EXCLUSIVE|DDSCL_FULLSCREEN);
HRC(hr, SetCooperativeLevel);
hr = g_lpDDraw-SetDisplayMode(640, 480, 8, 0, 0);
HRC(hr, SetDisplayMode);
DDSURFACEDESC2 surf_desc;
//ZeroMemory((LPVOID*)surf_desc, sizeof(surf_desc));
fill_char((void*)surf_desc, 0, sizeof(surf_desc));
surf_desc.dwSize = sizeof(surf_desc);
surf_desc.dwFlags = DDSD_CAPS|DDSD_BACKBUFFERCOUNT;
surf_desc.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE|DDSCAPS_FLIP|
DDSCAPS_COMPLEX;
surf_desc.dwBackBufferCount = 1;
hr = g_lpDDraw-CreateSurface(surf_desc, g_lpPrimary, 0);
HRC(hr, CreatePrimary);
MSG msg;
while (g_bRunning){
if (PeekMessage(msg, hWnd, 0, 0, PM_REMOVE)){
TranslateMessage(msg);
DispatchMessage(msg);
}
else{
//idle
}
}
if (g_lpDDraw){
g_lpDDraw-RestoreDisplayMode();
}
SREL(g_lpPrimary);
SREL(g_lpDDraw);
UnregisterClass(WNDCLASSNAME, hInst);
//return 0;
}
Re: mshtml: Implement HTMLElement_get_children.
Hi,
+elem_vector buf = {NULL, 0, 8};
+
+TRACE((%p)-(%p)\n, This, p);
+
+buf.buf = mshtml_alloc(buf.size*sizeof(HTMLElement**));
elem_vector is a self-resizable table, but in this case you know the size while
creating it from nsIDOMNodeList::GetLength. I'd suggest to use it here during
creation of buf to avoid useless memory reallocations.
Thanks,
Jacek
Re: mshtml: Implement HTMLDocument_QueryInterface for IHTMLDOMNode, IHTMLElement and IHTMLElement2.
Hi, I've just sent a test showing that native doesn't implement these interfaces so we shouldn't either. It's strange because IDL declaration says something else. And BTW. your patch violates COM QueryInterface rules (not that MS always respects these rules...). Thanks, Jacek
Re: wine menus
Damjan Jovanovic wrote:
Hi
At the moment, wine builds fd.o menus by calling winemenubuilder and
wineshelllink when shell32's IPersistFile_fnSave is invoked. This both
misses menus copied directly into the menu directory without calling
IPersistFile_fnSave, and provides no way to remove the menus when the
app is uninstalled.
Installers that doing this sort of stuff are broken by design. They usually
don't work well/at all on different language systems. Or the pre-made .lnk
files won't work if app is installed into different location.
Is it possible to add a new utility, or patch an existing utility like
wineboot, to synchronize between wine's .lnk files in the windows
directory and the fd.o menus, instead of using
winemenubuilder/wineshelllink? Would a patch that does that be okay?
All you really need to synchronize is something like this:
find ~/.wine/drive_c/ -name *.lnk -exec wine winemenubuilder '{}' \;
However this is one-way and it won't remove uninstalled links (which is
pretty easy to add). But this still does not account for number of things:
1. Desktop entries (they are tricky - winemenubuilder uses some magic to
decide if the link should be placed on the desktop or menu).
2. Multiple WINEPREFIXes
3. User modified .desktop entries (added extra parameters, env variables, etc.)
4. User (re)moved Wine menu entries using KDE/Gnome/etc menu editor(s). I
can see this can be a huge annoyance when user deletes something and it's
coming back.
I think what you can do, is to move location where Wine creates it's XDG
links and menu structure somewhere under WINEPREFIX itself. Not sure if this
would help or not. Most installers won't remove directories if they are not
empty, even if created during the install.
Vitaliy.
WIDL: Implement support for explicit user handles
This patch implements support for explicit user handles.
Regards
Eric Kohl
ChangeLog:
Implement support for explicit user handles.
diff --git a/tools/widl/client.c b/tools/widl/client.c
index 86ead20..6a84e94 100644
--- a/tools/widl/client.c
+++ b/tools/widl/client.c
@@ -89,12 +89,14 @@ static void write_function_stubs(type_t *iface, unsigned
int *proc_offset)
{
const var_t *def = func-def;
const var_t* explicit_handle_var;
+const var_t* explicit_user_handle_var;
/* check for a defined binding handle */
explicit_handle_var = get_explicit_handle_var(func);
+explicit_user_handle_var = get_explicit_user_handle_var(func);
if (explicit_handle)
{
-if (!explicit_handle_var)
+if (!explicit_handle_var !explicit_user_handle_var)
{
error(%s() does not define an explicit binding handle!\n,
def-name);
return;
@@ -102,7 +104,7 @@ static void write_function_stubs(type_t *iface, unsigned
int *proc_offset)
}
else if (implicit_handle)
{
-if (explicit_handle_var)
+if (explicit_handle_var || explicit_user_handle_var)
{
error(%s() must not define a binding handle!\n, def-name);
return;
@@ -167,6 +169,19 @@ static void write_function_stubs(type_t *iface, unsigned
int *proc_offset)
print_client(_Handle = %s;\n, explicit_handle_var-name);
fprintf(client, \n);
}
+else if (explicit_user_handle_var)
+{
+print_client(_Handle = %s_bind(%s);\n,
+ explicit_user_handle_var-type-name,
+ explicit_user_handle_var-name);
+print_client(if (_Handle == 0)\n);
+print_client({\n);
+indent++;
+print_client(RpcRaiseException(RPC_S_INVALID_BINDING);\n);
+indent--;
+print_client(}\n);
+fprintf(client, \n);
+}
write_remoting_arguments(client, indent, func, PASS_IN,
PHASE_BUFFERSIZE);
@@ -240,6 +255,19 @@ static void write_function_stubs(type_t *iface, unsigned
int *proc_offset)
print_client(NdrFreeBuffer((PMIDL_STUB_MESSAGE)_StubMsg);\n);
+if (explicit_user_handle_var)
+{
+fprintf(client, \n);
+print_client(if (_Handle)\n);
+print_client({\n);
+indent++;
+print_client(%s_unbind(%s, _Handle);\n,
+ explicit_user_handle_var-type-name,
+ explicit_user_handle_var-name);
+indent--;
+print_client(}\n);
+}
+
indent--;
print_client(}\n);
print_client(RpcEndFinally\n);
diff --git a/tools/widl/header.c b/tools/widl/header.c
index 6f2da32..1119542 100644
--- a/tools/widl/header.c
+++ b/tools/widl/header.c
@@ -463,6 +463,21 @@ const var_t* get_explicit_handle_var(const func_t* func)
return NULL;
}
+const var_t* get_explicit_user_handle_var(const func_t* func)
+{
+const var_t* var;
+
+if (!func-args)
+return NULL;
+
+LIST_FOR_EACH_ENTRY( var, func-args, const var_t, entry )
+if ((var-type-type != RPC_FC_BIND_PRIMITIVE)
+is_attr(var-type-attrs, ATTR_HANDLE))
+return var;
+
+return NULL;
+}
+
int has_out_arg_or_return(const func_t *func)
{
const var_t *var;
@@ -480,6 +495,40 @@ int has_out_arg_or_return(const func_t *func)
return 0;
}
+static struct list user_handle_list = LIST_INIT(user_handle_list);
+
+struct user_handle
+{
+struct list entry;
+char name[1];
+};
+
+void add_user_handle(type_t *type)
+{
+struct user_handle *uh;
+
+if (is_attr(type-attrs, ATTR_HANDLE))
+{
+uh = (struct user_handle *)xmalloc(sizeof(struct user_handle) +
strlen(type-name));
+if (uh)
+{
+strcpy(uh-name, type-name);
+list_add_tail(user_handle_list, uh-entry);
+}
+}
+}
+
+void write_user_handles(void)
+{
+const struct user_handle *uh;
+
+LIST_FOR_EACH_ENTRY(uh, user_handle_list, struct user_handle, entry)
+{
+fprintf(header, handle_t __RPC_USER %s_bind(%s);\n, uh-name,
uh-name);
+fprintf(header, void __RPC_USER %s_unbind(%s, handle_t);\n,
uh-name, uh-name);
+}
+}
+
/** INTERFACES **/
@@ -710,6 +759,7 @@ static void write_function_protos(const type_t *iface)
const char *implicit_handle = get_attrp(iface-attrs, ATTR_IMPLICIT_HANDLE);
int explicit_handle = is_attr(iface-attrs, ATTR_EXPLICIT_HANDLE);
const var_t* explicit_handle_var;
+ const var_t* explicit_user_handle_var;
const func_t *cur;
int prefixes_differ = strcmp(prefix_client, prefix_server);
@@ -720,13 +770,19 @@ static void write_function_protos(const type_t *iface)
/* check for a defined binding handle */
Re: Slackware 11: After Wine update applications crash if WINEDEBUG not set
On 6/24/07, Victor [EMAIL PROTECTED] wrote: On Saturday 23 June 2007 09:06, Victor wrote: After upgrading wine (from 0.9.37 to 0.9.38 or from 0.9.38 to 0.9.39 - I'm not sure) many graphical applications started crashing if WINEDEBUG+=all or WINEDEBUG+=relay not set. Please file a bug report and do a regression test. I was able to find where crash occurs, but didn't yet find why this happens. I've used one of my own ddraw test applications (written for windows) that produces same result - crashes if WINEDEBUG+=relay is not set, and works if it is set. Source code is at the end of message. (If someone need it, I can send a windows executable since it is 3584 bytes big.) I can't compile your program to verify on my slackware system.
fix for wine 0.9.24 segfault on startup
Hi On Ubuntu 7.04, versions of wine before around 0.9.24 die on startup with an undebuggable segmentation fault. After this bug stopped me from doing 2 regression tests, I decided to reverse regression test for the fix to the bug, and I found that the patch at http://www.winehq.org/pipermail/wine-cvs/2006-November/027508.html allows earlier versions of wine to run successfully. Thought this might be helpful to others Damjan
VST wrapper
Hi, I'm interested in the goal of using Windows VST/VSTi audio plugins on my Intel Mac in OS X. I found the fst project, did some porting, and managed to get a few VSTs to work, which had me pretty stoked. Thanks to the FST folks and the Wine team for making this possible! On the other hand, I'd rather have the option of running the plugins in-process with my DAW software instead of as separate processes connected by JACK. I can imagine a super-thin layer of code that just translates calls between the plugin and the host and allows the plugin to access the Win32 API. In case I'm being unclear, here's how it breaks down. There's a host application that's native OS X and knows nothing about Wine. I'd like to write a plugin that, when it's loaded, will load a windows dll. The host will call into the plugin, which will call into the dll. The dll will make upcalls to the plugin, which will in turn call up to the host. The dll will probably be running a windows gui as well and making calls to various windows APIs. So is this possible? I'm pretty new to Wine and Windows programming so forgive me if the answer to this question is obvious. I've seen plenty of examples of how to build and run .exes that are windows programs from the ground up, but I've never seen wine used as part of a plugin. If it's possible, can you point me to any examples? What are the relevant parts of Wine I should look at? Thanks, -n8 -- -- Nathaniel Gray -- Caltech Computer Science -- -- Mojave Project -- http://mojave.cs.caltech.edu --
Re: VST wrapper
By the way, please CC me with replies. I'm not set up to receive mail from the list. Thanks, -n8 -- -- Nathaniel Gray -- Caltech Computer Science -- -- Mojave Project -- http://mojave.cs.caltech.edu --
