wine-devel

wine-devel@winehq.org

9 participants
84458 discussions

Re: PPC CPU Detection in configure
by Marcus Meissner 13 Jul '03

13 Jul '03

On Sun, Jul 13, 2003 at 02:20:53PM +0200, Pierre d'Herbemont wrote: > Hi, > > Here is a patch which adds CPU Detection for the PowerPC Processor in > configure.ac. There wasn't any in configure, is there any reason? By > the way there is two flags for the powerpc : __PPC__ and __powerpc__ > any reason, or should they be unified? My gcc already defines them correctly. Ciao, Marcus

2 1

bridge winelib app and linux app
by Evalet Olivier 13 Jul '03

13 Jul '03

Hello, I'm working on an application "audacity" which use the multi-os wxWindows lib. This application uses a feature available only on windows and Mac - the audio effects for the VST plug-ins. Now I have done a winelib app to bridge the native dll (audio VST effects) with the native unix app. It seems to be ok, all plugins are loaded. But, I would like to know if I must establish a link between wine and my linux app for some resources like the threads? Thanks Olivier

2 3

Concerning palettes
by Johan Gill 13 Jul '03

13 Jul '03

I am wondering about the Windows implementation of GDI32.GetSystemPaletteEntries. Wine does not return any palette for a display DC if X is not running in paletted mode, but is this correct? That is, does Windows running in a non-paletted display mode behave the same way? /Johan Gill <johane(a)lysator.liu.se>

1 0

future chat meetings ?
by Tom 13 Jul '03

13 Jul '03

hello, I read over the log's of the last chat meeting and it looks like you guy's had alot of fun :)) And got some future details worked out ..... May I ask if there is another one planned ? or if we should plan one each quarter or so ? Tom

1 0

stupid question........ Talkbacks on winehq front page
by Tom 13 Jul '03

13 Jul '03

Hello, May I ask how hard it would be to add talk-backs to the front page of winehq ?? like those of linuxtoday ... If we were to do this (someday) would we need a moderator ? Anyone have any thoughts about this? Tom

1 0

LoadLibrary problem
by Dimitrie O. Paun 12 Jul '03

12 Jul '03

Hi guys, I'm back from my vacation! :) Before I left I had problems running visual-mingw when built as a Winelib app. This is a C++ app and needs the wrapper idea to work. In other words the main app is in a dll names 'visual-mingw-wrap.dll.so' (I've added the 'wrap' in the name to avoid potential confusion, and to make it easier to search for it). The wrapper simply does a LoadLibrary for this DLL, and this LoadLibrary call fails. Here is the relevant part of a --debugmsg +module,+server Any ideas? .... trace:module:MODULE_InitDLL (0x40980000,PROCESS_ATTACH,0x1) - RETURN 1 trace:module:MODULE_DllProcessAttach (user32.dll,0x1) - END trace:module:MODULE_DllProcessAttach (visual-mingw.exe,0x1) - END trace:module:GetModuleFileNameW L"F:\\dev\\wine\\visual-mingw\\bin\\visual-mingw.exe" trace:module:MODULE_GetLoadOrder looking for F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so trace:module:GetModuleFileNameW L"F:\\dev\\wine\\visual-mingw\\bin\\visual-mingw.exe" trace:module:open_app_key searching 'F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so' in AppDefaults\visual-mingw.exe\DllOverrides 0009: open_key( parent=(nil), access=000f003f, name=L"Machine\\Software\\Wine\\Wine\\Config\\AppDefaults" ) Open key ERROR 0009: open_key() = OBJECT_NAME_NOT_FOUND { hkey=(nil) } 0009: get_key_value( hkey=0x14, name=L"F:\\dev\\wine\\visual-mingw\\bin\\visual-mingw-wrap.dll.so" ) 0009: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, total=0, data={} } 0009: get_key_value( hkey=0x14, name=L"*visual-mingw-wrap.dll.so" ) 0009: get_key_value() = OBJECT_NAME_NOT_FOUND { type=-1, total=0, data={} } trace:module:MODULE_GetLoadOrder got hardcoded path default "n,b" for "F:\\dev\\wine\\visual-mingw\\bin\\visual-mingw-wrap.dll.so" trace:module:load_dll Trying native dll 'F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so' 0009: create_file( access=80000000, inherit=0, sharing=00000001, create=3, attrs=00000000, drive_type=3, filename="/home/dimi/dev/wine/visual-mingw/bin/visual-mingw-wrap.dll.so" ) 0009: create_file() = 0 { handle=0x34 } trace:module:PE_LoadImage loading F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is correct, Wine finds the file correctly. trace:module:PE_LoadImage Trying to create section... Here, we're executing this (which fails): TRACE( "Trying to create section...\n" ); if (NtCreateSection( &mapping, STANDARD_RIGHTS_REQUIRED | SECTION_QUERY | SECTION_MAP_READ, &attr, &lg_int, 0, SEC_IMAGE, hFile ) != STATUS_SUCCESS) return 0; 0009: create_mapping( size_high=0, size_low=0, protect=192, access=000f0005, inherit=0, file_handle=0x34, name=L"" ) 0009: create_mapping() = INVALID_FILE_FOR_SECTION { handle=(nil) } 0009: close_handle( handle=0x34 ) 0009: close_handle() = 0 { fd=-1 } warn:module:load_dll Loading of native DLL F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so failed (status -1073741595). warn:module:load_dll Failed to load module 'F:\dev\wine\visual-mingw\bin\visual-mingw-wrap.dll.so'; status=-1073741595 trace:module:LdrGetDllHandle 0 0 L"user32.dll" -> 0x40980000 trace:module:GetModuleHandle16 (USER) .... -- Dimi.

3 2

Dungeon Crafter
by Marcus Brubaker 12 Jul '03

12 Jul '03

Hey All, I'm working on getting the Dungeon Crafter (version 1.4.1) working. You can download the program for free at www.dungeoncrafter.com. The installation goes perfectly (Excellent work to everyone who's been working on installers. I'm very impressed) but when I run the program it gives the following: fixme:ole:CoRegisterMessageFilter stub fixme:ole:OleLoadPictureEx (0x418bfe4c,19410,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x407929f0), partially implemented. err:ole:_jpeg_skip_input_data (3506), should not get here. Corrupt JPEG data: 370 extraneous bytes before marker 0x03 Unsupported marker type 0x03 I'm using the wine rpm for redhat 9 downloaded from the sourceforge page. This is a windows free installation and the only changes I made to the default configuration is to update the drive paths. Any suggestions on what might be happening? Regards, -- Marcus Brubaker <marcus.brubaker(a)utoronto.ca>

3 2

Re: Question about IPC between WINE and other processes
by Roderick Colenbrander 12 Jul '03

12 Jul '03

You need to develop this winelib dll from Linux. Also check out the winelib docs. (I'd recommend you to use winegcc since you likely won't port old code ... ) Roderick On Friday 11 July 2003 23:41, you wrote: > Hello Roderick, > > I have nother question about the usage of dll: > > Can I use visual studio in windows to generate a windows dll to implement > all the functionalities I need, then transfer it directly to linux using > under WINE? > > Maybe it can't work for IPC stuffs discussed before, right? > > Many thanks > > -Lechun > > Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > What Mike meant is the same as I said. Look at the winelib docs at the wine > page. I'm not sure if they are up2date. A new but easier way to use winelib > is to use "winegcc" a frontend to gcc which handles all difficult wine > linking stuff. The syntax is similar to gcc and it supports various mingw > options. > > All dlls wine uses are winelib dlls. It are linux libraries but with a > similar structure as native windows dlls. Because of this structure you can > easily replace a native dll of your app with a winelib dll. > > The advantage of winelib is that you can use all libraries you have on > windows and all you have on windows. > > So I would move the linux functionality you need inside a winelib dll. > Using this way you don't need to recompile all the source of your app using > winelib which can be a pain. This way is used by lots of companies since it > is easy and gives good performance. > > I hope this helps and good luck, > Roderick > > On Friday 11 July 2003 18:44, you wrote: > > Hello Roderick, > > > > Thank you for your answering. > > Actually, now I am trying to use WINE to port an windows application to > > linux. But if I use program loader provided by WINE to directly run the > > exe file under linux, some of the functionalities are involved with IPC > > between WINE and other local X processes, which is not supported by WINE. > > > > So, I need to rewrite the local codes for them, as Mike explained before, > > > > "What you can do is rewrite only the parts that need rewriting and turn > > them into shared libraries. Then you can use WineLib to combine the > > Win32 code and the Linux code into one program." > > > > Here, I am glad to learn from you there seems a more easy way: > > (As my understanding, the other way you mentioned is the same one as > > Mike's) > > > > "An easy way is to put this > > X functionality in a winelib dll. This dll can then be used by your app. > > The advantage of a winelib dll is that it can use win32 api's but also > > native Linux api's." > > > > Could you please make sure whether this method can meet the need to "find > > any process's window info", not only "windows under WINE" ? > > > > And could you please give some more implementation details about that? > > > > Thanks a lot! > > > > -Lechun > > > > Roderick Colenbrander wrote: > > Hi, > > > > As I understand it you have a Windows app that needs to have access to > > some X stuff. To access that you somehow need to extend your app with > > some X functionality. There are several ways to do that. An easy way is > > to put this X functionality in a winelib dll. This dll can then be used > > by your app. The advantage of a winelib dll is that it can use win32 > > api's but also native Linux api's. The other option is to completely > > build your app using winelib and also add the native code. Personally I > > think the dll is the easiest way. > > > > Roderick > > > > On Thursday 10 July 2003 23:36, dd jj wrote: > > > Hello Mike, > > > > > > So as my understanding, even recompile the original windows codes using > > > WINELIB will not work, am I correct? > > > > > > Since finding window info under cursor is only one of the functionality > > > in this application, it will be a huge work to rewrite all the codes > > > for X window. Is there any Avenue to port such a windows application to > > > Linux? Using Visual Mainwin or Win/U is better choices? or any other > > > comments on it? > > > > > > Thanks a lot! > > > > > > -Lechun > > > > > > Mike Hearn wrote: > > > Programs run under emulation are only aware of other Wine programs. If > > > you want to write an app like that, you'd need to rewrite it for Linux. > > > > > > BTW, you might want to talk to a guy named Bill Haneman (i think that's > > > the spelling). He does Gnome accessibility, and i think they have an > > > app that can read info about stuff under the mouse cursor. > > > > > > On Thu, 2003-07-10 at 20:41, dd jj wrote: > > > > Thank you for response. The following is my further question: > > > > > > > > Here is my case: > > > > > > > > Now I am trying to run our own developed application under wine, the > > > > original function of this app is working as a background daemon > > > > without GUI who is trying to figure out some window information under > > > > the current cursor, such as the window title, class name using > > > > GetWindowTitle, GetClassName ... WIN32 API calls. > > > > > > > > When I run this under WINE, it can't "see" any other Local X > > > > application windows such as Xterm, Xclock... which don't run under > > > > WINE. > > > > > > > > > > > > I am wondering whether I can recompile the codes to generate a lcoal > > > > X application using winelib to solve this problem, or I must write > > > > X11 based codes? > > > > > > > > Thanks a lot! > > > > > > > > -Lechun > > > > > > > > Mike Hearn wrote: > > > > > fixme:class:get_class_ptr reading from class of other > > > > > > > > process window > > > > > > > > > 0x2002a > > > > > err:win:WIN_FindWndPtr window 0x2003a belongs to other > > > > > > > > process > > > > > > > > Well these two are known problems. I think it's something > > > > Alexandre will > > > > be working on at some point, inter-process window > > > > communication isn't > > > > really implemented well in Wine at present. > > > > > > > > > Also I found other errors when I launch my window appication > > > > > > > > under > > > > > > > > > wine: > > > > > > > > > > err:module:import_dll No implementation for > > > > > > > > USER32.dll.GetTitleBarInfo > > > > > > > > > imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef > > > > > err:module:import_dll No implementation for > > > > > > > > USER32.dll.GetMenuBarInfo > > > > > > > > > imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef > > > > > > > > Unless the program actually uses them, this isn't a problem. > > > > If it does, > > > > the app will crash, at which point we'd need to write those > > > > functions or > > > > stub them out. > > > > > > > > thanks -mike > > > > > > > > > > > > _____________________________________________________________________ > > > >_ Do you Yahoo!? > > > > SBC Yahoo! DSL - Now only $29.95 per month! > > > > > > --------------------------------- > > > Do you Yahoo!? > > > SBC Yahoo! DSL - Now only $29.95 per month! > > > > --------------------------------- > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > --------------------------------- > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month!

1 0

Re: wine/dlls/opengl32 wgl.c
by Marcelo Duarte 12 Jul '03

12 Jul '03

Em Sex 11 Jul 2003 18:53, Alexandre Julliard escreveu: > ChangeSet ID: 8742 > CVSROOT: /home/winehq/opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/07/11 16:53:26 > > Modified files: > dlls/opengl32 : wgl.c > > Log message: > Lionel Ulmer <lionel.ulmer(a)free.fr> > Check if 'GLX_ARB_get_proc_address' is supported before using > glXGetProcAddressARB. > > Patch: > http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8742 > > Old revision New revision Changes Path > 1.35 1.36 +9 -5 wine/dlls/opengl32/wgl.c In my system, the last patch caused this warnings. Thank you. make[2]: Entering directory `/home/mduarte/wine/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 d3d8_private.h:192, from basetexture.c:29: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from basetexture.c:29: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from basetexture.c:29: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from basetexture.c:29: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 cubetexture.o cubetexture.c In file included from d3d8_private.h:192, from cubetexture.c:29: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from cubetexture.c:29: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from cubetexture.c:29: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from cubetexture.c:29: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 d3d8_main.o d3d8_main.c In file included from d3d8_private.h:192, from d3d8_main.c:28: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from d3d8_main.c:28: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from d3d8_main.c:28: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from d3d8_main.c:28: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 device.o device.c In file included from d3d8_private.h:192, from device.c:36: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from device.c:36: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from device.c:36: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from device.c:36: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 directx.o directx.c In file included from d3d8_private.h:192, from directx.c:32: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from directx.c:32: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from directx.c:32: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from directx.c:32: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition directx.c: In function `IDirect3D8Impl_FillGLCaps': directx.c:779: warning: implicit declaration of function `glXGetProcAddressARB' 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 drawprim.o drawprim.c In file included from d3d8_private.h:192, from drawprim.c:34: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from drawprim.c:34: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from drawprim.c:34: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from drawprim.c:34: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 indexbuffer.o indexbuffer.c In file included from d3d8_private.h:192, from indexbuffer.c:29: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from indexbuffer.c:29: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from indexbuffer.c:29: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from indexbuffer.c:29: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 resource.o resource.c In file included from d3d8_private.h:192, from resource.c:29: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from resource.c:29: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from resource.c:29: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from resource.c:29: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 shader.o shader.c In file included from d3d8_private.h:192, from shader.c:31: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from shader.c:31: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from shader.c:31: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from shader.c:31: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 stateblock.o stateblock.c In file included from d3d8_private.h:192, from stateblock.c:31: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from stateblock.c:31: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from stateblock.c:31: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from stateblock.c:31: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 surface.o surface.c In file included from d3d8_private.h:192, from surface.c:33: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from surface.c:33: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from surface.c:33: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from surface.c:33: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 swapchain.o swapchain.c In file included from d3d8_private.h:192, from swapchain.c:29: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from swapchain.c:29: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from swapchain.c:29: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from swapchain.c:29: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 texture.o texture.c In file included from d3d8_private.h:192, from texture.c:29: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from texture.c:29: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from texture.c:29: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from texture.c:29: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 utils.o utils.c In file included from d3d8_private.h:192, from utils.c:34: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from utils.c:34: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from utils.c:34: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from utils.c:34: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 vertexbuffer.o vertexbuffer.c In file included from d3d8_private.h:192, from vertexbuffer.c:29: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from vertexbuffer.c:29: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from vertexbuffer.c:29: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from vertexbuffer.c:29: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 volume.o volume.c In file included from d3d8_private.h:192, from volume.c:32: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from volume.c:32: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from volume.c:32: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from volume.c:32: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 volumetexture.o volumetexture.c In file included from d3d8_private.h:192, from volumetexture.c:29: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from volumetexture.c:29: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from volumetexture.c:29: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from volumetexture.c:29: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition 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 vshaderdeclaration.o vshaderdeclaration.c In file included from d3d8_private.h:192, from vshaderdeclaration.c:31: d3dcore_gl.h:129:1: warning: "GL_DOT3_RGB_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from vshaderdeclaration.c:31: /usr/include/GL/glext.h:462:1: warning: this is the location of the previous definition In file included from d3d8_private.h:192, from vshaderdeclaration.c:31: d3dcore_gl.h:130:1: warning: "GL_DOT3_RGBA_EXT" redefined In file included from /usr/include/GL/gl.h:2436, from d3d8_private.h:30, from vshaderdeclaration.c:31: /usr/include/GL/glext.h:464:1: warning: this is the location of the previous definition -- Marcelo Duarte

1 0

Building winelib without wine...
by Mark Easton 11 Jul '03

11 Jul '03

Having scanned the WineHQ website thoroughly I've come across a couple of posts that suggest that winelib has been previously been made to work on PPC, although I cannot find any details of how to attempt such a thing. Can anyone suggest how I could start trying to get Winelib built on PPC as I really can't find any details about building winelib without wine Cheers Mark Easton

2 1

Re: Question about IPC between WINE and other processes
by dd jj 11 Jul '03

11 Jul '03

Hello Roderick, I have nother question about the usage of dll: Can I use visual studio in windows to generate a windows dll to implement all the functionalities I need, then transfer it directly to linux using under WINE? Maybe it can't work for IPC stuffs discussed before, right? Many thanks -Lechun Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: What Mike meant is the same as I said. Look at the winelib docs at the wine page. I'm not sure if they are up2date. A new but easier way to use winelib is to use "winegcc" a frontend to gcc which handles all difficult wine linking stuff. The syntax is similar to gcc and it supports various mingw options. All dlls wine uses are winelib dlls. It are linux libraries but with a similar structure as native windows dlls. Because of this structure you can easily replace a native dll of your app with a winelib dll. The advantage of winelib is that you can use all libraries you have on windows and all you have on windows. So I would move the linux functionality you need inside a winelib dll. Using this way you don't need to recompile all the source of your app using winelib which can be a pain. This way is used by lots of companies since it is easy and gives good performance. I hope this helps and good luck, Roderick On Friday 11 July 2003 18:44, you wrote: > Hello Roderick, > > Thank you for your answering. > Actually, now I am trying to use WINE to port an windows application to > linux. But if I use program loader provided by WINE to directly run the exe > file under linux, some of the functionalities are involved with IPC between > WINE and other local X processes, which is not supported by WINE. > > So, I need to rewrite the local codes for them, as Mike explained before, > > "What you can do is rewrite only the parts that need rewriting and turn > them into shared libraries. Then you can use WineLib to combine the > Win32 code and the Linux code into one program." > > Here, I am glad to learn from you there seems a more easy way: > (As my understanding, the other way you mentioned is the same one as > Mike's) > > "An easy way is to put this > X functionality in a winelib dll. This dll can then be used by your app. > The advantage of a winelib dll is that it can use win32 api's but also > native Linux api's." > > Could you please make sure whether this method can meet the need to "find > any process's window info", not only "windows under WINE" ? > > And could you please give some more implementation details about that? > > Thanks a lot! > > -Lechun > > Roderick Colenbrander wrote: > Hi, > > As I understand it you have a Windows app that needs to have access to some > X stuff. To access that you somehow need to extend your app with some X > functionality. There are several ways to do that. An easy way is to put > this X functionality in a winelib dll. This dll can then be used by your > app. The advantage of a winelib dll is that it can use win32 api's but also > native Linux api's. The other option is to completely build your app using > winelib and also add the native code. Personally I think the dll is the > easiest way. > > Roderick > > On Thursday 10 July 2003 23:36, dd jj wrote: > > Hello Mike, > > > > So as my understanding, even recompile the original windows codes using > > WINELIB will not work, am I correct? > > > > Since finding window info under cursor is only one of the functionality > > in this application, it will be a huge work to rewrite all the codes for > > X window. Is there any Avenue to port such a windows application to > > Linux? Using Visual Mainwin or Win/U is better choices? or any other > > comments on it? > > > > Thanks a lot! > > > > -Lechun > > > > Mike Hearn wrote: > > Programs run under emulation are only aware of other Wine programs. If > > you want to write an app like that, you'd need to rewrite it for Linux. > > > > BTW, you might want to talk to a guy named Bill Haneman (i think that's > > the spelling). He does Gnome accessibility, and i think they have an app > > that can read info about stuff under the mouse cursor. > > > > On Thu, 2003-07-10 at 20:41, dd jj wrote: > > > Thank you for response. The following is my further question: > > > > > > Here is my case: > > > > > > Now I am trying to run our own developed application under wine, the > > > original function of this app is working as a background daemon > > > without GUI who is trying to figure out some window information under > > > the current cursor, such as the window title, class name using > > > GetWindowTitle, GetClassName ... WIN32 API calls. > > > > > > When I run this under WINE, it can't "see" any other Local X > > > application windows such as Xterm, Xclock... which don't run under > > > WINE. > > > > > > > > > I am wondering whether I can recompile the codes to generate a lcoal X > > > application using winelib to solve this problem, or I must write X11 > > > based codes? > > > > > > Thanks a lot! > > > > > > -Lechun > > > > > > Mike Hearn wrote: > > > > fixme:class:get_class_ptr reading from class of other > > > > > > process window > > > > > > > 0x2002a > > > > err:win:WIN_FindWndPtr window 0x2003a belongs to other > > > > > > process > > > > > > Well these two are known problems. I think it's something > > > Alexandre will > > > be working on at some point, inter-process window > > > communication isn't > > > really implemented well in Wine at present. > > > > > > > Also I found other errors when I launch my window appication > > > > > > under > > > > > > > wine: > > > > > > > > err:module:import_dll No implementation for > > > > > > USER32.dll.GetTitleBarInfo > > > > > > > imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef > > > > err:module:import_dll No implementation for > > > > > > USER32.dll.GetMenuBarInfo > > > > > > > imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef > > > > > > Unless the program actually uses them, this isn't a problem. > > > If it does, > > > the app will crash, at which point we'd need to write those > > > functions or > > > stub them out. > > > > > > thanks -mike > > > > > > > > > ______________________________________________________________________ > > > Do you Yahoo!? > > > SBC Yahoo! DSL - Now only $29.95 per month! > > > > --------------------------------- > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > --------------------------------- > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!

1 0

patch makes all apps ignore input
by Saulius Krasuckas 11 Jul '03

11 Jul '03

it wasn't hard to find which patch did it: http://www.winehq.org/hypermail/wine-cvs/2003/07/0085.html

1 0

Re: French keyboard layout without Euro
by Dmitry Timoshkov 11 Jul '03

11 Jul '03

"Stephan BEUZE" <sbeuze(a)hotmail.com> wrote: > It used to work without FIXME message, why should it suddently give me all > the time this message. I don't think that it's my patch that caused the FIXME to appear. Could you try to revert my patch and see whether FIXME goes away? > IMO wine claims thereis a problem that doesn't exist. > It should not work such a way. FIXME was added on purpose. It reports a real problem, it just happens that the problem doesn't affect you too much. -- Dmitry.

2 1

Question about IPC between WINE and other processes
by dd jj 11 Jul '03

11 Jul '03

Hello Everyone, I am trying to run a windows application under WINE program loader, but it fails when trying to find other local application windows, It seems when it run under wine, it can't "SEE" other Local X application. How can I solve this problem? Thanks in advance --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!

4 9

Re: lostwages/ news/2003071101.xml wwn/wn20030711_ ...
by Vincent Béron 11 Jul '03

11 Jul '03

Le ven 11/07/2003 à 10:16, Jeremy Newman a écrit : > ChangeSet ID: 8735 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: jnewman(a)wine.codeweavers.com 2003/07/11 09:16:16 > > Added files: > news : 2003071101.xml > wwn : wn20030711_178.xml > > Log message: > WWN Issue 178 > > Patch: http://cvs.winehq.com/patch.py?id=8735 > > Old revision New revision Changes Path > Added 1.1 +0 -0 lostwages/news/2003071101.xml > Added 1.1 +0 -0 lostwages/wwn/wn20030711_178.xml Using small fonts and a somewhat big Mozilla window (~1600x1200), the last subject has a smaller width than the others, but is still centered. It's because there's no line of text long enough to fill the whole width of the window. Is that the intended effect, or something I happen to see because of font/width? Some weeks it makes WWN really awkward to look at. Vincent

1 0

Re: French keyboard layout without Euro
by Dmitry Timoshkov 11 Jul '03

11 Jul '03

"biggun from the sun" <fbiggun(a)hotmail.com> wrote: > Changelog: > Add a French keyboard layout without Euro. Why do you need a new keyboard layout? With the new CP_UNIXCP support in place all the keys should work for you as expected. Or is it just to suppress a FIXME message? If the latter, I'd suggest to refrain from commiting this and similar patches. -- Dmitry.

4 11

Re: [Patch] dlls/oleaut32/typelib.c - fix kazaalite
by Dmitry Timoshkov 11 Jul '03

11 Jul '03

"Stefan Jones" <cretin(a)gentoo.org> wrote: > On upgrading to Wine 20030618/20030709 I found that kazaa lite will no longer > work ... > The following patch reversal fixes it: > ( it undoes Dmitry's patch ) If you could confirm that after your patch attached program while loading native olepro32.dll and msvbvm60.dll still prints the following: Loading: "olepro32.dll" LoadTypeLib() = 00000000 GetLibAttr() = 00000000 ITypeLib2_Release() = 0 Loading: "msvbvm60.dll" LoadTypeLib() = 00000000 GetLibAttr() = 00000000 ITypeLib2_Release() = 0 then your patch is OK. -- Dmitry.

2 1

Re: Question about IPC between WINE and other processes
by Dan Kegel 10 Jul '03

10 Jul '03

Lechun wrote: > Now I am trying to run our own developed application under wine, the > original function of this app is working as a background daemon without > GUI who is trying to figure out some window information under the current > cursor, such as the window title, class name using GetWindowTitle, > GetClassName ... WIN32 API calls. > > When I run this under WINE, it can't "see" any other Local X application > windows such as Xterm, Xclock... which don't run under WINE. > > I am wondering whether I can recompile the codes to generate a lcoal > X application using winelib to solve this problem, or I must write X11 > based codes? Why not use sockets for IPC? Have the background daemon open up a listening socket bound to 127.0.0.1, and have the foreground app that wants to talk to the daemon connect to that socket. Or does the daemon actually need GUI information for some reason? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

RE: LZCopy mantain the timestamp in expanded file
by Robert Shearman 10 Jul '03

10 Jul '03

> > Changelog: > - LZCopy: modified timestamp of a expanded file have to be the same of > original file. > > Index: dlls/lzexpand/lzexpand_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/lzexpand/lzexpand_main.c,v > retrieving revision 1.20 > diff -u -r1.20 lzexpand_main.c > --- dlls/lzexpand/lzexpand_main.c 30 Apr 2003 17:15:06 -0000 1.20 > +++ dlls/lzexpand/lzexpand_main.c 9 Jul 2003 17:03:14 -0000 > @@ -476,6 +476,16 @@ > if (wret!=ret) > return LZERROR_WRITE; > } > + > + /* Change the timestamp of file */ > + HFILE fd; > + FILETIME filetime; > + struct lzstate *lzs; Sorry, but this won't compile on older versions of gcc. You need to put the variable declarations at the start of the block. > + fd = (!(lzs = GET_LZ_STATE(src))) ? src : lzs->realfd; > + GetFileTime((HANDLE)fd, NULL, NULL, &filetime); > + SetFileTime((HANDLE)dest, NULL, NULL, &filetime); > + > + /* close handle */ > if (usedlzinit) > LZClose(src); > return len; > Rob

1 0

c2man -R
by biggun from the sun 10 Jul '03

10 Jul '03

1 0

Re: Proxy from environment (resend)
by Mike McCormack 10 Jul '03

10 Jul '03

The proxy support in Wine seems quite broken, and I've added alot of proxy related fixes and features to the Crossover tree (eg. username/password support for proxies). These should be merged to the WineHQ tree after the next release of Crossover Office. Mike Mike Hearn wrote: > ChangeLog: > Take http proxy info from environment when not set in registry

1 0

Wine status Core page
by Tom 10 Jul '03

10 Jul '03

Hello, There has been alot of changes since the last post on this so i'm going to post it again here for everyone to see :)) A short list of changes thus far.. WWN link's (Thanks to Brian) Regedit as a tool. Guessed on the percentage. Winehelp as a tool. Guessed on the percentage. Links to (Instructions) changes made to % Remove : Native Windows printer drivers Remove : DLL placeholder file Remove : CPU emulation remove : WineHQ and Corel relationship remove : Berto from Wine Resource Compiler,Wine Message Compiler.....Add: dimi remove : broken links Add : Eric Pouech as worker to Dll separation Change the Wine release plan from 1.0 to 0.9 and add link to todo's on the front page... Some questions We have statments under, memory managment, Serial/parallel ports, IO port access, VxD's, Initial registry contents, Initial INI contents. Do they still look correct ? Is Regedit, Winehelp % correct ? I still need to add more links to doc status and change the status if it needs be... At this point i'm just looking for feedback on the changes that I have made and if something is incorrect fix it now.. -Thanks Tom **

1 0

Problem In Wine Please Consideration
by faisal shah 10 Jul '03

10 Jul '03

Hi, I have a problem for using wine-20030408 in Linux 8. I am trying to execute the visual basic 6 executable file which includes "tab controls" that using file �tabctrl32.ocx� and �Microsoft Hierarchical FlexGrid Control� that using file �MSHFLXGD.ocx�. When I run the visual basic executable file on Linux through wine, it generates an error which description given below: �Failed to load control �SSTAB� from TABCTL32.OCX. Your version of TABCTL32.OCX may be outdated. Make sure you are using the version of control that was provided with your application.� Manually i register TABCTL32.OCX file using REGSRV32.EXE, and its successfully registered but its gives an error which mentioned above. My question is that I do a right procedure for executing the visual basic file which includes OCX files or not. Please give some solution for these kinds of errors. Faisal Shah. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

1 0

Question about improving debugging on Mingw build
by Steven Edwards 10 Jul '03

10 Jul '03

Hello, I am interested in improving debugging for dlls built with either Mingw or MS_VC if that is ever fixed. We are to the point now where a lot of needed dlls can be built with little or no changes and so I would like to start doing some major testing on Windows and ReactOS but I am unable to see TRACE/WARN/ERR and FIXME messages. Can we make libwine debug channels use OutputDebugString or one of the *printf functions or hell even MessageBox on Windows? In the ReactOS tree one of our developer started his own debug dll with the WINE debug channels using out DbgPrint function but I would like to implement something that is usable on both ReactOS and Windows. Thanks Steven __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

2 3

Re: CPU detection work
by Alexandre Julliard 09 Jul '03

09 Jul '03

Mike Hearn <mike(a)theoretic.com> writes: > ChangeLog: > - Move performance frequency code to misc/cpu.c > - New function, get_cpu_speed() > - Make MHz registry key and QueryPerformanceFrequency use it I was hoping you would merge the CPU speed detection with the rest of the CPU info code, there's really no reason to parse /proc/cpuinfo twice. Also the value that QueryPerformanceFrequency returns needs to match the behavior of QueryPerformanceCounter, you can't simply divide it by 1000. -- Alexandre Julliard julliard(a)winehq.com

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel