Typo on download page for debian packages
Hi, I don't know who who is responsible for maintaining the website, but probably he will read wine-devel ;-) I found a little typo on the download site for the debian packages. The link to the repository works for me only without the space: deb http://wine.sourceforge.net/apt/ binary/ should be: deb http://wine.sourceforge.net/apt/binary/ cu, Stefan pgpksIzNPS1kD.pgp Description: PGP signature
Re: Bug 3885
Hi, On Thursday 22 December 2005 03:29, Aric Cyr wrote: Tom Spear speeddymon at gmail.com writes: Aric Cyr wrote: I took a look at the D3D_OK hack, and I believe the problem to be CheckDeviceFormat in wined3d/directx.c. This function should return an error if D3DFMT_D32 is checked for on cards which don't support 32bit depth. Currently it just returns OK for most formats though. This code is really just a stub as it stands, and needs to be converted to check if there are any visuals that meet the requested format's requirements, and if there is, return D3D_OK, otherwise D3D_NOTAVAILBLE. To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case (you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() and see if that fixes that issue or not. This would be just another hack though, so a real patch would still be necessary as I decribed above. Well I took a stab at adding the case for D3DFMT_D32, to the bottom of the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes the first one and then goes to do the second one, but crashes in a different spot, so it seems we also have some stack corrupion (as was mentioned in the bug).. So that hack works for now, I would suggest that since the rest of that code is stubbed out, we should probably go ahead and submit a patch so we can at least run the darn thing and then start debugging the stack corruption issue. Thanks for testing this out. You have proved my theory correct, so I'll see about making a patch which will correct CheckDeviceFormat(). Basically that whole function needs a re-write, so I'd rather do it that way than to put this hack in there. Especially since, I assume, this problem is not present on nVidia systems, only ATI. No, as x11 only handle 24 bpp buffers (instead of 32), GLX always reports 24 bpp on such cards (for depth buffers) and many games want 16 or 32 Depth Buffers (only few support 24 bits) for exemple in mine card, i have a lot of config as: id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 0 0 None ... 0x67 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon ... always 24-bpp for Depth Buffer for 32-bpp Pixel Buffer (stupid limitation ?) I hate X11 limitations :( Maybe one day we will have a native alpha support and 32-bpp for buffers on X I should add that on the first run, I disabled the title screens between benchmarks, and changed the Display and CPU Settings so that I was using 32-bit textures and triple buffering, and it ran thru several of the tests, while on the 2nd and 3rd runs, I left all settings at defaults; during run 2, it died just after the title screen for mark #2, and during run 3, it died in the middle of mark #2... If I'm not mistaken, doesn't 3DMark change resolutions between benchmark and title screens? If so, it is possible, and quite likely that there is a resolution change bug in wine. If I recall, I had similar crashing problems with World of Warcraft if I tried to change resolutions from in-game. Wine cannot change resolution in-game. as created window and associated context are managed by x11drv init we cannot handle this case (and never manage case you want to change bpp because of x11 limitations). Anyway i plan (when i'll have time, and when ddraw will use wined3d) to rethink x11drv glx init to only init glx window context on need (so in future only for opengl32 and wined3d) using wanted rendering options. Regards, Aric Regards, Raphael pgpTSnH7DKSmI.pgp Description: PGP signature
Re: [lostwages] Remove winetools from download page
On Thu, 22 Dec 2005 02:59:57 +0100, Tom Wickline [EMAIL PROTECTED] wrote: On 12/21/05, James Hawkins [EMAIL PROTECTED] wrote: As much as I appreciate the work you, Joachim, and others have put into winetools, we're getting closer to the point in time when winetools needs to be phased out by a better, more functional wine. Getting closer, sure, but it's not for tommorow Part of this process is removing it from the official download page. Part of this process will be removing winetool link. is implies the present and we are not at this stage with wine yet. Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say we need to have Wine run everything out of the box and to accomplish this were going to remove a link to a user friendly tool that currently helps our users. I agree, I think there has to be an easy start method with at least half a chance of getting things running. Most new users , many probably new to linux as well will NOT even be aware of what an IRC channel is an probably never met a maiing list either. It seems some of the ppl posting on this thread dont even realise that they are living on a different plane to those actually using wine. If new users cant get some positive result quickly they will just conclude that wine is unusable, and from an average user point , they would be right. If they can be hooked by getting somethings to work they _may just_ go a bit further with some things that dont. Hell , they may even read the doc if they can find it. As for argueing that bugs wont get reported. I was not aware that there was a shortage of things to do in fixing Wine. If Wine scares off new users by expecting everyone to be a software developer it will fail in it's primary role of helping users to migrate to Linux. regards.
Re: ATI Opengl regression (DRI?)
On Friday 16 December 2005 02:26, Aric Cyr wrote: Raphael fenix at club-internet.fr writes: On Thursday 15 December 2005 19:55, Jesse Allen wrote: Hi, It seems that the patch git-1399edb0925966a802a6a39835025c22c22c18e1.patch found here http://www.winehq.org/pipermail/wine-cvs/2005-December/019731.html causes an opengl regression on my system. With the patch loading War3 causes X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply) Serial number of failed request: 429 Current serial number in output stream: 429 Which seems to stop the game loading thread and causes the game to use the fail-safe thread Please insert disc, so the game wont load. Reversing the patch fixes the problem. I have a Radeon 9200 using DRI snapshots about 20051024. X Window System Version 6.8.99.901 (6.9.0 RC 1) (Minimal DRI build from X.org tr ee) Release Date: 18 October 2005 + cvs X Protocol Version 11, Revision 0, Release 6.8.99.901 Build Operating System: Linux 2.6.14-rc5 i686 [ELF] Current Operating System: Linux tesore 2.6.15-rc4-git1 #1 PREEMPT Fri Dec 2 17:0 3:32 MST 2005 i686 Build Date: 28 October 2005 Is this a DRI problem? No, only that DRI don't implement GLX 1.3 i just sent a patch to fix (ie. by-pass) this regression. You really don't need to use glXQueryServerString() and glXQueryClientString(). It would be better, easier (not strcmp) and more correct to just use glXQueryVersion(). glXQueryVersion will automatically report the version common to both the client and server (so in this case 1.2). No, we cannot - glXGetFBConfigs is implemented by glx client (normally when glx client version 1.2 but in many 1.2 implementations its provided by Xorg). - glXQueryDrawable is only implemented by glx server (when glx server version 1.2) - for others calls we check if client version 1.2 else we use SGIX extension Another thing I don't understand in your patch is why you have wine_glx_t and wine_glx defined at global scope. It looks like the only place in your patch they are used is in wgl.c, so why not define wine_glx_t in wgl.c and make wine_glx static? Sorry if I am missing something. It's for future use by wgl_ext.c. I don't like the idea to duplicate glx version/extensions checks and glXGetProcAddressARB pointer parameter on functions (Also there is some DEPTH_BITS hack in internal_glGetIntegerv which I assume is unrelated to this GLX patch?) yes i comment it (i use it for debug) i thought that DRI implemented GLX 1.3 specs but seems they use a too older x code :( http://cvs.sourceforge.net/viewcvs.py/dri/xc/xc/programs/Xserver/GL/glx/ Too old perhaps, but that what DRI (and hence ATI) are using. Both support most of the 1.3 features so there really isn't much of an issue. The problem is that we cannot assume 1.3 regardless of how old 1.2 is. The reason for the glx version is so that we can do the right thing in any case. Not really, many of GLX features are supported by glx clients. And only old clients (ie X versions) reports 1.2 caps (and generaly they support 1.3 extensions) I have only problems with 1.2 glx servers (who don't support drawable queries), who is the DRI / ATI configuration :( Also seems like we should be relying on glXGetProcAddress() but need to be using glXGetProcAddressARB() since nVidia apparently doesn't export the former. ??? where you see glXGetProcAddress use ? wgl.c:1044: p_glXGetProcAddressARB = wine_dlsym(opengl_handle, glXGetProcAddressARB, NULL, 0); Regards, Aric Regards, Raphael pgpR4psJ4A0ZF.pgp Description: PGP signature
Resent: [opengl] fix last wgl regression
Resent resync patch with little correction
Regards,
Raphael
On Thursday 15 December 2005 23:59, Raphael wrote:
Hi,
Thix patch should fix last wgl patch regression
anyway i don't understand why ATI drivers don't support older GLX 1.3 specs
(as 1.4 is already here).
For glXGetFBConfigs i don't plan to support a compatibility code,
it should be too buggy (on pixel format selection) as was older opengl code
as we can't query visuals
Changelog:
- fix wgl regression: test glx server version and extensions to use (and
not use glXQueryDrawable on older glx implementations)
Regards,
Raphael
? opengl32.dll.dbg.c
? opengl32.spec.def
Index: wgl.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl.c,v
retrieving revision 1.71
diff -u -r1.71 wgl.c
--- wgl.c 8 Dec 2005 13:09:37 - 1.71
+++ wgl.c 15 Dec 2005 22:48:33 -
@@ -39,6 +39,9 @@
WINE_DEFAULT_DEBUG_CHANNEL(opengl);
+/** global glx object */
+wine_glx_t wine_glx;
+
/* x11drv GDI escapes */
#define X11DRV_ESCAPE 6789
enum x11drv_escape_codes
@@ -191,7 +194,7 @@
GLXFBConfig* cfgs_fmt = NULL;
int value;
int gl_test = 0;
-cfgs_fmt = glXGetFBConfigs(display, DefaultScreen(display), nCfgs_fmt);
+cfgs_fmt = wine_glx.p_glXGetFBConfigs(display, DefaultScreen(display), nCfgs_fmt);
if (NULL == cfgs_fmt || 0 == nCfgs_fmt) {
ERR(Cannot get FB Configs, expect problems.\n);
SetLastError(ERROR_INVALID_PIXEL_FORMAT);
@@ -203,7 +206,7 @@
return NULL;
}
cur_cfg = cfgs_fmt[hdcPF - 1];
-gl_test = glXGetFBConfigAttrib(display, cur_cfg, GLX_FBCONFIG_ID, value);
+gl_test = wine_glx.p_glXGetFBConfigAttrib(display, cur_cfg, GLX_FBCONFIG_ID, value);
if (gl_test) {
ERR(Failed to retrieve FBCONFIG_ID from GLXFBConfig, expect problems.\n);
SetLastError(ERROR_INVALID_PIXEL_FORMAT);
@@ -220,7 +223,7 @@
ret-display = display;
ret-fb_conf = cur_cfg;
/*ret-vis = vis;*/
- ret-vis = glXGetVisualFromFBConfig(display, cur_cfg);
+ ret-vis = wine_glx.p_glXGetVisualFromFBConfig(display, cur_cfg);
TRACE( creating context %p (GL context creation delayed)\n, ret);
return (HGLRC) ret;
@@ -463,6 +466,38 @@
}
}
+static int describeContext(Wine_GLContext* ctx) {
+ int tmp;
+ int ctx_vis_id;
+ TRACE( Context %p have (vis:%p):\n, ctx, ctx-vis);
+ wine_glx.p_glXGetFBConfigAttrib(ctx-display, ctx-fb_conf, GLX_FBCONFIG_ID, tmp);
+ TRACE( - FBCONFIG_ID 0x%x\n, tmp);
+ wine_glx.p_glXGetFBConfigAttrib(ctx-display, ctx-fb_conf, GLX_VISUAL_ID, tmp);
+ TRACE( - VISUAL_ID 0x%x\n, tmp);
+ ctx_vis_id = tmp;
+ return ctx_vis_id;
+}
+
+static int describeDrawable(Wine_GLContext* ctx, Drawable drawable) {
+ int tmp;
+ int draw_vis_id;
+ if (3 wine_glx.version || NULL == wine_glx.p_glXQueryDrawable) {
+/** glXQueryDrawable not available so returns not supported */
+return -1;
+ }
+ TRACE( Drawable %p have :\n, (void*) drawable);
+ wine_glx.p_glXQueryDrawable(ctx-display, drawable, GLX_FBCONFIG_ID, (unsigned int*) tmp);
+ TRACE( - FBCONFIG_ID as 0x%x\n, tmp);
+ wine_glx.p_glXQueryDrawable(ctx-display, drawable, GLX_VISUAL_ID, (unsigned int*) tmp);
+ TRACE( - VISUAL_ID as 0x%x\n, tmp);
+ draw_vis_id = tmp;
+ wine_glx.p_glXQueryDrawable(ctx-display, drawable, GLX_WIDTH, (unsigned int*) tmp);
+ TRACE( - WIDTH as %d\n, tmp);
+ wine_glx.p_glXQueryDrawable(ctx-display, drawable, GLX_HEIGHT, (unsigned int*) tmp);
+ TRACE( - HEIGHT as %d\n, tmp);
+ return draw_vis_id;
+}
+
/***
* wglMakeCurrent (OPENGL32.@)
*/
@@ -479,31 +514,13 @@
Wine_GLContext *ctx = (Wine_GLContext *) hglrc;
Drawable drawable = get_drawable( hdc );
if (ctx-ctx == NULL) {
- int tmp;
int draw_vis_id, ctx_vis_id;
VisualID visualid = (VisualID)GetPropA( GetDesktopWindow(), __wine_x11_visual_id );
+ TRACE( Wine desktop VISUAL_ID is 0x%x\n, (unsigned int) visualid);
+ draw_vis_id = describeDrawable(ctx, drawable);
+ ctx_vis_id = describeContext(ctx);
- TRACE( desktop VISUAL_ID is 0x%x\n, (unsigned int) visualid);
-
- TRACE( drawable %p have :\n, (void*) drawable);
- glXQueryDrawable(ctx-display, drawable, GLX_FBCONFIG_ID, (unsigned int*) tmp);
- TRACE( - FBCONFIG_ID as 0x%x\n, tmp);
- glXQueryDrawable(ctx-display, drawable, GLX_VISUAL_ID, (unsigned int*) tmp);
- TRACE( - VISUAL_ID as 0x%x\n, tmp);
- draw_vis_id = tmp;
- glXQueryDrawable(ctx-display, drawable, GLX_WIDTH, (unsigned int*) tmp);
- TRACE( - WIDTH as %d\n, tmp);
- glXQueryDrawable(ctx-display, drawable, GLX_HEIGHT, (unsigned int*) tmp);
- TRACE( - HEIGHT as %d\n, tmp);
-
- TRACE( Context %p have (vis:%p):\n, ctx, ctx-vis);
- glXGetFBConfigAttrib(ctx-display, ctx-fb_conf, GLX_FBCONFIG_ID, tmp);
- TRACE( - FBCONFIG_ID 0x%x\n, tmp);
- glXGetFBConfigAttrib(ctx-display, ctx-fb_conf, GLX_VISUAL_ID, tmp);
- TRACE( - VISUAL_ID 0x%x\n, tmp);
- ctx_vis_id = tmp;
-
- if (draw_vis_id
Re: SPARC assembly won't compile, problems with NT headers
Troy Rollo [EMAIL PROTECTED] writes:
2. can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data
section}
This problem is more sinister. It arises from the same limitation as the
first
problem, but is not susceptible to being worked around. The offending code is
the code that attempts to generate the NT header of the executable -
specifically the SizeOfImage element. I can't see any way at this point to
provide for this calculation to be done until after the linker output is
generated. I suspect the solution to this problem is to just output a zero in
this location and have winegcc modify the executable image to insert the
correct values after the linker has created it.
You can probably fix it by defining an _end symbol, like we do for
MacOS. You certainly don't want to try modifying the binary after it
has been built.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Typo on download page for debian packages
Hi, On Thu, Dec 22, 2005 at 09:20:47AM +0100, Stefan Munz wrote: Hi, I don't know who who is responsible for maintaining the website, but probably he will read wine-devel ;-) I found a little typo on the download site for the debian packages. The link to the repository works for me only without the space: deb http://wine.sourceforge.net/apt/ binary/ should be: deb http://wine.sourceforge.net/apt/binary/ This is not true, and further you could even see it from three locations that it's not: this line, the screenshot below, and the second line even further below (and from my own testing which confirmed that it's correct). Let me guess that you're not a Debian user, right? ;-) Andreas
Re: ATI Opengl regression (DRI?)
On 12/22/05, Raphael [EMAIL PROTECTED] wrote: On Friday 16 December 2005 02:26, Aric Cyr wrote: Raphael fenix at club-internet.fr writes: On Thursday 15 December 2005 19:55, Jesse Allen wrote: You really don't need to use glXQueryServerString() and glXQueryClientString(). It would be better, easier (not strcmp) and more correct to just use glXQueryVersion(). glXQueryVersion will automatically report the version common to both the client and server (so in this case 1.2). No, we cannot - glXGetFBConfigs is implemented by glx client (normally when glx client version 1.2 but in many 1.2 implementations its provided by Xorg). - glXQueryDrawable is only implemented by glx server (when glx server version 1.2) - for others calls we check if client version 1.2 else we use SGIX extension Sorry, I think I was asleep when I posted that. What I meant to say is that we don't need any of the glXQueryServerString or glXQueryClientString calls, since we can and should just use glXQueryExtensionsString. In fact, this is what the code does, but it also passes around the server and client strings to each of the query_functions, even though none of them use those parameters. I guess you put those in for future use, but I think they will never get used and just clutter things up. i thought that DRI implemented GLX 1.3 specs but seems they use a too older x code :( http://cvs.sourceforge.net/viewcvs.py/dri/xc/xc/programs/Xserver/GL/glx/ Too old perhaps, but that what DRI (and hence ATI) are using. Both support most of the 1.3 features so there really isn't much of an issue. The problem is that we cannot assume 1.3 regardless of how old 1.2 is. The reason for the glx version is so that we can do the right thing in any case. Not really, many of GLX features are supported by glx clients. And only old clients (ie X versions) reports 1.2 caps (and generaly they support 1.3 extensions) I have only problems with 1.2 glx servers (who don't support drawable queries), who is the DRI / ATI configuration :( By drawable queries do you glXDrawableAttribARB? There is zero documentation for that function, and the entire GLX_ARB_render_texture extension. It seems like the ARB dropped the whole idea. Last mention of it was in 2002, from what I could find. I don't think we can rely on this extension to implement wglSetPbuffersAttribARB(). Maybe framebuffer objects would be a better solution, which ATI and nVidia both support now. Also seems like we should be relying on glXGetProcAddress() but need to be using glXGetProcAddressARB() since nVidia apparently doesn't export the former. ??? where you see glXGetProcAddress use ? Ya I checked the code after I sent this. I just happened to be reading the thread that I mentioned and thought it would be good advice to throw into the mail. Regards, Aric -- Aric Cyr Aric.Cyr at gmail dot com(http://acyr.net)
Re: Typo on download page for debian packages
Am Donnerstag, 22. Dezember 2005 10:45 schrieb Andreas Mohr: Hi, On Thu, Dec 22, 2005 at 09:20:47AM +0100, Stefan Munz wrote: Hi, I don't know who who is responsible for maintaining the website, but probably he will read wine-devel ;-) I found a little typo on the download site for the debian packages. The link to the repository works for me only without the space: deb http://wine.sourceforge.net/apt/ binary/ should be: deb http://wine.sourceforge.net/apt/binary/ This is not true, and further you could even see it from three locations that it's not: this line, the screenshot below, and the second line even further below (and from my own testing which confirmed that it's correct). Let me guess that you're not a Debian user, right? ;-) Since a few weeks a use kubuntu on my laptop, that's why I was looking on the debian download page. But I'm definitely a debian newbie ;-) My fault was to try the explore the repository with a web browser and take it as one url. Sorry for your inconvenience. cu, Stefan Andreas -- Dipl.-Inform. Stefan Munz. . . . . . . . . . [EMAIL PROTECTED] ITOMIG GbR . . . . . . . . . . . . . . . . . www.itomig.de Sand 14 . . . . . . . . . . . . . . . . . . phone: +49 7071 29 704 93 D-72076 Tübingen . . . . . . . . . . . . . . mobil: +49 178 729 72 72 pgptZe33pJzxE.pgp Description: PGP signature
Re: SPARC assembly won't compile, problems with NT headers
Troy Rollo wrote:
winegcc from the current WineHQ produces assembly output for SPARC systems
that cannot be processed by the assembler.
I've attached the patches we're using for winebuild on SPARC. This
fixes both of the problems you're encountering. I'm not sure if the fix
is the right one, but it works quite nicely :-) We use gcc/gas.
Eric
Index: import.c
===
--- import.c(.../vendor/wine/current/tools/winebuild) (revision 31841)
+++ import.c(.../trunk/wine/tools/winebuild)(revision 31841)
@@ -314,7 +314,7 @@
if (odp-flags FLAG_PRIVATE) continue;
imp-exports[imp-nb_exports++] = odp;
}
-imp-exports = xrealloc( imp-exports, imp-nb_exports *
sizeof(*imp-exports) );
+imp-exports = xrealloc( imp-exports, imp-nb_exports ? (imp-nb_exports
* sizeof(*imp-exports)) : 1);
if (imp-nb_exports)
qsort( imp-exports, imp-nb_exports, sizeof(*imp-exports), func_cmp
);
return 1;
@@ -835,7 +835,10 @@
if (!nb_imm) return;
fprintf( outfile, \n/* immediate import thunks */\n\n );
-fprintf( outfile, \t.text\n );
+if (target_cpu == CPU_SPARC)
+fprintf( outfile, \t.data\n );
+else
+fprintf( outfile, \t.text\n );
fprintf( outfile, \t.align %d\n, get_alignment(8) );
fprintf( outfile, %s:\n, asm_name(import_thunks));
@@ -959,7 +962,10 @@
if (!nb_delayed) return;
fprintf( outfile, \n/* delayed import thunks */\n\n );
-fprintf( outfile, \t.text\n );
+if (target_cpu == CPU_SPARC)
+fprintf( outfile, \t.data\n );
+else
+fprintf( outfile, \t.text\n );
fprintf( outfile, \t.align %d\n, get_alignment(8) );
fprintf( outfile, %s:\n, asm_name(delayed_import_loaders));
fprintf( outfile, \t%s\n, func_declaration(__wine_delay_load_asm) );
@@ -1147,7 +1153,10 @@
for (i = 0; i ext_link_imports.count; i++)
fprintf( outfile, \t%s %s\n, get_asm_ptr_keyword(),
asm_name(ext_link_imports.names[i]) );
-fprintf( outfile, \n\t.text\n );
+if (target_cpu == CPU_SPARC)
+fprintf( outfile, \t.data\n );
+else
+fprintf( outfile, \t.text\n );
fprintf( outfile, \t.align %d\n, get_alignment(get_ptr_size()) );
fprintf( outfile, %s:\n, asm_name(__wine_spec_external_link_thunks) );
@@ -1239,6 +1248,15 @@
output_delayed_imports( outfile, spec );
output_immediate_import_thunks( outfile );
output_delayed_import_thunks( outfile, spec );
+
+if (target_cpu == CPU_SPARC)
+{
+/* DJANKOV QD */
+fprintf( outfile, \n\t.data\n );
+fprintf( outfile, \t.align %d\n, get_alignment(4) );
+fprintf( outfile, %s:\n, asm_name(_end) );
+fprintf( outfile, \t.long 0\n );
+}
output_external_link_imports( outfile, spec );
if (nb_imports || ext_link_imports.count || has_stubs(spec))
output_get_pc_thunk( outfile );
}
Re: Bug 3885
--- Aric Cyr [EMAIL PROTECTED] wrote: Tom Spear speeddymon at gmail.com writes: Aric Cyr wrote: I took a look at the D3D_OK hack, and I believe the problem to be CheckDeviceFormat in wined3d/directx.c. This function should return an error if D3DFMT_D32 is checked for on cards which don't support 32bit depth. Currently it just returns OK for most formats though. This code is really just a stub as it stands, and needs to be converted to check if there are any visuals that meet the requested format's requirements, and if there is, return D3D_OK, otherwise D3D_NOTAVAILBLE. To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case (you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() and see if that fixes that issue or not. This would be just another hack though, so a real patch would still be necessary as I decribed above. Well I took a stab at adding the case for D3DFMT_D32, to the bottom of the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes the first one and then goes to do the second one, but crashes in a different spot, so it seems we also have some stack corrupion (as was mentioned in the bug).. So that hack works for now, I would suggest that since the rest of that code is stubbed out, we should probably go ahead and submit a patch so we can at least run the darn thing and then start debugging the stack corruption issue. Thanks for testing this out. You have proved my theory correct, so I'll see about making a patch which will correct CheckDeviceFormat(). Basically that whole function needs a re-write, so I'd rather do it that way than to put this hack in there. Especially since, I assume, this problem is not present on nVidia systems, only ATI. I'm part of the way through re-writing this function to use an inclusive list per usage instead of an exclusive list for all usages and should hopefully have the re-write finished by the end of the week along with CheckDeviceType and friends. Oliver. Regards, Aric ___ Does your mail provider give you FREE antivirus protection? Get Yahoo! Mail http://uk.mail.yahoo.com
Re: [lostwages] Remove winetools from download page
Wednesday, December 21, 2005, 8:12:43 PM, Tom Wickline wrote: Winetools helps people run programs that they might not be able to and it helps them do that now. And that's what 99.9% of end users care about, can I run what I want to now? If the answer is no 99.8% of them will leave while .1% might stick around and wait on a fix. Could you please show me some one, or ask them speak up on #winehq. So for I have yet to talk to anyone there who had used winetools and had IE6 working (that's the main goal of this isn't it?). Ok it looks like there is 1 person who did use winetools and they worked. So, Tom, could you please specify the place where I can redirect all the people who having problems _with winetools_? To wine-users I presume? As it looks to me that's the place where all the advertisement going on about using winetools. Also had an interesting case last night: person had problems with winetools. When I asked the version, he said it's 3.0.9. So, there is your problem. Some one packaged winetools and made this version number. As far as winetools go. I see a really bad patterns there. 1. There is no clean way to install them for a local user to test. Winetools are invasive and change too many things and go into to many places. This is not the way to package software. 2. It can't use wine from the source tree (again for testing). 3. It's using redundant scripts to like findwine. For what purpose? 4. Those scripts override environment variables that wine and wine parts, depend on. Why? 5. It adds some extra needless overrides to the registry, like DLLOVERRIDES=*=native, builtin. Is there a reason for this? That _is exactly_ what we, developers, trying to avoid. 6. Version=win98 - that is wrong. Wine's default _is_ win2k. Please, we do not need this quality software linked to from the main download page. We can have a link to it in user section of wiki. But NOT the main download page! These tools defeat the purpose of what we, developers, are trying to archive. Happy Holiday's
Re: [lostwages] Remove winetools from download page
Hi Vitaliy, On Thursday 22 December 2005 18:32, Vitaliy Margolen wrote: Also had an interesting case last night: person had problems with winetools. When I asked the version, he said it's 3.0.9. So, there is your problem. Some one packaged winetools and made this version number. This seems to be the version we are distributing via our debian apt-repository. Have a look at http://wine.sourceforge.net/apt/binary/ As far as winetools go. I see a really bad patterns there. 1. There is no clean way to install them for a local user to test. Winetools are invasive and change too many things and go into to many places. This is not the way to package software. 2. It can't use wine from the source tree (again for testing). 3. It's using redundant scripts to like findwine. For what purpose? 4. Those scripts override environment variables that wine and wine parts, depend on. Why? 5. It adds some extra needless overrides to the registry, like DLLOVERRIDES=*=native, builtin. Is there a reason for this? That _is exactly_ what we, developers, trying to avoid. 6. Version=win98 - that is wrong. Wine's default _is_ win2k. You should bring your concerns to Joachim von Thadden's or Sven Paschukat's attention. If they fix them, we can keep the link to winetools. If they prefer not to fix them, we can explain to them why we think this is a problem for wine's development progress and thus give a rational for removing the link. Merry Christmas (or if you prefer, Happy Holidays ;) -- Michael Jung [EMAIL PROTECTED]
Re: [lostwages] Remove winetools from download page
Vitaliy Margolen wrote: 5. It adds some extra needless overrides to the registry, like DLLOVERRIDES=*=native, builtin. Is there a reason for this? That _is exactly_ what we, developers, trying to avoid. Actually, this makes sense for apps that install executables that are coincidently named like programs that Wine has, e.g. calc.exe or user.exe. On a slightly related note, in CrossOver we force a whole bunch of DLLs to be builtin, like ole32, oleaut32, rpcrt4 and msi. Maybe we should do the same for Wine? -- Rob Shearman
Re: advpack: fix LaunchInfSection[Ex] documentation
On 12/22/05, Markus Amsler [EMAIL PROTECTED] wrote: - * show[I] How the window should be shown. + * show[I] Reboot behaviour: + * 'A' reboot always + * 'I' default, reboot if needed + * 'N' no reboot * Where are you getting this behavior from? Microsoft's public header advpub.h does not include this information, and while that doesn't mean we shouldn't include it either, it would be nice to see tests for this behavior, either in the form of an app that displays the behavior or preferably tests in wine's test suite. -- James Hawkins
Re: advpack: fix LaunchInfSection[Ex] documentation
James Hawkins wrote: On 12/22/05, Markus Amsler [EMAIL PROTECTED] wrote: - * show[I] How the window should be shown. + * show[I] Reboot behaviour: + * 'A' reboot always + * 'I' default, reboot if needed + * 'N' no reboot * Where are you getting this behavior from? Microsoft's public header advpub.h does not include this information, and while that doesn't mean we shouldn't include it either, it would be nice to see tests for this behavior, either in the form of an app that displays the behavior or preferably tests in wine's test suite. -- James Hawkins I found it on MSDN for LaunchINFSectionEx [1], and assumed the same for LaunchInfSection. I haven't tested it (yet). We shouldn't test the reboot behaviour in the wine tests, a lot of windows testers would get angry. Perhaps i code a little app. Markus [1] http://msdn.microsoft.com/workshop/delivery/download/overview/launchinfsectionex.asp
Re: SPARC assembly won't compile, problems with NT headers
On Thu, 22 Dec 2005 19:52, Alexandre Julliard wrote: You can probably fix it by defining an _end symbol, like we do for MacOS. You certainly don't want to try modifying the binary after it has been built. This will work if (and only if) the value of SizeOfImage is unimportant for Winelib executables. Of course in that case there is probably some merit in setting it to zero anyway since at least that would make it obvious that it has no meaningful value if somebody reads it later. -- Troy Rollo - [EMAIL PROTECTED]
Problem with WineD3D Surface Locking
Hello,
I've spotted a bug in WineD3D's surface locking, and I have no clue how to fix
this. The problem is that unlocking the back buffer causes it to become
completely black, no matter what's written to it's memory or what has been
there before.
I have written a small D3D9 test app which shows this behavior: Compile it
with winemaker ., followed by make, and run it. Pressing ESC will cause it
to quit, pressing any other keys makes IDirect3DDevice9::Clear call on the
back buffer, with a color value based on the pressed keys. A click anywhere
will LockRect() the whole backbuffer, write 0xff into the whole locked
memory, and UnlockRect() it.
The screen should become completely white, but instead it goes black. With the
fglrx driver and 24 bit color depth it shows the correct behavior, but with
any other driver(radeon, software rendering) or 16 bit color depth, it
doesn't work. The bug is somehow related to some GL calls in
UnlockRect(glPixelZoom and glOrtho), but I couldn't find anything specific.
I hope you can help me, I am quite stuck here,
Stefan
#include stdio.h
#include windows.h
#include d3d9.h
#include assert.h
WNDCLASS wc;
HWND hwnd;
IDirect3D9 *D3D=NULL;
IDirect3DDevice9 *device=NULL;
LRESULT CALLBACK WndProc(HWND hWnd, UINT uiMessage, WPARAM wParam, LPARAM lParam);
static void createwindow(void)
{
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = GetModuleHandleA(0);
wc.hIcon = LoadIconA(wc.hInstance, IDI_APPLICATION);
wc.hCursor = LoadCursorA(NULL, IDC_ARROW);
wc.hbrBackground = (HBRUSH) GetStockObject(BLACK_BRUSH);
wc.lpszMenuName = NULL;
wc.lpszClassName = TestWindowClass;
if(!RegisterClassA(wc))
assert(0);
hwnd = CreateWindowExA(0, TestWindowClass, TestWindowClass,
WS_POPUP, 0, 0,
GetSystemMetrics(SM_CXSCREEN),
GetSystemMetrics(SM_CYSCREEN),
NULL, NULL, GetModuleHandleA(0), NULL);
assert(hwnd != NULL);
ShowWindow(hwnd, SW_HIDE);
UpdateWindow(hwnd);
SetFocus(hwnd);
}
LRESULT CALLBACK WndProc(HWND hWnd, UINT uiMessage, WPARAM wParam, LPARAM lParam)
{
// printf(Message %lx, wparam %lx, lparam %lx\n, uiMessage, wParam, lParam);
static WPARAM old1 = 0;
static WPARAM old2 = 0;
HRESULT hr;
BYTE *lockedmem;
long memsize;
long i;
IDirect3DSurface9 *BackBuffer;
D3DLOCKED_RECT rect;
switch(uiMessage)
{
case WM_DESTROY:
// Close the window, terminate the app
PostQuitMessage(0);
return 0;
case WM_LBUTTONDOWN:
hr = IDirect3DDevice9_GetBackBuffer(device, 0, 0, D3DBACKBUFFER_TYPE_MONO, BackBuffer);
assert(hr == D3D_OK);
hr = IDirect3DSurface9_LockRect(BackBuffer, rect, NULL, 0);
assert(hr == D3D_OK);
memset(rect.pBits, 0xff, rect.Pitch * 480);
hr = IDirect3DSurface9_UnlockRect(BackBuffer);
assert(hr == D3D_OK);
hr = IDirect3DDevice9_Present(device, NULL, NULL, 0, NULL);
assert(hr == D3D_OK);
break;
case WM_KEYUP:
if(lParam == 0xc0010001) /* Escape */
{
PostQuitMessage(0);
return 0;
}
hr = IDirect3DDevice9_Clear(device,
0,
NULL,
D3DCLEAR_TARGET ,
(old2 16) + (old1 8) + wParam,
0, 0);
assert(hr == D3D_OK);
hr = IDirect3DDevice9_Present(device, NULL, NULL, 0, NULL);
assert(hr == D3D_OK);
old2 = old1;
old1 = wParam;
break;
default:
return DefWindowProc(hWnd, uiMessage, wParam, lParam);
}
}
int main()
{
D3DFORMAT format=D3DFMT_R5G6B5;
D3DPRESENT_PARAMETERS pp;
HRESULT hr;
MSG Message;
pp.BackBufferCount= 1;
pp.MultiSampleType=D3DMULTISAMPLE_NONE;
pp.MultiSampleQuality=0;
pp.SwapEffect = D3DSWAPEFFECT_DISCARD;
pp.hDeviceWindow=hwnd;
pp.Flags=0;
pp.Windowed = FALSE;
pp.BackBufferWidth = 640;
pp.BackBufferHeight = 480;
pp.FullScreen_RefreshRateInHz=D3DPRESENT_RATE_DEFAULT;
pp.PresentationInterval=D3DPRESENT_INTERVAL_DEFAULT;
pp.BackBufferFormat=format;
pp.EnableAutoDepthStencil=FALSE;
createwindow();
D3D = Direct3DCreate9( D3D_SDK_VERSION);
hr=IDirect3D9_CreateDevice(D3D, D3DADAPTER_DEFAULT,
D3DDEVTYPE_HAL,
hwnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING,
pp,
device);
assert(hr == D3D_OK);
while(GetMessage(Message, NULL, 0, 0))
{
TranslateMessage(Message);
DispatchMessage(Message);
}
IDirect3DDevice9_Release(device);
if(D3D)
{
IDirect3D9_Release(D3D);
D3D=NULL;
}
return 0;
}
pgpZ8y39ypuXb.pgp
Description: PGP signature
Re: Use the new RtlExitUserThread function instead of exporting
With this change [*] header does not compile under MSVC 6: --- include/winternl.h +++ include/winternl.h @@ -1985,6 +1985,7 @@ BOOL WINAPI RtlEqualPrefixSid(PSID, BOOL WINAPI RtlEqualSid(PSID,PSID); BOOLEAN WINAPI RtlEqualString(const STRING*,const STRING*,BOOLEAN); BOOLEAN WINAPI RtlEqualUnicodeString(const UNICODE_STRING*,const UNICODE_STRING*,BOOLEAN); +void WINAPI RtlExitUserThread(ULONG) DECLSPEC_NORETURN; NTSTATUS WINAPI RtlExpandEnvironmentStrings_U(PWSTR, const UNICODE_STRING*, UNICODE_STRING*, ULONG*); LONGLONG WINAPI RtlExtendedMagicDivide(LONGLONG,LONGLONG,INT); LONGLONG WINAPI RtlExtendedIntegerMultiply(LONGLONG,INT); Moving DECLSPEC_NORETURN to before a WINAPI keyword helps. [*] http://source.winehq.org/git/?p=wine.git;a=blobdiff;h=ee582be9bc8ae5797b762b3c340e0821faca1c0d;hp=090f8b5698699d13a2afb848aa37cb77c61a0705;hb=4de75b5a6f83d7714c5736477376eda399ef1d01;f=include/winternl.h
Re: advpack: fix LaunchInfSection[Ex] documentation
On 12/22/05, Markus Amsler [EMAIL PROTECTED] wrote: I found it on MSDN for LaunchINFSectionEx [1], and assumed the same for LaunchInfSection. I haven't tested it (yet). Fair enough :) They must have recently added this, because I've never seen LaunchInfSection[Ex] documentation on msdn before. We shouldn't test the reboot behaviour in the wine tests, a lot of windows testers would get angry. Perhaps i code a little app. No need if it's documented. -- James Hawkins
Re: msiexec null reference
Bill Medland wrote:
+static const WCHAR dfv[] = {
+'M','S',' ','S','h','e','l','l',' ','D','l','g',0 };
+if (!dialog-default_font)
+{
+DWORD len = strlenW (dfv) + 1;
+dialog-default_font = msi_alloc(len*sizeof(WCHAR));
+if (!dialog-default_font) return -1;
+memcpy (dialog-default_font, dfv, len*sizeof(WCHAR));
+}
How about this?
if (!dialog-default_font)
dialog-default_font = msi_strdupW( dfv );
Mike
Re: Poser label issue [Bug 2737]
*sigh* sorry about spamming the list... Thought that my messages weren't going thro. Didn't mean to send 3 copies of it Vik
Re: [lostwages] Remove winetools from download page
On Thu, 2005-12-22 at 09:43 +0100, [EMAIL PROTECTED] wrote: On Thu, 22 Dec 2005 02:59:57 +0100, Tom Wickline [EMAIL PROTECTED] wrote: On 12/21/05, James Hawkins [EMAIL PROTECTED] wrote: As much as I appreciate the work you, Joachim, and others have put into winetools, we're getting closer to the point in time when winetools needs to be phased out by a better, more functional wine. Getting closer, sure, but it's not for tommorow As someone coming from a Windows (professionally at least, Linux at home) background I have to say that making it harder to install programs by dropping the link to winetools, given the known, current limitations of Wine, could completely undo all of the efforts of the last 10 years. One thing to remember is that 'Windows users are stupid'. Of course, I don't mean that literally; rather, anyone considering a switch to Linux is going to want to see some hard proof that their Windows programs might work. If they just get a crash (or a 'go to irc at etc') they will give up immediately. I have seen some very sensible comments suggesting that once Wine reaches 1.0 then THAT is the time to drop references to winetools. Part of this process is removing it from the official download page. Part of this process will be removing winetool link. is implies the present and we are not at this stage with wine yet. Agreed Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say we need to have Wine run everything out of the box and to accomplish this were going to remove a link to a user friendly tool that currently helps our users. I agree completely I agree, I think there has to be an easy start method with at least half a chance of getting things running. Most new users , many probably new to linux as well will NOT even be aware of what an IRC channel is an probably never met a maiing list either. It seems some of the ppl posting on this thread dont even realise that they are living on a different plane to those actually using wine. If new users cant get some positive result quickly they will just conclude that wine is unusable, and from an average user point , they would be right. See above If they can be hooked by getting somethings to work they _may just_ go a bit further with some things that dont. Hell , they may even read the doc if they can find it. As for argueing that bugs wont get reported. I was not aware that there was a shortage of things to do in fixing Wine. ing 'please look here If Wine scares off new users by expecting everyone to be a software developer it will fail in it's primary role of helping users to migrate to Linux. Could not agree more. Wine needs to 'get it right for the users ', even if that involves occasionally saying 'please look here; we like you and we want to keep you here'. Fixing bugs is the devs job, not the end user's job, yes? regards.
Re: msiexec null reference
On December 22, 2005 06:15 pm, Mike McCormack wrote:
Bill Medland wrote:
+static const WCHAR dfv[] = {
+'M','S',' ','S','h','e','l','l',' ','D','l','g',0
};
+if (!dialog-default_font)
+{
+DWORD len = strlenW (dfv) + 1;
+dialog-default_font =
msi_alloc(len*sizeof(WCHAR)); +if
(!dialog-default_font) return -1;
+memcpy (dialog-default_font, dfv,
len*sizeof(WCHAR)); +}
How about this?
if (!dialog-default_font)
dialog-default_font = msi_strdupW( dfv );
Mike
1. Alexandre has already committed it, using strdupW. (I am a
little uncomfortable with the asymmetry but heck!)
2. Basically that was what I wanted to do but I couldn't (can't)
find an msi_strdupW anywhere. I suppose I could have written it
as such but seeing as how there wasn't one yet I presumed that
there was insufficient demand.
--
Bill Medland
mailto:[EMAIL PROTECTED]
http://webhome.idirect.com/~kbmed
Re: Wine IE6 and JVM
On Thu, 2005-12-15 at 17:38 +0200, Adrian Munteanu wrote: Hi guys, I am trying to use wine with IE 6. Most of the pages are displaying fine, however the problem is with pages requesting JVM running. So could you please help me find away, if available, to make IE use installed JVM? Thanks and best regards Adrian Have you tried latest winetools? I ask because it worked for me with IE6 .It has been updated to the 0.9 wine version. Hope this helps, Dom
Re: [lostwages] Remove winetools from download page
James Hawkins wrote: Usability is another rapidly progressing area of wine. What usability? I've been reading the mailing list for a few months now, and the only extent of 'usability' discussions for wine has been over whether or not experienced linux geeks will be confused by options in winecfg. That's not usability. That just means it's easy for hardcore users to figure things out without having to look for docs. The work being done in winecfg is both good and necessary, but it's still a long ways away from wine being 'usable' to non-geeks. When all of the binary packages (heck, any) on winehq.org have .Desktop files so that winecfg is at least accessible without the use of a terminal, and you can launch a wine application that asks the user what windows app they would like to run or make shortcut to so they don't have to use terminal there either, /then/ maybe there can be some usability discussion. And then maybe it would be appropriate to remove winetools.
Re: [lostwages] Remove winetools from download page
Thursday, December 22, 2005, 4:16:54 PM, Sven Paschukat wrote: Vitaliy Margolen schrieb: 2. It can't use wine from the source tree (again for testing). It should. What were your problems? I do not have Wine installed. All I have is wine symlink in my ~/bin dir. And winetools could not find wine nor winecfg. So when I ran wt it complained about that. 3. It's using redundant scripts to like findwine. For what purpose? It makes some checks to avoid problems. It was not our goal to write Mm looking at those checks I would say 95% of them are invalid and/or not as flexible as wine itself is. perfect code like wine. So it is titled 3rd Party Tools. No one talks about perfect code here. We are talking about entitlement to be listed in the same line as Wine itself. 4. Those scripts override environment variables that wine and wine parts, depend on. Why? Can you say more precisely what code fragment do you mean? findwine - 95% bogus. winetools - should be split into separate scripts for each installed app. Makes it cleaner and more flexible. All the scripts in scripts/ dir what are they for? Most seems to be 100% redundant to what wine or wine prog.exe wineserver -w do. 5. It adds some extra needless overrides to the registry, like DLLOVERRIDES=*=native, builtin. Is there a reason for this? That _is exactly_ what we, developers, trying to avoid. Using as much native dlls as possible makes chances best to install windows software, of course not user32.dll and such. No that's not the case at all. And this part specifically defeats the whole propose of developing new dlls. Why would anyone in their right mind start new dll, if you can use native? But the question is can you? Most people DO NOT own Windows 98 licence. That means that each such person should not even attempt to download or run winetools. 6. Version=win98 - that is wrong. Wine's default _is_ win2k. It is right for the goal of the winetools. Again, this is why it's titled 3rd Party Tools. No, it's not. Some major changes have been made to low level code that makes Wine much more like with winNT then win9x. If you enforce win9x for each program - you creating potential problems. And again, most programs with do things differently on win9x then winNT. Like disabling some features. So that again means that we never getting feedback from users.
Re: [lostwages] Remove winetools from download page
Thursday, December 22, 2005, 12:04:52 PM, Robert Shearman wrote: Vitaliy Margolen wrote: 5. It adds some extra needless overrides to the registry, like DLLOVERRIDES=*=native, builtin. Is there a reason for this? That _is exactly_ what we, developers, trying to avoid. Actually, this makes sense for apps that install executables that are coincidently named like programs that Wine has, e.g. calc.exe or user.exe. Then this is Wine's bug and has to be fixed as such. There is no reason to hide it. Not in Wine at least. On a slightly related note, in CrossOver we force a whole bunch of DLLs to be builtin, like ole32, oleaut32, rpcrt4 and msi. Maybe we should do the same for Wine? Well we could add them to the override list I guess. But I think it's the part of the same problem. We seems not doing it the same as windows does. We went from one extreme (using as much native dlls as possible) to another extreme (use builtins only). Vitaliy
Re: [lostwages] Remove winetools from download page
On 12/22/05, Joseph Garvin [EMAIL PROTECTED] wrote: What usability? I've been reading the mailing list for a few months now, and the only extent of 'usability' discussions for wine has been over whether or not experienced linux geeks will be confused by options in winecfg. That's not usability. That just means it's easy for hardcore users to figure things out without having to look for docs. The work being done in winecfg is both good and necessary, but it's still a long ways away from wine being 'usable' to non-geeks. Wine is an open source project, and as such, the developers of wine encourage peer review. We value bug reports, comments, suggestions, and criticisms, whether good or bad, so that we can make wine a better application. Your comments infer that the developers aren't interested in making wine easier for the end user, or that we are too 'hardcore' to realize that wine may be hard to use. The latter is possible, but the former is completely untrue. We take usability reports very seriously, and increasing usability is a top priority. The only problem is that we don't get those types of reports as often as we should. One reason why we don't get these reports is because users have winetools to make wine easier. They don't run wine directly, configure wine with winecfg, and stumble over any usability issues. That is why this issue began in the first place. Speaking specifically to you Joseph, I've checked through the wine-devel and wine-users mailing list archives for reports of usability issues from you, but this is the first one. The constructive thing to do would be to politely report your problems on the wine-devel list, or even file bug reports for them. When all of the binary packages (heck, any) on winehq.org have .Desktop files so that winecfg is at least accessible without the use of a terminal, On at least KDE and Gnome, alt-f2 will bring up a run dialog, type winecfg and press enter. Even if winecfg was only usable from the command line, that doesn't count against usability. If that were the case, many well-known command line applications would be considered to have poor usability. and you can launch a wine application that asks the user what windows app they would like to run or make shortcut to so they don't have to use terminal there either, /then/ maybe there can be some usability discussion. winefile And then maybe it would be appropriate to remove winetools. Please re-read the posts. No one is advocating removing winetools, only the link to the winetool's download from winehq.org. -- James Hawkins
