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

Re: still many warnings from Mesa

by Gerald Pfeifer

On Mon, 30 Jun 2003, Lionel Ulmer wrote: >> This is not a Linux versus FreeBSD issue. > Well, the Linux ABI tells this : There is no such thing that is widely known as the "Linux ABI" _and_ that mandates things like this. Do you refer to http://oss.sgi.com/projects/ogl-sample/ABI/ ? > " 4.4. glx.h must include the prototype of the glXGetProcAddressARB extension > described above. If we're nitpicking, this has nothing to do with an ABI, but with an API. If we are not nitpicking, this problem still exists with Mesa-5.0.1, so it would be nice to address it (as Raphaël once suggested). Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

June 30, 2003

Re: still many warnings from Mesa

by Lionel Ulmer

> Nah. It works perfectly, without a single warning, once > > #define GL_GLEXT_PROTOTYPES > > is added, but Raphaël didn't want that due to problems with broken nVIDEA > drivers or somthing like that. (...) > This is not a Linux versus FreeBSD issue. Well, the Linux ABI tells this : " 4.4. glx.h must include the prototype of the glXGetProcAddressARB extension described above. 4.5. All OpenGL 1.2 and ARB_multitexture, GLU 1.3, and GLX 1.3 entry points and enumerants must be present in the corresponding header files gl.h, glu.h, and glx.h, even if only OpenGL 1.1 is implemented at runtime by the associated runtime libraries. " So if your system was compliant, you should have all the glMulti* prototypes defined in your gl.h file and glXGetProcAddressARB too.... So you should not have any warning. Nothing is mentionned in the ABI about any need for 'GL_GLEXT_PROTOTYPES' protection of these calls, so well, I still think that it's somehow a problem in your headers :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

June 30, 2003

Re: Mac OS X Support : Asm syntax support [Fixed]

by Alexandre Julliard

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Hum... If my memory is well I do use PPC_SYM in order to convert > delay_imports to _delay_imports on darwin target. the assembler syntax > requires it. Yes, that's exactly what __ASM_NAME is supposed to do. > If you want, but for me it seems that it is clearer this way. because > you endup with things like: > fprintf((output," \"li " PPC_REG(1) ", 0\\n\"\n"); > fprintf(outfile, "\t\"\\tlis " PC_REG(9) > PPC_LOW(delay_imports+%d,9)\\n\"\n", pos); > But in fact it is also readable. If you prefer this way I'll do what > you like ;) IMO it would be more readable with a separate function, and then something like: fprintf( output, "li %s,0", ppc_reg(1) ); -- Alexandre Julliard julliard(a)winehq.com

June 30, 2003

Re: Memory Protection Wierdness

by Alexandre Julliard

Robert Lunnon <bob(a)yarrabee.net.au> writes: > But of course this code doesn't reset the page protections to allow the access. > > I Doctored this code so it would always allow the access and the installer then completed OK, But worms itself will not run yet > > Q. Should all views have handlers ? Under What Conditions would they not ??? No, most views don't need handlers. Except in specific cases like guard pages or DIB handling, if a given page is marked as no access then we very much want to crash if it is accessed. Resetting the protections on all accesses would make page protections completely useless. You'll need to investigate where that page comes from and why it's not accessible. -- Alexandre Julliard julliard(a)winehq.com

June 30, 2003

Re: Loader fix for pathes differing by extra backslashes

by Mike McCormack

Hi Eric, No, I didn't test what windows does, but something is amiss with what we're doing because Office 97 will not install with builtin ole32 without this fix. (I'm pretty sure it installs on windows :) The double backslash comes from within the Office 97 installer itself. Even if windows treats these as seperate modules, then we still have a problem, because dlopen works with unix pathes, and filenames differing by a backslash still have the same unix path. Mike Eric Pouech wrote: > Did you test what Windows does in that case ? (I also wonder where the > double backslash comes from). > A+

June 30, 2003

Re: Loader fix for pathes differing by extra backslashes

by Eric Pouech

Mike McCormack wrote: > > Hi, > > The loader seems to have a problem with extra backslashes in module > pathnames. > > If "c:\\windows\\system\\ole32.dll" is loaded and unloaded, then > "c:\\windows\\system\\\\ole32.dll" is loaded, there will be trouble, as > the loader does not recognise these two as the same module, yet dlopen > does. Did you test what Windows does in that case ? (I also wonder where the double backslash comes from). A+ -- Eric Pouech

June 30, 2003

Re: still many warnings from Mesa

by Gerald Pfeifer

On Mon, 30 Jun 2003, Lionel Ulmer wrote: >> Could someone please have a look at addressing these? > Well, I think the only way to safely remove these are by using > --disable-opengl. Nah. It works perfectly, without a single warning, once #define GL_GLEXT_PROTOTYPES is added, but Raphaël didn't want that due to problems with broken nVIDEA drivers or somthing like that. > I know it's a Linux only ABI but well, people on other platforms can fix > the issue if they need it to be fixed :-) This is not a Linux versus FreeBSD issue. Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

June 30, 2003

Re: RESUBMIT: --disable-debug -> no -gstabs+

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > Except when we explicitly --disable-debug, add -gstabs+ > if possible. I don't see much point in doing that, --disable-debug is broken anyway (and should probably be removed). You need to tweak the CFLAGS to make it work right, and then you can just as well get rid of -gstabs+ in the CFLAGS too. -- Alexandre Julliard julliard(a)winehq.com

June 30, 2003

Re: Official MS symbol sets

by Eric Pouech

Mike Hearn wrote: > Hi, > > http://www.microsoft.com/whdc/ddk/debugging/symbolpkg.mspx > > I assume people have looked at this before - how easy are they to match > up with Wine, and do people use them for debugging faults in native > code? I never tested this before. It depends on which debugger you're using. WinDbg (the MS one) should be easy to use, but you'll miss the native part. WineDbg has some support for loading PDB files, but the latest formats are likely not to be supported, so YMMV. A+ -- Eric Pouech

June 30, 2003

Re: [dx61] d3d9 guid + d3d9 header fixes

by Alexandre Julliard

Raphaël Junqueira <fenix(a)club-internet.fr> writes: > Index: include/d3d9types.h > =================================================================== > RCS file: /home/wine/wine/include/d3d9types.h,v > retrieving revision 1.2 > diff -u -r1.2 d3d9types.h > --- include/d3d9types.h 24 Jun 2003 19:26:51 -0000 1.2 > +++ include/d3d9types.h 27 Jun 2003 22:14:40 -0000 > @@ -1131,8 +1131,10 @@ > typedef struct _D3DADAPTER_IDENTIFIER9 { > char Driver[MAX_DEVICE_IDENTIFIER_STRING]; > char Description[MAX_DEVICE_IDENTIFIER_STRING]; > - char DeviceName[32]; /* Device name for GDI (ex. \\.\DISPLAY1) */ > - LARGE_INTEGER DriverVersion; > + char DeviceName[32]; > + DWORD DriverVersionLowPart; > + DWORD DriverVersionHighPart; > + Isn't DriverVersionLow/HighPart supposed to be for 16-bit code? Why do you need to use that instead of DriverVersion? -- Alexandre Julliard julliard(a)winehq.com

June 30, 2003