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

Re: Re: Re: Submits galore
by fenix＠club-internet.fr 06 Jun '03

06 Jun '03

>> PS: As jason have some compilation problems too as it use a specific gl.h >> with a generic glext.h, i'm thinking about not using anymore the gl/glext >> headers definitions (i'm too bored to fixes each mismatch headers >> declaration) Hi All, >Well, I would say that we use the standard gl.h file (otherwise >it's too messy) but completely remove the dependency on glext.h. well, the problem is that gl.h defines ugly things too. as i have reports from users using mesa headers 3.4 (openGL 1.2 only declared but ugly pre 1.3 support) while using Mesa5.0 (very easy to do: install a XFree4.0 and after install only mesa5) >I plan to change all _EXT and _ARB stuff in the D3D7 code by >_WINE #defines (defined from the GL extension specs) and to never >use at all the function pointer typedef and use my own. i think you'll have many breakage :) >Basically, my baseline would be GL 1.2 and all the rest would be >redefined. As you want, But for me, I think building with GL1.4 (last ans most complete) headers and detecting/activing caps on runtime it's a more proper solution (no more #ifdef/#define in code, only in d3dcore_gl.h definitions). > Lionel Regards, Raphael

2 1

Re: dlls/d3d8/device.c fails to compile
by fenix＠club-internet.fr 06 Jun '03

06 Jun '03

Hi, Stefan Leichter have already sent a patch (wine-patches archive) to fix it. Thanks to him. But now i want to understand why my gcc3 in c89 mode compil this code without any problem :( Regards, Raphael ----Message d'origine---- >Date: Fri, 6 Jun 2003 11:08:01 +0200 (CEST) >De: Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> >A: wine-devel(a)winehq.com >Copie à: Raphael Junqueira <fenix(a)club-internet.fr> >Sujet: dlls/d3d8/device.c fails to compile > >After the recent wave of commits, I'm getting a build failure for the >following line in dlls/d3d8/device.c: > > IDirect3DBaseTexture8* cont = NULL; > >The failure looks as follows > > device.c:1989: syntax error before `*' > device.c:1991: `hr' undeclared (first use in this function) > device.c:1991: (Each undeclared identifier is reported only once > device.c:1991: for each function it appears in.) > device.c:1991: `cont' undeclared (first use in this function) > gmake[2]: *** [device.o] Error 1 > gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/d3d8' > gmake[1]: *** [d3d8] Error 2 > gmake[1]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls' > gmake: *** [dlls] Error 2 > >which indicates that IDirect3DBaseTexture8 is not a known type at that >point. > >That's using XFree86-4.3.0 and Mesa-3.4.2 (on FreeBSD 4.8). > >Gerald > >PS: I'll happily test any patches to fix this. >-- >Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/ > >

1 0

[FYI] Vacation
by Dimitrie O. Paun 06 Jun '03

06 Jun '03

Folks, I'm leaving for vacation today for a month, I'll be back July 7th. I'll probably read my email from time to time, but I will not be very active on the lists. All the best, and I'll see you soon! (maybe Wineconf? :)) -- Dimi. P.S. Don't release 0.9 without me! :)))

2 2

Re: Re: GL Header question
by fenix＠club-internet.fr 06 Jun '03

06 Jun '03

>> well, better ;) >> my goal is to detect and active all capabilities on runtime and never bother >> again about declared/defined caps from gl headers (gl,glext,glx). >> For this we need an header where all defines and functions pointers are >> declared (as seen in d3dcore_gl.h) > >As said in another mail, I agree for glext.h but not for GL.h. Or >if we go that way, why not ship a 'valid' set of gl.h / glext.h / >glxext.h that are known to work instead of redoing all the >constants ? No, i not want to redefine all constants, i'll only define needed defines and prototypes for compilation. For GL.h see my last mail >For example, we know that Raphael has a configuration where his >tree builds... Well, let him ship his .hs in Wine :-) lol why not, but i think sending the three (or two) headers in wine tree can be replaced by a "minimalist" header (only define what we need) for compilation > Lionel Raphael

1 0

Re: RE: GL Header question
by fenix＠club-internet.fr 06 Jun '03

06 Jun '03

Re, >>As said in another mail, I agree for glext.h but not for GL.h. Or if we go >>that way, why not ship a 'valid' set of gl.h / glext.h / glxext.h that are >>known to work instead of redoing all the constants ? > >Curiously, why glext and not gl? I'd be more for shipping all 3 >if required or merging them all into one wine header. Could we >not just be causing ourselves the same problem further down the >line otherwise? I not approve to merge all gl headers into one HUGE header. I only want to have its the minimalist header where we only define what we need. >>For example, we know that Raphael has a configuration where his >>tree builds... Well, let him ship his .hs in Wine :-) > >Perhaps they are copyright nvidia? :-) Yes, but i think they redistribuable. (they are here: http://cvs1.nvidia.com/inc/GL/) Else we can always use last mesa headers. >Jason Raphael

2 1

Fixme:s in simcity 4 native install (DDRAW.dll.DdEntry, commctrl:InitCommo)
by Arne Falk 06 Jun '03

06 Jun '03

I am trying to install Simcity 4 natively in Linux with just wine setup.exe, everything else default. I get some Fixme:s that I hope someone is interested in. [root(a)foo cdrom]# wine setup.exe err:font:ReadFontDir Can't open directory "/mnt/windows/windows/Fonts" err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/drakfont/ttf " FIXME:pthread_cond_init ... ... (these 3 lines are repeated many times) ... fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x8000 err:dc:DCE_FreeWindowDCE [0x3003f] GetDC() without ReleaseDC()! FIXME:pthread_cond_init mcop warning: user defined signal handler found for SIG_PIPE, overriding err:wave:ARTS_WaveInit arts_init() failed (-1) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403d2cf8)->(00000000,00000008 ) err:module:import_dll No implementation for NTDLL.dll.IoUnregisterDeviceInterfac e imported from C:\windows\system\cfgmgr32.dll, setting to 0xdeadbeef fixme:file:DeviceIoControl ignored dwIoControlCode=80000072 err:module:import_dll No implementation for DDRAW.dll.DdEntry18 imported from C: \windows\system\d3d8.dll, setting to 0xdeadbeef err:module:import_dll No implementation for DDRAW.dll.DdEntry19 imported from C: \windows\system\d3d8.dll, setting to 0xdeadbeef ... (repeated many times for other DdEntryxx) ... fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403d4258)->(00000000,00000008 ) err:module:import_dll No implementation for NTDLL.dll.IoUnregisterDeviceInterfac e imported from C:\windows\system\cfgmgr32.dll, setting to 0xdeadbeef fixme:file:DeviceIoControl ignored dwIoControlCode=80000072 _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus

2 1

Re: Add root drive mapping to default config file
by PETREOLLE Sylvain 06 Jun '03

06 Jun '03

Hi Mike, please dont add / to the default config. Some reasons no to do that: - its insecure, since you can write everywhere you want and some filesystem corruption still exist today. - it will cause recursion/drive change problems => example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ? On my RH box I have a drive called W: that contains wine sources and P: contains programs/. If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:\. Sylvain Petreolle -at work-

21 48

Re: loading and running windows dlls in a linux program
by Rolf Kalbermatter 06 Jun '03

06 Jun '03

Stefan Sperling <w9rk(a)gmx.net> wrote: >Three of which come from wine: > > LoadLibraryA > GetProcAddress > FreeLibrary > >Are these all I need? In theory, this looks about enough to be able to load >a shared object... but I will need a lot of other wine internals too, >in case a dll does a system call (like malloc, which will definitely happen), >won't I? Well they probably come from Wine but as they are just the standard Win32 API functions they could be from anywhere. Also note that this closed source approach wouldn't be possible with the current Wine license anymore. Have you looked at the according functions? They need to almost completely understand the executable file format layout of Windows files which isn't exactly simple. And I believe the current Wine implementation also supports loading ELF libraries as DLLs, something you won't really need. Taking this code and integrate it in your own environment will certainly be quite some work and may actually end up to be a major project of its own! >What happens if I pass a pointer to a method contained in a windows >dll?? Will wine take care about low level stuff like keeping track >of memory layouts of structs and convert them if they are incorrect? >More precisely: If I reimplement data structures external to the dll but >used by it, will the difference in memory layout between the original >struct the dll expects and my new implementation under linux matter? I think you should safely assume that it will indeed matter. The Windows API is defined on a binary level too, including the calling convention of functions and things such as stucture member alignements. You better make sure your compiler used assumes the same alignement rules or otherwise make him do so by using the correct pragmas. This is usually done by using the official headers of such components, which of course may not be GNU C compilable out of the box. LoadLibrary and GetProcAddress have not enough information about the calling convention and alignement constraints used both in the DLL itself as in the caller to actually do the necessary translation for you. Rolf Kalbermatter

1 0

Re: Re: Submits galore
by fenix＠club-internet.fr 06 Jun '03

06 Jun '03

hmmm, very strange, what gl.h and glext.h header you are using ? can you send me the two ? PS: As jason have some compilation problems too as it use a specific gl.h with a generic glext.h, i'm thinking about not using anymore the gl/glext headers definitions (i'm too bored to fixes each mismatch headers declaration) Regards, Raphael >> It seems Alexandre is back or just got tired of the patch storm :) D3D-lovers should update from CVS I'd say. > >Do I get the following because I'm not? > >| make[2]: Entering directory `/usr/home/projects/wine/mywine/dlls/d3d8' >| gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o basetexture.o basetexture.c >| In file included from ../../include/objbase.h:306, >| from ../../include/d3d8.h:22, >| from d3d8_private.h:55, >| from basetexture.c:29: >| ../../include/objidl.h:5960: warning: declaration does not declare anything >| In file included from basetexture.c:29: >| d3d8_private.h:198: error: parse error before "PFNGLCOLORTABLEEXTPROC" >| d3d8_private.h:198: warning: no semicolon at end of struct or union >| d3d8_private.h:198: error: parse error before "glPointParameterfEXT" >| d3d8_private.h:198: warning: type defaults to `int' in declaration of `glPointParameterfEXT' >| d3d8_private.h:198: error: `glPointParameterfEXT' redeclared as different kind of symbol >| /usr/include/GL/gl.h:2484: error: previous declaration of `glPointParameterfEXT' >| d3d8_private.h:198: warning: data definition has no type or storage class >| d3d8_private.h:198: error: parse error before "glPointParameterfvEXT" >| d3d8_private.h:198: warning: type defaults to `int' in declaration of `glPointParameterfvEXT' >| d3d8_private.h:198: error: `glPointParameterfvEXT' redeclared as different kind of symbol >| /usr/include/GL/gl.h:2485: error: previous declaration of `glPointParameterfvEXT' >| d3d8_private.h:198: warning: data definition has no type or storage class >| d3d8_private.h:198: error: parse error before "glSecondaryColor3ubEXT" >| d3d8_private.h:198: warning: type defaults to `int' in declaration of `glSecondaryColor3ubEXT' >| d3d8_private.h:198: error: `glSecondaryColor3ubEXT' redeclared as different kind of symbol >| /usr/include/GL/gl.h:2562: error: previous declaration of `glSecondaryColor3ubEXT' >| d3d8_private.h:198: warning: data definition has no type or storage class >| d3d8_private.h:198: error: parse error before "glSecondaryColor3fEXT" >| d3d8_private.h:198: warning: type defaults to `int' in declaration of `glSecondaryColor3fEXT' >| d3d8_private.h:198: error: `glSecondaryColor3fEXT' redeclared as different kind of symbol >| /usr/include/GL/gl.h:2556: error: previous declaration of `glSecondaryColor3fEXT' >| d3d8_private.h:198: warning: data definition has no type or storage class >| d3d8_private.h:198: error: parse error before "glSecondaryColor3fvEXT" >| d3d8_private.h:198: warning: type defaults to `int' in declaration of `glSecondaryColor3fvEXT' >| d3d8_private.h:198: error: `glSecondaryColor3fvEXT' redeclared as different kind of symbol >| /usr/include/GL/gl.h:2557: error: previous declaration of `glSecondaryColor3fvEXT' >| d3d8_private.h:198: warning: data definition has no type or storage class >| d3d8_private.h:198: error: parse error before "glSecondaryColorPointerEXT" >| d3d8_private.h:198: warning: type defaults to `int' in declaration of `glSecondaryColorPointerEXT' >| d3d8_private.h:198: error: `glSecondaryColorPointerEXT' redeclared as different kind of symbol >| /usr/include/GL/gl.h:2568: error: previous declaration of `glSecondaryColorPointerEXT' >| d3d8_private.h:198: warning: data definition has no type or storage class >| d3d8_private.h:200: error: parse error before '}' token >| d3d8_private.h:200: warning: type defaults to `int' in declaration of `GL_Info' >| d3d8_private.h:200: warning: data definition has no type or storage class >| d3d8_private.h:256: error: parse error before "GL_Info" >| d3d8_private.h:256: warning: no semicolon at end of struct or union >| make[2]: *** [basetexture.o] Error 1 >| make[2]: Leaving directory `/usr/home/projects/wine/mywine/dlls/d3d8' >| make[1]: *** [d3d8] Error 2 >| make[1]: Leaving directory `/usr/home/projects/wine/mywine/dlls' >| make: *** [dlls] Error 2 > >Rein. >-- >Rein Klazes >rklazes(a)xs4all.nl > >

2 1

Documentation?
by Hal Mikimoto 06 Jun '03

06 Jun '03

Hello all, I've been watching Wine grow for the last two years or somsuch. During this time I have wished that I could contribute to the cause, but alas my coding skills rank somewhere around the level of Jello and can't offer much there. While reading the list I saw the Wine Status pages were linked a few emails ago. I have never seen these pages before and a quick glance and shown that the Documentation side of things needs some TLC *badly*. For those who don't know who I am, I wrote a PSX internals doc a few years ago that made Slashdot a few times. I quite versed at internet data mining and putting the resultant finds in documentation form. The problem is that I'm confused by what kind of documentation you need. Let me give you an example. On the Wine Status DLL page comctl32 is reported of having nonexistant documentaion. A quick look in the CVS browser-thingy shows that in the code itself, comctl32 is quite nicely documented. So what exactly is needed? An API listing? a very verbose version of the .spec file? How to use it? What it does? It's depencies? Is there a particular format I have to stick to? Could anyone hive a pointer of what exactly you are looking for? Joshua "Haruhito" Walker P.S. I have a killer Registry API book too, if that helps any. __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com

3 2