Re: SHELL32: cleanup, create unicode versions of some functions
"Mike McCormack" <[EMAIL PROTECTED]> wrote:
> There's quite a few strcasecmp calls revealed by:
>
> find . -name \*.c -exec grep strcasecmp {} \; -ls
>
> We probably need somebody to go through and clean them all up. Maybe a
> janitorial task?
Almost all of them can be directly replaced by lstrcmpiA, the exceptions are:
dlls/kernel/locale.c - can't use A->W conversions on a start-up phase
dlls/ntdll/relay.c - can't use A->W conversions on a start-up phase
server/* - unix app
tools/widl/* - unix app
tools/winebuild/* - unix app
tools/winedump/* - unix app
tools/wmc/* - unix app
tools/wrc/* - unix app
--
Dmitry.
Re: SHELL32: cleanup, create unicode versions of some functions
-if (strcasecmp ( szData1, szData2 )!=0 )
+if (strcasecmp( szData1, szData2 ))
As a common rule strcasecmp should never be used in Wine code, since
it introduces problem with portability and unexpected side effects
when locale of the underlying system differs from a Wine one.
You could make it a part of your clean up as well :-)
There's quite a few strcasecmp calls revealed by:
find . -name \*.c -exec grep strcasecmp {} \; -ls
We probably need somebody to go through and clean them all up. Maybe a
janitorial task?
Mike
Re: SHELL32: cleanup, create unicode versions of some functions
"Mike McCormack" <[EMAIL PROTECTED]> wrote: > ChangeLog: > * cleanup, create unicode versions of _ILCreateFromPath, > _ILCreateGuidFromStr, and _ILCreateFromFindData > @@ -524,7 +516,7 @@ BOOL WINAPI ILIsEqual(LPCITEMIDLIST pidl > _ILSimpleGetText(pidltemp1, szData1, MAX_PATH); > _ILSimpleGetText(pidltemp2, szData2, MAX_PATH); > > -if (strcasecmp ( szData1, szData2 )!=0 ) > +if (strcasecmp( szData1, szData2 )) > return FALSE; > > pidltemp1 = ILGetNext(pidltemp1); > @@ -574,7 +566,7 @@ BOOL WINAPI ILIsParent(LPCITEMIDLIST pid > _ILSimpleGetText(pParent, szData1, MAX_PATH); > _ILSimpleGetText(pChild, szData2, MAX_PATH); > > -if (strcasecmp ( szData1, szData2 )!=0 ) > +if (strcasecmp( szData1, szData2 )) > return FALSE; As a common rule strcasecmp should never be used in Wine code, since it introduces problem with portability and unexpected side effects when locale of the underlying system differs from a Wine one. You could make it a part of your clean up as well :-) -- Dmitry.
Re: "bachelor project" with wine ?
Joris Huizer wrote: I'm supposed to choose a topic - and work it out - for a "bachelor project"; Now, at the moment I have no clue, and teachers are discussing what topics to hand; in the mean time, I think maybe it might be interesting to do some wine work in such a form that it's ok for this "bachelor project" :) This project is supposed to be something like 308 hours; and of course, it should be possible to show something interesting at the end of that. About my background, I have a few years of (simple) programming experience (in C and C++, mostly) and most of that was done under linux -- just school programs most of the time; I don't have much experience with X programming and *none at all* with winapi; Is there a "project"/are there "projects" in wine, suitable for this? Absolutely. I'm sure others will suggest more ideas, but here's my suggestion: add some test cases to the Wine conformance test suite. I am mentoring about 14 college students doing this right now for college credit; four are doing it for a whole year, ten are doing it for a single semester. They are finding it appropriately challenging, and I think you will, too. See http://www.kegel.com/wine/sweng/ for the step-by-step instructions I wrote up for the semester class. (I'll be revising that as the semester continues to address issues found by the students.) Good luck, and feel free to write me with any questions! - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: World Of Warcraft
On Tue, 22 Feb 2005 09:22, [EMAIL PROTECTED] wrote: > >Since it's the only entry where the string and > >pointer/function/object/structure/whatever don't match I wondered it > >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather > >than. > > You are right > Seems that lionel made a typo :) Nope. That typo was mine.
Re: Collection of wine tools on windows
Casper Hornstrup wrote: W32api IS the MinGW headers. No, we have a wine win32 package on our download page, it's build with wine headers, not the mingw ones. Ivan.
Re: regression
--- Mike Hearn <[EMAIL PROTECTED]> wrote: > On Mon, 21 Feb 2005 16:47:11 +, Oliver Stieber > wrote: > > Now it starts up and I get the error. > > > > "err:virtual:NtMapViewOfSection Sizes larger than > 4Gb > > not supported" > > Wacky. Can you post a +ole,+tid,+seh trace please. > > > It doesn't look like ole at all, I've attached the last bit of a log with more-or-less everything turned on. ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com plain Description: plain
Re: Add new headers and changes in headers about security
Le lun 21/02/2005 à 13:47, Alexandre Julliard a écrit : > Vincent Béron <[EMAIL PROTECTED]> writes: > > > Move definitions from winerror.h to issperr.h. > > I don't think you want to do that, issperr.h is supposed to be an > obsolete header. Ok, I don't have a current SDK to check against. Anyway, the application I was compiling couldn't find those defines through it's normal #include, so I checked where they were defined in a VC6 install I have access to. I'll try to find out where to put them/which #include to change (in Wine or the application). Vincent
RE: [ros-dev] RE: Collection of wine tools on windows
--- Casper Hornstrup <[EMAIL PROTECTED]> wrote: > Yes, but then you need to publish the sources for the non-free application > under the LGPL. When using headers to build your application, you create a > derived work of those headers. > > http://www.fsf.org/licensing/licenses/lgpl.html The headers are a public interface and as such only the phsical copy of the header falls under that sort of restriction. Go check out the GTK/GLIB headers. Both of which were developed for GNOME under the eye of the free software foundation. 1000s of closed source applications are developed using GTK/GLIB and there is no question that YES you can use them in a closed source application provided you make a offer for your changes to GTK/GLIB. The Wine people consulted the FSF and other projects before moving to the LGPL and having the headers under the LGPL is not a problem. Thanks Steven __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Re: Re: World Of Warcraft
> >I have absolutely no understanding of this but in the list at the
> >end of your patch mailed to the list there is...
> >
> > { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL},
> >
> >and 5 lines later
> >
> > { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}
> >
> >Since it's the only entry where the string and
> >pointer/function/object/structure/whatever don't match I wondered it
> >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather
> >than.
> >
>
> You are right
> Seems that lionel made a typo :)
Oh, I will let you fix it when you send the PBuffer patch in with REAL
working code this time :-)
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: Re: World Of Warcraft
On Mon, Feb 21, 2005 at 10:19:42PM +, [EMAIL PROTECTED] wrote: > GL_VERSION isn't pertinent as it contains (only) provider and > driver version while GLX_VERSION is really the version string of GLX impl. Well, on my machine: OpenGL version string: 1.4.0 NVIDIA 43.63 So it gives you, at least, the OpenGL version which may be different from the GLX version. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: World Of Warcraft
On Mon, Feb 21, 2005 at 09:25:05PM +, Alex Woods wrote: > It looks as though it's the Pbuffer stuff it is after. Right after all > those wglGetProcAddress it does this: > > trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c) > trace:opengl:wglGetPbufferDCARB ((nil)) Ah ah !! Now we have some motivation to actually work on PBuffers... Now who, from Raphael, Olivier or me will send the patch first :-) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Recent CVS update causes Quicken popup problem/Help please
On Monday, February 21, 2005 03:43 pm, Rein Klazes wrote:
> On 10 Feb 2005 21:19:46 +0100, you wrote:
> > Carl Sopchak <[EMAIL PROTECTED]> writes:
> > > I guess my problem is that I have NO CLUE as to how this SHOULD be
> > > handled. Should the style be set to (style & ~WS_VISIBLE) when the
> > > rectangle is {0,0;0,0}? Should {0,0;0,0} be considered a valid
> > > rectangle in validate_window_rectangles()? Should
> > > validate_window_rectangles() only get called if the rectangle is not
> > > {0,0;0,0}? Or, very possibly, is there something else that should
> > > happen? Just to see what happened, I commented out the call to
> > > validate_window_rectangles, and the popup disappeared as it should.
> >
> > The client rectangle should have been set to {0,0;0,0} too. You should
> > look at the WM_NCCALCSIZE processing (SWP_DoNCCalcSize in
> > dlls/x11drv/winpos.c) and check what's happening there with the
> > rectangles.
>
> Experimenting for another issue, I noticed today:
>
> If I execute this under Win2K for a window with the WS_BORDER style:
> | MoveWindow( hwnd, 0,0,0,0,0);
> | GetWindowRect ( hwnd, &rc);
> | trace(" 1. %ld,%ld-%ld,%ld\n", rc.left,rc.top, rc.right, rc.bottom);
> | DefWindowProcA(hwnd, WM_NCCALCSIZE, 0, (LPARAM)&rc);
> | trace(" 2. %ld,%ld-%ld,%ld\n", rc.left,rc.top, rc.right, rc.bottom);
>
> this is the result:
>
> 1. 0,0-0,0
> 2. 1,1-1,1
>
> It seems to me this should be allowed as valid.
>
> Rein.
This is the same issue. I had sent the following under another subject, so it
didn't get "attached" to this thread, but here is what I found upon further
investigation:
Ok, so what is happening is this: In dlls/x11drv/winpos.c, the pNewWindowRect
is coming into SWP_DoNCCalcSize as (0,0;0,0), wndPtr->rectWindow is
(182,977;662;998), and wndPty->rectClient is (183,978;661,997). Then
winpos.c sends it's own WM_NCCALCSIZE message, and upon return,
params.rgrc[0] is (1,1;1,1)! This, in turn, causes the third and fourth
conditions in the section commented as "If the application sends back
garbage, ignore it" to be true, which in turn causes the next condition to be
false, so the client rectangle (pNewClientRect) does NOT get set. (Follow
that?? )
Tracing through the processing of this WM_NCCALCSIZE, I find it ends up
generating two WM_NCCALCSIZE messages, one being handled by DefWindowProc32.
This leads me to ./windows/defwnd.c, which calls NC_HandleNCCalcSize
in ./windows/nonclient.c. Within NC_HandleNCCalcSize, a call is made to
NC_AdjustRectOuter, then the window's rectangle (winRect) is adjusted based
on this call. It is this call and adjustment of winRect that changes winRect
from (0,0;0,0) to (1,1;-1,-1), which is later "fixed" to (1,1;1,1).
Diving deeper, into NC_AdjustRectOuter, I find that because the window style
has WS_BOARDER set, adjust is set to 1, then InflateRect is called, which
sets rect to (-1,-1;1,1) [returned to NC_HandleNCCalcSize tmpRect variable].
So, there's the problem. The new rectangle size is (0,0;0,0), but has
WS_BOARDER set, so the WM_NCCALCSIZE message returns (1,1;1,1) erroneously.
The only thing is, I'm still not sure where the "best" place would be to check
for the new window rectangle of (0,0;0,0) and handle it appropriately - or
what "appropriate" would be, for that matter...
Further help would be appreciated.
Thanks,
Carl
Re: Re: World Of Warcraft
Message d'origine
>De: Colin Wright <[EMAIL PROTECTED]>
>A: Raphael <[EMAIL PROTECTED]>
>Sujet: Re: World Of Warcraft
>Date: Mon, 21 Feb 2005 21:07:14 +
>
>Raphael wrote:
>
>> Ouppsss
>>
>> better patch
>>
>> sorry
>>
>> Regards,
>> Raphael
>>
>> On Monday 21 February 2005 09:58, Alex Woods wrote:
>>> On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
>>> > can you try this patch ?
>>>
>>> Yes, doesn't look any different though. I did notice that with either
>>> patch I get this though:
>>>
>>> 0009:warn:opengl:wglGetProcAddress Did not find extension
>>> wglGetExtensionsStringARB in either Wine or your OpenGL library.
>>>
>>> Whereas without the patches I get this:
>>>
>>> 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB)
>>> 0009:trace:opengl:wglGetProcAddress returning WGL function (0x561cbf90)
>>> 0009:trace:opengl:wglGetCurrentDC ()
>>> 0009:trace:opengl:wglGetCurrentDC returning 0x7b8 (GL context 0x780d7fd8
>>> - Wine context 0x5593f478) 0009:trace:opengl:wglGetExtensionsStringARB ()
>>> returning "WGL_ARB_extensions_string WGL_EXT_extensions_string"
>>>
>>> So something must be broken ;)
>
>I have absolutely no understanding of this but in the list at the
>end of your patch mailed to the list there is...
>
> { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL},
>
>and 5 lines later
>
> { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}
>
>Since it's the only entry where the string and
>pointer/function/object/structure/whatever don't match I wondered it
>"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather
>than.
>
You are right
Seems that lionel made a typo :)
Thx
Regards,
Raphael
Re: World Of Warcraft
On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote: > Ouppsss > > better patch It looks as though it's the Pbuffer stuff it is after. Right after all those wglGetProcAddress it does this: trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c) trace:opengl:wglGetPbufferDCARB ((nil)) So I guess it could be setting up stuff for the minimap long before it gets into the actual game. Have you actually started on the Pbuffer code now Raphael? If you have, is there anything I can do to help? At the very least I have a testbed I suppose ;) -- Alex
Re: Re: World Of Warcraft
Hi lionel, GL_VERSION isn't pertinent as it contains (only) provider and driver version while GLX_VERSION is really the version string of GLX impl. Regards, Raphael Message d'origine >De: Lionel Ulmer <[EMAIL PROTECTED]> >A: Raphael <[EMAIL PROTECTED]> >Copie à: Alex Woods <[EMAIL PROTECTED]>, wine-devel@winehq.org >Sujet: Re: World Of Warcraft >Date: Mon, 21 Feb 2005 21:44:31 +0100 > >On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote: >> Ouppsss >> >> better patch > >Why did you do this change: > >-const char *gl_version = (const char *) glGetString(GL_VERSION); >+const char *gl_version = glXGetClientString(display, GLX_VERSION); > >I.e. replacing the GL version with the one of GLX ? Maybe the GLX version is >needed, but we could then log both of them and not replace GL by GLX. > > Lionel > >-- >Lionel Ulmer - http://www.bbrox.org/ > >
Re: [ros-dev] RE: Collection of wine tools on windows
Hi, --- Casper Hornstrup <[EMAIL PROTECTED]> wrote: > I might vote for using WINE headers in ReactOS if WINE relicensed > its headers to a w32api or BSD like license that will allow use in > a non-free application. What I would like to see most though, is > for all three projects to share w32api. What do you mean? The headers are LGPL so you can use them in a non-free application. Thanks Steven __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
Re: World Of Warcraft
On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote: > Ouppsss > > better patch Thanks, and good timing - I was just about to go and debug it ;) The new patch gives the following wglGetProcAddress stuff, which looks more like it (chopping the top bits off): trace:opengl:wglGetProcAddress (glIsProgramNV) trace:opengl:wglGetProcAddress returning function (0x561a0810) trace:opengl:wglGetProcAddress (GetProgramivNV) warn:opengl:wglGetProcAddress Did not find extension GetProgramivNV in either Wine or your OpenGL library. trace:opengl:wglGetProcAddress (glVertexAttribPointerNV) trace:opengl:wglGetProcAddress returning function (0x561b6590) trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc150) trace:opengl:wglGetCurrentDC () trace:opengl:wglGetCurrentDC returning 0x7b8 (GL context 0x780d7fb8 - Wine context 0x5593f4c8) trace:opengl:wglGetExtensionsStringARB () returning "WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_ARB_pbuffer WGL_ARB_pixel_format WGL_ARB_render_texture" trace:opengl:wglGetProcAddress (wglGetPixelFormatAttribivARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc2a0) trace:opengl:wglGetProcAddress (wglGetPixelFormatAttribfvARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc330) trace:opengl:wglGetProcAddress (wglChoosePixelFormatARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc3c0) trace:opengl:wglGetProcAddress (wglCreatePbufferARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc450) trace:opengl:wglGetProcAddress (wglGetPbufferDCARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc4d0) trace:opengl:wglGetProcAddress (wglReleasePbufferDCARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc530) trace:opengl:wglGetProcAddress (wglDestroyPbufferARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc5a0) trace:opengl:wglGetProcAddress (wglQueryPbufferARB) trace:opengl:wglGetProcAddress returning WGL function (0x561cc610) trace:opengl:wine_glGetIntegerv (34047, 0x5a4582e0) trace:opengl:wine_glGetFloatv (34045, 0x5a4582ec) -- Alex
Re: possibly new regression
On Sun, 20 Feb 2005 16:41:09 +0100, you wrote:
> On Sun, 20 Feb 2005 16:04:54 +0100
> Rein Klazes <[EMAIL PROTECTED]> wrote:
> >
> > Does this patch help?
> >
> > Rein.
>
> Unfortunately not - still the exact same error.
Surprise :(
OK, I can try once more, perhaps the counter is much more then the
program expects (it resets when windows is restarted, here it counts up
from 1970/1/1). Try attached patch (first reverse previous patch, them
make; make install and test again)
Then if it does not work. As the patch fixes a real problem, reverting
is not an option. You will need to debug this to find out why the crash
happens.
If you run this with WINEDEBUG=+relay, can you look for both
QueryPerformanceCounter or QueryPerformanceFrequency in the lines just
before the crash?
With some luck the addresses of the call (look at ret=..) is near
where the crash happens ( it is reported by the debugger: 0x00500280)
and we can look at the disassembled code (debugger command
"disass adr1, addr2").
Rein.
--- wine/dlls/ntdll/nt.c2005-02-12 08:18:02.0 +0100
+++ mywine/dlls/ntdll/nt.c 2005-02-21 19:28:46.0 +0100
@@ -519,10 +519,14 @@ NTSTATUS WINAPI NtQueryPerformanceCounte
OUT PLARGE_INTEGER Counter,
OUT PLARGE_INTEGER Frequency)
{
-LARGE_INTEGER time;
-NtQuerySystemTime( &time );
-Counter->QuadPart = time.QuadPart;
-Frequency->QuadPart = 1000;
+struct timeval now;
+gettimeofday( &now, 0 );
+/* convert a counter that increments at a rate of 1 MHz
+ * to one of 1193182 Hz, with some care for arithmetic overflows
+ * ( will not overflow until 2038 ) */
+Counter->QuadPart = (((now.tv_sec - 1109009802)* (ULONGLONG) 100 +
now.tv_usec )
+* 105) / 88 ; /* 105/88 = 1.19318182 */
+Frequency->QuadPart = 1193182;
return 0;
}
Re: World Of Warcraft
On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote: > Ouppsss > > better patch Why did you do this change: -const char *gl_version = (const char *) glGetString(GL_VERSION); +const char *gl_version = glXGetClientString(display, GLX_VERSION); I.e. replacing the GL version with the one of GLX ? Maybe the GLX version is needed, but we could then log both of them and not replace GL by GLX. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Recent CVS update causes Quicken popup problem/Help please
On 10 Feb 2005 21:19:46 +0100, you wrote:
> Carl Sopchak <[EMAIL PROTECTED]> writes:
>
> > I guess my problem is that I have NO CLUE as to how this SHOULD be handled.
> >
> > Should the style be set to (style & ~WS_VISIBLE) when the rectangle is
> > {0,0;0,0}? Should {0,0;0,0} be considered a valid rectangle in
> > validate_window_rectangles()? Should validate_window_rectangles() only get
> > called if the rectangle is not {0,0;0,0}? Or, very possibly, is there
> > something else that should happen? Just to see what happened, I commented
> > out the call to validate_window_rectangles, and the popup disappeared as it
> > should.
>
> The client rectangle should have been set to {0,0;0,0} too. You should
> look at the WM_NCCALCSIZE processing (SWP_DoNCCalcSize in
> dlls/x11drv/winpos.c) and check what's happening there with the
> rectangles.
Experimenting for another issue, I noticed today:
If I execute this under Win2K for a window with the WS_BORDER style:
| MoveWindow( hwnd, 0,0,0,0,0);
| GetWindowRect ( hwnd, &rc);
| trace(" 1. %ld,%ld-%ld,%ld\n", rc.left,rc.top, rc.right, rc.bottom);
| DefWindowProcA(hwnd, WM_NCCALCSIZE, 0, (LPARAM)&rc);
| trace(" 2. %ld,%ld-%ld,%ld\n", rc.left,rc.top, rc.right, rc.bottom);
this is the result:
1. 0,0-0,0
2. 1,1-1,1
It seems to me this should be allowed as valid.
Rein.
Re: World Of Warcraft
Ouppsss
better patch
sorry
Regards,
Raphael
On Monday 21 February 2005 09:58, Alex Woods wrote:
> On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
> > can you try this patch ?
>
> Yes, doesn't look any different though. I did notice that with either
> patch I get this though:
>
> 0009:warn:opengl:wglGetProcAddress Did not find extension
> wglGetExtensionsStringARB in either Wine or your OpenGL library.
>
> Whereas without the patches I get this:
>
> 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB)
> 0009:trace:opengl:wglGetProcAddress returning WGL function (0x561cbf90)
> 0009:trace:opengl:wglGetCurrentDC ()
> 0009:trace:opengl:wglGetCurrentDC returning 0x7b8 (GL context 0x780d7fd8 -
> Wine context 0x5593f478) 0009:trace:opengl:wglGetExtensionsStringARB ()
> returning "WGL_ARB_extensions_string WGL_EXT_extensions_string"
>
> So something must be broken ;)
Index: wgl_ext.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
retrieving revision 1.2
diff -u -r1.2 wgl_ext.c
--- wgl_ext.c 31 Jan 2005 11:32:13 - 1.2
+++ wgl_ext.c 21 Feb 2005 20:38:15 -
@@ -42,10 +42,31 @@
static char *WGL_extensions = NULL;
/* Extensions-query functions */
-BOOL query_function_pbuffers(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
- const char *server_glx_extensions, const char *client_glx_extensions)
+BOOL query_function_multisample(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
+const char *server_glx_extensions, const char *client_glx_extensions)
{
-return FALSE;
+ return NULL != strstr("GLX_ARB_multisample", glx_extensions);
+}
+
+BOOL query_function_pbuffer(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+ FIXME("gl_version is: \"%s\"\n", gl_version);
+ FIXME("glx_exts is: \"%s\"\n", glx_extensions);
+
+ return 0 <= strcmp("1.3", gl_version) || NULL != strstr(glx_extensions, "GLX_SGIX_pbuffer");
+}
+
+BOOL query_function_pixel_format(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+ return TRUE;
+}
+
+BOOL query_function_render_texture(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+ return 0 <= strcmp("1.3", gl_version) || NULL != strstr(glx_extensions, "GLX_SGIX_pbuffer");
}
/***
@@ -86,12 +107,176 @@
return swap_interval;
}
+typedef struct wine_glpbuffer {
+ Drawable drawable;
+ intpixelFormat;
+ intwidth;
+ intheight;
+ int* attribList;
+} Wine_GLPBuffer;
+
+#define PUSH1(attribs,att)attribs[nAttribs++] = (att);
+#define PUSH2(attribs,att,value) attribs[nAttribs++] = (att); attribs[nAttribs++] = (value);
+
+#define WGL_NUMBER_PIXEL_FORMATS_ARB 0x2000
+#define WGL_DRAW_TO_WINDOW_ARB 0x2001
+#define WGL_DRAW_TO_BITMAP_ARB 0x2002
+#define WGL_ACCELERATION_ARB 0x2003
+#define WGL_NEED_PALETTE_ARB 0x2004
+#define WGL_NEED_SYSTEM_PALETTE_ARB 0x2005
+#define WGL_SWAP_LAYER_BUFFERS_ARB 0x2006
+#define WGL_SWAP_METHOD_ARB 0x2007
+#define WGL_NUMBER_OVERLAYS_ARB 0x2008
+#define WGL_NUMBER_UNDERLAYS_ARB 0x2009
+#define WGL_TRANSPARENT_ARB 0x200A
+#define WGL_TRANSPARENT_RED_VALUE_ARB 0x2037
+#define WGL_TRANSPARENT_GREEN_VALUE_ARB 0x2038
+#define WGL_TRANSPARENT_BLUE_VALUE_ARB 0x2039
+#define WGL_TRANSPARENT_ALPHA_VALUE_ARB 0x203A
+#define WGL_TRANSPARENT_INDEX_VALUE_ARB 0x203B
+#define WGL_SHARE_DEPTH_ARB 0x200C
+#define WGL_SHARE_STENCIL_ARB 0x200D
+#define WGL_SHARE_ACCUM_ARB 0x200E
+#define WGL_SUPPORT_GDI_ARB 0x200F
+#define WGL_SUPPORT_OPENGL_ARB 0x2010
+#define WGL_DOUBLE_BUFFER_ARB 0x2011
+#define WGL_STEREO_ARB0x2012
+#define WGL_PIXEL_TYPE_ARB 0x2013
+#define WGL_COLOR_BITS_ARB 0x2014
+#define WGL_RED_BITS_ARB 0x2015
+#define WGL_RED_SHIFT_ARB 0x2016
+#define WGL_GREEN_BITS_ARB 0x2017
+#define WGL_GREEN_SHIFT_ARB 0x2018
+#define WGL_BLUE_BITS_ARB 0x2019
+#define WGL_BLUE_SHIFT_ARB 0x201A
+#define WGL_ALPHA_BITS_ARB 0x201B
+#define WGL_ALPHA_SHIFT_ARB 0x201C
+#define WGL_ACCUM_BITS_ARB 0x201D
+#define WGL_ACCUM_RED_BITS_ARB 0x201E
+#define WGL_ACCUM_GREEN_BITS_ARB 0x201F
+#define WGL_ACCUM_BLUE_BITS_ARB 0x2020
+#define WGL_ACCUM_ALPHA_BITS_ARB 0x2021
+#define WGL_DEPTH_BITS_ARB 0x2022
+#define WGL_STENCIL_BITS_ARB 0x2023
+#define WGL_AUX_BUFFERS_ARB 0x2024
+
+static void ConvertAttrib(const int* iWGLAttr, int* oGLXAttr) {
+ unsigned nAttribs = 0;
+
+ int pop;
+ while (0 != iWGLAttr[nAttribs]) {
+switch (iWGLAttr[nAttribs]) {
+case WGL_COLOR_BITS_ARB:
+ pop = iWGLAttr[++nAttribs];
+ P
[PATCH] Add NZDT support to TZ_INFO
Adds support for NZDT (New Zealand Daylight Time) to TZ_INFO.
Cheers,
--
Darryl Dixon <[EMAIL PROTECTED]>
diff -ru wine-20050211/dlls/ntdll/time.c wine-20050211_NZDT/dlls/ntdll/time.c
--- wine-20050211/dlls/ntdll/time.c 2005-02-09 01:13:36.0 +1300
+++ wine-20050211_NZDT/dlls/ntdll/time.c 2005-02-21 16:32:37.0 +1300
@@ -309,6 +309,9 @@
{"NZST",
{'N','e','w',' ','Z','e','a','l','a','n','d',' ','S','t','a','n','d','a',
'r','d',' ','T','i','m','e','\0'}, -720, 0},
+ {"NZDT",
+{'N','e','w',' ','Z','e','a','l','a','n','d',' ','D','a','y','l','i','g',
+ 'h','t',' ','T','i','m','e','\0'}, -780, 1},
{"FJT",
{'F','i','j','i',' ','S','t','a','n','d','a','r','d',' ','T','i','m','e',
'\0'}, -720, 0},
Re: dlls/gdi: fix GetGlyphOutline(resend)
TANABE Hiroshi <[EMAIL PROTECTED]> writes:
> if(!(fuFormat & GGO_GLYPH_INDEX)) {
> -p = FONT_mbtowc(hdc, (char*)&uChar, 1, NULL, NULL);
> +int len;
> +if(uChar > 0xff) { /* but, 2 bytes charactor only */
> +len = 2;
> +uChar = (uChar & 0xff) << 8 | (uChar & 0xff00) >> 8;
> +} else
> +len = 1;
> +p = FONT_mbtowc(hdc, (char*)&uChar, len, NULL, NULL);
You should use an array of two chars here.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Add new headers and changes in headers about security
Vincent Béron <[EMAIL PROTECTED]> writes: > Move definitions from winerror.h to issperr.h. I don't think you want to do that, issperr.h is supposed to be an obsolete header. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Checking Wine's spec files
Francois Gouget <[EMAIL PROTECTED]> writes: > On Mon, 21 Feb 2005, Alexandre Julliard wrote: > > > Francois Gouget <[EMAIL PROTECTED]> writes: > > > >> -noname vs. ordinal internal consistency > >> - > >> > >> This check verifies that all APIs which have the '-noname' property, > >> also have an explicit ordinal. This is the only check which does not > >> depend on dumps of the Windows dlls. > > > > Actually this is enforced by winebuild, so you will never find a > > problem here. > > Ok. I've removed it. Do the other checks make sense to you? Are they > useful? Any other useful tests to perform? Yes I think they are very useful, though I wouldn't suggest blindly fixing things based on the reports since I suspect that at least in some cases we have wrong ordinals and this will cause complaints about the wrong functions. We should definitely strive to make the checks pass as much as possible, but doing that will require a careful analysis of each case. Another very useful test would be the ability that you mentioned to correlate with the MS import libs too, but that's not trivial to do. -- Alexandre Julliard [EMAIL PROTECTED]
Should winecfg drive detection create device symlinks
Hey, I was wondering if winecfg should create symlinks for devices (dosdevices/d:: -> /dev/cdrom)? If it has to, how should it be implented. I can only see drive device symlinks created here: http://source.winehq.org/source/dlls/kernel/volume.c#L219 But I don't think that's the correct place to do it. Can we maybe have a custom flag in DefineDosDevice? I think that would be the right place to do it. Kind regards, Paul
Re: Checking Wine's spec files
On Mon, 21 Feb 2005, Alexandre Julliard wrote: Francois Gouget <[EMAIL PROTECTED]> writes: -noname vs. ordinal internal consistency - This check verifies that all APIs which have the '-noname' property, also have an explicit ordinal. This is the only check which does not depend on dumps of the Windows dlls. Actually this is enforced by winebuild, so you will never find a problem here. Ok. I've removed it. Do the other checks make sense to you? Are they useful? Any other useful tests to perform? -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
Re: Wrong keycodes (bug#2742) ?
George Ginden ha scritto: Hi do you guys know anything about that already ? It looks like some keys are not mapped correctly: Also this is related to bug #2742: http://bugs.winehq.org/show_bug.cgi?id=2742
Re: regression
On Mon, 21 Feb 2005 16:47:11 +, Oliver Stieber wrote: > Now it starts up and I get the error. > > "err:virtual:NtMapViewOfSection Sizes larger than 4Gb > not supported" Wacky. Can you post a +ole,+tid,+seh trace please.
Re: Checking Wine's spec files
Francois Gouget <[EMAIL PROTECTED]> writes: > -noname vs. ordinal internal consistency > - > > This check verifies that all APIs which have the '-noname' property, > also have an explicit ordinal. This is the only check which does not > depend on dumps of the Windows dlls. Actually this is enforced by winebuild, so you will never find a problem here. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Ctrl-Shift-N recognized as Ctrl-N
Le samedi 19 fÃvrier 2005 Ã 10:02 +0100, Tobias Burnus a Ãcrit : > PPS: Can one now submit new applications to the app.winehq.org app > database? I already tried several times, but I got no response at all, > then I gave up. > It works. But the application you submit have to be reviewed before integration in the database (takes 1-2 days).
Re: status of wine dll's
Michael Jung <[EMAIL PROTECTED]> writes: > * I think we should get rid of the rsabase.dll entry on the status_dll site > (and probably also in wine cvs): rsaenh.dll is a complete replacement and > rsabase isn't shipped anymore by Microsoft since Win2k (Applications don't > load rsabase/rsaenh directly, but via advapi32, which looks it up in the > registry). I'm not convinced we want to remove it completely, there just might be an app somewhere that looks for it explicitly, and it doesn't cost anything to keep it. We could remove the code though, and make it forward everything to rsaenh. -- Alexandre Julliard [EMAIL PROTECTED]
regression
Hi, I've had a regression with Creatures 2 between and 2005-02-03 and 2005-02-19.. Creatures 2 makes heavy use of out-of-process COM for it's components, the main screen used to work ok (but the components didn't). Now it starts up and I get the error. "err:virtual:NtMapViewOfSection Sizes larger than 4Gb not supported" I'll try to find out what patch caused the regression. 1 0x405168ec RaiseException 2 0x5f45394berr:virtual:NtMapViewOfSection Sizes larger than 4Gb not supported ?? in mfc42 (0x406ffcd8) 3 0x5f40d992 ?? in mfc42 (0x0047ceb8) ...stack missing. other threads are waiting for ConnectNamedPipe,sync.c:1311 RPCRT4_Receive,rpc_message.c:312 RPCRT4_process_packet,rpc_server.c:316 ... RPCRT4_server_thread, rpc_server.c:506 User_update_thread, dsurface/user.c:515 RPCRT4_worker_thread, rpc_server.c:353 ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Checking Wine's spec files
The recent problems with -noname in shell32.spec got be to dig up an old script I had which reads spec and dumpbin files and processes them. I then retrofitted it so it could do some hopefully useful checks for this kind of issues. So this script works by comparing the output of winedump or dumpbin on the Windows dlls for as many platforms as are available (I have 7 so far) with the contents of Wine's spec files. It then applies a number of rules to try to detect problems. However the information we can extract from the Windows dlls is incomplete so this script uses heuristics. This means the problems it reports should be treated with a grain of salt. Running the check script To download and run the check script, see the instructions are on my web site: http://fgouget.free.fr/wine/checkspec-en.shtml Then you can run it as follows: ./check_spec --verbose ~/wine/dlls/shell32.spec And here is a description of the checks it performs so far, illustrated with the output for shell32.dll. Comments and suggestions for more checks or improvements are welcome. I'll wait a bit (and then start sending some patches unless someone else wants to tackle this (could be a nice janitorial project). Notes: * It would be nice if winedump could dump the Platform SDK's .lib files. These files must have an explicit mention of which entry points have the -noname property so this would give us a more reliable source of information than the heuristics in this script. * dumpbin will something special when an API is being forwarded: 40 [NONAME] (forwarded to shlwapi.PathIsRelativeW) But winedump prints nothing special. It would be nice to add this functionality to winedump. -noname vs. ordinal internal consistency - This check verifies that all APIs which have the '-noname' property, also have an explicit ordinal. This is the only check which does not depend on dumps of the Windows dlls. No problem found here. APIs which should not have an explicit ordinal -- The script scans the Wine spec file for APIs which have both a name and an explicit ordinal. For each of these, the script looks up the API by name on the Windows platforms and collates a list of the corresponding ordinals. If it finds more than one ordinal then it considers the API should not be given an explicit ordinal. In that case it reports how many times the API was found with the right ordinal on Windows, and how many different values were found. If the former is 0 or 1 then it's clear the API should not be given an explicit ordinal. If the latter is 2 then things are maybe not so clear. These 64 APIs should not have an ordinal: SHGetDataFromIDListA (correct 0 times, found 5 values) StrChrIW (correct 0 times, found 3 values) SheGetCurDrive (correct 0 times, found 5 values) ShellAboutW(correct 0 times, found 5 values) SheFullPathA (correct 0 times, found 5 values) DllGetClassObject (correct 0 times, found 5 values) SheGetDirA (correct 0 times, found 5 values) SheGetPathOffsetW (correct 0 times, found 5 values) SheGetDirW (correct 0 times, found 5 values) DragFinish (correct 0 times, found 5 values) StrCmpNW (correct 0 times, found 3 values) StrNCmpA (correct 0 times, found 3 values) StrCmpNIA (correct 0 times, found 3 values) ShellExecuteW (correct 0 times, found 5 values) SheChangeDirW (correct 0 times, found 5 values) Shell_NotifyIconW (correct 0 times, found 5 values) StrCpyNA (correct 0 times, found 3 values) SheRemoveQuotesW (correct 0 times, found 5 values) StrCmpNA (correct 0 times, found 3 values) ShellExecuteExA(correct 0 times, found 5 values) StrRStrIA (correct 0 times, found 3 values) StrStrA(correct 0 times, found 3 values) StrStrW(correct 0 times, found 3 values) StrChrA(correct 0 times, found 3 values) SheShortenPathA(correct 0 times, found 5 values) StrNCmpIW (correct 0 times, found 3 values) StrRChrIA (correct 0 times, found 3 values) StrChrIA (correct 0 times, found 3 values) SheConvertPathW(correct 0 times, found 5 values) StrNCpyW (correct 0 times, found 3 values) DragAcceptFiles(correct 0 times, found 5 values) StrRStrIW (correct 0 times, found 3 values) StrNCmpIA (correct 0 times, found 3 values) Shell_NotifyIconA (
Re: Installshield (with Roller Coaster Tycoon demo)
On Mon, Feb 21, 2005 at 04:57:05PM +0100, Paul Vriens wrote: > On Mon, 2005-02-21 at 15:16, Paul Vriens wrote: > > Hi (again), > > > > I've applied OLE#75 and OLE#76 and now I've something that doesn't look > > right: > > > > trace (without OLE75/OLE76 and with native stdole32.tlb): > > > > 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc) > > 000b:trace:ole:LoadTypeLibEx > > (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc) > > 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" > > index 1 > > 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240 > > > > trace (with OLE75/OLE76 and builtin stdole32.tlb): > > > > 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x3dd0dc) > > 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x3dd0dc) > > 000b:trace:ole:LoadTypeLibEx File L"stdole32.tlb" index 1 > > 000b:trace:ole:TLB_ReadTypeLib not found, trying to load L"stdole32.tlb" as > > library > > 000b:trace:loaddll:load_dll Loaded module > > L"c:\\windows\\system\\stdole32.tlb" : builtin > > 000b:trace:ole:ITypeLib2_Constructor_MSFT 0xe31180, TLB length = 4384 > > > > trace (with OLE75/OLE76 and native stdole32.tlb copied to \windows\system): > > > > 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x80d0dc) > > 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x80d0dc) > > 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" > > index 1 > > 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e9602b0, TLB length = 4240 > > > > Why do we use _SLTG in the first and last trace and _MSFT in the second? > > > > Cheers, > > > > Paul. > > > I have 3 native stdole files: > > [EMAIL PROTECTED] tools]$ ll std* > -rw-rw-r-- 1 paul paul 16896 Feb 21 14:39 stdole2.tlb > -rw-rw-r-- 1 paul paul 7168 Feb 17 19:57 stdole32.tlb > -rw-rw-r-- 1 paul paul 5472 Feb 21 16:48 stdole.tlb > > `strings` show: > > [EMAIL PROTECTED] tools]$ strings stdole2.tlb | grep -e MSFT -e SLTG > MSFT > [EMAIL PROTECTED] tools]$ strings stdole32.tlb | grep -e MSFT -e SLTG > SLTG > [EMAIL PROTECTED] tools]$ strings stdole.tlb | grep -e MSFT -e SLTG > SLTG > > This explains the traces (a bit). But not why our stdole32.tlb has a > MSFT signature. Becasue we only have typelib generation code for MSFT type typelibs. The assumption is that no app will actually try to parse the typelib itself so we're free to use either format. Huw. -- Huw Davies [EMAIL PROTECTED]
Wrong keycodes ?
Hi do you guys know anything about that already ? It looks like some keys are not mapped correctly: grep -r VK_* * | grep include/winuser.h include/winuser.h:#define VK_LEFT 0x25 include/winuser.h:#define VK_UP 0x26 include/winuser.h:#define VK_RIGHT0x27 include/winuser.h:#define VK_DOWN 0x28 These keys are the directional arrows, not the numpad keys... Now look at what wine thinks about those keys when block num is not kicked in: tail -f /projects/tmp/winetrace.log | grep keyboard trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = trace:keyboard:X11DRV_ToUnicodeEx Found keycode 83 (0x53) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff96 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = trace:keyboard:X11DRV_ToUnicodeEx Found keycode 80 (0x50) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff97 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = trace:keyboard:X11DRV_ToUnicodeEx Found keycode 85 (0x55) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff98 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = trace:keyboard:X11DRV_ToUnicodeEx Found keycode 88 (0x58) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff99 Kickin'in the block num: trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 100 (0x64) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff51 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 98 (0x62) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff52 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 102 (0x66) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff53 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 104 (0x68) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff54 What's wrong ? Oh, and this output is when using within a edit control. Last but not least, any test against VK_UP VK_DOWN, VK_LEFT, VK_RIGHT fails ... Regards.
Re: Installshield (with Roller Coaster Tycoon demo)
On Mon, 2005-02-21 at 15:16, Paul Vriens wrote: > Hi (again), > > I've applied OLE#75 and OLE#76 and now I've something that doesn't look > right: > > trace (without OLE75/OLE76 and with native stdole32.tlb): > > 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc) > 000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc) > 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1 > 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240 > > trace (with OLE75/OLE76 and builtin stdole32.tlb): > > 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x3dd0dc) > 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x3dd0dc) > 000b:trace:ole:LoadTypeLibEx File L"stdole32.tlb" index 1 > 000b:trace:ole:TLB_ReadTypeLib not found, trying to load L"stdole32.tlb" as > library > 000b:trace:loaddll:load_dll Loaded module > L"c:\\windows\\system\\stdole32.tlb" : builtin > 000b:trace:ole:ITypeLib2_Constructor_MSFT 0xe31180, TLB length = 4384 > > trace (with OLE75/OLE76 and native stdole32.tlb copied to \windows\system): > > 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x80d0dc) > 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x80d0dc) > 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1 > 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e9602b0, TLB length = 4240 > > Why do we use _SLTG in the first and last trace and _MSFT in the second? > > Cheers, > > Paul. > I have 3 native stdole files: [EMAIL PROTECTED] tools]$ ll std* -rw-rw-r-- 1 paul paul 16896 Feb 21 14:39 stdole2.tlb -rw-rw-r-- 1 paul paul 7168 Feb 17 19:57 stdole32.tlb -rw-rw-r-- 1 paul paul 5472 Feb 21 16:48 stdole.tlb `strings` show: [EMAIL PROTECTED] tools]$ strings stdole2.tlb | grep -e MSFT -e SLTG MSFT [EMAIL PROTECTED] tools]$ strings stdole32.tlb | grep -e MSFT -e SLTG SLTG [EMAIL PROTECTED] tools]$ strings stdole.tlb | grep -e MSFT -e SLTG SLTG This explains the traces (a bit). But not why our stdole32.tlb has a MSFT signature. Cheers, Paul.
"bachelor project" with wine ?
Hello, I'm supposed to choose a topic - and work it out - for a "bachelor project"; Now, at the moment I have no clue, and teachers are discussing what topics to hand; in the mean time, I think maybe it might be interesting to do some wine work in such a form that it's ok for this "bachelor project" :) This project is supposed to be something like 308 hours; and of course, it should be possible to show something interesting at the end of that. About my background, I have a few years of (simple) programming experience (in C and C++, mostly) and most of that was done under linux -- just school programs most of the time; I don't have much experience with X programming and *none at all* with winapi; Is there a "project"/are there "projects" in wine, suitable for this? It's ok if I have to do api learning but ofcourse that'd take a part of those hours; As you can see, it should be some clearly showable (either visible or something in behavior) progress in running windows executables under wine; I hope you can give me a hand finding an interesting topic (and I guess I'll be asking a lot of questions here in the coming weeks if you hand me something I want to work on ;) ) thanks in advance for any ideas regards Joris
Re: Microsoft genuine downloads looking for wine
On February 19, 2005 03:19 pm, Brian Vincent wrote: > On Sat, 19 Feb 2005 13:25:17 -0700, Jesse Allen <[EMAIL PROTECTED]> wrote: > > On Wed, 16 Feb 2005 22:28:59 +0100, Ivan Leo Puoti <[EMAIL PROTECTED]> wrote: > > > By quickly looking at the program, I noticed it looks for a registry > > > key, this key is... > > > SOFTWARE\Wine\Wine\Config > > > the wine configuration key. > > > > Has anyone tried creating this key on Win2k or 98 and seeing what > > happens with the program? > > I just created the SOFTWARE\Wine\Wine\Config key here on both Win98 > and Win2k. It failed. > > Both print the same error: It ran fine on mine (running GenuineCheck.exe). However that might be because I had already run it a couple of times before I added the key. -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: Installshield (with Roller Coaster Tycoon demo)
Hi (again), I've applied OLE#75 and OLE#76 and now I've something that doesn't look right: trace (without OLE75/OLE76 and with native stdole32.tlb): 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc) 000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa9d0dc) 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e8702b0, TLB length = 4240 trace (with OLE75/OLE76 and builtin stdole32.tlb): 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x3dd0dc) 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x3dd0dc) 000b:trace:ole:LoadTypeLibEx File L"stdole32.tlb" index 1 000b:trace:ole:TLB_ReadTypeLib not found, trying to load L"stdole32.tlb" as library 000b:trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\stdole32.tlb" : builtin 000b:trace:ole:ITypeLib2_Constructor_MSFT 0xe31180, TLB length = 4384 trace (with OLE75/OLE76 and native stdole32.tlb copied to \windows\system): 000b:trace:ole:LoadTypeLib (L"stdole32.tlb",0x80d0dc) 000b:trace:ole:LoadTypeLibEx (L"stdole32.tlb",0,0x80d0dc) 000b:trace:ole:LoadTypeLibEx File L"C:\\windows\\system\\stdole32.tlb" index 1 000b:trace:ole:ITypeLib2_Constructor_SLTG 0x7e9602b0, TLB length = 4240 Why do we use _SLTG in the first and last trace and _MSFT in the second? Cheers, Paul.
Re: [OLE #76] Avoid infinite loop when doing a typelib marshalled IUnknown::QueryInterface
Rob Shearman wrote: Does this happen with only builtin oleaut32? I'm not sure, I didn't try mixing native/builtins for this problem. If so, it should be fixed so that it doesn't cause an infinite loop. I don't think standard marshaled proxies should cause infinite loops (if I remember the test cases we have correctly). Yes, I also have a vague feeling that it may be covering up for an issue elsewhere, but can't quite place my finger on what. The problem was quite subtle and confusing (as everything in DCOM is ) InstallShield gets a TLB proxy xCall, IUnknown::QueryInterface -> rpc to stub -> IRemUnknown::RemQueryInterface marshals result tmarshal.c:_unmarshal_interface called on the result of the QI CoUnmarshalInterface( ... results of QI ... ) IMarshal::UnmarshalInterface sets up the TLBProxy IUnknown::QueryInterface on the TLBProxy object xCall, IUnknown::QueryInterface -> rpc to stub -> [infinite loop] I have a feeling the QI in CoUnmarshalInterface should be a no-op because the typelib proxies should aggregate the proxy manager, which would optimize out a QI for an already unmarshalled interface. So possibly the real issue is that we never made the tmarshaller aggregate the proxy manager. I don't recall if you did that or not, I know I didn't. However, this patch should go in as it is a good optimisation. Right. It also unblocks InstallShield for the time being, letting us get back to the stage where it needs RPC re-entrancy. thanks -mike
Re: World Of Warcraft
On Mon, Feb 21, 2005 at 10:58:31AM +0100, Lionel Ulmer wrote: > Can you send me the same snippet of log but with the patch you sent the > other day ? It's just to be sure that it correctly advertises the three new > extensions you added in your patch :) > > If all the wglGetProcAddress lines were in the log too, it would even be > better (i.e. even if the application does not use the new functions, we can > check if it even tries to get new ones compared to a log without your > patch). grep -C 2 "wglGetProcAddress" dump-1.txt: 0009:trace:opengl:wine_glGetString (7938) 0009:trace:opengl:wine_glGetString (7939) 0009:trace:opengl:wglGetProcAddress (glLockArraysEXT) 0009:trace:opengl:wglGetProcAddress returning function (0x561a14b0) 0009:trace:opengl:wglGetProcAddress (glUnlockArraysEXT) 0009:trace:opengl:wglGetProcAddress returning function (0x561b12d0) 0009:trace:opengl:wine_glGetIntegerv (34018, 0xa2b680) 0009:trace:opengl:wglGetProcAddress (glActiveTextureARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56190a50) 0009:trace:opengl:wglGetProcAddress (glClientActiveTextureARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56192e40) 0009:trace:opengl:wglGetProcAddress (glCompressedTexImage2DARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56194990) 0009:trace:opengl:wglGetProcAddress (glCompressedTexSubImage2DARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56194f00) 0009:trace:opengl:wglGetProcAddress (glBindBufferARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56191770) 0009:trace:opengl:wglGetProcAddress (glDeleteBuffersARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56196620) 0009:trace:opengl:wglGetProcAddress (glGenBuffersARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56199cb0) 0009:trace:opengl:wglGetProcAddress (glBufferDataARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56192a70) 0009:trace:opengl:wglGetProcAddress (glBufferSubDataARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56192c60) 0009:trace:opengl:wglGetProcAddress (glMapBufferARB) 0009:trace:opengl:wglGetProcAddress returning function (0x561a16f0) 0009:trace:opengl:wglGetProcAddress (glUnmapBufferARB) 0009:trace:opengl:wglGetProcAddress returning function (0x561b13e0) 0009:trace:opengl:wglGetProcAddress (glDrawRangeElementsEXT) 0009:trace:opengl:wglGetProcAddress returning function (0x56197a30) 0009:trace:opengl:wine_glGetIntegerv (33000, 0x55bdfc50) 0009:trace:opengl:wine_glGetIntegerv (33001, 0x55bdfc44) 0009:trace:opengl:wglGetProcAddress (glCombinerInputNV) 0009:trace:opengl:wglGetProcAddress returning function (0x561940f0) 0009:trace:opengl:wglGetProcAddress (glCombinerOutputNV) 0009:trace:opengl:wglGetProcAddress returning function (0x561941b0) 0009:trace:opengl:wglGetProcAddress (glFinalCombinerInputNV) 0009:trace:opengl:wglGetProcAddress returning function (0x561983f0) 0009:trace:opengl:wglGetProcAddress (glCombinerParameterfvNV) 0009:trace:opengl:wglGetProcAddress returning function (0x56194360) 0009:trace:opengl:wglGetProcAddress (glCombinerParameteriNV) 0009:trace:opengl:wglGetProcAddress returning function (0x561943f0) 0009:trace:opengl:wglGetProcAddress (glCombinerStageParameterfvNV) 0009:trace:opengl:wglGetProcAddress returning function (0x56194510) 0009:trace:opengl:wglGetProcAddress (glProgramStringARB) 0009:trace:opengl:wglGetProcAddress returning function (0x561a9010) 0009:trace:opengl:wglGetProcAddress (glBindProgramARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56191a40) 0009:trace:opengl:wglGetProcAddress (glProgramLocalParameter4fvARB) 0009:trace:opengl:wglGetProcAddress returning function (0x561a8830) 0009:trace:opengl:wglGetProcAddress (glDeleteProgramsARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56196ae0) 0009:trace:opengl:wglGetProcAddress (glGenProgramsARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56199f70) 0009:trace:opengl:wglGetProcAddress (glIsProgramARB) 0009:trace:opengl:wglGetProcAddress returning function (0x561a0880) 0009:trace:opengl:wglGetProcAddress (glGetProgramivARB) 0009:trace:opengl:wglGetProcAddress returning function (0x5619dc00) 0009:trace:opengl:wine_glGetIntegerv (34929, 0xa2b67c) 0009:trace:opengl:wine_glGetIntegerv (34930, 0xa2b678) 0009:trace:opengl:wglGetProcAddress (glVertexAttribPointerARB) 0009:trace:opengl:wglGetProcAddress returning function (0x561b65a0) 0009:trace:opengl:wglGetProcAddress (glEnableVertexAttribArrayARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56197e90) 0009:trace:opengl:wglGetProcAddress (glDisableVertexAttribArrayARB) 0009:trace:opengl:wglGetProcAddress returning function (0x56197310) 0009:trace:opengl:wglGetProcAddress (glProgramStringARB) 0009:trace:opengl:wglGetProcAddress returning function (0x561a9010) 0009:trace:opengl:wglGetProcAddress (glBindProgramARB) 0009:trace:opengl:wglGetProcAddress returning f
Re: World Of Warcraft
On Mon, Feb 21, 2005 at 08:58:26AM +, Alex Woods wrote: > Yes, doesn't look any different though. I did notice that with either > patch I get this though: > > 0009:warn:opengl:wglGetProcAddress Did not find extension > wglGetExtensionsStringARB in either Wine or your OpenGL library. > > Whereas without the patches I get this: > > 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB) > 0009:trace:opengl:wglGetProcAddress returning WGL function (0x561cbf90) > 0009:trace:opengl:wglGetCurrentDC () > 0009:trace:opengl:wglGetCurrentDC returning 0x7b8 (GL context 0x780d7fd8 - > Wine context 0x5593f478) > 0009:trace:opengl:wglGetExtensionsStringARB () returning > "WGL_ARB_extensions_string WGL_EXT_extensions_string" > > So something must be broken ;) Can you send me the same snippet of log but with the patch you sent the other day ? It's just to be sure that it correctly advertises the three new extensions you added in your patch :) If all the wglGetProcAddress lines were in the log too, it would even be better (i.e. even if the application does not use the new functions, we can check if it even tries to get new ones compared to a log without your patch). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: World Of Warcraft
On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote: > Hi Alex, > > can you try this patch ? Well, as even with adding the new extensions in the string reported to the application via wglQueryExtensionStrings it does not try to get these extensions, I wonder if the problem is really related to our GL support or if it does not come from somewhere else (it does a lot of strange stuff like SuspendThread and co around the time it returns the error - no idea if it's part of their 'assert' procedure or if it is 'normal'). Or maybe it's not waiting for either PBuffers or render-to-texture but another extension (and then it should fail at the start, not after logging to the game). So we could add all known WGL extensions to the list and see what happens :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: World Of Warcraft
On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote: > can you try this patch ? Yes, doesn't look any different though. I did notice that with either patch I get this though: 0009:warn:opengl:wglGetProcAddress Did not find extension wglGetExtensionsStringARB in either Wine or your OpenGL library. Whereas without the patches I get this: 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB) 0009:trace:opengl:wglGetProcAddress returning WGL function (0x561cbf90) 0009:trace:opengl:wglGetCurrentDC () 0009:trace:opengl:wglGetCurrentDC returning 0x7b8 (GL context 0x780d7fd8 - Wine context 0x5593f478) 0009:trace:opengl:wglGetExtensionsStringARB () returning "WGL_ARB_extensions_string WGL_EXT_extensions_string" So something must be broken ;) -- Alex
Re: World Of Warcraft
Hey Alex, On Mon, 21 Feb 2005 09:33:29 +0100, Raphael <[EMAIL PROTECTED]> wrote: > Hi Alex, > > can you try this patch ? Just applied and tried. It doesn't seem to get the game any further. I can provide you with a log if you like. Paul
Re: World Of Warcraft
Hi Alex,
can you try this patch ?
Regards,
Raphael
> On Sun, Feb 20, 2005 at 01:43:44PM +0100, Lionel Ulmer wrote:
> > Well, if you want just to test if the application works better, just add
> > (stubbed) support for the following extensions:
> >
> > http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pixel_format.txt
> > http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pbuffer.txt
> > http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_render_texture.tx
> >t
> >
> > This entails:
> >
> > = adding the string for the extension in the WGL extension string (no
> > idea if it needs to be duplicated also in the 'standard' extension
> > string). = adding all functions that are described in the three preceding
> > extensions (having them returning correct values) and printing debug
> > output = run the game again and see if it actually uses now these
> > functions and if it works better (ie better in 'not crashing', not better
> > as in 'working'
> >
> >:-) ).
>
> Well, I've given it a try, but they're either not getting called, or I
> haven't implemented them correctly (first time hacking wine). I've
> included a patch below showing what I've done. A few of them don't
> return nice values, but I figured it should get to the traces if they
> are getting called.
>
> > > I guess it's not just a case of passing through like the bulk of the
> > > opengl functions or they'd be done already.
> >
> > For PBuffers, the WGL and SGIX interface is a bit different so an
> > adaptation is required. For 'render to texture', one needs to use
> > 'GL_EXT_framebuffer_object' (or PBuffers) to emulate the extension.
> >
> > So this is not the 'simple' thunking that most of the rest of the OpenGL
> > implementation is...
>
> Well, if I can confirm that some of the functions are getting called, I
> may as well have a go at it ;)
>
> Thanks for your help.
>
> Index: opengl32.spec
> ===
> RCS file: /home/wine/wine/dlls/opengl32/opengl32.spec,v
> retrieving revision 1.23
> diff -u -r1.23 opengl32.spec
> --- opengl32.spec 7 Feb 2004 01:29:33 - 1.23
> +++ opengl32.spec 20 Feb 2005 16:09:21 -
> @@ -24,6 +24,17 @@
> @ stdcall wglGetPixelFormat(long) gdi32.GetPixelFormat
> @ stdcall wglSetPixelFormat(long long ptr) gdi32.SetPixelFormat
> @ stdcall wglSwapBuffers(long) gdi32.SwapBuffers
> +@ stdcall wglGetPixelFormatAttribivARB(ptr long long long ptr ptr)
> +@ stdcall wglGetPixelFormatAttribfvARB(ptr long long long ptr ptr)
> +@ stdcall wglChoosePixelFormatARB(ptr ptr ptr long ptr ptr)
> +@ stdcall wglCreatePbufferARB(ptr long long long ptr)
> +@ stdcall wglGetPbufferDCARB(ptr)
> +@ stdcall wglReleasePbufferDCARB(ptr ptr)
> +@ stdcall wglDestroyPbufferARB(ptr)
> +@ stdcall wglQueryPbufferARB(ptr long long)
> +@ stdcall wglBindTexImageARB(ptr long)
> +@ stdcall wglReleaseTexImageARB(ptr long)
> +@ stdcall wglSetPbufferAttribARB(ptr ptr)
> @ stdcall glAccum( long long ) wine_glAccum
> @ stdcall glAlphaFunc( long long ) wine_glAlphaFunc
> @ stdcall glAreTexturesResident( long ptr ptr )
> wine_glAreTexturesResident Index: wgl_ext.c
> ===
> RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
> retrieving revision 1.2
> diff -u -r1.2 wgl_ext.c
> --- wgl_ext.c 31 Jan 2005 11:32:13 - 1.2
> +++ wgl_ext.c 20 Feb 2005 16:09:43 -
> @@ -39,7 +39,7 @@
>
> /* Some WGL extensions... */
> static const char *WGL_extensions_base = "WGL_ARB_extensions_string
> WGL_EXT_extensions_string"; -static char *WGL_extensions = NULL;
> +static char *WGL_extensions = "WGL_ARB_pixel_format WGL_ARB_pbuffer
> WGL_ARB_render_texture";
>
> /* Extensions-query functions */
> BOOL query_function_pbuffers(const char *gl_version, const char
> *gl_extensions, const char *glx_extensions, @@ -143,11 +143,89 @@
> }
> }
>
> +GLboolean WINAPI wglGetPixelFormatAttribivARB(HDC hdc, int iPixelFormat,
> int iLayerPlane, UINT nAttributes, const int *piAttributes, int *piValues)
> +{
> +TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane,
> nAttributes, piAttributes, piValues); +return GL_TRUE;
> +}
> +
> +GLboolean WINAPI wglGetPixelFormatAttribfvARB(HDC hdc, int iPixelFormat,
> int iLayerPlane, UINT nAttributes, const int *piAttributes, FLOAT
> *pfValues) +{
> +TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane,
> nAttributes, piAttributes, pfValues); +return GL_TRUE;
> +}
> +
> +GLboolean WINAPI wglChoosePixelFormatARB(HDC hdc, const int
> *piAttribIList, const FLOAT *pfAttribFList, UINT nMaxFormats, int
> *piFormats, UINT *nNumFormats) +{
> +TRACE("(%p, %p, %p, %d, %p, %p)\n", hdc, piAttribIList, pfAttribFList,
> nMaxFormats, piFormats, nNumFormats); +return GL_TRUE;
> +}
> +
> +#define HPBUFFERARB void *
> +HPBUFFERARB WINAPI wglCreatePbufferARB(HDC hdc, int iPixelFormat, int
> iWidth, int iHeight, const int *piAttr
Re: Collection of wine tools on windows
Dimitrie O. Paun wrote: > Heh, the MinGW folks seem to have some strange requirements for their headers, I don't think they'll drop theirs. But we can start by having ReactOS adopt our headers. We should also offer our headers as a separate package that works out of the box as a replacement for the MinGW ones. This way people can just get our headers if they are better than the MinGW ones. Can't the win32api package headers be used to replace the mingw headers? Ivan.
Re: Winemaker questions
Francois Gouget wrote:
__TRY {}/__FINALLY()? I'm not sure the changes I did are now compilable
under MSVC nor MingW.
4) Would there be a way to transform __try {}/__finally{} blocks to
Unfortunately they don't work exactly the same. There has been many
attempts to improve exception support in Winelib but none that were
deemed good enough to be committed to CVS.
Below is a technique I use in C++. I'm not sure it can be used in C. But
if you have C++ it is perfect. And nothing needs done in Winemaker Just
have the #define available before the using code like in your StdAfx.h
file.
<__try__finally>
#define __try try
#define _CONCAT_(s1,s2) s1##s2
#define __except( foofoo ) \
catch(...){ \
int d = foofoo ; \
switch(d){ \
case 0: \
throw ; \
case -1: \
case 1 : \
goto _CONCAT_(gifs,__LINE__) ; } } _CONCAT_(gifs,__LINE__) :
the CONCAT macro is because of the pseudo 2 pass of the preprocessor,
Other wise the __LINE__ is not expanded to produce a unique goto label.
goto is used to jump over the "}}" closing scope of the catch and
switch. So using code does not change. (There is one restriction you
can't use 2 __except statements in the same line)
Free Life
Boaz
