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
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
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
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?
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 :)
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
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
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
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
