Re: Wine's Registry
2005/6/19, James Liggett [EMAIL PROTECTED]: Hi Brad, I've been following you discussion about wine's registry format, and I find it interesting. I gave it some thought, I have have an idea. Have you thought about using XML as a potential format? Since the registry is a non-relational tree database, this seems to fit quite well. Plus, there's a few libraries that would do the dirty work for us (libxml, expat, many others, name your pick). It could even be possible to modularize the registry using technologies like XInclude or XLink. Just thought I'd offer my two cents. Sure, the tree format would match. But this would not really make things better. You would also have to read the registry at once at startup time. The best solution would be to use native Windows registry format. This way you could use real Windows registry files, and can read and update registry piecewise. It's organized like a little file system - or database if you want to see it this way. It's not documented. But you could have a look at the ReactOS implementation, which claimes to be compatible to NT4. Regards, Martin
Re: Crashes due to OGL
On Monday 20 June 2005 04:18, Robert Lunnon wrote: I see the following X error (After fixing a bug in utah GLX) trace:ddraw:initialize enabling DirectDraw HAL trace:ddraw:d3ddevice_init_at_startup Initializing GL... @@Created GLX Context.. X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x21 Serial number of failed request: 7282 Current serial number in output stream: 7283 send_thread_signal 15 According to my GL log this request looks for visual 33 (IE vid=33) this is a non GL visual since utah GLX is allocating visuals 55 up on my system. I don't exactly know why wine should be trying to Create a GL context from a non GL visual but there you are... Bob Hi, seems more a ddraw problem on way how glx context is created :) can you try d3d8 games to see if it works better ? Regards, Raphael pgpUGGIInObl9.pgp Description: PGP signature
Re: World of Warcraft
Hi, On Friday 17 June 2005 16:12, Mike Hearn wrote: On Thu, 16 Jun 2005 09:44:34 +0200, Raphael wrote: Well cedega seems to have the same problem (google) and they fixed it using specific memory layout for WoW (mmap begins at 0x1000) Seems more a WoW bug than wine/cedega bug :) Yes, it's a WoW bug, some Windows users are affected too. Unfortunately it seems very few Windows users hit the problem but all Linux/Wine users see it. Yes seems a strange WoW optimization :) I don't want to do ugly hack to ovveride memory layout so if any wine memory layout expert can look why it happened (Alexandre ?) There's something else going on here, the Cedega fix doesn't seem to work for everybody. Well, I don't think Alexandre has a WoW account or copy and there isn't enough information here to see what's going on. It's odd that seems VM layout related though. as me, i haven't a WoW account but seems that WoW do some checks using presumption on VM layout (and wine VM layout is really different) The issue looks like it's in OpenGL though, their 1.5 patch hotfix is a replacement of the opengl32 DLL. 1.5.O WoW patch used to work (with my openGL patces to get 1.4.1 working) we are speaking about 1.5.1 problem thanks -mike Regards, Raphael pgp6C187YQDdD.pgp Description: PGP signature
Re: World of Warcraft
Hi, Hopefully somebody will figure this one out. If not maybe a trip to the local games shop is in order :) lol what about asking blizzard support :) thanks -mike Regards, Raphael pgpPMvZ8VJLuB.pgp Description: PGP signature
Re: World of Warcraft
Hi, On Mon, Jun 20, 2005 at 09:34:52AM +0200, Raphael wrote: Hi, Hopefully somebody will figure this one out. If not maybe a trip to the local games shop is in order :) lol what about asking blizzard support :) I'd really recommend doing exactly that. Those game publishers'd better get used to us having issues with their awkward patches all the time ;) That way they might go as far as testing it on Wine themselves before release or mailing it to interested Wine people beforehand. We need to get on the radar of those companies... Andreas Mohr
Re: Guild Wars
Hi,
On Sun, Jun 19, 2005 at 04:38:25PM -0500, Robert Shearman wrote:
This is fixed by patch OLE #81a (Part 1) if it gets committed.
It will then output:
err:ole:CoGetClassObject class {a65b8071-3bfe-4213-9a5b-491da4461ca7}
not registered
Wow, that was FAST! (hmm, or was your patch before my mail? don't remember)
It's only a semi-fix, though, since IMHO it should output something like:
err:ole:CoGetClassObject class {a65b8071-3bfe-4213-9a5b-491da4461ca7}
not registered - try running regsvr32 on the container DLL of this CLSID value!
which:
- mentions regsvr32
- mentions that an unregistered DLL is involved
And thus is an actually useful error message (to clueless endusers, that is).
Andreas Mohr
Wine on LinuxTag 2005
Hello guys, the LinuxTag 2005 has Wine as featured OSS project http://www.linuxtag.org/typo3site/projects.html?L=1 (german only). Does anybody know something about this? Andi? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgpwnHax5dn4G.pgp Description: PGP signature
Re: Crashes due to OGL
--- Raphael [EMAIL PROTECTED] wrote: On Monday 20 June 2005 04:18, Robert Lunnon wrote: I see the following X error (After fixing a bug in utah GLX) trace:ddraw:initialize enabling DirectDraw HAL trace:ddraw:d3ddevice_init_at_startup Initializing GL... @@Created GLX Context.. X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x21 Serial number of failed request: 7282 Current serial number in output stream: 7283 send_thread_signal 15 According to my GL log this request looks for visual 33 (IE vid=33) this is a non GL visual since utah GLX is allocating visuals 55 up on my system. I don't exactly know why wine should be trying to Create a GL context from a non GL visual but there you are... Bob Hi, seems more a ddraw problem on way how glx context is created :) can you try d3d8 games to see if it works better ? It would be great if you could try the d3d9 patches too (http://directxwine.sourceforge.net/), I've changed the way pbuffers are created compared to d3d8 Regards, Raphael ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Re: [shell32] Load file context menu from resources [Resent]
Tobias Burnus [EMAIL PROTECTED] writes: Second try (unchanged). Any suggestions how to improve the patch are welcome. Tobias Changed file overview: - shv_item_cmenu.c: Load from resources (the [currently unused] MENU resource already exists) - shell32_?.rc: Comment out two items (and a separator) and copy text from IDS_SELECT, needed to match the current context menu You shouldn't comment things out like that. Either the info is needed and it should be here, or it's not needed and it should be removed completely. Commenting it out is only creating confusion. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [Patch] winsock.h inclusion
Pierre d'Herbemont [EMAIL PROTECTED] writes: Alexandre, Using the current CVS on Darwin/Mac OS X, there are still compilation errors related to winsock.h inclusion. The error was: ../../../include/winsock.h:414: error: redefinition of 'struct timeval' My solution is to include wine/test.h after every other header. You should fix wine/test.h and/or winsock.h to work properly in all cases. Otherwise the problem will keep coming back. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Added XEmbed embedder support
Dimi Paun wrote:
On Mon, 2005-06-20 at 00:05 +0200, Jacek Caban wrote:
Hello.
This patch adds support for XEmbed embedder
It implements most of it (remaining todos
are listed in comments of xembed.c).
Cool stuff, I'm really excited about this work.
Not to mention that this might prove useful outside
of the MSHTML context.
I will not comment on the fundamentals of
the approach, that's more Alexandre's alley, but
just a few style nits.
+struct xembed_list
+{
+struct xembed_list *next;
+HWND hwnd;
+};
What about using the standard list from wine/list.h?
AFAIK using standard list lists or not is up to developer.
Personally I don't like Wine's implementation... I don't have
any argument why - I just feel better not using it :-)
/* DIB Section sync state */
@@ -590,6 +601,8 @@ enum x11drv_atoms
XATOM_XdndSelection,
XATOM_XdndTarget,
XATOM_XdndTypeList,
+XATOM__XEMBED,
+XATOM__XEMBED_INFO,
XATOM_WCF_DIB,
XATOM_image_gif,
XATOM_text_html,
@@ -649,6 +662,10 @@ struct x11drv_win_data
struct dce *dce;/* DCE for CS_OWNDC or CS_CLASSDC windows */
HBITMAP hWMIconBitmap;
HBITMAP hWMIconMask;
+union {
+struct xembed_list *list;
+ULONG_PTR cnt;
+} xembed;
};
Do we really need the union? We're not that hard pressed for
memory. What about just
@@ -649,6 +662,10 @@ struct x11drv_win_data
struct dce *dce;/* DCE for CS_OWNDC or CS_CLASSDC windows */
HBITMAP hWMIconBitmap;
HBITMAP hWMIconMask;
+struct xembed_list *list;
+ULONG_PTR cnt;
};
I can't see why union is worse... But instead of union it can
always be a list, if we don't care about memory. I didn't do it
this way because it was better for my earlier versions, but now
I may change it.
Also, instead of having explicit tests like these:
+if(data-xembed.cnt)
Maybe we can have a
BOOL win_has_embedded_children(struct x11drv_win_data *data)
function to make it more explicit what we're testing for.
OK, I thought it's clean enough, but I can change it.
Jacek
Problem with wine-cvs on FC4
For about a week now I've been able to compile wine-cvs on FC4 after manually excluding the ddraw-test references. But I'm yet to see an actual window created by wine. Even running the built in notepad application does not produce much meaningful result. In the console it outputs err:imagelist:ImageList_ReplaceIcon no color! a lot and then just sits there waiting. No window, no other messages. After running 'make test' I end up with these errors: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so imagelist.c touch imagelist.ok imagelist.c:303: Test failed: no hicon1 imagelist.c:305: Test failed: no hicon2 imagelist.c:307: Test failed: no hicon3 imagelist.c:355: Test failed: no hicon1 imagelist.c:357: Test failed: no hicon2 imagelist.c:359: Test failed: no hicon3 imagelist.c:402: Test failed: couldn't get DC imagelist.c:435: Test failed: DrawIndirect should succeed imagelist.c:445: Test failed: should succeed imagelist.c:447: Test failed: should succeed imagelist.c:449: Test failed: should succeed imagelist.c:485: Test failed: failed to create hicon1 There are also a few hundreds of the no color error, I can provide full make test output if wanted. -HK
Re: Wine's Registry
James Liggett wrote: Being as compatible with Windows as possible would probably be the best idea. As for looking to ReactOS as a guide, it might be feasible, but there's a lot of holes in their implementations of things, so this would take some looking into as to where they stand in that area. But it might be worth it. James On Mon, 2005-06-20 at 08:08 +0200, Martin Fuchs wrote: 2005/6/19, James Liggett [EMAIL PROTECTED]: Hi Brad, I've been following you discussion about wine's registry format, and I find it interesting. I gave it some thought, I have have an idea. Have you thought about using XML as a potential format? Since the registry is a non-relational tree database, this seems to fit quite well. Plus, there's a few libraries that would do the dirty work for us (libxml, expat, many others, name your pick). It could even be possible to modularize the registry using technologies like XInclude or XLink. Just thought I'd offer my two cents. Sure, the tree format would match. But this would not really make things better. You would also have to read the registry at once at startup time. The best solution would be to use native Windows registry format. This way you could use real Windows registry files, and can read and update registry piecewise. It's organized like a little file system - or database if you want to see it this way. It's not documented. But you could have a look at the ReactOS implementation, which claimes to be compatible to NT4. Regards, Martin I see a few people piping up and agreeing that Wine could use a new registry mechanism, but ultimately, Julliard is going to be the one who decides whether or not he's going to commit such a thing to cvs or not. . . I'd really like to get his approval before I do anything. . . I know you weren't convinced with my first post Alexandre, but has your opinion been changed since then? If it hasn't - I'll drop the whole subject now and let things be, but if it has, please let me know so I can begin work. Thanks, --Brad DeMorrow
Re: Problem with wine-cvs on FC4
Hi, On Mon, Jun 20, 2005 at 10:52:10AM +0200, Hans Kristian Rosbach wrote: For about a week now I've been able to compile wine-cvs on FC4 after manually excluding the ddraw-test references. But I'm yet to see an actual window created by wine. Even running the built in notepad application does not produce much meaningful result. In the console it outputs err:imagelist:ImageList_ReplaceIcon no color! a lot and then just sits there waiting. No window, no other messages. That sounds a lot like it is using the completely incapable/improper ttydrv (text mode) in the wine configuration instead of x11drv. But I could be wrong since I don't know for sure whether it's that kind of error messages that will appear when using ttydrv... Andreas Mohr
Re: [PATCH] FCI work for cabinet.dll [cabinet-fci-patch-02c.diff]
Gerold J. Wucherpfennig [EMAIL PROTECTED] writes: Please apply, it seems to be fine, so far. There is still some work to be done: - currently no support for big-endian machines - the ERF error structure aren't used on error - no real compression yet - unknown behaviour if files4GB or cabinet 4GB - incorrect status information - check if the maximum size for a cabinet is too small to store any data - call pfnfcignc on exactly the same position as MS FCIAddFile in every case You should get rid of all the PFCI_INT macro uses, that's making the code really ugly and hard to read. You should do the cast once at the start of the function (preferably as part of the handle validation routine) and then pass around a pointer of the appropriate type. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Guild Wars
Andreas Mohr wrote:
Hi,
On Sun, Jun 19, 2005 at 04:38:25PM -0500, Robert Shearman wrote:
This is fixed by patch OLE #81a (Part 1) if it gets committed.
It will then output:
err:ole:CoGetClassObject class {a65b8071-3bfe-4213-9a5b-491da4461ca7}
not registered
Wow, that was FAST! (hmm, or was your patch before my mail? don't remember)
It's only a semi-fix, though, since IMHO it should output something like:
err:ole:CoGetClassObject class {a65b8071-3bfe-4213-9a5b-491da4461ca7}
not registered - try running regsvr32 on the container DLL of this CLSID value!
If they have enough expertise to know that the CLSID is that of a DXDiag
object then I think they will know that they can register it by using
regsvr32 and I don't think this is the right place for documenting the
possible reasons for the error. However, this particular problem was
that the user didn't re-register all of the DLLs after upgrading. Maybe
we should have something in the docs that tells the user to do this
after upgrading to a new version of Wine or have it done automatically
somehow.
--
Rob Shearman
Re: Guild Wars
Andreas Mohr wrote:
Hi,
On Sun, Jun 19, 2005 at 04:38:25PM -0500, Robert Shearman wrote:
This is fixed by patch OLE #81a (Part 1) if it gets committed.
It will then output:
err:ole:CoGetClassObject class {a65b8071-3bfe-4213-9a5b-491da4461ca7}
not registered
Wow, that was FAST! (hmm, or was your patch before my mail? don't remember)
It's only a semi-fix, though, since IMHO it should output something like:
err:ole:CoGetClassObject class {a65b8071-3bfe-4213-9a5b-491da4461ca7}
not registered - try running regsvr32 on the container DLL of this CLSID value!
If they have enough expertise to know that the CLSID is that of a DXDiag
object then I think they will know that they can register it by using
regsvr32 and I don't think this is the right place for documenting the
possible reasons for the error. However, this particular problem was
that the user didn't re-register all of the DLLs after upgrading. Maybe
we should have something in the docs that tells the user to do this
after upgrading to a new version of Wine or have it done automatically
somehow.
--
Rob Shearman
Re: Using SVK and Subversion to manage distributed branches to Wine CVS
On Mon, 20 Jun 2005 11:44:11 +1000, Troy Rollo wrote: In the case of Wine, however, with the CVS repository being read-only except to Alexandre, the difference between read-only CVS and the combination of Subversion and SVK is even more dramatic (I would compare it to the difference between chiselling documents into stone tablets and using a word processor). +1 Thanks for doing this Troy, I had intended to set up an SVK gateway months ago and it never happened. It's great to see that I'm not crazy really ;) thanks -mike
Re: Change Name of Wine Marlett Font
On Mon, Jun 20, 2005 at 01:10:11PM -0500, Robert Shearman wrote: Changelog: The Wine Marlett font needs to be called Marlett for Steam to pick it up. The font replacement mechanism should make this unnecessary. Why doesn't that work in this case? Huw.
Re: Change Name of Wine Marlett Font
Huw D M Davies wrote: On Mon, Jun 20, 2005 at 01:10:11PM -0500, Robert Shearman wrote: Changelog: The Wine Marlett font needs to be called Marlett for Steam to pick it up. The font replacement mechanism should make this unnecessary. Why doesn't that work in this case? It enumerates the fonts, but Marlett isn't enumerated, only Wine Marlett. I tried adding a value in the FontSubstitutes and Fonts registry keys and the problem was the same. You can test this very easily using notepad's Edit-Font dialog. Steam only started working when Marlett was listed as a font in there. -- Rob Shearman
winecfg's registry convience functions
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
[EMAIL PROTECTED]
Re: Change Name of Wine Marlett Font
On Mon, Jun 20, 2005 at 01:37:45PM -0500, Robert Shearman wrote: Huw D M Davies wrote: On Mon, Jun 20, 2005 at 01:10:11PM -0500, Robert Shearman wrote: Changelog: The Wine Marlett font needs to be called Marlett for Steam to pick it up. The font replacement mechanism should make this unnecessary. Why doesn't that work in this case? It enumerates the fonts, but Marlett isn't enumerated, only Wine Marlett. I tried adding a value in the FontSubstitutes and Fonts registry keys and the problem was the same. You can test this very easily using notepad's Edit-Font dialog. Steam only started working when Marlett was listed as a font in there. Yup, that's the fonts substitutes mechanism which is different from the replacements oneg See LoadReplaceList in gdi/freetype.c You need something like this: [HKCU\Software\Wine\Fonts\Replacements] Marlett=Wine Marlett Huw.
Re: Change Name of Wine Marlett Font
Huw D M Davies wrote: On Mon, Jun 20, 2005 at 01:37:45PM -0500, Robert Shearman wrote: Huw D M Davies wrote: On Mon, Jun 20, 2005 at 01:10:11PM -0500, Robert Shearman wrote: Changelog: The Wine Marlett font needs to be called Marlett for Steam to pick it up. The font replacement mechanism should make this unnecessary. Why doesn't that work in this case? It enumerates the fonts, but Marlett isn't enumerated, only Wine Marlett. I tried adding a value in the FontSubstitutes and Fonts registry keys and the problem was the same. You can test this very easily using notepad's Edit-Font dialog. Steam only started working when Marlett was listed as a font in there. Yup, that's the fonts substitutes mechanism which is different from the replacements oneg See LoadReplaceList in gdi/freetype.c You need something like this: [HKCU\Software\Wine\Fonts\Replacements] Marlett=Wine Marlett Thanks, that works. This patch is unnecessary. -- Rob Shearman
unicode.h and -Wcast-qual
Hi,
i am currently trying to fix the -Wcast-qual warnings. In
include/wine/unicode.h there a 4 function:
static inline int strncmpW( const WCHAR *str1, const WCHAR *str2, int n)
static inline WCHAR *strchrW( const WCHAR *str, WCHAR ch )
static inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch )
static inline WCHAR *strpbrkW( const WCHAR *str, const WCHAR *accept )
whose signatures forces us to discard the const of an parameter while
returning it as the function value. Compiling with -Wcast-qual gives
(correctly) this warning:
../../include/wine/unicode.h:218: warning: cast discards qualifiers from
pointer target type
Together these four functions account for a total of 1400 (!) warnings.
In samba_4 sourcecode i discovered the following macros, which are
apparently a hack but silences these warnings:
#define discard_const(ptr) ((void *)((intptr_t)(ptr)))
#define discard_const_p(type, ptr) ((type *)discard_const(ptr))
an crude proof of concept is attached as a patch.
I am not sure how portable this solution is...
Any comments are welcome...
Regards,
Stefan
Index: configure.ac
===
RCS file: /home/wine/wine/configure.ac,v
retrieving revision 1.366
diff -u -r1.366 configure.ac
--- configure.ac20 Jun 2005 15:52:16 - 1.366
+++ configure.ac20 Jun 2005 20:16:14 -
@@ -1276,6 +1276,7 @@
AC_C_INLINE
AC_CHECK_TYPES([mode_t, off_t, pid_t, size_t, ssize_t, long long, fsblkcnt_t,
fsfilcnt_t])
AC_CHECK_TYPES([sigset_t],,,[#include signal.h])
+AC_CHECK_TYPES(intptr_t)
AC_CACHE_CHECK([whether linux/input.h is for real],
wine_cv_linux_input_h,
Index: include/wine/unicode.h
===
RCS file: /home/wine/wine/include/wine/unicode.h,v
retrieving revision 1.32
diff -u -r1.32 unicode.h
--- include/wine/unicode.h 28 Apr 2005 12:01:37 - 1.32
+++ include/wine/unicode.h 20 Jun 2005 20:16:14 -
@@ -31,6 +31,17 @@
#define WINE_UNICODE_API DECLSPEC_IMPORT
#endif
+#include stdint.h
+#include config.h
+
+#ifdef HAVE_INTPTR_T
+#define discard_const(ptr) ((void *)((intptr_t)(ptr)))
+#else
+#define discard_const(ptr) ((void *)(ptr))
+#endif
+#define discard_const_p(type, ptr) ((type *)discard_const(ptr))
+
+
/* code page info common to SBCS and DBCS */
struct cp_info
{
@@ -215,20 +226,20 @@
static inline WCHAR *strchrW( const WCHAR *str, WCHAR ch )
{
-for ( ; *str; str++) if (*str == ch) return (WCHAR *)str;
+for ( ; *str; str++) if (*str == ch) return discard_const_p(WCHAR, str);
return NULL;
}
static inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch )
{
WCHAR *ret = NULL;
-for ( ; *str; str++) if (*str == ch) ret = (WCHAR *)str;
+for ( ; *str; str++) if (*str == ch) ret = discard_const_p(WCHAR, str);
return ret;
}
static inline WCHAR *strpbrkW( const WCHAR *str, const WCHAR *accept )
{
-for ( ; *str; str++) if (strchrW( accept, *str )) return (WCHAR *)str;
+for ( ; *str; str++) if (strchrW( accept, *str )) return
discard_const_p(WCHAR, str);
return NULL;
}
@@ -263,7 +274,7 @@
static inline WCHAR *memchrW( const WCHAR *ptr, WCHAR ch, size_t n )
{
const WCHAR *end;
-for (end = ptr + n; ptr end; ptr++) if (*ptr == ch) return (WCHAR *)ptr;
+for (end = ptr + n; ptr end; ptr++) if (*ptr == ch) return
discard_const_p(WCHAR, ptr);
return NULL;
}
@@ -271,7 +282,7 @@
{
const WCHAR *end, *ret = NULL;
for (end = ptr + n; ptr end; ptr++) if (*ptr == ch) ret = ptr;
-return (WCHAR *)ret;
+return discard_const_p(WCHAR , ret);
}
static inline long int atolW( const WCHAR *str )
Re: unicode.h and -Wcast-qual
Stefan Huehner wrote: I am not sure how portable this solution is... To make it portable you can use ULONG_PTR instead of intptr_t. Jacek
Re: Wine's Registry Format
On Thursday 16 June 2005 11:20 pm, you wrote: On Sat, 18 Jun 2005 22:22:56 +0200, Alexandre Julliard wrote: Actually the current method is probably the fastest for everything except the initial read. The only reason that the current method is fast is because we're loading the entire registry into memory. As stated in Bugzilla, this is fine for small registries, but the author of the bug has noted wineserver allocated up to 30MB when wine initiates JUST for the registry! How do you propose to keep track of multiple sources of the registry data? At one time Wine supported system-wide registry files as well as per-user ones, and some people would like to see that again. Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information Samba already uses something called 'TDB', and it's been suggested that the two projects could share a case-insensitive-filename layer based on it; could you look into using that? - It would also provide us with a quicker and easier way to search through the registry - so we could finally implement the Find feature in wine's regedit without much effort ( Not that it couldn't be done as is, but things would definitely be easier ). This could only be done at the expense of several times increase in on-disk storage, and would actually not be used very much. A more useful enhancement would be to support PCRE syntax for find-and-replace, or multiple views of data, or version-control of the registry... in fact, there are Windows programs that do all that, and all they require is a good, stable, quick implementation of the registry calls, which is what Wine provides. -- DLL GPG key at http://www.cse.msu.edu/~lamber45/newmail.htm?GPGkey pgpJtRZJKkxaE.pgp Description: PGP signature
Re: World of Warcraft
On Monday 20 June 2005 09:40, Raphael wrote: Hi, To me it looks like an overoptimized geometry problem. As long there is only sky and no terrain or building behind the objects, you can klick them. This is mostly the case, when you look up. Just like users reported. I just wrote a lousy mmap wrapper which sets start to 0x1000 . This works for me with wine 20050601 and the latest from cvs. Interesting After some investigation (using interesting users dumps at http://home.gci.net/~slipster5/WowError/ and in many others places) looks like more an ugly WoW bug For example seeing this typilical error: This application has encountered a critical error: ERROR #132 (0x85100084) Program:C:\Program Files\World of Warcraft\WoW.exe Exception: 0xC005 (ACCESS_VIOLATION) at 001B:00650E16 The instruction at 0x00650E16 referenced memory at 0x33991588. The memory could not be read. While registers was: EAX=0001 EBX=13991500 ECX=00A49658 EDX=0003 ESI=1399155C EDI= EBP=0012FC58 ESP=0012FC38 EIP=00650E16 FLG=00210202 CS =001B DS =0023 ES =0023 SS =0023 FS =003B GS = The must interesting is that error address was always (EBX + 0x2000) + something little (usually between 0x10-0x88). for info 0x2000 = 512Mb :) So who go to blizzard to fix the bug ? :) Raphael pgpAZhseGaLeO.pgp Description: PGP signature
Re: World of Warcraft
Stupid kmail Sorry Raphael pgpcJIYGhghQ6.pgp Description: PGP signature
Re: Wine's Registry Format
David Lee Lambert wrote: On Thursday 16 June 2005 11:20 pm, you wrote: On Sat, 18 Jun 2005 22:22:56 +0200, Alexandre Julliard wrote: Actually the current method is probably the fastest for everything except the initial read. The only reason that the current method is fast is because we're loading the entire registry into memory. As stated in Bugzilla, this is fine for small registries, but the author of the bug has noted wineserver allocated up to 30MB when wine initiates JUST for the registry! How do you propose to keep track of multiple sources of the registry data? At one time Wine supported system-wide registry files as well as per-user ones, and some people would like to see that again. I'm not certain what you mean by multple sources of the registry - but if you're clearifying yourself with your second sentence here, I'm sure it I could bring back that feature if I get the opportunity to and allow system registry files as well as user registry files. Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information Samba already uses something called 'TDB', and it's been suggested that the two projects could share a case-insensitive-filename layer based on it; could you look into using that? I've not heard of this 'TDB' before, nor do I know anything about that situation, however, again - given the opportunity - I will look into whatever the community wants before I make any decisions about how the project will be done. - It would also provide us with a quicker and easier way to search through the registry - so we could finally implement the Find feature in wine's regedit without much effort ( Not that it couldn't be done as is, but things would definitely be easier ). This could only be done at the expense of several times increase in on-disk storage, and would actually not be used very much. I'm not certain you're correct there, and I've been frustrated before when wine's regedit has that menu item disabled when I wanted to use it lol :) At any rate, again, I'm not saying one way or the other about how this is going to work yet (if at all). I'll look into it. A more useful enhancement would be to support PCRE syntax for find-and-replace, or multiple views of data, or version-control of the registry... in fact, there are Windows programs that do all that, and all they require is a good, stable, quick implementation of the registry calls, which is what Wine provides. I agree with you there, that would be a nice feature to have - especially if the registry goes binary. . . I'm sure there are some people that would normally use techniques like that with their current registry files. . . Again, however, I'm not doing anything except research until Alexandre gives me the 'go ahead'. Thanks everyone who has been throwing out ideas, they're helpful and extremely appreciated. --Brad DeMorrow
Re: World of Warcraft
fixme:opengl:wglQueryPbufferARB unsupported WGL_PBUFFER_LOST_ARB (need glXSelectEvent/GLX_DAMAGED work) Arg, i didn't expect this fixme :( I don't think we have to worry about this fixme. We can always return GL_FALSE, since that is the way the OpenGL surfaces were created. From http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt: If the GLX_PRESERVED_CONTENTS_SGIX attribute is set to False in attrib_list, then an unpreserved pbuffer is created and the contents of the pbuffer may be lost at any time. If this attribute is not specified, or if it is specified as True in attrib_list, then when a resource conflict occurs the contents of the pbuffer will be preserved (most likely by swapping out portions of the buffer to main memory). In either case, the client can register to receive a buffer clobber event which is generated when the pbuffer contents have been preserved or have been damaged. (See the event description.) So the fixme should be fixed to always return GL_FALSE I think. Also, there is an interesting workaround for the clicking problem as well on the Gentoo forums. Seems to be working for the majority of people (including myself). It seems to reaffirm that the problem is indeed the memory layout. http://forums.gentoo.org/viewtopic-p-2509340.html#2509340 -- Aric Cyr acyr at alumni dot uwaterloo dot ca(http://acyr.net) gpg fingerprint: 943A 1549 47AC D766 B7F8 D551 6703 7142 C282 D542
Re: winefile: switch to UNICODE mode
Hi Marcelo, 2005/6/20, Marcelo Duarte [EMAIL PROTECTED]: I don´t understand something or winefile can use Michael Jung´s unixfs namespace extension? The difference is: The unixfs namespace extension is implemented in shell namespace. This is a quite huge overhead compared to directly accessing unix file system functions because of all the PIDL conversions. So you will notice a big difference in performance using the root filesystem in winefile compared to using the shell namespace (another option already existing in winefile). Regards, Martin
