July 2004 - Wine-Devel - list.winehq.org

Flags for building an rpm
by Dan Timis Aug. 1, 2004

Aug. 1, 2004

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

for whoever maintinas winrash
by Ivan Leo Puoti Aug. 1, 2004

Aug. 1, 2004

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 July 31, 2004

July 31, 2004

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 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