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

DllCanUnloadNow for dlls/msi
by Christian Gmeiner Nov. 30, 2005

Nov. 30, 2005

Hi all. I want to start coding for wine and therefore i have wirtten my first patch to add DllCanUnloadNow to msi. Now i need to test my patch. I have got the hint that i must create a COM object that msi.dll provides. Then the following must happen: try calling DllCanUnloadNow, and it should fail then ->Release() the object, and DllCanUnloadNow should succeed Can somebody give me some links or maybe a litte source to make such a test? Thanks, Christian -- Christian Gmeiner - student of computer science http://dxr3plugin.sf.net http://itb04.ath.cx

2 1

Monochrome bitmaps again
by Oldrich Jedlicka Nov. 30, 2005

Nov. 30, 2005

Hi all, again I go here to ask what is wrong with my patch sent on 23 Nov 2005 to wine-patches (still not in CVS). The problem with monochrome bitmaps with inverted colors was discovered in game "Neighbours from Hell". I tested the patch with simulated inverted colors monochrome bitmap and it is working perfectly. Also the game is working fully. I do not see any reason why it was (probably) ignored again (last time there was a hidden compile problem). Find attached patch. Regards, Oldrich.

2 2

creating the .so for multiple DLL's
by Ananth M Nov. 30, 2005

Nov. 30, 2005

Hi All, I am having a windows application that uses a Third Party DLL (let me call is at First.dll ), which uses internally another 3rd party DLL (let me call this as Second.dll). I am not having the equivalant .so files in the Linux version. If I want to use my application in Windows, then I am thinking two possible solutions: 1) Compile and build the executable in windows and run it on Linux using wine 2) Build the .so for the DLL's (First.dll and Second.dll) that are used by the application, and link to this .so from the Linux environment. If I want use the second approch, then, - DO I need to build to seperate .so files ? or can I combine them into Single .so file using winedump tool and forward dll's mechonism? - Is there any other tool available in Wine , otherthan winedump that deals with this kind of requirement more effectively? If any one had already tried this kind of problem, then can you please send me the steps or information on how to - Thank you Regards Ajay

1 0

Re: Add missing FreeLibrary calls
by Alexandre Julliard Nov. 30, 2005

Nov. 30, 2005

James Hawkins <truiken(a)gmail.com> writes: > Index: dlls/gdi/tests/gdiobj.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/tests/gdiobj.c,v > retrieving revision 1.10 > diff -u -p -r1.10 gdiobj.c > --- dlls/gdi/tests/gdiobj.c 26 Oct 2005 10:10:23 -0000 1.10 > +++ dlls/gdi/tests/gdiobj.c 29 Nov 2005 04:25:18 -0000 > @@ -274,9 +274,13 @@ static void test_GdiGetCharDimensions(vo > LONG ret; > SIZE size; > LONG avgwidth, height; > + HMODULE hGDI; > static const char szAlphabet[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"; > typedef LONG (WINAPI *fnGdiGetCharDimensions)(HDC hdc, LPTEXTMETRICW lptm, LONG *height); > - fnGdiGetCharDimensions GdiGetCharDimensions = (fnGdiGetCharDimensions)GetProcAddress(LoadLibrary("gdi32"), "GdiGetCharDimensions"); > + fnGdiGetCharDimensions GdiGetCharDimensions; > + hGDI = LoadLibrary("gdi32"); > + GdiGetCharDimensions = (fnGdiGetCharDimensions)GetProcAddress(hGDI, "GdiGetCharDimensions"); > + FreeLibrary(hGDI); You can't free libraries that will be called later on. And there's no reason to free anything in tests, everything is freed on exit anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [DbgHelp]: StackWalk64.
by Alexandre Julliard Nov. 30, 2005

Nov. 30, 2005

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > ChangeLog: > - implemented StackWalk64 (reusing StackWalk) You should really reuse it, not just duplicate such a big chunk of code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Question about current Shell Folder registry settings...
by Markus G�mmel Nov. 30, 2005

Nov. 30, 2005

Hello, HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/ShellFolders has the following settings on a freshly installed system after first calling wine: AppData c:\windows\profiles\mgoemmel\Application Data Cookies c:\windows\profiles\mgoemmel\Cookies Desktop z:\home\mgoemmel\Desktop Favorites c:\windows\profiles\mgoemmel\Favorites ... Personal z:\home\mgoemmel ... StartMenu c:\windows\profiles\mgoemmel\Start Menu Can anybody tell me why "Desktop" is set to Z: instead of set to "c:\windows\profiles\mgoemmel\Desktop"? And as a second question: would it be ok to add "My Music", "My Pictures" and "My Video" to this registry key? I would do this if anybody would agree that it's ok, and would send the necessary patches. Some if my programs blames me about these three missing values. If yes, where should it point to? z:\home\mgoemmel\My Music? Or would it be not much better to also point "Personal" to "c:\windows\profiles\mgoemmel\My Documents" too? Thanks for any answers and/or discussions... Markus Goemmel m.goemmel(a)compulab.de

2 2

Re; Question about current Shell Folder registry settings...
by Juan Lang Nov. 30, 2005

Nov. 30, 2005

Hi Markus, > Desktop z:\home\mgoemmel\Desktop (snip) > Can anybody tell me why "Desktop" is set to Z: instead of set > to "c:\windows\profiles\mgoemmel\Desktop"? Because this (z:\home\mgoemmel\Desktop) is the location of your Linux desktop. If you save stuff to "Desktop," you expect it to appear there, yes? Perhaps this shouldn't be done inside shell32 (where it currently is), but in winecfg instead. The trouble of course is that winecfg isn't run during installation. There was a patch that ran winecfg in an install mode from wineprefixcreate, had it gone in this would be possible. > And as a second question: would it be ok to add "My Music", > "My Pictures" and "My Video" to this registry key? I would do > this if anybody would agree that it's ok, and would send the > necessary patches. Some if my programs blames me about these > three missing values. If an app depends on them, then yes, by all means do. > If yes, where should it point to? z:\home\mgoemmel\My Music? > Or would it be not much better to also point "Personal" to > "c:\windows\profiles\mgoemmel\My Documents" too? Several questions in one here! Well, since Linux doesn't really have a "My Music" folder, I think it makes sense just to point it to the same place as "Personal," wherever that is. That, in turn, defaults to ~, since that is the closest thing to a "My Documents" directory in Linux. Incidentally, if you don't like the defaults, you can always change them. Just be sure to change them in "User Shell Folders" rather than "Shell Folders," the latter is deprecated and is treated as read-only (by both MS and Wine.) --Juan __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 1

Re: Dereferencing a pointer in winedbg
by Eric POUECH Nov. 30, 2005

Nov. 30, 2005

http://www.winehq.org/hypermail/wine-devel/2005/03/0219.html (not sure it still applies cleanly, at least some tiny parts are now in CVS tree) A+ > Message du 30/11/05 05:13 > De : "Vitaliy Margolen" > A : "Eric Pouech" > Copie à : wine-devel(a)winehq.org > Objet : Re: Dereferencing a pointer in winedbg > > Monday, November 28, 2005, 2:33:35 PM, Eric Pouech wrote: > > Vitaliy Margolen wrote: > >> Sunday, November 27, 2005, 10:50:39 PM, Marcus Meissner wrote: > >> > >>>On Sun, Nov 27, 2005 at 06:35:15PM -0700, Vitaliy Margolen wrote: > >>> > >>>>Is it possible to dereference a pointer in winedbg? Help says that > >>>>"*$eax" is a valid expression. But when I'm trying to use it it saying: > >>>>Wine-dbg>p *$eax > >>>>No type or type mismatch > >>>> > >>>>Is there are a way to do this? > >>> > >>>(x aka examine memory) > >>> > >>>x $eax > >>> > >>>Ciao, Marcus > >> > >> > >> Well I need to add that to display. Something like: display/x *$eax > >> Doing x $eax and then x 100s times kind of hard. > > > display /x means (in gdb) formatting differently the output, not > > dereferencing the (so called) pointer (display is a repeated 'p' > > command, not a 'x' one). > Yes I know. I meant /x for hex not decimal. > > > what you'd need is support for type casts and use something like: > > display *(int*)$eax > Yes correct. That's exactly what I need. > > > I sent a couple of months ago a patch for winedbg that (partly) > > implemented the support for typecasts in wine. You should look for it. > Could you please point me to it? I've spent last hour or so trying to > find it. > > Vitaliy. > > > > > > > > >

1 0

riched20: register ListBox & ComboBox classes
by Cihan Altinay Nov. 30, 2005

Nov. 30, 2005

Hi, > This patch partially implements the undocumented REExtendedRegisterClass() > function by registering the two missing classes. That way MS Office 2003 and > probably other programs that rely on these classes display dialogs > completely which were empty before. > > Changelog: > Cihan Altinay <cihan(a)uq.edu.au> > Partially implement REExtendedRegisterClass() to register missing window > classes so that applications relying on them don't get confused. > It seems this patch was ignored and I would appreciate some comments because I haven't done much wine development yet (and probably made a lot of mistakes). Basically, I did some reverse engineering to see what is going on under Windows and implemented the (de)registration of the two classes accordingly. The effect of the patch can be seen in the attached screenshots which is the Options dialog of MS PowerPoint 2003. I agree that a patch that makes the controls actually work would be better :-) Cheers, Cihan

1 0

Re: Implement symbolic link object in wineserver.
by Robert Shearman Nov. 29, 2005

Nov. 29, 2005

Hi Vitaliy, This patch looks pretty good, but needs some finishing touches. Are you planning to continue the directory work to get objects to start supporting it? Vitaliy Margolen wrote: >diff --git a/server/object.h b/server/object.h >index 0c2ee1a..1154e0a 100644 >--- a/server/object.h >+++ b/server/object.h >@@ -193,6 +193,11 @@ extern obj_handle_t open_object_dir( str > extern void init_directories(void); > extern void close_directories(void); > >+/* sybmolic link functions */ >+ >+extern void init_syboliclinks(void); >+extern void close_syboliclinks(void); > > Multiple spelling mistakes. >+ > /* global variables */ > > /* command-line options */ > > >diff --git a/server/symlink.c b/server/symlink.c >new file mode 100644 >index 0000000..5a07df3 >--- /dev/null >+++ b/server/symlink.c >@@ -0,0 +1,225 @@ >+/* >+ * Server-side symbolic link object management >+ * >+ * Copyright (C) 2005 Vitaliy Margolen >+ * >+ * This library is free software; you can redistribute it and/or >+ * modify it under the terms of the GNU Lesser General Public >+ * License as published by the Free Software Foundation; either >+ * version 2.1 of the License, or (at your option) any later version. >+ * >+ * This library is distributed in the hope that it will be useful, >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >+ * Lesser General Public License for more details. >+ * >+ * You should have received a copy of the GNU Lesser General Public >+ * License along with this library; if not, write to the Free Software >+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA >+ * >+ */ >+ >+#include "config.h" >+#include "wine/port.h" >+ >+#include <assert.h> >+#include <stdarg.h> >+#include <stdlib.h> >+#include <stdio.h> >+#include <sys/types.h> >+ >+#include "ntstatus.h" >+#define WIN32_NO_STATUS >+#include "winternl.h" >+#include "ddk/wdm.h" >+ >+#include "handle.h" >+#include "request.h" >+#include "object.h" >+#include "unicode.h" >+ >+struct syboliclink >+{ >+ struct object obj; /* object header */ >+ struct unicode_str target; /* target of the symlink */ >+}; > > Spelling mistake. In the server the name of the object struct typically mirrors the name of the file. So in this case it would be "struct symlink" >+ >+static void syboliclink_dump( struct object *obj, int verbose ); >+static struct object *symlink_lookup_name( struct object *obj, struct unicode_str *name, >+ unsigned int attr ); >+static void syboliclink_destroy( struct object *obj ); > > Spelling mistakes and lack of consistency with the naming. They should have the name of the object as a prefix: symlink_dump, symlink_lookup_name, symlink_destroy. >+struct syboliclink *create_syboliclink( struct directory *root, const struct unicode_str *name, >+ unsigned int attr, const struct unicode_str *target ) > > Spelling mistake again. Also, should match whatever name is decided for the name of the object. >+ >+/* Global initialization */ >+ >+static struct syboliclink *link_dosdev, *link_global1, *link_global2, *link_local; >+ >+void init_syboliclinks(void) >+{ >+ static const WCHAR dir_globalW[] = {'\\','?','?'}; >+ static const WCHAR dir_basenamedW[] = {'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s'}; >+ static const struct unicode_str dir_global_str = {dir_globalW, sizeof(dir_globalW)}; >+ static const struct unicode_str dir_basenamed_str = {dir_basenamedW, sizeof(dir_basenamedW)}; >+ >+ static const WCHAR link_dosdevW[] = {'\\','D','o','s','D','e','v','i','c','e','s'}; >+ static const WCHAR link_global1W[] = {'\\','?','?','\\','G','l','o','b','a','l'}; >+ static const WCHAR link_global2W[] = {'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s','\\','G','l','o','b','a','l'}; >+ static const WCHAR link_localW[] = {'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s','\\','L','o','c','a','l'}; >+ static const struct unicode_str link_dosdev_str = {link_dosdevW, sizeof(link_dosdevW)}; >+ static const struct unicode_str link_global1_str = {link_global1W, sizeof(link_global1W)}; >+ static const struct unicode_str link_global2_str = {link_global2W, sizeof(link_global2W)}; >+ static const struct unicode_str link_local_str = {link_localW, sizeof(link_localW)}; >+ >+ link_dosdev = create_syboliclink( NULL, &link_dosdev_str, 0, &dir_global_str ); >+ link_global1 = create_syboliclink( NULL, &link_global1_str, 0, &dir_global_str ); >+ link_global2 = create_syboliclink( NULL, &link_global2_str, 0, &dir_basenamed_str ); >+ link_local = create_syboliclink( NULL, &link_local_str, 0, &dir_basenamed_str ); >+} >+ >+void close_syboliclinks(void) >+{ >+ release_object( link_dosdev ); >+ release_object( link_global1 ); >+ release_object( link_global2 ); >+ release_object( link_local ); >+} > > It would probably be nicer to have all of the namespace initialisation done in one place, e.g. directory.c That would mean exporting the create_symlink function, but then init_symboliclinks and close_symboliclinks would no longer have to be exported. >+ >+ >+/* create a symbolic link object */ >+DECL_HANDLER(create_symlink) >+{ >+ struct syboliclink *symlink; >+ struct unicode_str name, target; >+ struct directory *root = NULL; >+ >+ get_req_unicode_str( &name ); >+ target.str = name.str + req->symlink_name_len / sizeof(WCHAR); >+ target.len = name.len - req->symlink_name_len; >+ name.len = req->symlink_name_len; >+ >+ if (req->rootdir && !(root = get_directory_obj( current->process, req->rootdir, 0 ))) >+ return; > > Does NT really allow you to open a directory without having any specific access rights? -- Rob Shearman

2 1