- wine-devel - winehq.org

winrash: only sleep xx commands ?
by Sylvain Petreolle 01 Aug '04

01 Aug '04

After a successful install of winrash with 'Usurp' as nick and this mailbox : spetreolle(a)n5o5s5p5a5m.yahoo.fr It seems that winrash is doing only sleep commands, having a look to <winrash>\debug.txt. Simulating about 27 hours of running service with some 'time' and a 'date' commands seem to produce nothing else than "sleep 3600" commands in debug.txt. Can someone help ? The service is up and running in E:\winrash. Machine: Windows XP home. Output: E:\winrash>winrash -v && winrash -q Winrash version: 'winrash-0009-chris-msvc.exe' Current script commands: 1 total commands, current command is 1 0: sleep 3600 Querying service Current state: SERVICE_RUNNING Part of debug.txt: ... c:\winrash\winrash.c:1197 01/08/2004 16:57:00 c:\winrash\winrash.c:1200 entered with currentCommandIndex of '0' c:\winrash\winrash.c:593 sleep command of 'sleep 3600' c:\winrash\winrash.c:1275 no errors in command c:\winrash\winrash.c:1775 debug file not yet large enough to clear c:\winrash\winrash.c:390 entered c:\winrash\winrash.c:441 found a clientID of 'Usurp' c:\winrash\winrash.c:443 after removing characters we have a clientID of 'Usurp' c:\winrash\winrash.c:509 built a url of 'http://test.winehq.com/service?winrash= winrash-0009-chris-msvc.exe&id=Usurp' c:\winrash\winrash.c:312 url of 'http://test.winehq.com/service?winrash=winrash- 0009-chris-msvc.exe&id=Usurp' c:\winrash\winrash.c:533 got file: sleep 3600 c:\winrash\winrash.c:534 got 11 bytes out of a total buffer of 15000 c:\winrash\winrash.c:556 Software\winrash\Command_0 c:\winrash\winrash.c:1197 01/08/2004 17:57:21 ... ===== 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

2 2

Program runs okay, but has tiny font.
by Niek Beernink 01 Aug '04

01 Aug '04

Hello all, TD in #winehq told me to post this here. I'm trying to run the following program in wine, <ftp://212.67.96.161/loaded/diablo2/utilities/runewizard101.zip> It loads up okay, but the font in the program is really tiny and I was wondering if any of you knew of a possible fix. Here's a screenshot of this happening: <http://digital-conquest.ath.cx/src/tinyfont> I'm running Gentoo Linux with Wine version 20040615. crusade omega # emerge info Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.7-gentoo) ================================================================= System uname: 2.6.7-gentoo i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -ffast-math" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -ffast-math" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://ftp.snt.utwente.nl/gentoo" USE="3dnow X aalib acpi alsa avi berkdb bzlib cddb cdr cups divx4linux dvd encode ffmpeg flac foomaticdb gdbm geoip gif gstreamer gtk2 imlib java jpeg kde libwww mad memlimit mikmod mmx mpeg mpeg4 ncurses nls oggvorbis opengl operanom2 pam pdflib perl png ppds python qt quicktime readline samba sdl slang speex sse ssl svga tcpd tga theora tiff truetype usb videos x86 xml xml2 xmms xv xvid zlib" Hopefully this should be enough information. If you need to know anything else, do ask. Best regards, Niek Beernink.

2 2

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

Re: RPCRT4_NdrClientCall2 stub (fixme)?
by Filip Navara 30 Jul '04

30 Jul '04

Alexandre Julliard wrote: > Mike Hearn <mike(a)navi.cx> writes: > >>> Yes, I have an implementation of NdrClientCall2 in my local tree, but >>> I'm a bit busy with other COM things at the moment. I'll send an >>> updated >>> patch to the list either tonight or sometime over the weekend. >>> >> >> Alexandre, why was this not merged when it was originally sent? >> > > No idea, please resubmit. > IIRC Robert said that the patch isn't cleaned up yet and so it shouldn't be commited. He also said that he hasn't tested it much except for simple tests and the complex types weren't tested at all. - Filip

3 4

possible bug in wcmd
by Henning Gerhardt 30 Jul '04

30 Jul '04

Hi, I discovered a possible bug in wcmd. If you run "help for" inside wcmd, wcmd crashed and the winedebugger is called. I used to confirm this bug on my machine the latest tarball and a CVS-snapshot from today. If anybody can confirm this bug I will be happy :) The following lines are only correct if this bug is true: The problem is that a single % letter inside the resource strings. Look for the for-help text in En.rc file and you find the sentence "The requirement to double the % sign when using FOR in a batch file does") get parsed and this single % caused the crash. I found the following solutions and I don't know what is the right solution: 1. replace the single % with a double %% in all resource files 2. replace in the function WCMD_give_help (builtins.c:330) WCMD_output with WCMD_output_asis (WCMD_output (wcmdmain.c:733) called WCMD_output_asis but make some stuff for possible dynamic parameters) 3. patch the function WCMD_output (wcmdmain.c:733) with the attached patch (Replace a single % with a double % and all later called system function are be happy) I prefer personal the second or third solution. Regards, Henning

1 0

Linking with dlls and Linux libs using winelib?
by James Supancic 30 Jul '04

30 Jul '04

I need to compile a Windows application under Linux. I need to use dlls and Linux librarys. No matter what I try I can't get winegcc to include the Linux librarys in the linking stage. What must I do to get winegcc to link with both the dlls and Linux libs? Thank you for your time, James Steven Supancic III _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Re: Re: WineHQ:service.cgi: fix winrash option
by chmorgan＠charter.net 30 Jul '04

30 Jul '04

> <chmorgan(a)charter.net> writes: > > > Which errors are you referring to? The most frequent ones > > lately are the ones where the winetest package isn't > > available on the sourceforge osdn mirror. > > For example this: > > > Winrash version: winrash-0008-chris-msvc.exe > > [...] > > winetest = winetest-200407091000-kevin-mingw.zip > > winetest_history = > > Script: > > 8 total commands, current command is 6 > > 0: error_url http://test.winehq.org/error > > 1: error_sleep 3600 > > 2: download winetest-200407091000-kevin-mingw.zip http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin… > > 3: cookie winetest winetest-200407091000-kevin-mingw.zip > > 4: cookie winetest_history > > 5: unzip winetest-200407091000-kevin-mingw.zip > > --> 6: run winetest-200407091000-kevin-mingw.exe -c -t Cogman -u http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin… > > 7: sleep 300 > > Command in error: > > 6 > > Last error text: The system cannot find the file specified. > > Does the above mean that the download was unsuccessful? > Equally for "Last error text: %1 is not a valid Win32 > application."? Then we don't need these messages (which > could be improved at least). > Yep. I just tried that url and it worked. Many of the ones I've tried in the past haven't and the cause seems to be that the mirror chosen doesn't have the file. I'm not sure what a good solution is. Perhaps we should implement a way of providing a list of potential download sites for a file. I'm not sure how to detect that the download fails. Sourceforge provides a page that says that the file can't be found. This is what winrash probably downloaded in this case. Any ideas how to make the system more robust without making it much more complex? > Hmm, some still try to download winrash-0008 from the osdn > mirror, which has been obsoleted for a long time. Why? > I have no idea what the issue is here. The script should be telling the 0007 client to download 0009. I'm not sure if this is a bug or not. > And service.cgi shouldn't pass the -u option to winetest > anymore, I patched it out. At least I think so. > > > We are still asking people to download the tests from this > > location for particular test releases. I'd imagine the > > fix is simply to point the downloads at valid mirror for > > the file. > > By editing service.cgi's database? You could ask Jer, his > is very helpful if you can catch him on IRC. I wish there > was some logging feature in service.cgi... I'll go deeper > in a couple of days. > -- > Feri. Your help is much appreciated. This is a tricky issue it seems as SF isn't always reliable for downloads... Chris

7 9

formal standard for wine devel style
by James Hawkins 30 Jul '04

30 Jul '04

Is there a written formal standard specifying the style in which wine code is written? I remember a message a while back about how a patch couldn't be committed because it didn't meet the standards of wine coding style and that someone who knew the style could fix it. -- James Hawkins

3 2

Re: DCOM: Disconnect Proxies at COM Shutdown
by Robert Shearman 30 Jul '04

30 Jul '04

Robert Shearman wrote: > Changelog: > > Mike Hearn <mh(a)codeweavers.com> > Disconnect proxies at COM shutdown to release the corresponding stubs. Sorry, this one was an old patch. Rob

1 0

Bug in menu.c
by Dan Timis 30 Jul '04

30 Jul '04

Hi, The MS documentation on the structure MENUITEMINFO says that the field fMask indicates what fields to retrieve or set. Here is what it says about the value MIIM_TYPE: > Retrieves or sets the fType and dwTypeData members. Windows 98/Me, > Windows 2000/XP: MIIM_TYPE is replaced by MIIM_BITMAP, MIIM_FTYPE, > and MIIM_STRING. So if one wants to specify a text menu item in XP, one would use MIIM_STRING, not MIIM_TYPE. fType would also need to be MFT_STRING. In menu.c in GetMenuItemInfo_common(): /* copy the text string */ if ((lpmii->fMask & (MIIM_TYPE|MIIM_STRING)) && (MENU_ITEM_TYPE(menu->fType) == MF_STRING) && menu->text) { and so on... This works fine. It retrieves the text if either MIIM_TYPE or MIIM_STRING are set. But, in GetMenuItemInfo_common(): if (lpmii->fMask & MIIM_TYPE) { /* Get rid of old string. */ if (IS_STRING_ITEM(menu->fType) && menu->text) { HeapFree(GetProcessHeap(), 0, menu->text); menu->text = NULL; } /* make only MENU_ITEM_TYPE bits in menu->fType equal lpmii->fType */ menu->fType &= ~MENU_ITEM_TYPE(menu->fType); menu->fType |= MENU_ITEM_TYPE(lpmii->fType); menu->text = lpmii->dwTypeData; and so on... This sets the text only if MIIM_TYPE is set. I changed the first line to: if (lpmii->fMask & (MIIM_TYPE|MIIM_STRING)) { and menus that were drawing before as a long thin vertical line, started to show correctly. I'm not sure if this is the right way to fix this, but it works for me. I am using a wine version from 2004-04-08. BTW, I reported earlier a crash in menu.c. I did not hear anything back. Should I log this into Bugzilla? Thanks, Dan Timis Muse Research, Inc.

2 1

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

30 Jul '04

"James Hawkins" <truiken(a)gmail.com> wrote: > This is a resubmit of my original patch that cleans up a->w cross > calls in crypt. > > Changelog > * cleanup a->w cross calls in advapi32/crypt.c > + static const WCHAR KEYSTR[] = { > + 'S','o','f','t','w','a','r','e','\\','\\', > + 'M','i','c','r','o','s','o','f','t','\\','\\', > + 'C','r','y','p','t','o','g','r','a','p','h','y','\\','\\', > + 'D','e','f','a','u','l','t','s','\\','\\', > + 'P','r','o','v','i','d','e','r','\\','\\',0 > + }; Remove double backslashes here and everywhere else. > - keyname = CRYPT_Alloc(strlen(KEYSTR) + strlen(pProvName) +1); > + keyname = CRYPT_Alloc(strlenW(KEYSTR) + strlenW(pProvName) + 1); Add '* sizeof(WCHAR)' and everywhere else where storage for unicode strings is allocated. > - keyname = CRYPT_Alloc( (user ? strlen(USERSTR) : strlen(MACHINESTR)) +1); > + keyname = CRYPT_Alloc( (user ? strlenW(USERSTR) : strlenW(MACHINESTR)) +1); Add '* sizeof(WCHAR)' > + static WCHAR nameW[] = {'N','a','m','e',0}; > + static WCHAR typeW[] = {'T','y','p','e',0}; > + static WCHAR imagePathW[] = {'I','m','a','g','e',' ','P','a','t','h',0}; > + static WCHAR signatureW[] = {'S','i','g','n','a','t','u','r','e',0}; > + static WCHAR sigInFileW[] = {'S','i','g','I','n','F','i','l','e',0}; Add 'const'. > - if ( !(provname = CRYPT_Alloc(strlen(pszProvider) +1)) ) > + if ( !(provname = CRYPT_Alloc(strlenW(pszProvider) +1)) ) Add '* sizeof(WCHAR)' > - len = ExpandEnvironmentStringsA(temp, NULL, 0); > + len = ExpandEnvironmentStringsW(temp, NULL, 0); > if ( !(imagepath = CRYPT_Alloc(len)) ) Add '* sizeof(WCHAR)' ... And lots of similar bugs. -- Dmitry.

1 0

Re: change the nt service pack version from 6 to 6a, correct win2k3 name
by Ivan Leo Puoti 30 Jul '04

30 Jul '04

>Easy, take several W2K3 system DLLs and kick them through winedump with what command line?

1 0

Re: add autodetect audio driver capability to winmm, second try
by Alexandre Julliard 29 Jul '04

29 Jul '04

James Hawkins <truiken(a)gmail.com> writes: > + /* try to detect arts */ > + argv_new[2] = "ps awx|grep artsd|grep -v grep|grep artsd > /dev/null"; > + if(!spawnvp(_P_WAIT, "/bin/sh", argv_new)) > + { > + driversFound[numFound] = "winearts.drv"; > + name[numFound] = "aRts"; > + numFound++; > + } This code does not belong in winmm. Autodetection in winmm should be done by having the drivers themselves fail to load if the corresponding support is missing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Test drive error
by sergio ojalvo 29 Jul '04

29 Jul '04

Hi I'm working on Debian Linux. I just install the wine packages and download sources for trying the test driver. Running Winemaker to winemine test project I note: that configure script was not created and Makefile is created instead of Makefile.in. (like wrote in the web page) I think is a new feature... I'm wrong? Anyway, I try to run make after that and that is the output: winebuild -o winemine.exe.dbg.c --debug -C. dialog.c main.c winegcc -c -mno-cygwin -I. -o winemine.exe.dbg.o winemine.exe.dbg.c winegcc -c -mno-cygwin -I. -o dialog.o dialog.c winegcc -c -mno-cygwin -I. -o main.o main.c wrc -I. -foEn.res En.rc En.rc:23:22: Error: syntax error make: *** [En.res] Error 1 After that I try with another 2 projects (win32 code) and I receive a lot of compilation errors like: In file included from /usr/include/c++/3.3/iosfwd:46, from /usr/include/c++/3.3/ios:44, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from midi2nokia.cpp:4: /usr/include/c++/3.3/i486-linux/bits/c++locale.h:53: error: `uselocale' was not declared in this scope In file included from /usr/include/c++/3.3/i486-linux/bits/c++io.h:35, from /usr/include/c++/3.3/bits/fpos.h:44, from /usr/include/c++/3.3/iosfwd:49, from /usr/include/c++/3.3/ios:44, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from midi2nokia.cpp:4: /usr/include/c++/3.3/cstdio:167: error: `snprintf' not declared /usr/include/c++/3.3/cstdio:168: error: `vfscanf' not declared /usr/include/c++/3.3/cstdio:169: error: `vscanf' not declared /usr/include/c++/3.3/cstdio:171: error: `vsscanf' not declared /usr/include/c++/3.3/cstdio:177: error: `snprintf' not declared /usr/include/c++/3.3/cstdio:178: error: `vfscanf' not declared /usr/include/c++/3.3/cstdio:179: error: `vscanf' not declared /usr/include/c++/3.3/cstdio:181: error: `vsscanf' not declared In file included from /usr/include/c++/3.3/i486-linux/bits/gthr-default.h:37, from /usr/include/c++/3.3/i486-linux/bits/gthr.h:98, from /usr/include/c++/3.3/i486-linux/bits/c++io.h:37, from /usr/include/c++/3.3/bits/fpos.h:44, from /usr/include/c++/3.3/iosfwd:49, from /usr/include/c++/3.3/ios:44, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from midi2nokia.cpp:4: /usr/include/pthread.h:651: error: type specifier omitted for parameter `clockid_t' /usr/include/pthread.h:651: error: parse error before `*' token In file included from /usr/include/c++/3.3/bits/fpos.h:45, from /usr/include/c++/3.3/iosfwd:49, from /usr/include/c++/3.3/ios:44, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from midi2nokia.cpp:4: /usr/include/c++/3.3/cwchar:142: error: `fwide' not declared /usr/include/c++/3.3/cwchar:149: error: `mbsinit' not declared /usr/include/c++/3.3/cwchar:157: error: `vfwscanf' not declared /usr/include/c++/3.3/cwchar:159: error: `vswscanf' not declared /usr/include/c++/3.3/cwchar:161: error: `vwscanf' not declared /usr/include/c++/3.3/cwchar:176: error: `wcstof' not declared /usr/include/c++/3.3/cwchar:182: error: `wmemcmp' not declared /usr/include/c++/3.3/cwchar:183: error: `wmemcpy' not declared /usr/include/c++/3.3/cwchar:184: error: `wmemmove' not declared /usr/include/c++/3.3/cwchar:185: error: `wmemset' not declared /usr/include/c++/3.3/cwchar:213: error: `wmemchr' not declared /usr/include/c++/3.3/cwchar: In function `wchar_t* std::wmemchr(wchar_t*, wchar_t, unsigned int)': /usr/include/c++/3.3/cwchar:217: error: invalid conversion from `const wchar_t* ' to `wchar_t*' /usr/include/c++/3.3/cwchar: At global scope: /usr/include/c++/3.3/cwchar:233: error: `wcstold' not declared /usr/include/c++/3.3/cwchar:242: error: `wcstoll' not declared /usr/include/c++/3.3/cwchar:243: error: `wcstoull' not declared /usr/include/c++/3.3/cwchar:249: error: `wcstold' not declared /usr/include/c++/3.3/cwchar:250: error: `wcstoll' not declared /usr/include/c++/3.3/cwchar:251: error: `wcstoull' not declared etc, etc, etc.... I send you my gcc configuration: gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.4/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.4 (Debian 1:3.3.4-4) Any suggestion? Thanks a lot for your help. -- ____________________________ ________ _______________________________ | Sergio Ojalvo \ \ / | | Senior System Analyst \ \/ To bring IN-OVATION turn to | | mailto:sergio@ximpo.com /\ \ your open source of solutions | | Phone: +972-545-558586 / \ \ | | Fax: +972-151-545-558586 -------- http://www.ximpo.com/ | |__________________________ Ximpo Group _____________________________|

3 4

Re: [D3D] Added native and emulated S3TC support
by Lionel Ulmer 29 Jul '04

29 Jul '04

I have just a few comments on the patch (yeah, it would not have been fun if I had commented on wine-d3d first :-) ). But anyway, great work ! > +static BOOL DDRAW_bind_to_s3tc( void ) > +{ > + const char *s3tcname = SONAME_LIBS3TC; > + > + s3tc_handle = wine_dlopen(s3tcname, RTLD_NOW, NULL, 0); > + if (!s3tc_handle) { > + printf("Wine cannot find the S3TC software decompression library (%s).\n",s3tcname); Why did you use 'printf' here instead of WARN or ERR ? Moreover, with this, we will print an error at DirectX loading when the users do not have this library installed ... even if the game does never request any compressed mode textures. Would it not be better to somehow print the error message when the application wants to create a DXTN texture (ie somehow remember that we do not support this feature and keep the error message for later). > + return FALSE; > + } > + > +#define API_FUNCTION(f) \ > + if((f = wine_dlsym(s3tc_handle, #f, NULL, 0)) == NULL) \ > + { \ > + printf("Can't find symbol %s\n", #f); \ Same printf comment here (but this one can be kept here :-) ). > + goto sym_not_found; \ > + } > + API_FUNCTION(fetch_2d_texel_rgba_dxt1); > + API_FUNCTION(fetch_2d_texel_rgba_dxt3); > + API_FUNCTION(fetch_2d_texel_rgba_dxt5); > +#undef API_FUNCTION > + > + return TRUE; > + > +sym_not_found: > + WARN("Wine cannot find functions that are necessary for S3TC decompression\n"); > + wine_dlclose(s3tc_handle, NULL, 0); > + s3tc_handle = NULL; > + return FALSE; > +} > + (...) > > + if (src_pf->dwFlags & DDPF_FOURCC) { > + GLenum retVal; > + int size = surf_ptr->surface_desc.u1.dwLinearSize; > + int width = surf_ptr->surface_desc.dwWidth; > + int height = surf_ptr->surface_desc.dwHeight; > + LPVOID buffer = surf_ptr->surface_desc.lpSurface; > + > + switch (src_pf->dwFourCC) { > + case MAKE_FOURCC('D','X','T','1'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT; break; > + case MAKE_FOURCC('D','X','T','3'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT3_EXT; break; > + case MAKE_FOURCC('D','X','T','5'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT; break; > + default: > + FIXME("FourCC Not supported\n"); > + return DD_OK; > + break; > + } > + GL_extensions.glCompressedTexImage2D(GL_TEXTURE_2D, current_level, retVal, width, height, 0, size, buffer); How are we sure that this code will never be called with the 'glCompressedTexImage2D' unset ? I.e. when we are in emulation mode, what happens here ? Is this because when we are in emulation mode, we do not advertise support for DTXN textures, this means that the application can create such textures, but will be automagically converted to RGB ones at Loading ? Anyway, I would still prefer a test here to prevent crashes for application which do not behave well :-) (...) > + if (current_surface->surface_desc.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) { > + GLint retVal; > + int size = current_surface->surface_desc.u1.dwLinearSize; > + int width_ = current_surface->surface_desc.dwWidth; > + int height_ = current_surface->surface_desc.dwHeight; > + LPVOID buffer = current_surface->surface_desc.lpSurface; > + > + switch (current_surface->surface_desc.u4.ddpfPixelFormat.dwFourCC) { > + case MAKE_FOURCC('D','X','T','1'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT; break; > + case MAKE_FOURCC('D','X','T','3'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT3_EXT; break; > + case MAKE_FOURCC('D','X','T','5'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT; break; > + default: > + FIXME("Not supported\n"); > + return DD_OK; > + break; > + } > + /* GL_extensions.glCompressedTexSubImage2D(GL_TEXTURE_2D, current_level, xoffset, yoffset, width, height, retVal, (unsigned char*)temp_buffer); */ > + GL_extensions.glCompressedTexImage2D(GL_TEXTURE_2D, current_level, retVal, width_, height_, 0, size, buffer); Same here. > + } > + > + if (strstr(glExtensions, "GL_EXT_texture_compression_s3tc")) { > + TRACE(" - S3TC compression supported\n"); > + GL_extensions.s3tc_compressed_texture = TRUE; > + GL_extensions.glCompressedTexImage2D = pglXGetProcAddressARB("glCompressedTexImage2D"); > + GL_extensions.glCompressedTexSubImage2D = pglXGetProcAddressARB("glCompressedTexSubImage2D"); > } If I were pedantic, you should test for 'GL_ARB_texture_compression' to be able to get the 'glCompressedTexImage2DARB' and 'glCompressedTexSubImage2DARB' functions (which may be better than using the non-ARB versions which are, AFAIK, the ones in GL 1.4). And then to get 'GL_EXT_texture_compression_s3tc' to set 'GL_extensions.s3tc_compressed_texture' to TRUE. But as 'GL_EXT_texture_compression_s3tc' depends on 'GL_ARB_texture_compression', I will let you do this shortcut :-) > - /* We do not support for now compressed texture formats... */ > - if (ddsd.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) > + /* We support for now only DXT1, DXT3 & DXT5 compressed texture formats... */ > + if ((ddsd.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) && > + (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','1')) && > + (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','3')) && > + (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','5')) ) > { > return DDERR_INVALIDPIXELFORMAT; > } What to do here when neither hardware nor emulated support is present ? Maybe we should print an error (cf previous comment) and return INVALIDPIXELFORMAT, no ? Lionel (who goes testing NOFL :-) ) -- Lionel Ulmer - http://www.bbrox.org/

3 5

Re: Fix crash in dsound test
by Robert Reif 29 Jul '04

29 Jul '04

How did this fail in windows. Since it doesn't crash with wine, wine is doing something wrong. Lets try to figure out what is wrong and correct wine to have the same behavior as windows or at least notify someone that something is wrong. Is anyone working on getting direct sound into the windows port of our regression tests? Francois Gouget wrote: > > Changelog: > > * dlls/dsound/tests/dsound.c > > Francois Gouget <fgouget(a)codeweavers.com> > Call IDirectSound::Initialize() as per MSDN before using the > DirectSound object. Fixes a crash on Windows. > >------------------------------------------------------------------------ > >Index: dlls/dsound/tests/dsound.c >=================================================================== >RCS file: /var/cvs/wine/dlls/dsound/tests/dsound.c,v >retrieving revision 1.24 >diff -u -r1.24 dsound.c >--- dlls/dsound/tests/dsound.c 13 Jul 2004 23:35:09 -0000 1.24 >+++ dlls/dsound/tests/dsound.c 16 Jul 2004 16:23:51 -0000 >@@ -69,6 +69,9 @@ > if (rc==DS_OK) > IDirectSound8_Release(ds8); > >+ rc=IDirectSound_Initialize(dso,NULL); >+ ok(rc==DS_OK,"IDirectSound_Initialize(NULL) failed: %s\n",DXGetErrorString9(rc)); >+ > /* DSOUND: Error: Invalid caps buffer */ > rc=IDirectSound_GetCaps(dso,0); > ok(rc==DSERR_INVALIDPARAM,"GetCaps should have failed: %s\n",DXGetErrorString9(rc)); >@@ -168,6 +171,9 @@ > if (rc==DS_OK) > IDirectSound8_Release(ds8); > >+ rc=IDirectSound8_Initialize(dso,NULL); >+ ok(rc==DS_OK,"IDirectSound_Initialize(NULL) failed: %s\n",DXGetErrorString9(rc)); >+ > /* DSOUND: Error: Invalid caps buffer */ > rc=IDirectSound8_GetCaps(dso,0); > ok(rc==DSERR_INVALIDPARAM,"GetCaps should have failed: %s\n",DXGetErrorString9(rc)); > >

5 7

Question about mmap issues on FreeBSD/NetBSD
by Yorick Hardy 29 Jul '04

29 Jul '04

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. Am I correct? Kind regards, -- Yorick Hardy

2 1

Re: Is bugzilla worth keeping?
by Dan Kegel 29 Jul '04

29 Jul '04

Mike Hearn wrote: > So are we misleading users by having a bugzilla into thinking that if > they file a bug there, it'll be fixed when it probably won't? Not at all. Just because not enough people are doing bug triage or fixing doesn't mean we should drop bugzilla. Somebody will eventually go through the bug reports, I think. > If we were to simply drop bugzilla, how would it impact the project? It would deprive us of long-term memory. For instance, I filed the bug report http://bugs.winehq.org/show_bug.cgi?id=1404 in January 2003 with a nice test case (but one that's hard to translate into a unit test). Without Bugzilla, we'd have a harder time remembering problems like that. (Unless cxtest really takes off, I suppose...) - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 3

Re: winetests/winrash
by Rolf Kalbermatter 29 Jul '04

29 Jul '04

Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: >I wouldn't mind adding a systray icon. I wasn't really sure how that was >supposed to be done. I tried having the service add a systray icon without >much success, I don't believe services can interact with the desktop. That >may mean that a separate winrash monitor may have to be written that >communicates with the service. Services can interact with the desktop but not by default. It is a special option you specify when installing the service. The magic for this is in the dwServiceType parameter of the CreateService() to register a service object in the system. >From MSDN: SERVICE_FILE_SYSTEM_DRIVER File system driver service. SERVICE_KERNEL_DRIVER Driver service. SERVICE_WIN32_OWN_PROCESS Service that runs in its own process. SERVICE_WIN32_SHARE_PROCESS Service that shares a process with one or more other services. For more information, see Service Programs. If you specify either SERVICE_WIN32_OWN_PROCESS or SERVICE_WIN32_SHARE_PROCESS, and the service is running in the context of the LocalSystem account, you can also specify the following type. Type Meaning SERVICE_INTERACTIVE_PROCESS The service can interact with the desktop. Not sure how winrash is currently installed but if it is not through a small Win32 setup app but an InstallShield app, I'm sure it has according parameters to let it install as interactive service Rolf Kalbermatter

2 1

Fwd: Re: rsabase.dll
by Michael Jung 29 Jul '04

29 Jul '04

I'm sorry, if this mail appears three times on the wine-devel list. I've sent it twice already, but it doesn't seem to get forwarded to the wine-devel list. Is there a problem with the mailing list? Rob, could you give me a short notificaton, if you have received those mails? Thank, Michael ---------- Forwarded Message ---------- Subject: Re: rsabase.dll Date: Tuesday 27 July 2004 10:08 From: Michael Jung <mjung(a)iss.tu-darmstadt.de> To: wine-devel(a)winehq.org Cc: rob(a)codeweavers.com Rob, > I think there are many reasons to favour "real handles": If a long running > process is using rsabase (e.g. a webserver serving https: requests) with > many temporary connections and many keys, resource leakage is an issue. > Furthermore, since rsabase is a cryptographic service provider, it might be > important that a key, which is not referenced anymore is in fact destroyed > (and the > corresponding memory be nulled). I would think that otherwise you will > over time accumulate a lot of keys in your address space, which is probably > a security problem. Now, I'm aware that wine is not in a state today to be > used for security critical applications and first rsabase implementations > will probably have security issues more severe than this. However, sometime > I think rsabase will have to use real handles. Why not right from the > start? I've thought about this statement again and realized that I'm wrong and that I probably misunderstood you. I realized that one doesn't need "real handles" in user mode code at all to implement correct resource management. And I think I understand that one does need them in the kernel (aka wineserver) for objects, which are accessed from multiple threads. However, there are some instances of "real handle" implementations outside wineserver in wine (e.g. dlls/msi/handle.c). Do you (or anybody else on the mailing list) now what for? Some things, which I could imagine would still be easier to implement correctly with "real handles", are the INVALID_HANDLE_VALUE value, checking that a thread does not access a resource via an already released handle and in general checking in a precise manner if a handle value is valid (which, as I understand it, is often done in wine with a magic value at the beginning of the object.) Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

1 0

Is bugzilla worth keeping?
by Mike Hearn 29 Jul '04

29 Jul '04

One thing I notice about most other open source projects is that they have many more flamewars than we do. So, I thought I'd start one: It strikes me, looking at the wine-bugs list, that there is a huge disparity between the number of people maintaining it and the number of people filing bugs in it. It seems to be quite rare for communication on bugfixes to take place there, wine-devel is the more usual forum. So are we misleading users by having a bugzilla into thinking that if they file a bug there, it'll be fixed when it probably won't? If so, does it matter? If we were to simply drop bugzilla, how would it impact the project? Thoughts, anybody? thanks -mike

10 10

winetests/winrash
by James Hawkins 29 Jul '04

29 Jul '04

What is it exactly that winrash does? Is it running winetests using the native libraries of the Windows operating system that the user is running the tests on, or are the wine libraries being tested through some means? Is there a site where this information is readily available? I have one suggestion: users typically like to see results when they volunteer their computer time to a project such as this, which is understandable, so a future version might benefit from a system tray icon that can be opened up to see the test running and/or display results of the tests that have been run. -- James Hawkins

2 1

How do we handle unicode (utf-8) codepages?
by Shachar Shemesh 29 Jul '04

29 Jul '04

What do we do if the user requests a Unicode codepage? I've just had a conversation with a user on IRC where I believe things didn't work for him because LANG was set to es_ES.UTF-8. On one hand, I don't think we can force ANSI applications to work in Unicode. On the other hand, we cannot change the locale - it will mean noone (whether ANSI or not) will not be able to access non-ASCII file names and files. Comments? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

2 1

Re: Re: WineHQ:service.cgi: fix winrash option
by chmorgan＠charter.net 28 Jul '04

28 Jul '04

Which errors are you referring to? The most frequent ones lately are the ones where the winetest package isn't available on the sourceforge osdn mirror. We are still asking people to download the tests from this location for particular test releases. I'd imagine the fix is simply to point the downloads at valid mirror for the file. Chris > > From: Ferenc Wagner <wferi(a)afavant.elte.hu> > Date: 2004/07/26 Mon AM 07:57:51 EDT > To: wine-devel(a)winehq.org > CC: <wine-patches(a)winehq.com>, <cmorgan(a)alum.WPI.EDU> > Subject: Re: WineHQ:service.cgi: fix winrash option > > <chmorgan(a)charter.net> writes: > > > What is the service doing with winrash options btw? The > > installer stops, installs and starts the winrash service. > > > > The installer uses /S for silent installs, otherwise it > > will try to popup windows. Are you sure the service isn't > > calling the installer with /S? > > You are right, I was wrong. This patch is rubbish. I can't > really understand the errors on wine-test-results. Have you > got an idea what may have gone wrong? Aren't any functional > winrash instances running? Is something broken in the > service script? The documentation is somewhat scarce so I'm > doing a slow start... > -- > Feri. > >

2 1

Re: DCOM: Fix Ref Counting in StdMarshalImpl_MarshalInterface
by Robert Shearman 28 Jul '04

28 Jul '04

Robert Shearman wrote: > Changelog: > > Mike Hearn <mh(a)codeweavers.com> > Fix ref counting in StdMarshalImpl_MarshalInterface for case where the > stub already exists. > >Index: wine/dlls/ole32/compobj_private.h >=================================================================== >RCS file: /home/wine/wine/dlls/ole32/compobj_private.h,v >retrieving revision 1.14 > Oops. Wrong patch. Rob

1 0

Re: COM RPC: Fix Infinite Loop
by Robert Shearman 28 Jul '04

28 Jul '04

Robert Shearman wrote: > Changelog: > Fix for infinite loop that could occur if _invoke_onereq failed. Please don't apply this patch. I'll submit a better and more complete one in a minute. Rob

1 0

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