wine-devel

wine-devel@winehq.org

10 participants
84460 discussions

Flags for building an rpm
by Dan Timis 01 Aug '04

01 Aug '04

A colleague built a wine rpm a while ago. Here is the size and date: 9922591 Apr 29 14:32 wine-20040408-1muse.athlon.rpm If I look on the winehq site I see similar sizes, only slightly larger: wine-20040716-1rh8winehq.athlon.rpm 11662876 Unfortunately, my colleague is incommunicado for the next couple of weeks, and I cannot ask him how he built the rpm. I added a patch to fix the problem I reported recently in menu.c. Then, I built the rpm with the command: # rpmbuild -ba --platform athlon wine-20040408-2muse.spec Here is what I get: 85910178 Jul 29 21:25 wine-20040408-2muse.athlon.rpm This is significantly larger. I looked at the contents and the problem seems to be mainly in /usr/lib/ All files are significantly larger. What flags am I missing when I am building the rpm? Thanks, Dan Timis Muse Research, Inc.

3 2

winrash: some todos
by Sylvain Petreolle 01 Aug '04

01 Aug '04

Some suggestions for winrash: * Running Windows NT version >= 4.XY, we should check for the use of an administrator account... installing as normal user gave these results : no error message said the HKLM keys couldnt be created => UserID & mail not set => service install/run fails silently * http links : the 3 http links fail to open at the end of installation, this has already been reported on wine-users list. (the mouse arrow changes though) ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) Say NO to software patents Dites NON aux brevets logiciels "You believe it's the year 1984, when in fact, its closer to 2184"1984 / Matrix Vous manquez despace pour stocker vos mails ? Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

1 0

Re: cleanup a->w cross calls in advapi32/crypt.c
by Dmitry Timoshkov 01 Aug '04

01 Aug '04

"James Hawkins" <truiken(a)gmail.com> wrote: > Fixed even more bugs spotted by Dmitry. > > Changelog > * cleanup cross-call functions The quality of the patch still is not good enough. -- Dmitry.

2 2

Re: cleanup a->w cross calls in commdlg/fontdlg.c
by Dmitry Timoshkov 01 Aug '04

01 Aug '04

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog > * fix cross-call functions > - return DialogBoxIndirectParamA(COMDLG32_hInstance, template, > + return DialogBoxIndirectParamW(COMDLG32_hInstance, template, > lpChFont->hwndOwner, FormatCharDlgProcA, (LPARAM)lpChFont ); You can't pass a not unicode dlgproc to DialogBoxIndirectParamW and hope that it will work. -- Dmitry.

1 0

Re: Question about mmap issues on FreeBSD/NetBSD
by Yorick Hardy 01 Aug '04

01 Aug '04

Try the patch below, I am not yet sure why this would be necessary. Perhaps it helps. >I've got some cross platform issues i cannot resolve. There are some >obvious issues like the assumption that round() is in the math library >and not linking in the math library itself. i've worked passed those. >Currently, I'm working with a patched version of the latest cvs source >on Solaris 9x86. After applying Robert Lunnon's patch kit to the latest >cvs course and substituting rint for the round function in >wine/dlls/dsound/mixer.c and add the math library to EXTRALIBS, I got a >clean compile. however running the wine binary results in the following: > >try_mmap_fixed: vfork: Resource temporarily unavailable > >I'm not intimately familiar with how wine manages it's memory so I >hesitate to guess what is going on. I've attached the output of the >truss if anyone has any ideas on what it going on or how to fix it >please let me know. Kind regards, -- Yorick Hardy --- libs/wine/mmap.c.orig Thu Jul 29 20:03:03 2004 +++ libs/wine/mmap.c Sun Aug 1 13:07:07 2004 @@ -135,6 +135,8 @@ has exited. Furthermore, Wine sets SIGCHLD to SIG_IGN, so we don't need to wait for the child. */ + waitpid(pid, &pagesize, 0); + return result == addr; } #endif /* (__svr4__ || __NetBSD__) && !MAP_TRYFIXED */

1 0

Re: [RESENT] Make wine work with freedesktop.org MIME system
by Mike Hearn 01 Aug '04

01 Aug '04

This was checked into CVS a few days ago, no need to resend. thanks -mike On Sun, 2004-08-01 at 11:35 +0200, Christian Neumair wrote: > Mike felt good enough to explain me on IRC where I should hook into the > wine build system. I've put up a tiny patch that works like a charm with > GNOME/shared-mime-info HEAD. It associates wine with the MIME type used > for DOS/Win32 binaries. > > regs, > Chris

1 0

Wine leaking GDI handles?
by Jon Griffiths 01 Aug '04

01 Aug '04

Hi, I am trying to track down some GDI leaks in a large application I am porting. To make things easier I added logging to GDI_AllocObject and GDI_FreeObject in order to find mismatches at program termination, and hacked a script to find allocations that weren't deallocated. The patch to dlls/gdi/gdiobj.c and the script used are both attached below. My first question is; Is this a valid approach to tracking leaks, or are some GDI objects deallocated in another way? i.e. Should there be a GDI_FreeObject call for every GDI_AllocObject call or not? I run this analysis by setting WINEDEBUG="+all" and executing my app redirecting the results to a file. I then run the matching script to generate a list of addresses from GDI_AllocObject that have no corresponding GDI_FreeObject, along with the line number in the trace that the allocation occurred. This produced a rather overwhelming list which has thus far enabled me to find several application bugs causing leaks. However investigating several of the calls makes me suspect that Wine itself may have some leaks. If you follow the directions above against Wines clock.exe it lists here 121 unmatched deallocations (winver has 126). Some of these are for things like stock objects which arguably aren't very important, since they are only created once. But it appears that window creation/destruction may have leaks which is of definite concern here since my app creates many windows while generating screens on the fly (I see in my app that when GetDC is called for the first time on a window, causing a CreateDCW call, a region is leaked, or at least thats what it looks like to me). I seems a good idea to attempt to diagnose the leaks on a simple program like clock/winver before trying a more complicated app. Could someone with more experience in GDI verify that these leaks are genuine? I am a little lost amongst the GDI/user code... Thanks, Jon p.s. The script below does not handle GDI realloc, but I have yet to see it in any of my traces yet. ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail

1 0

Re: cleanup a->w cross calls in advapi32/crypt.c
by Dmitry Timoshkov 01 Aug '04

01 Aug '04

"James Hawkins" <truiken(a)gmail.com> wrote: > Fixed more bugs spotted by Dmitry. > > Changelog > * cleanup cross-call functions If you could use 'static const' as everywhere else and not 'const static' that would be nice. > + size = sizeof(DWORD); > + r = RegQueryValueExW(key, nameW, NULL, &keytype, NULL, &size); Why did you add size initialization here? If that wasn't done before there was a reason for that. > + provNameLen = *pcbProvName * sizeof(WCHAR); > + if ( pszProvName && (str = CRYPT_Alloc(provNameLen * sizeof(WCHAR))) ) > + CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); > + ret = CryptEnumProvidersW(dwIndex, pdwReserved, dwFlags, pdwProvType, str, &provNameLen); Remove double sizeof(WCHAR) multiplcation here and everywhere else. > - DWORD size = sizeof(DWORD); > + DWORD size = sizeof(pdwProvType); > HKEY subkey; > - if (RegEnumKeyA(hKey, dwIndex, pszProvName, *pcbProvName)) > + if (RegEnumKeyW(hKey, dwIndex, pszProvName, *pcbProvName)) RegEnumKeyW takes number of characters, not bytes. Why did you change that since your previous patch? Please read documentation first, otherwise you are wasting your and our time. -- Dmitry.

1 0

Re: cleanup a->w cross calls in advapi32/crypt.c
by Dmitry Timoshkov 01 Aug '04

01 Aug '04

"James Hawkins" <truiken(a)gmail.com> wrote: > Fixed bugs spotted by Dmitry > > Changelog > * cleanup cross-call functions Still there are bugs in the patch. 1. RegQueryValueExW/RegSetValueExW take bytes in the last parameter 2. Do not use 'strlen' as a name of the variable, that at least very confusing. -- Dmitry.

1 0

for whoever maintinas winrash
by Ivan Leo Puoti 01 Aug '04

01 Aug '04

We've had the following complaints on wine-users. > 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? > > 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. Ivan.

4 5

Re: [Wine]starcraft fails right at the end of the install
by Michael Chang 31 Jul '04

31 Jul '04

On Sat, Jul 31, 2004 at 11:21:30AM +0000, cedric wrote: > Hi all i'm running wine 20040716, installed manualy, no wineinstall, blank > windows drive, only the right dirs are present there, as i couldn't get > regedit to make the default reg keys for me > > I tried to install starcraft, but right after it copied all the files it comes > up with this error screen: > Error: > Unable to create a link to E:\Help\Star.htm as C:\Windos\start > menu\programs\starcraft\help.lnk Installation aborted error 0: success at > LinkUndo.cpp line 165. I noticed this "error" with other programs. Apparently, wine (or at least this build) doesn't support creating links in the start menu, or something along those lines -- it makes sence when you consider that wine users shouldn't exactly see a point in "accessing" these windows shortcuts. However, your program's setup is finicky about being unable to create shortcuts for the program, so you can't continue. (Some installs complain, but allow you to continue...) Maybe wine-devel could consider creating a stub, or just falsely return true to these calls? Also, you might want to look at CVS code, to see if this has already been implemented. If all else fails, try looking at the M$ Windows binaries/patches for win95 - i.e. DCOM, and MSI stuff, etc. They *might* help, but correct me if I'm wrong. > After i click cancel all the starcraft files are deleted. After i tried again > i killed wine without pressing cancel. All the starcraft files remain, but > when i run the installer again it askes me to install the game instead of run, > so i guess not all the regestry keys have been created. Also, when i try to > run the game from the program files directory, sc complains about the cd not > being present. Setup Program probably creates shortcuts, then reg entries. But since it can't create shortcuts, it never creates the reg entries. That's my theory. (See above.) Most games are stupid in that they rely on their registry entries to tell them that the program is installed, as opposed to actually checking the filesystem. > > here are the errors wine gave me: > bash-2.05b$ cd /mnt/cdrom/ > bash-2.05b$ wine INSTALL.EXE Oh! One more thing. Your CD-Rom should be mounted to a dosdevice, and you should/can execute it from there, I think. So your first line should/might say "cd /home/<user>/.wine/dosdevices/<cd>:". (/home/cedric/.wine/dosdevices/e:) Also, note that windows never had case-sensitive names -- maybe bad program is causing errors by Linux/wine being case sensitive? > err:font:ReadFontDir Can't open directory > "/home/cedric/.wine/dosdevices/c:/windows/Fonts" > Fontconfig error: line 24: not well-formed (invalid token) > Fontconfig error: Cannot load default config file > fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy > fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy > fixme:shell:Stream_WriteLocationInfo writing empty location info > err:font:ReadFontDir Can't open directory > "/home/cedric/.wine/dosdevices/c:/windows/Fonts" > Fontconfig error: line 24: not well-formed (invalid token) > Fontconfig error: Cannot load default config file > err:menubuilder:InvokeShellLinker failed to extract icon. > fixme:shell:Stream_WriteLocationInfo writing empty location info > err:font:ReadFontDir Can't open directory > "/home/cedric/.wine/dosdevices/c:/windows/Fonts" > Fontconfig error: line 24: not well-formed (invalid token) > Fontconfig error: Cannot load default config file > err:menubuilder:InvokeShellLinker failed to extract icon. > > And some random info: > bash-2.05b$ ls -l ~/.wine/dosdevices/ > total 0 > lrwxr-xr-x 1 cedric users 8 Jul 11 10:22 a:: -> /dev/fd0 > lrwxr-xr-x 1 cedric users 22 May 16 22:16 c: > -> /storage/windows-drive > lrwxr-xr-x 1 cedric users 10 May 16 22:16 com1 -> /dev/ttyS0 > lrwxr-xr-x 1 cedric users 10 May 16 22:16 com2 -> /dev/ttyS1 > lrwxr-xr-x 1 cedric users 10 May 16 22:16 com3 -> /dev/ttyS2 > lrwxr-xr-x 1 cedric users 10 May 16 22:16 com4 -> /dev/modem > lrwxr-xr-x 1 cedric users 2 Jul 11 10:53 d: -> /d > lrwxr-xr-x 1 cedric users 11 Jul 11 18:25 e: -> /mnt/cdrom/ > lrwxr-xr-x 1 cedric users 12 May 16 22:16 f: -> /home/cedric > lrwxr-xr-x 1 cedric users 8 May 16 22:16 lpt1 -> /dev/lp0 > > bash-2.05b$ uname -a > Linux lfs 2.6.7 #1 Sat Jun 26 14:30:34 Local time zone must be set--see zic > manu i686 GenuineIntel unknown GNU/Linux > > bash-2.05b$ gcc -v > Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs > Configured with: ../gcc-3.3.2/configure --prefix=/usr --enable-shared > --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu > --enable-languages=c,c++ : (reconfigured) ../gcc-3.3.2/configure --prefix=/usr > --enable-shared --enable-threads=posix --enable-__cxa_atexit > --enable-clocale=gnu --enable-languages=c,c+ > > Please CC me as i'm not a member of this list I hope you don't mind me putting you in the To: line instead. > > Regards, > cedric > -- > The only dumb question is the one omitted > > De enige domme vraag is degene die niet gesteld wordt > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-users Just my two cents. Hope I helped in any way possible. Consider joining the wine-users/wine-devel lists, and taking part. It's a good idea, and using e-mail filtering software like POPFile is easy; even the most inexperienced users can just mention noticed behaviour in Wine. (Or, use internal filtering software in your e-mail client - 99% of wine e-mails already have [Wine] in their subject lines anyways.) Error messages are self-explainatory if you know how to read them. :) -Michael

1 0

Re: No go here (Re: [D3D] Added native and emulated S3TC support (take 2))
by Andreas Mohr 31 Jul '04

31 Jul '04

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 31 Jul '04

31 Jul '04

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 31 Jul '04

31 Jul '04

* 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 31 Jul '04

31 Jul '04

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 31 Jul '04

31 Jul '04

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 31 Jul '04

31 Jul '04

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 31 Jul '04

31 Jul '04

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 31 Jul '04

31 Jul '04

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 31 Jul '04

31 Jul '04

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 31 Jul '04

31 Jul '04

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

Re: [D3D] Added native and emulated S3TC support (take 2)
by Lionel Ulmer 30 Jul '04

30 Jul '04

> 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. Well, the page where you can download it is the third Google link when searching for 'libtxc_dxtn'. So I think the information there is enough :-) Lionel PS: thanks for the edits, will be able to test the final version now that it's commited :-) -- Lionel Ulmer - http://www.bbrox.org/

1 0

regression
by Ivan Leo Puoti 30 Jul '04

30 Jul '04

The following patch http://www.winehq.com/hypermail/wine-cvs/2004/03/0434.html causes an infinite loop when installing the word97/2k viewer. A relay log from the loop is attached. Can someone please fix this? Ivan.

1 0

RPCRT4_NdrClientCall2 stub (fixme)?
by Jeroen Janssen 30 Jul '04

30 Jul '04

Hello, I have 'hit' upon a RPCRT4_NdrClientCall2 stub/fixme call. It seems some discussion on this has been happening in a the past few months? Can someone maybe explain the current status on this? (probably Rob or Mike, since they seem to be the Wine COM "gurus"?) Below is is a short snip of trace logging I get: trace:ole:COMPOBJ_DLLList_Add trace:ole:CStdPSFactory_QueryInterface (0x660cea80)->QueryInterface({d5f569d0-593b-101a-b569-08002b2dbf7a},0x4067faa4) trace:ole:CStdPSFactory_CreateProxy (0x660cea80)->CreateProxy((nil),{11ef83d1-553a-11d3-bb12-0004ac9658d6},0x4067faa0,0x4067fbfc) trace:ole:FindProxyInfo found: ProxyInfo 0x660cbc48 Index 65 trace:ole:StdProxy_Construct ((nil),0x660cd048,0x660cea80,0x4067faa0,0x4067fbfc) ICoKMFactoryManager trace:ole:StdProxy_Construct stubless=0x660c5230 trace:ole:StdProxy_Construct iid={11ef83d1-553a-11d3-bb12-0004ac9658d6} trace:ole:StdProxy_Construct vtbl=0x660cd050 trace:ole:StdProxy_Construct stubless thunks: count=6 trace:ole:StdProxy_Construct method 3: stacksize=12 trace:ole:StdProxy_Construct method 4: stacksize=16 trace:ole:StdProxy_Construct method 5: stacksize=4 trace:ole:CStdPSFactory_AddRef (0x660cea80)->AddRef() trace:ole:CStdPSFactory_Release (0x660cea80)->Release() trace:ole:StdProxy_Connect (0x4034f1f0)->Connect(0x4034f288) trace:ole:StdProxy_Release (0x4034f1f0)->Release() trace:ole:ObjectStubless (0x4034f1f4)->(3)([12 bytes]) ret=4067fc94 fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x660c7c08,pFormat = ^0x660c7d30,...): stub trace:ole:IUnknown_Release_Proxy (0x4034f1f0)->Release() ICoKMFactoryManager wine: Unhandled exception (thread 0014), starting debugger... Best regards, Jeroen Janssen

5 8

Re: possible bug in wcmd
by Ivan Leo Puoti 30 Jul '04

30 Jul '04

It looks like a bug to me. [ivan@localhost wcmd]$ ./wcmd WCMD Version 0.17 Z:\home\ivan\Development\Wine\CVS\wine\wine\programs\wcmd>help for wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405ec9e0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x20656854 in 32-bit code (0x400d2473). In 32 bit mode. 0x400d2473 strlen in libc.so.6: movl 0x0(%eax),%ecx Wine-dbg>bt Backtrace: =>1 0x400d2473 strlen+0x33 in libc.so.6 (0x406eed1c) 2 0x400ba8cb _IO_vsprintf+0x8b in libc.so.6 (0x406eede4) 3 0x405c9eeb WCMD_output+0x2b(format=0x406ef20c) [wcmdmain.c:741] in wcmd (0x406ef200) 4 0x405c7020 WCMD_give_help+0x80(command=0x4039b8a5) [builtins.c:352] in wcmd (0x406efa18) 5 0x405c9563 .L153+0x9 in wcmd (0x406efa58) 6 0x405c91d4 main+0x4f4(argc=0x1, argv=0xbffff49c) [wcmdmain.c:244] in wcmd (0x406efe9c) 7 0x405c6169 __wine_exe_main+0x169 in wcmd (0x406eff2c) 8 0x404e6a88 start_process+0xc8(arg=0x0) [process.c:995] in kernel32 (0x406efff4) 9 0x4001cd9d wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) Wine-dbg>quit WineDbg terminated on pid 0x8 [ivan@localhost wcmd]$

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