- Wine-Devel - list.winehq.org

Re: No go here (Re: [D3D] Added native and emulated S3TC support (take 2))
by Andreas Mohr July 31, 2004

July 31, 2004

Hi, On Sat, Jul 31, 2004 at 02:32:41PM +0100, Christian Costa wrote: > Does this help? > > Changelog: > Moved libtxc_dxt definitions into ddraw headers. Yup, now it appears to compile through, thanks! Haven't tested Lionel's second patch yet, though (thanks, BTW!). Now running with Lionel patch 1 and this patch. Andreas Mohr

2 1

Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered
by Mike Hearn July 31, 2004

July 31, 2004

On Sat, 31 Jul 2004 12:51:01 +0200, Jeroen Janssen wrote: > This change will make sure that if a proxy/stub dll was already registered, > it is not overwritten by the TypeLib Marshaller if we're not registering > an ole automation interface. > I think we (always?) want to use a 'real' available proxy/stub > implementation when available, instead of simply 'overruling' to the > typelib marshaller. Our current DCOM does not use RPC connection management so I'm not sure this will work. That hack is there for a reason: how many InstallShields did you verify this patch works with, and which versions were they?

1 0

Re: [Wine]Help the wine project
by Joshua Crawford July 31, 2004

July 31, 2004

* Michael Chang <michael(a)cherryblossom.homelinux.com> [2004-07-30 13:12 -0400]: > On Fri, 30 Jul 2004 14:12:50 +1000, Joshua Crawford > <mortarn_lists(a)yahoo.com.au> wrote: > >* Ivan Leo Puoti <puoti(a)inwind.it> [2004-07-28 19:14 +0200]: > >>The wine developers have created a test sistem to check if wine works > >>like microsoft windows, but more users are needed to run the tests. > [snip] > >I installed this on a windows 98se box. I can't say I like having the DOS > >window open all the time (it's ugly). Can this not be written as a > >windows programme, and sit in the system tray? > Yes. I don't know how, but I know it's possible. You'd have to probably > find example code that allows this -- writing that kind of thing requires > knowledge of the Windows API for the systray. I think. Maybe send this > request to wine-devel? I don't know (how). One thing to point out though > - > if it ran in the system tray, then you wouldn't be able to run it within > wine. (Yes, I know that sounds stupid...) Cc: to wine-devel added. <snip console app vs. gui, and resizing window> > >Also, during the installation process, after I entered my email address, > >the installer removed what it called 'invalid characters' - i.e., > >underscores. > >All my main email addresses contain underscores, so I was forced to > >enter an old one that is not very reliable. > > How'd this happen? Underscores are very much valid characters in e-mails. > Was the installation check only accepting alpha-numeric characters as > the user part of the e-mail? Dashes should also be acceptable, in both > the username and the domain name. (Otherwise, how could we send e-mail > to the "wine-users" account of the mail server so the mailman service > could get to them?) It boggles me too. Something new: I just booted up that system for the first time since installing winrash (it's not used often), and Windows complained about it performing an illegal operation. Naturally, I tried repeating that by rebooting, and it didn't do it again. -- Joshua 'bruce' Crawford ... http://www.geocities.com/mortarn "Always be sincere, even when you don't mean it." -Irene Peter

2 1

Re: Wine isn't GUI user friendly
by Mike Hearn July 31, 2004

July 31, 2004

Christian Neumair <chris(a)gnome-de.org> writes: > That reminds me of asking for nicer, GUI-driven error handling: > touch mustardandwiener.exe && > wine mustardandwiener.exe > returns > wine: cannot determine executable type for L"H:\\Desktop\\test.exe" > which is neither verbose enough nor user friendly, because it is simply > printed at a terminal. Modern desktop environments usually launch wine > from their file manager, i.e. without terminals. Well, as to the contents of the message itself, I don't know how it could be improved. You asked Wine to run an empty file and it said it can't figure out what kind of executable it is: why is this a problem? As to using message boxes for errors, well I have submitted patches to do this before and some were accepted, and some were not. The reasoning was that having all errors appear in message boxes would be annoying. Perhaps if there was a generic mechanism such that when a terminal was available the message was printed, and when it was not (like in a GUI) a message box was used, that would be more acceptable. I don't know how to tell if a console is available or not though. Plus to be convenient it'd need to be a new Wine API and we're trying to remove them rather than add to them :) > Can't we have popup dialogs for that kind of errors? As far as I know, > debian guys have build a shell/wrapper around wine that pops up if weird > things like these occur. Can't we have such a wrapper in stock wine? For > now, it would be enough to just catch the most common problems (binary > not found, binary can't be loaded, etc.). To be frank I still think displaying the output of stderr when a program launched from the GUI fails is the desktops job. All kinds of messages can be printed by Wine before we even have a chance to initialize the GUI subsystem - in fact the "cannot run exe" message may well be an example of that. Writing a patch to Gnome to make it do that wouldn't be hard and would solve a broad class of problems. thanks -mike

6 10

Re: No go here (Re: [D3D] Added native and emulated S3TC support (take 2))
by Andreas Mohr July 31, 2004

July 31, 2004

Hi, On Sat, Jul 31, 2004 at 01:16:45PM +0200, Lionel Ulmer wrote: > Fixed in the attached patch... At least we know now that Alexandre finally > installed some OpenGL stuff on his development box :-) Works. :) Oh, wait... just when I *wanted* to say it works, I switched back to the console compiling Wine, and: make[2]: Entering directory `/usr/src/apps/CVS/wine/dlls/ddraw' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o main.o main.c main.c:123: error: parse error before "fetch_2d_texel_rgba_dxt1" main.c:123: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt1' main.c:123: warning: data definition has no type or storage class main.c:124: error: parse error before "fetch_2d_texel_rgba_dxt3" main.c:124: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt3' main.c:124: warning: data definition has no type or storage class main.c:123: error: parse error before "fetch_2d_texel_rgba_dxt1" main.c:123: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt1' main.c:123: warning: data definition has no type or storage class main.c:124: error: parse error before "fetch_2d_texel_rgba_dxt3" main.c:124: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt3' main.c:124: warning: data definition has no type or storage class main.c:125: error: parse error before "fetch_2d_texel_rgba_dxt5" main.c:125: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt5' main.c:125: warning: data definition has no type or storage class main.c: In function `DDRAW_bind_to_s3tc': main.c:148: warning: assignment makes integer from pointer without a cast main.c:148: warning: comparison between pointer and integer main.c:149: warning: assignment makes integer from pointer without a cast main.c:149: warning: comparison between pointer and integer main.c:150: warning: assignment makes integer from pointer without a cast main.c:150: warning: comparison between pointer and integer make[2]: *** [main.o] Error 1 make[2]: Leaving directory `/usr/src/apps/CVS/wine/dlls/ddraw' make[1]: *** [ddraw] Error 2 make[1]: Leaving directory `/usr/src/apps/CVS/wine/dlls' make: *** [dlls] Error 2 Take (more ;) care, Andreas

1 0

No go here (Re: [D3D] Added native and emulated S3TC support (take 2))
by Andreas Mohr July 31, 2004

July 31, 2004

Hi, On Thu, Jul 29, 2004 at 11:49:33PM +0100, Christian Costa wrote: > Hi, > > This is the second version of my patch which take into account Lionel's > comments plus another fix. > > I've only mentionned the libtxc_dxtn.so library for software > decompression when the video card does not support S3TC. > Maybe Lionel can say if we can add more precise information i.e > reference to the DRI project. CVS compile bombs for me with: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw/hal.o ddraw/hal.c gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw/main.o ddraw/main.c ddraw/main.c: In function `create_texture': ddraw/main.c:394: error: `GL_extensions' undeclared (first use in this function)ddraw/main.c:394: error: (Each undeclared identifier is reported only once ddraw/main.c:394: error: for each function it appears in.) make[2]: *** [ddraw/main.o] Error 1 make[2]: Leaving directory `/usr/src/apps/CVS/wine/dlls/ddraw' make[1]: *** [ddraw] Error 2 make[1]: Leaving directory `/usr/src/apps/CVS/wine/dlls' make: *** [dlls] Error 2 Command exited with non-zero status 2 /* Check if we can really support DXT1, DXT3 & DXT5 */ if ((ddsd.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) && !GL_extensions.s3tc_compressed_texture && !s3tc_initialized) { ERR("Trying to create DXT1, DXT3 or DXT5 texture which is not supported by the video card!!!\n"); ERR("However there is a library libtxc_dxtn.so that can be used to do the software decompression...\n"); return DDERR_INVALIDPIXELFORMAT; } ii xlibmesa-gl 4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] ii xlibmesa-glu 4.3.0.dfsg.1-1 Mesa OpenGL utility library [XFree86] 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 03) (shouldn't matter anyway) /* Define if the OpenGL headers define extension typedefs */ /* #undef HAVE_GLEXT_PROTOTYPES */ /* Define if the OpenGL library supports the glXGetProcAddressARB call */ /* #undef HAVE_GLX_GETPROCADDRESS */ /* Define to 1 if you have the <GL/glext.h> header file. */ /* #undef HAVE_GL_GLEXT_H */ /* Define to 1 if you have the <GL/glx.h> header file. */ /* #undef HAVE_GL_GLX_H */ /* Define to 1 if you have the <GL/gl.h> header file. */ /* #undef HAVE_GL_GL_H */ /* Define if OpenGL is present on the system */ /* #undef HAVE_OPENGL */ /* Define to the soname of the libGL library. */ #define SONAME_LIBGL "libGL.so" Good luck, Andreas Mohr

1 0

shell32 patch
by Jens Collin July 31, 2004

July 31, 2004

Hi, I've made a small change in shell32.dll to enable one to type a myfile.txt from Start->Run dialog (for example). I've simply replaced the call to CreateProcess with ShellExecute. I've tested this change in reactos and it works nicely. It won't really work since there is something wrong with ShellExecute itself (or rather FindExecutable) but I've contacted Francois (fgouget(a)free.fr) to get some help on this. Anyway, it partially adds a tiny function and it doesn't break anything. Can someone commit this small patch for me please? Thanks in advance, Jens Collin

1 0

Re: USB?
by Ivan Leo Puoti July 31, 2004

July 31, 2004

I don't think drivers are an issue, what we wants to do is use an app that uses the usb ports, and he wants to use this app from wine. So he wants to write an interface for wine, that would take driver calls from the program and forward them to ioctl(whatever) so the app will work with the usb ports, or at least thats how I think it may work. I don't think it's easy to find USB ports not supported by linux now days, but wine isn't usb-aware. Ivan.

1 0

Re: Question about mmap issues on FreeBSD/NetBSD
by Yorick Hardy July 31, 2004

July 31, 2004

Thanks for the response. I must be doing something wrong, since wine-kthread gave the same error. Anything I may have missed? I copied wine-kthread from loader/wine-kthread. It does not appear to be correct, but is there any chance madvise(..., MADV_DONTNEED) could help? Also in libs/wine/mmap.c line 119 the result of mincore is never tested, should it not be if ( (mincore( (caddr_t)addr + i, pagesize, &vec ) != -1) && (vec&1) ) (with a slight variation for FreeBSD), although I think this will not resolve the current problem. >You need MAP_NORESERVE support otherwise we can't control the address >space correctly (unless you have a ton of virtual memory): if you run >wine-kthread directly it should still work though unless you have >execshield type address space randomisation active. > >On Thu, 29 Jul 2004 09:13:25 +0200, Yorick Hardy wrote: >> Just a question about the mmap issues experienced on FreeBSD, i.e. >> http://www.winehq.org/?issue=230#Wine%20on%20FreeBSD >> >> I encountered the same on NetBSD. It seems the error message is set from >> ld.elf_so in NetBSD and ld-elf.so.1 in FreeBSD, when the address space >> is mapped for the run time linking? Since MAP_NORESERVE is not documented >> (and not supported?) for mmap on FreeBSD and NetBSD, it would appear >> that wine and the ld.elf_so together require too much memory for all the mmap >> calls. Kind regards, -- Yorick Hardy

5 5

ms devel tools
by Ivan Leo Puoti July 31, 2004

July 31, 2004

If anyone needs to test something out with m$ development tools for whatever reason, they are giving away free betas (It doesn't matter, all m$ software is alpha/beta) of the express development tools, so if you need one get it until you can. http://lab.msdn.microsoft.com/express/ I'm going to try and see how much of wine will build with visualc++. Ivan.

1 0