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

winecfg's registry convience functions
by Michael Jung June 23, 2005

June 23, 2005

I would like to add a checkbox control ("Show host filesystem") to winecfg to allow the user to easily (un-)register the unixfs shell namespace extension. So winecfg would have to query and create/delete the "HKLM\Software\Microsoft\CurrentVersion\Explorer\MyComputer\Namespace\{UNIXFS-CLSID}" key. There are helper functions in winecfg.c to cache registry values for later application, iff the user clicks "Apply" or "Ok". However, those seem to work only for keys rooted at the config key "HKCU\Software\Wine". My question is: Am I doomed to implement the caching on my own for this key, should I generalize the helper functions, or do you think this configuration option should'nt be in winecfg at all? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 7

Cross-compiling with winelib
by Eric Frias June 23, 2005

June 23, 2005

We're working on setting up an environment to cross-compile a winelib application (initially from x86 linux to sparc solaris). To do this, we need a cross-compiling version of winebuild which will generate the assembly code for the target architecture instead of the build architecture. I see two basic ways we can accomplish this. We could either use autoconf's --target flag to specify the target architecture, and then replace all of the "#ifdef __sparc__" statements in winebuild with "#ifdef __target_arch_sparc". I came across an autoconf macro (http://autoconf-archive.cryp.to/ac_create_target_h.html) that would generate the appropriate defines. The other way we could approach the problem is to modify winebuild to always generate assembly code for all of the architectures, pushing the #ifdefs down into the .spec.c file. I'm inclined to stick with the first option, since it looks like less work and less chance of introducing errors, but I wanted to run it by the list before starting work. Would a patch like this be accepted into wine? Do you know of any other gotchas we should be aware of? Thanks, Eric

2 2

Re: COMDLG32: PageSetupDlg improvements
by Alexandre Julliard June 23, 2005

June 23, 2005

Vitaly Lipatov <lav(a)etersoft.ru> writes: > +#define CALLANYPAINTHOOK(msg, wParam, lParam) \ > + (((pda->dlga->Flags & PSD_ENABLEPAGEPAINTHOOK) && \ > + pda->dlga->lpfnPagePaintHook(hWnd,msg,wParam,lParam)) || \ > + PRINTDLG_DefaultPagePaintHook(hWnd,msg,wParam,lParam)) It would be a lot cleaner to always call your DefaultPagePaintHook function and have it call the user's hook first if it's set. > + if (CALLANYPAINTHOOK(WM_PSD_PAGESETUPDLG, MAKELONG(papersize, orientation), (LPARAM)pda)) > + return FALSE; The LPARAM should probably be pda->dlga here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advapi32: Implement ImpersonateNamedPipeClient
by Dmitry Timoshkov June 23, 2005

June 23, 2005

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog > * Implement ImpersonateNamedPipeClient. > @@ -871,9 +871,13 @@ BOOL WINAPI InitializeAcl(PACL acl, DWOR > > BOOL WINAPI ImpersonateNamedPipeClient( HANDLE hNamedPipe ) > { > - FIXME("%p - stub\n", hNamedPipe); > + PIO_STATUS_BLOCK pio = NULL; > > - return FALSE; > + TRACE("(%p)\n", hNamedPipe); > + > + return set_ntstatus( NtFsControlFile(hNamedPipe, NULL, NULL, NULL, pio, > + CTL_CODE(FILE_DEVICE_NAMED_PIPE, 7, METHOD_BUFFERED, FILE_ANY_ACCESS), > + NULL, 0, NULL, 0) ); > } What's the purpose of introducing PIO_STATUS_BLOCK pio if you don't actually use it? -- Dmitry.

1 0

winefile: switch to UNICODE mode
by Martin Fuchs June 23, 2005

June 23, 2005

Changelog: switch winefile to UNICODE mode Why did I declare a new macro $(PREINCL) and insert it into Make.rule.in ? To allow inserting the include directory <include/msvcrt> before <include>. Another way would be to change the following line in Make.rule.in and move $(EXTRAINCL) before -I$(TOPSRCDIR)/include: INCLUDES = -I$(SRCDIR) -I. $(EXTRAINCL) -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include Why did I remove the following from include/tchar.h? #if defined(_UNICODE) || defined(_MBCS) #error You must use msvcrt when building in Unicode/MBCS mode #endif Because it's just crazy - a few lines later _UNICODE and _MBCS are used to build the A/W mapping macros: /***************************************************************************** * tchar mappings */ #ifndef _UNICODE # ifndef _MBCS # include <string.h> # define WINE_tchar_routine(std,mbcs,unicode) std # else # include <mbstring.h> # define WINE_tchar_routine(std,mbcs,unicode) mbcs # endif #else /* _UNICODE */ # include <wchar.h> # define WINE_tchar_routine(std,mbcs,unicode) unicode #endif If _UNICODE and _MBCS would not be allowed to be used in <tchar.h> at all, what would be the sense of the whole file?

5 10

40tude dialog suddenly broken in latest cvs...
by zhilla June 22, 2005

June 22, 2005

well, i compile wine from cvs every couple of days. 40tude dialog has been working nicely for ages now, accept for minor annoyances. but today... blam. err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2 err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program Files\\40tude Dialog\\dialog.exe" failed, status c0000142 well, i did once copy comctl32 and commctrl.dll from 98se to 40tude directory, so i deleted it and now it works again. as usual, when it works, it says only stuff like... err:ole:CoGetClassObject class {4657278a-411b-11d2-839a-00c04fd918d0} not registered err:ole:CoGetClassObject class {4657278a-411b-11d2-839a-00c04fd918d0} not registered err:x11drv:X11DRV_CreateWindow invalid window height -3 err:x11drv:X11DRV_CreateWindow invalid window height -3 while i'm at it, let me just say couple more problems with it: -in xfce, no task bar icon. i try to dock it into tray with kdocker, it says that "it does not appear to be normal window". hmm... -if there already is an instance of wine running (any other wine program), it does show it in taskbar. still, kdocker does not seem to like it. and if i click couple of times on it in taskbar, File...Edit... bar on 40tude dissapears! funny, funny. -compose window behaves weird. see, there's a line at the bottom that marks real end of the post - so you dont post whitespace. but it, and under it, is not refreshed properly. for example, try to delete part of follow up text, so that line comes above last text. it stays there. and line is gone... otherwise, program works mostly good... damn people, this is clearly "near gold program", needs just some tweaking :)

1 0

system wide file lock server
by Vitaly Lipatov June 22, 2005

June 22, 2005

And again about standalone (system wide) file lock server. WINE provides file locking capabilities, its realized in ntdll -> wineserver. I propose light solution for multiuser lock support - start existing wineserver as independent service under special user and use it specially for file locking purposes. What the objective reasons do not do so? It can be realized with the same code as already exist in wineserver. We can disable this mode during compiling (it depends how we realized wine_server_call special for file related functions). Any suggestions? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

1 0

Re: winefile: switch to UNICODE mode
by Ralf Reiterer June 22, 2005

June 22, 2005

Hi, > The pure existence of <include/tchar.h> in the Wine code base > shows me, Wine is aimed to support TCHARs. So why don't you > want to properly activate its functionality and take Winefile > as an example how to use it? > ... > I know, I won't be able to convince you. Any one out there to > support my point of view? ;-) the whole existance of the TCHAR type and associated functions is to allow applications to be portable between ANSI and Unicode and therefore avoid ugly #ifdefs for distinguishing between ANSI and Unicode. As it is part of the Platform SDK at least since Windows 95 was released, I'm sure many Win32 applications (still) rely on the TCHAR type. At least the MFC library and ATL does and hence all MFC/ATL based applications rely on that type too. So I really think Wine has to support the TCHAR type and all associated functions/macros to stay as close to the Windows API as possible. And since it helps to avoid #ifdefs in application source, I think that's a strong argument not to eliminate it from Winelib (includes). Maybe these arguments help to convince you, Alexandre. ;-) Regards Ralf

3 3

Memory problem in winelib apps?
by Walt Ogburn June 22, 2005

June 22, 2005

Hi developers, I'm trying to understand why the following simple program crashes. I think this is the same problem that prevents jack_fst from running with the current version of wine. (Jack_fst allows a lot of programs called VSTs to be run, for audio work). I compiled this with: > winemaker . > make and ran it with: > wine membug.exe.so If BUFSIZE is 1044097, there's an error like this: err:seh:setup_exception stack overflow 12 bytes in thread 0009 eip 4057426f esp 40580ff4 stack 0x40580000-0x40680000 If BUFSIZE is 1044096 or lower, there's no error. If BUFSIZE is much higher (like 2000000), there's a segfault. All the program does is define a character array of size BUFSIZE and scribble in it to make sure it really gets allocated. Maybe this simple example will show how to make jack_fst work. Thanks, Walter

5 6

Wine's Registry Format
by Brad June 22, 2005

June 22, 2005

There's a bug on bugzilla (422) that asks for the registry file format to be re-written in order to be able to dynamically load parts of the registry. If you don't feel like looking it up - don't worry, I'm going to explain why this would benefit wine. . . It's said that wine loads the entire registry when it first runs, which can get become a waste - even if it's going to be swapped off anyway. . . It's also not the fastest method of input and especially output to the registry. . . I've looked into using a Balanced Tree DB from BerkelyDB as a quicker interface to the registry. . . I think it would be a good solution, but the question is whether or not you want the overhead of another library added to wine. . . That's why I'm writing here actually - I need to know if it's ok to add this dependancy to wine, or if I should find a different approach. I know this would cause some chaos in the community - so If this is something that everyone agrees should be done, I'll write a small utility to convert the current ascii registry files into the new format. . . Let me know what you think . . . --Brad DeMorrow

5 5