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

dinput - fix detection under Windows
by Steven Edwards Nov. 24, 2004

Nov. 24, 2004

I am sending this to wine-devel as I would like a DirectInput hacker to comment on it. With this patch we are able to run some of the DirectX sample application using Wine dinput.dll on Windows. Changelog: Magnus Olsen <magnus(a)itkonsult-olsen.com> Add more polling of keyboard and mouse devices under DirectInput as Windows depends on this behavior. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

Stubs in PE build
by Ge van Geldorp Nov. 24, 2004

Nov. 24, 2004

Stubs declared in .spec files were not generated or exported for PE (MinGW) builds. The patch below fixes that. It adds a new mode to winebuild, --pedll, which generates the stubs. Since it's a global change I'm sending it here for review first. Ge van Geldorp. Index: Make.rules.in =================================================================== RCS file: /home/wine/wine/Make.rules.in,v retrieving revision 1.179 diff -u -r1.179 Make.rules.in --- Make.rules.in 7 Oct 2004 03:12:44 -0000 1.179 +++ Make.rules.in 24 Nov 2004 20:49:51 -0000 @@ -104,7 +104,7 @@ api_manext = 3w conf_manext = 5 CLEAN_FILES = *.o *.a *.so *.ln *.$(LIBEXT) \\\#*\\\# *~ *% .\\\#* *.bak *.orig *.rej \ - *.flc *.spec.c *.spec.def *.dbg.c *.tab.c *.tab.h @LEX_OUTPUT_ROOT(a).c core + *.flc *.spec.c *.spec.def *.dbg.c *.pedll.c *.tab.c *.tab.h @LEX_OUTPUT_ROOT(a).c core OBJS = $(C_SRCS:.c=.o) $(EXTRA_OBJS) @@ -113,7 +113,7 @@ # Implicit rules -.SUFFIXES: .mc .rc .mc.rc .res .res.o .spec .spec.c .spec.def .idl .h .ok .sfd .ttf +.SUFFIXES: .mc .rc .mc.rc .res .res.o .spec .spec.c .spec.def .pedll.c .idl .h .ok .sfd .ttf .c.o: $(CC) -c $(ALLCFLAGS) -o $@ $< @@ -135,6 +135,9 @@ .spec.spec.def: $(WINEBUILD) -w $(DEFS) -o $@ --def $< + +.spec.pedll.c: + $(WINEBUILD) $(DEFS) -o $@ --pedll $< .idl.h: $(WIDL) $(IDLFLAGS) -h -H $@ $< Index: dlls/Makedll.rules.in =================================================================== RCS file: /home/wine/wine/dlls/Makedll.rules.in,v retrieving revision 1.69 diff -u -r1.69 Makedll.rules.in --- dlls/Makedll.rules.in 19 Oct 2004 23:06:12 -0000 1.69 +++ dlls/Makedll.rules.in 24 Nov 2004 20:49:53 -0000 @@ -31,8 +31,8 @@ # Rules for .dll files -$(MODULE): $(RCOBJS) $(OBJS) $(MODULE).dbg.o $(SPEC_DEF) $(IMPORTLIBS) Makefile.in - $(DLLWRAP) -k --def $(SPEC_DEF) -o $@ $(RCOBJS) $(OBJS) $(MODULE).dbg.o -L$(DLLDIR) $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) $(ALL_LIBS) +$(MODULE): $(RCOBJS) $(OBJS) $(MODULE).dbg.o $(MODULE:%.dll=%).pedll.o $(SPEC_DEF) $(IMPORTLIBS) $(DLLDIR)/libntdll.$(IMPLIBEXT) Makefile.in + $(DLLWRAP) -k --def $(SPEC_DEF) -o $@ $(RCOBJS) $(OBJS) $(MODULE).dbg.o $(MODULE:%.dll=%).pedll.o -L$(DLLDIR) $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) -lntdll $(ALL_LIBS) $(SPEC_DEF): $(WINEBUILD) Index: tools/winebuild/build.h =================================================================== RCS file: /home/wine/wine/tools/winebuild/build.h,v retrieving revision 1.54 diff -u -r1.54 build.h --- tools/winebuild/build.h 8 Oct 2004 21:11:18 -0000 1.54 +++ tools/winebuild/build.h 24 Nov 2004 20:50:34 -0000 @@ -185,6 +185,7 @@ extern void BuildSpec32File( FILE *outfile, DLLSPEC *spec ); extern void BuildDef32File( FILE *outfile, DLLSPEC *spec ); extern void BuildDebugFile( FILE *outfile, const char *srcdir, char **argv ); +extern void BuildPedllFile( FILE *outfile, DLLSPEC *spec ); extern int parse_spec_file( FILE *file, DLLSPEC *spec ); extern int parse_def_file( FILE *file, DLLSPEC *spec ); Index: tools/winebuild/main.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/main.c,v retrieving revision 1.57 diff -u -r1.57 main.c --- tools/winebuild/main.c 19 Oct 2004 23:09:02 -0000 1.57 +++ tools/winebuild/main.c 24 Nov 2004 20:50:34 -0000 @@ -77,7 +77,8 @@ MODE_DEF, MODE_DEBUG, MODE_RELAY16, - MODE_RELAY32 + MODE_RELAY32, + MODE_PEDLL }; static enum exec_mode_values exec_mode = MODE_NONE; @@ -164,7 +165,8 @@ " --exe=NAME Build a .c file for the named executable\n" " --debug [FILES] Build a .c file with the debug channels declarations\n" " --relay16 Build the 16-bit relay assembly routines\n" -" --relay32 Build the 32-bit relay assembly routines\n\n" +" --relay32 Build the 32-bit relay assembly routines\n" +" --pedll Build a .c file for PE dll\n\n" "The mode options are mutually exclusive; you must specify one and only one.\n\n"; enum long_options_values @@ -178,7 +180,8 @@ LONG_OPT_RELAY16, LONG_OPT_RELAY32, LONG_OPT_SUBSYSTEM, - LONG_OPT_VERSION + LONG_OPT_VERSION, + LONG_OPT_PEDLL }; static const char short_options[] = "C:D:F:H:I:K:L:M:N:d:e:f:hi:kl:m:o:r:w"; @@ -195,6 +198,7 @@ { "relay32", 0, 0, LONG_OPT_RELAY32 }, { "subsystem",1, 0, LONG_OPT_SUBSYSTEM }, { "version", 0, 0, LONG_OPT_VERSION }, + { "pedll", 1, 0, LONG_OPT_PEDLL }, /* aliases for short options */ { "source-dir", 1, 0, 'C' }, { "delay-lib", 1, 0, 'd' }, @@ -356,6 +360,11 @@ case LONG_OPT_VERSION: printf( "winebuild version " PACKAGE_VERSION "\n" ); exit(0); + case LONG_OPT_PEDLL: + set_exec_mode( MODE_PEDLL ); + spec_file_name = xstrdup( optarg ); + set_dll_file_name( optarg, spec ); + break; case '?': usage(1); break; @@ -460,6 +469,11 @@ case MODE_RELAY32: if (argv[0]) fatal_error( "file argument '%s' not allowed in this mode\n", argv[0] ); BuildRelays32( output_file ); + break; + case MODE_PEDLL: + if (argv[0]) fatal_error( "file argument '%s' not allowed in this mode\n", argv[0] ); + if (!parse_input_file( spec )) break; + BuildPedllFile( output_file, spec ); break; default: usage(1); Index: tools/winebuild/spec32.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/spec32.c,v retrieving revision 1.84 diff -u -r1.84 spec32.c --- tools/winebuild/spec32.c 18 Oct 2004 21:27:52 -0000 1.84 +++ tools/winebuild/spec32.c 24 Nov 2004 20:50:34 -0000 @@ -860,12 +860,10 @@ int is_data = 0; if (!odp) continue; - if (odp->flags & FLAG_REGISTER) continue; - if (odp->type == TYPE_STUB) continue; - if (odp->name) name = odp->name; + else if (odp->type == TYPE_STUB) name = make_internal_name( odp, spec, "stub" ); else if (odp->export_name) name = odp->export_name; - else continue; + else name = make_internal_name( odp, spec, "noname_export" ); fprintf(outfile, " %s", name); @@ -895,11 +893,37 @@ } break; } + case TYPE_STUB: + { + if (!kill_at) + { + const char *check = name + strlen(name); + while (name != check && + '0' <= check[-1] && check[-1] <= '9') + { + check--; + } + if (name != check && check != name + strlen(name) && + '@' == check[-1]) + { + fprintf(outfile, "%s", check - 1); + } + } + if (NULL != odp->name) + { + fprintf(outfile, "=%s", make_internal_name( odp, spec, "stub" )); + } + break; + } default: assert(0); } fprintf( outfile, " @%d", odp->ordinal ); +#if 0 /* MinGW binutils cannot handle this correctly */ if (!odp->name) fprintf( outfile, " NONAME" ); +#else + if (!odp->name && (odp->type == TYPE_STUB || odp->export_name)) fprintf( outfile, " NONAME" ); +#endif if (is_data) fprintf( outfile, " DATA" ); if (odp->flags & FLAG_PRIVATE) fprintf( outfile, " PRIVATE" ); fprintf( outfile, "\n" ); @@ -1005,4 +1029,25 @@ "}\n", prefix ); free( prefix ); +} + + +/******************************************************************* + * BuildPedllFile + * + * Build a PE DLL C file from a spec file. + */ +void BuildPedllFile( FILE *outfile, DLLSPEC *spec ) +{ + int nr_exports; + + nr_exports = spec->base <= spec->limit ? spec->limit - spec->base + 1 : 0; + output_standard_file_header( outfile ); + + if (nr_exports) + { + /* Output the stub functions */ + + output_stub_funcs( outfile, spec ); + } }

1 0

Clipping error
by Stefan Dösinger Nov. 24, 2004

Nov. 24, 2004

Hello! I'm trying to run apple iTunes 4.7.0.42 in Winehq CVS and I'm getting this failure when I try to access the music store. Wine asks me to report this. err:local:LOCAL_GetBlock not enough space in GDI heap 10bf for 28 bytes err:region:CombineRgn Invalid rgn=(nil) err:local:LOCAL_GetBlock not enough space in GDI heap 10bf for 28 bytes err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. err:ntdll:RtlpWaitForCriticalSection section 0x407d7740 "gdiobj.c: GDI_level" wait timed out in thread 0070, blocked by 0075, retrying (60 sec) wine: Unhandled exception (thread 0070), starting debugger... Can't attach process 61: error 5 If it's interesting for you I can provide more infos, otherwise simply drop my mail. I'm just sending it because wine asks me to report this. The rest of iTunes seems to work somehow. The Gui opens and I can play music, but it's slow, with X eating 100% of my CPU time. I have to use a native setupapi.dll from WinXP. Stefan

2 1

read registry
by mammique Nov. 24, 2004

Nov. 24, 2004

Hello, i'm looking for a lightweight way to read the windows regitry. I don't know windows, so i don't know how it's done. The goal in simply to check the windows network configuration of a machine from a live-cd, to use the same parameters on the running live-cd. Do i need wine api and dlls to do that, or is this the windows registry readable using lower-level way ? I would prefer not to use wine, then network detection could be done from ramdisk during boot. Wating for your ligths :-) Regards. Camille.

3 3

winecfg/drivedetect.c breaks portability (#include <mntent.h>)
by Gerald Pfeifer Nov. 24, 2004

Nov. 24, 2004

The addition of winecfg/drivedetect.c via revision 1.1 date: 2004/11/23 13:50:23; author: julliard; state: Exp; Mike Hearn <mike(a)navi.cx> - More heapification. - Split drive code into core, UI and autodetect. - Implement drive autodetection. - Slight redesign of drive tab. - Code cleanup. broke FreeBSD 4.10 which does not have <mntent.h>: /sw/gcc-3.3.4/bin/gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o drivedetect.o drivedetect.c drivedetect.c:28:20: mntent.h: No such file or directory In fact, FreeBSD 4.10 does not have getmntent() at all which leads to further breakage even if you properly autoconf for <mntent.h>: drivedetect.c:206: warning: implicit declaration of function `getmntent' The Linux man page states SysV also has a getmntent() function but the calling sequence differs, and the returned structure is different. Under SysV /etc/mnttab is used. BSD 4.4 and Digital Unix have a routine getmntinfo(), a wrapper around the system call getfsstat(). http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=getmntinfo has the man page for FreeBSD. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 1

Problem roundup
by Mike Hearn Nov. 24, 2004

Nov. 24, 2004

Hi, So, trolling linuxquestions.org reveals the following top 3 problems users are having with Wine currently: 1) The RH9 RPMs are apparently being compiled with epoll support linked in. This is causing user pain. We should really be using dlsym here, why are we not again? 2) Our bestest bestest friends over at InstallShield Corp have released a new version of their elegant and simple product, which refuses to start with builtin DCOM. 3) Some people still seem to be getting the "C:\\Windows\\System does not exist" message. thanks -mike

6 21

Packaging Questions, New Debian Package, Packagers Guide
by Scott Ritchie Nov. 24, 2004

Nov. 24, 2004

The Debian packages have gotten rather out of date, and it looks like Ove's not going to be making them any more. I took the initiative and decided to try making one myself. I'm polishing off a new Debian package now. Some major things I noticed: 1) There were a lot of old hacks in the package that are probably no longer necessary, due to advancements in wine like wineprefixcreate and such. There was also the remenants of a very old problem with compiling using flex (which I remember experiencing the old days) in the form of a special exception for installing newer flex packages. 2) Very old packages like winesetuptk should now be officially obsoleted by making them conflicted and replaced. I also did the same to the libwine-* packages that weren't doing anything but making documentation folders, like libwine-alsa. 3) Making my package looks to be a lot simpler than what's implied in the (now year out of date) package makers guide. I found that documentation quite useless (and didn't even find it until I was about half way done anyway). Again, this is probably due to advancements in wine itself. 4) What I didn't find is a standard list of packages that aren't strictly required for wine (like libxt-dev and flex), but that wine can benefit from. A good example would be the alsa development files. These are all things that should be included in the build dependencies for the package. So far, my list of build dependant packages is the following: flex, bison, libx11-dev, libasound2-dev, libxt-dev, libicu28-dev However, I'm not sure if this means the wine binary package should depend on them, since it's compiled in. So, should I make libicu28 a dependancy for wine? Now, this leads to the question: is it worth even having a package maintainers guide? If so, who wants to update it? Thanks, Scott Ritchie

8 20

Fwd: Re: [Wine]DC++ crashes with current CVS wine
by Pavel Troller Nov. 24, 2004

Nov. 24, 2004

Hi! I've sent the message below to wine-users mailing list and nobody has replied until now. So I subscribed do wine-devel and I'm posting the message here. Of course I cannot distinguish whether this problem is important enough to be fixed, but I think it's some problem with wine dlls so it can help other apps too.. With regards, Pavel Troller ----- Forwarded message from Pavel Troller <patrol(a)sinus.cz> ----- > Hi! > I have a problem, that DC++ client now crashes in wine. The problem is that it > crashes using its own exception handler, from the wine's point of view the app > is running OK. The client simply pops up a dialog box saying that it just > crashed and the debug info is placed in a file called exceptioninfo.txt. OK, the > file is really there and it really shows something important: > > Code: c0000005 > Version: 0.4034 > Major: 4 > Minor: 10 > Build: 67766446 > SP: 0 > Type: 0 > Time: 2004-11-21 08:09:57 > TTH: EJEUEI5NYOW2OQOXRJC7OHZ2ZUSLA5JF6IPD6TI > > c:\documents\vcprojects\dcplusplus\windows\transferview.cpp(195): ? > c:\documents\vcprojects\dcplusplus\windows\transferview.h(50): ? > c:\program files\vs.net 2003\vc7\atlmfc\include\atlwin.h(3017): ? > user32!0x666BABF7: ? > user32!0x666BAF39: ? > user32!0x666C0D29: ? > user32!0x666ED284: ? > user32!0x666EE099: ? > user32!0x666EE2D5: ? > comctl32!0x57758097: ? > comctl32!0x5775D2C5: ? > comctl32!0x5775DFAE: ? > comctl32!0x5775E518: ? > comctl32!0x577666D7: ? > comctl32!0x577675C7: ? > user32!0x666BABF7: ? > user32!0x666BAF39: ? > user32!0x666C0D29: ? > c:\program files\vs.net 2003\vc7\atlmfc\include\atlwin.h(3020): ? > user32!0x666BABF7: ? > user32!0x666BAF39: ? > user32!0x666C0D29: ? > user32!0x666A3996: ? > c:\documents\vcprojects\include\wtl-7.5.4196\atlapp.h(499): ? > c:\documents\vcprojects\dcplusplus\windows\main.cpp(270): ? > 0x1F83D6C8: ? > > Because user32 and comctl32 are both mentioned in the backtrace, I tried to > switch them to native, but the program then crashed in a much worse way, > ending at a wine-dbg> prompt. > This exception info is shown, when win98 is emulated. Normally I'm emulating > nt40, in which case the backtrace is missing but the crash is looking very > similar from the user's point of view. > No important information (like unimplemented call etc.) is shown in the > wine's stdout/stderr. > Is there a developer which can help with this problem ? > With regards, Pavel Troller Hi! I have a lot of news in this case: I've downloaded sources for DC++ unstable and looked onto them to see in which place the program crashes. I've found that it occurs when the download/upload progress bar is about to be drawn. I've also found that progress bar drawing can be disabled in advanced setting (oh yes, source is the best user's manual You can have :-) ). I did so and DC++ started to work for me. I think that it is a good starting point for a wine developer to find, what's happening there, it should be easy to find when the source code which exhibits the bug is available and exact location of bug invocation is known. Because I know windows at a zero level, I cannot help with this, but I hope that others can, and fixing this bug may help other apps too (and, even in DC++, the bars are a nice eye-candy :-) ). Should I post this message to wine-devel, or is it enough to post it here, in wine-users ? With regards, Pavel Troller ----- End forwarded message -----

1 0

Re: Implement OleDuplicateData
by Dmitry Timoshkov Nov. 23, 2004

Nov. 23, 2004

"Robert Shearman" <rob(a)codeweavers.com> wrote: > + logpalette->palVersion = 1; /* FIXME: what should this be? */ All Microsoft and other samples I've seen initialize this filed to 0x300. -- Dmitry.

1 0

Re: Problem roundup
by Ivan Leo Puoti Nov. 23, 2004

Nov. 23, 2004

> So perhaps it would be better to build the RPMs against "pure" installs of > each distro, from the CDs? As i think nobody wants buggy systems, this will mean using --force to install RPMs of old headers. I've never heard of such an update breaking my RPMs so I won't do any such thing without considerable proof that it is really necessary and there is no better option. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

Re: Version Resources
by Dan Kegel Nov. 23, 2004

Nov. 23, 2004

Tom wrote: > I hope this patch looks better. :) > If anything is incorrect just let me know. FYI, please don't use # in patch filenames. Sometimes that's a comment character, and it gives us shell programmers the willies. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

System colors
by Kevin Koltzau Nov. 23, 2004

Nov. 23, 2004

CreateBrushIndirect under Wine currently returns stock brushes if the brush requested matches the color. In gdi/brush.c the following comment is made: /* If a solid brush is created in a color matching one of the * stock brushes, native returns the stock object (GDI heap * optimisation). Some apps rely on this as they otherwise * would leak their brushes. */ However under both Windows 95 and Windows XP this does not seem to be the case. Under Windows, the following holds true, but fails under Wine GetStockObject(BLACK_BRUSH) != CreateSolidBrush(RGB(0,0,0)) This issue currently breaks applications making calls to SetSysColors as stock brushes are deleted as the new colors are added. Does anyone know why this was setup in this way? Or which version of Windows that exhibits the behavior mentioned in the comment? -Kevin

2 1

Problems with mailing list
by Robert van Herk Nov. 23, 2004

Nov. 23, 2004

Hi all, Last month I moved, as did my ip address. Since then, I don't seem to get any messages from the wine devel mailing list, although I am still subscribed. I don't know whom to send this to, but can somebody (the admin of the list) please try to find out what is the problem? Thanx, Robert

2 1

Handles in GDI
by lats Nov. 23, 2004

Nov. 23, 2004

I have been trying to track a problem in gdiobj.c where I had a handle of 0x107e. In GDI_GetObjPtr the handle & 2 is said to indicate a GDI Heap handle. From everything else I have read, that bit is supposed to indicate a Moveable handle. Is there something special about GDI handles that I should know about? Jeff

1 0

Configure missing a step
by Scott Ritchie Nov. 23, 2004

Nov. 23, 2004

I managed to get past configure and then have a compile error due to a missing header file: intrinsic.h Configure should be checking for this file, like it checks for flex and bison and such. The package I needed to install was libxt-dev I'm on Ubuntu at the moment, but this should be true for all Debian systems. Could someone else clean this up? I'm scared to touch configure. -Scott Ritchie

1 0

Re: syscolors: do not delete stock brushes
by Kevin Koltzau Nov. 22, 2004

Nov. 22, 2004

Please do not apply this patch On Thursday 11 November 2004 11:38 pm, Kevin Koltzau wrote: > This is a bit of a bad hack, but very bad things happen when a stock brush is deleted > > Changelog > Prevent deletion of stock brushes when system colors change >

1 0

Re: Resend: [dx9-12 next try] SetStreamSource changes
by Mike Hearn Nov. 22, 2004

Nov. 22, 2004

On Mon, 22 Nov 2004 20:01:03 +0000, Ann and Jason Edmeades wrote: > Was there a problem with this one - Its really holding me up with progress, > so I need to ensure I resolve any issues asap. Apologies if this is still in > your list of patches to work through as I heard you have just moved If the problem is source control related (as opposed to technical direction related) you may want to look at svk, which lets you branch CVS repositories into a local repository then commit to your branch. Unlike arch it doesn't require a gateway and it isn't hard to set up or use. Hope that helps. thanks -mike

2 1

Re: profiling GTA4. question about polling
by Brian Gunlogson Nov. 22, 2004

Nov. 22, 2004

--- Raphael <fenix(a)club-internet.fr> wrote: > Well, drawStriddedSlow is very very very slow (as function name :) ) > because is the software rendering path of wine d3d8 implementation > The only way to have good performances is to add needed support to hardware > rendering path (drawStriddedFast). > > Current version on hardware rendering path doesn't support (see > d3d8/drawprim.c:1590): > - pixel size (rarely used) > - blending weights (low use) > - diffuse color (highly used) > > In this cases the slow rendering path is used instead. > > I have a local "prototype" to have a better support of that cases (using > hardware vertex buffers) who have very good performances. > Ex: i have now a good framerate for UT2004 and Unreal2 (before i had ugly > lags) > > But, as Jason is currently doing a lot of work on splitting/moving code to > wined3d, we'll have to wait to commit it (and i should help him, when i'll > have time). Is this a tedious task or does it require knowledge of the codebase? I might be able to help. > Anyway, can you test what GTA4 want to use: diffuse, psize or/and blending ? > I'll try to send you a patched version of d3d8 to test after that :) GTA uses diffuse color exclusively. This was after playing the game for about 3 minutes on highest settings: pixel size: 0 diffuse: 745455 blending weights: 0 > Regards, > Raphael > > PS: > how have you done to use oprofile on wine ? > i'm very interested :) Just download the latest CVS from http://oprofile.sourceforge.net/download/ and see the README. I assume you know how to get it compiled and installed :) As root: # opcontrol --start # opcontrol --reset '--reset' clears out any old unwanted profiling data # opcontrol --separate=kernel '--separate=kernel' Seperates output by library and kernel [this is the hardest option to understand]. Profiling is on, run the application to profile and do not do anything else. When done: # opcontrol --dump '--dump' flushes remaining data to disk # opreport -l >./myreport.log Stores the flat profile in a file called myreport.log. Brian G __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

Re: epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 22, 2004

Nov. 22, 2004

Mike Hearn wrote: >> I'm not aware of e.g. an LSB-1.3 application that doesn't run properly >> on any system that supports LSB-1.3. Are you? > > I'm not aware of any LSB applications at all, actually. But let's take > RealPlayer for example. Let's pretend that Real had made it an LSB app. > > Would that have saved it from being broken by NPTL. No. LSB doesn't > specify (as far as I'm aware) that LSB apps must be linked > against LinuxThreads. Bzzt. In the real world, the distro vendor would have noticed this during LSB certification, and since the shared library loader for LSB 1.3 is /lib/ld-lsb.so.1 rather than /lib/ld-linux.so.2, the vendor can easily force libc to be linuxthreads based even if the default libc is NPTL based. I believe that as people start building LSB-compliant apps, they'll find it quite a useful way to avoid having to package ten different flavors of their apps just to be compatible. It's going to be a lot easier with LSB 3.0, since by that time the C++ ABI will have settled down, but I do think even LSB 2.0 is worth looking at for some applications. Yes, I know, you'll probably want to post something bitter and negative about LSB in response, but I'm going to put my hands over my ears and go "la la la", so I won't notice whether you actually do :-) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 2

epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 22, 2004

Nov. 22, 2004

Mike Hearn: > 1) The RH9 RPMs are apparently being compiled with epoll support linked > in. This is causing user pain. We should really be using dlsym here, > why are we not again? Alexandre Julliard: > glibc is not backwards compatible, the RH9 RPMs should be built > against the RH9 glibc. There is nothing special about epoll, you can > have the same issue with any glibc symbol, and we can't start > dynamically loading them all. Mike Hearn: > We don't have to be over-general about it, just dynamically loading the > ones that cause problems would be fine (or using syscalls directly). The > vast majority of the symbols are always there and so it doesn't make sense > to use dlsym. Alexandre Julliard: > I think it's much better to ask packagers to build their packages > correctly, it will cause much less trouble in the long run. Or better yet, ask people to download the right package. I just downloaded http://prdownloads.sourceforge.net/wine/wine-20041019-1rh9winehq.i686.rpm and it worked fine on RH9. I wonder, though: the fact that somebody downloaded the wrong package means there are probably too many different versions at sourceforge to download. I count 24 packages! (OK, a few of them are srpms.) Shoot, can't we package Wine as an LSB package? I suspect Wine depends on nothing that isn't in the LSB. That'd make life a lot easier for the users... at least for those whose distros come with LSB support installed by default. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

12 28

Re: epoll, LSB (was: Re: Problem roundup)
by Ivan Leo Puoti Nov. 22, 2004

Nov. 22, 2004

>> I know Dimi is against it, but that looks like a good thing to do to me. > >It's not that I'm against it, I don't much care for the sf.net download page, >really. If people are willing to work on something that is less confusing, >by all means, but let's try to not complicate our current download page, >it is rather nice :) Well, wine.sf.net just redirects to winehq.com, using it for a nvidia like download page instead would be cool. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

KERNEL32: add a test case for CompareStringW undocumented flag 0x10000000
by Mike McCormack Nov. 22, 2004

Nov. 22, 2004

Hi All, I've written a regression test that shows what the undocumented flag 0x10000000 passed by shlwapi.StrIsIntlEqualW/A to CompareStringW/A does. I discovered the different by writing a short program that compared the output of CompareString with and without the flag for all unicode characters... it took a while to run :) The flag (0x10000000) passed to CompareString reverse the sort order of a number of unicode characters. I've got no idea why it would want to do that... maybe somebody can shed some light on what the reason behind this would be? Mike ChangeLog: * add a test case for CompareStringW undocumented flag 0x10000000 Index: dlls/kernel/tests/locale.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/locale.c,v retrieving revision 1.33 diff -u -r1.33 locale.c --- dlls/kernel/tests/locale.c 21 Nov 2004 15:47:24 -0000 1.33 +++ dlls/kernel/tests/locale.c 21 Nov 2004 17:01:12 -0000 @@ -1410,6 +1410,76 @@ } #endif +static void test_CompareString_undoc(void) +{ + WCHAR table1[] = { + 0x0651, 0x3005, 0x3031, 0x3032, 0x309d, 0x309e, 0x30fc, 0x30fd, + 0x30fe, 0xfe7c, 0xfe7d, 0xff70 + }; + WCHAR table2[] = { + 0x02b9, 0x02ba, 0x02bb, 0x02bc, 0x02bd, 0x02be, 0x02bf, 0x02c0, + 0x02c1, 0x02c2, 0x02c3, 0x02c4, 0x02c5, 0x02c8, 0x02cc, 0x02cd, + 0x02ce, 0x02cf, 0x02d1, 0x02d2, 0x02d3, 0x02d4, 0x02d5, 0x02d6, + 0x02d7, 0x02de, 0x02e4, 0x02e5, 0x02e6, 0x02e7, 0x02e8, 0x02e9, + 0x0300, 0x0301, 0x0302, 0x0303, 0x0304, 0x0305, 0x0306, 0x0307, + 0x0308, 0x0309, 0x030a, 0x030b, 0x030c, 0x030d, 0x030e, 0x030f, + 0x0310, 0x0311, 0x0312, 0x0313, 0x0314, 0x0315, 0x0316, 0x0317, + 0x0318, 0x0319, 0x031a, 0x031b, 0x031c, 0x031d, 0x031e, 0x031f, + 0x0320, 0x0321, 0x0322, 0x0323, 0x0324, 0x0325, 0x0326, 0x0327, + 0x0328, 0x0329, 0x032a, 0x032b, 0x032c, 0x032d, 0x032e, 0x032f, + 0x0330, 0x0331, 0x0332, 0x0333, 0x0334, 0x0335, 0x0336, 0x0337, + 0x0338, 0x0339, 0x033a, 0x033b, 0x033c, 0x033d, 0x033e, 0x033f, + 0x0340, 0x0341, 0x0342, 0x0343, 0x0344, 0x0345, 0x0346, 0x0347, + 0x0348, 0x0370, 0x0371, 0x0372, 0x0483, 0x0484, 0x0485, 0x0486, + 0x0559, 0x055a, 0x0591, 0x0592, 0x0593, 0x0594, 0x0595, 0x0596, + 0x0597, 0x0598, 0x0599, 0x059a, 0x059b, 0x059c, 0x059d, 0x059e, + 0x059f, 0x05a0, 0x05a1, 0x05a2, 0x05a3, 0x05a4, 0x05a5, 0x05a6, + 0x05a7, 0x05a8, 0x05a9, 0x05aa, 0x05ab, 0x05ac, 0x05ad, 0x05ae, + 0x05af, 0x05b0, 0x05b1, 0x05b2, 0x05b3, 0x05b4, 0x05b5, 0x05b6, + 0x05b7, 0x05b8, 0x05b9, 0x05ba, 0x05bb, 0x05bc, 0x05bd, 0x05bf, + 0x05c0, 0x05c1, 0x05c2, 0x093c, 0x0951, 0x0952, 0x0953, 0x0954, + 0x0981, 0x09bc, 0x09c1, 0x09c2, 0x09c3, 0x09c4, 0x09cd, 0x09e2, + 0x09e3, 0x0a02, 0x0a3c, 0x0a41, 0x0a42, 0x0a47, 0x0a48, 0x0a4b, + 0x0a4c, 0x0a70, 0x0a71, 0x0a81, 0x0a82, 0x0abc, 0x0ac1, 0x0ac2, + 0x0ac3, 0x0ac4, 0x0ac5, 0x0ac7, 0x0ac8, 0x0acd, 0x0b01, 0x0b3c, + 0x0b3f, 0x0b41, 0x0b42, 0x0b43, 0x0b4d, 0x0bcd, 0x0c3e, 0x0c3f, + 0x0c40, 0x0c46, 0x0c47, 0x0c48, 0x0c4a, 0x0c4b, 0x0c4c, 0x0c4d, + 0x0c55, 0x0c56, 0x0cbf, 0x0cc6, 0x0ccd, 0x0d41, 0x0d42, 0x0d43, + 0x0d4d, 0x0e47, 0x0e48, 0x0e49, 0x0e4a, 0x0e4b, 0x0e4c, 0x0e4d, + 0x0eb1, 0x0eb4, 0x0eb5, 0x0eb6, 0x0eb7, 0x0eb8, 0x0eb9, 0x0ebb, + 0x0ebc, 0x0ec8, 0x0ec9, 0x0eca, 0x0ecb, 0x0ecc, 0x0ecd, 0x1026, + 0x1027, 0x1028, 0x1029, 0x102a, 0x102e, 0x1030, 0x1036, 0x1037, + 0x103b, 0x103d, 0x103e, 0x104b, 0x104c, 0x20d0, 0x20d1, 0x20d2, + 0x20d3, 0x20d4, 0x20d5, 0x20d6, 0x20d7, 0x20d8, 0x20d9, 0x20da, + 0x20db, 0x20dc, 0x20dd, 0x20de, 0x20df, 0x20e0, 0x20e1, 0x302a, + 0x302b, 0x302c, 0x302d, 0x302e, 0x302f, 0x3099, 0x309a, 0x309b, + 0x309c, 0xfb1e, 0xff9e, 0xff9f + }; + DWORD r,i,j; + WCHAR x[2],y[2]; + BOOL bPass = TRUE; + + x[1]=0; + y[1]=0; + for(i=0; bPass && (i<sizeof table1/sizeof table1[0]); i++) + { + x[0] = table1[i]; + for(j=0; bPass && (j<sizeof table2/sizeof table2[0]); j++ ) + { + y[0] = table2[2]; + r = CompareStringW(LOCALE_SYSTEM_DEFAULT, 0x10000000, x, 2, y, 2 ); + if (r!=CSTR_GREATER_THAN) + bPass = FALSE; + r = CompareStringW(LOCALE_SYSTEM_DEFAULT, 0, x, 2, y, 2 ); + if (r==CSTR_LESS_THAN) + bPass = FALSE; + } + } + todo_wine { + ok(bPass,"undocumented flag 0x10000000 test failed\n"); + } +} + static void test_FoldStringA(void) { int ret, i; @@ -2103,6 +2173,7 @@ test_GetCurrencyFormatA(); /* Also tests the W version */ test_GetNumberFormatA(); /* Also tests the W version */ test_CompareStringA(); + test_CompareString_undoc(); test_LCMapStringA(); test_LCMapStringW(); test_FoldStringA();

3 3

Re: epoll, LSB (was: Re: Problem roundup)
by Ivan Leo Puoti Nov. 21, 2004

Nov. 21, 2004

>You're forgetting K6 and K6-2 users with i586. Also, RH never provided >i586 packages (except for kernel and glibc), so it'd be foreign to the >distro to offer only that. The why not just 386 and 686, that will fit all. And you could not build devel and srps packages, or build them but hide them, and put a links to them somewhre else than the main download page, so that people that want them can get them but end users who just want runtime stuff can get it easily. Or we could just build some download pages for winehq, and just host the files on sf.net, like that we could make them more user friendly. Or we could make some pages and put them on winehq.sf.net, so that packagers could edit them without having to touch the lostwages cvs. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

3 2

Re: epoll, LSB (was: Re: Problem roundup)
by Ivan Leo Puoti Nov. 21, 2004

Nov. 21, 2004

> Could we show (our own pages) where users could choose distro, then > distro version, then actual package? Instead of pointing them to a few > screenful of files directly... We already partially have this, if you go to http://www.winehq.com/download and click on Red Hat you get this page http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=77396 that only contains RH packages. But I still think you should consider building fewer packages, probably an i586 build would do for almost all users. > Other ideas? Also have you ever tried building an RPM that runs on more than one version of RH? To run on 3 versions of mdk I only had to make very minor changes to the RPM. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

2 1

headers suggestion
by Jonathan Wilson Nov. 21, 2004

Nov. 21, 2004

In light of e.g. http://reactos.com:8080/archives/public/ros-dev/2004-November/000658.html I would like to suggest the following header ideas. Currently MingW has: 1.A set of headers that contain a copy of part of the platform SDK 2.Some extra stuff (like that ntdll.h) 3.A set of headers that contain a copy of part of the windows DDK 4.Mabie again some extra stuff MS doesnt have (I dont know) 5.A set of headers that contain a copy of part of the visual C++ runtime library 6.Some extra stuff (mainly bits required to deal with differences between GCC and Visual C I think) WINE has: 1.A set of headers that are supposed to contain a copy of part of the platform SDK (although some things have been claimed to be wrong) 2.A set of headers that are supposed to contain a copy of part of the visual C++ runtime library (although again there may be things that are wrong) and 3.Extra definitions for stuff in both header sets microsoft doesnt define in the platform SDK (e.g. internal bits, functions microsoft doesnt document etc) ReactOS has: w32api (the ROS import of it) include/ddk (the ReactOS version of the windows DDK) include/wine (the WINE windows API headers) include/msvcrt (the MSVCRT headers ROS uses to build and link with msvcrt) include (various misc ReactOS specific headers) What I suggest for ReactOS (and I think some of this is already being done) is as follows: grab any headers from include/* that are public DDK headers (if there are any) and make sure they are all in include/ddk grab everything from the current WINE headers MingW is missing. Check that its all correct and stuff and add it to the ReactOS import of w32api. (if anything is found to be wrong in the wine headers, it should be fixed) grab anything from include itself and add to w32api as needed Get permission to relicence the stuff and contribute back to the main w32api tree. grab contents of include/msvcrt on ReactOS plus include/msvcrt on WINE and also mingw-runtime. Create one set of header files from the 3 sets such that it matches the microsoft headers as closely as possible. Merge w32api DDK headers with ROS DDK headers and create one set that, again, matches the MS headers. For w32api/mingw-runtime, the suggestion is that they look at all the "new stuff" generated by the merging of the 3 sets of msvcrt headers plus the ROS/WINE/w32api merger plus the DDK merger and look at acccepting it. For WINE, I suggest they start using the new "merged" headers if at all possible. Basicly, the idea is that mingw-runtime would become the "definitive" set of msvcrt.dll headers out there and that ReactOS, MingW and WINE would start using it for any case where you are talking to msvcrt.dll from the public side. both ROS and WINE would then have their own internal msvcrt headers as necessary to build their msvcrt* builds Then, w32api would become the "definitive" set of win32 api headers and would contain as much of the Microsoft Platform SDK as people have legally cloned. All userland components of ReactOS (as well as kernel-side bits that need the stuff in the userland headers e.g. win32k.sys) would use this. Be nice if WINE were to use this too but because of what WINE is and how it is built/used, there may be reasons for the WINE team not to use w32api as the build headers used to build WINE. And, there would be one "definitive" set of DDK headers which would be good enough for building ReactOS with. And for building any kernel-side stuff WINE decides to add (e.g. that stuff to load the device drivers for vaerious copy protection systems that was being worked on). And for anyone using MingW and MingW GCC to build kernel-mode stuff. Anything private or project specific would go into a set of private headers as needed for the different projects and sub-sections (dlls etc) within them Anything exported by microsoft but undocumented would go into a set of "undocumented" headers (which could then be shared between ReactOS and WINE since I dont think w32api would accept anything not documented in MSDN) Just suggestions btw, if they are good, say so If they are bad, say so (and say why) If there are issues with my idea, say what they are.

3 2

Re: epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 21, 2004

Nov. 21, 2004

Mike Hearn wrote: > [The LSB] really doesn't deal with anything useful at all that isn't already > stable and on every Linux system anyway. Correct. When a commonly-needed package becomes "stable", a snapshot of its interface specification is taken, and added to the LSB. LSB applications can then rely on that interface being available. That might sound like a no-op, but the painstaking attention to detail involved in nailing down the interfaces of the LSB offers a lot of stability. > The LSB is toothless while upstream > projects continue to treat platform stability as a trivial detail. I'm not aware of e.g. an LSB-1.3 application that doesn't run properly on any system that supports LSB-1.3. Are you? > Note: the LSB did nothing to avoid the NPTL fiasco The transition to NPTL, like many other transitions in Linux's history, was painful, but that's exactly the kind of pain the LSB saves applications from. > and it's doing nothing to > avoid the COMPOSITE ARGB mess despite both libc and Xlibs being a part of > the supposedly "stable" base. http://freedesktop.org/pipermail/xorg/2004-August/002326.html says "COMPOSITE is experimental, users of it should expect things to break." I believe that the COMPOSITE extension is not part of LSB, so any application using it is not LSB-conformant. Here again, applications that conform to the LSB are saved from the pain of unstable interfaces changing. > The LSB process moves so slowly though that there's > no chance of them ever having an up to date desktop specification. That's ok. All we need is that they have a useful, working desktop specification. Mike, I get the feeling you want the LSB to be something it's not. Relax, let the LSB folks do their thing. Yes, LSB applications will always be using stable old interfaces, but *that's the point*. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

[test.winehq.org] summary broken
by Stefan Leichter Nov. 21, 2004

Nov. 21, 2004

Hello, i noticed something wrong in the summary of 200411201000. The main summary shows that the tests winspool.drv:info fails sometimes on the platform win2k, but in the summary of win2k (2000 differences) the line winspool.drv:info is not listed. Bye Stefan

2 1

GDI : implementation of GetLayout
by Rémi Assailly Nov. 21, 2004

Nov. 21, 2004

I would like to know if my implementation of GetLayout is clean. I did not found any information about GetLayout16, I would like to know if it is correct too. Thanks Rémi

1 0

Re: epoll, LSB (was: Re: Problem roundup)
by Dan Kegel Nov. 21, 2004

Nov. 21, 2004

Mike Hearn wrote: >> can't we package Wine as an LSB package? > > No, that's really not possible/sensible. > >> I suspect Wine depends on nothing that isn't in the LSB. > > I suspect it depends on a lot, for instance FreeType, OpenSSL, CUPS, > fontconfig, libasound/arts/jack, SANE, libjpeg etc etc. LSB 2.0 doesn't deal with sound, scanning, or printing (beyond lpr, anyway?), so an LSB 2.0 version of Wine would probably have to do without those. That'd be fine for me - I never use any of those features - but I realize that real users require themm. LSB 3, on the other hand, is going to add Gnome support, so they're at least thinking about the desktop now. (Your other objections - FreeType, fontconfig, libjpeg, OpenSSL, etc - could be packaged along with an LSB implementation of Wine, so they're not really an issue.) It would be worth doing an LSB 2.0 implementation of Wine as a demonstration of what's missing in the LSB; IMHO it would help put pressure on the LSB folks to include the missing bits in the next version. But remember, LSB can only standardize what has already stabilized in the field, and things like sound and printing are only now starting to not suck on Linux... - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

3 3

Version information in hhctrl.ocx breaks hhupd.exe
by Sven.Paschukat＠t-online.de Nov. 21, 2004

Nov. 21, 2004

Hello! I have noticed that in the last few days the native hhctrl.ocx doesn't installs anymore. Both the automatically installation in Internet Explorer and the manually start of Microsofts hhupd.exe fails with the message "This computer already has a newer version of HTML Help." I found out that integrating version information in the builtin hhctrl.ocx caused this effect. Look into the newest version of wine/dlls/hhctrl.ocx/Makefile.in and version.rc. Is this done wilfully or is it a bug? Thanks, Sven

6 14

SetForegroundWindow() from WM_ACTIVATE broken
by Jon Griffiths Nov. 21, 2004

Nov. 21, 2004

Hi, I have an application that keeps a fullscreen back panel window open, with its current working windows always in front. The back panel and all working windows are parented to the desktop. On windows clicking anywhere on the back panel momentarily activates the back panel, then the working window is brought to the front. On wine the back panel is brought to the front and activated (title bar active), obscuring the working window. I have narrowed the cause of this down and created a tiny test app to demonstrate the problem. Under windows, Calling SetForegroundWindow(xxx) from within the WndProc (specifically, while handling the WM_ACTIVATE message), will cause the xxx window to become the foreground window and rise to the top of the z-order. On Wine the window that called SetForegroundWindow() rises to the top of the z-order and gets its titlebar activated. This makes the app rather unusable at present. Does anyone have an idea how to correct this behaviour? I have attached the test app and its source for testing in case that helps, and I'll post more info if I find anything more. Thanks, Jon ===== "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!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

1 0

Re: epoll, LSB (was: Re: Problem roundup)
by Ivan Leo Puoti Nov. 20, 2004

Nov. 20, 2004

> Do you think I should add an explicit dependancy on the redhat-release > (or fedora-release) package, so people don't install them on the wrong > distribution? Yes, it would be a good idea considering how many packages you build. > It's a mess, but Wine does some things so close to glibc that > it's difficult to provide a "one binary fits all" without compiling an a > very old setup I build on Mandrake 10.1, but the RPM works on 10.0 and 9.2, and I'm quite confident it will run on 10.2 with little or no changes. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

Re: epoll, LSB (was: Re: Problem roundup)
by Ivan Leo Puoti Nov. 20, 2004

Nov. 20, 2004

> I count 24 packages Well, I've got only one RPM that works on Mandrake 9.2, 10.0 and 10.1, and it runs on 9.1 too if you upgrade your glibc packages, so having fewer packages is porbably also possible for RH. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

1 0

Re: (no subject)
by Dmitry Timoshkov Nov. 20, 2004

Nov. 20, 2004

"Tom" twickline(a)sitestar.net wrote: > I changed the format to reflect the other version.rc files > +#define WINE_PRODUCTNAME_STR "winsock" You don't need to invent a product name, it's already defined in include/wine/wine_common_ver.rc. The product name is Wine. -- Dmitry.

2 2

TeleVantage client on Wine
by alexanderhenry＠cox.net Nov. 20, 2004

Nov. 20, 2004

I am attempting to install the <a href="http://televantage.activelogic.com">TeleVantage Client</a> into wine. I have compiled Wine-20041019 from source. Upon running the installer, I get way too many errors: alexander(a)reservations:~$ wine .wine/drive_c/AppsPatches/netsetup/setup.exe fixme:msi:MsiGetProductInfoA "{8715D03E-39E4-4260-BB83-C63CA64D7660}" "PackageCode" 0x4069dbbc 0x4069dc2c fixme:msi:MsiGetProductInfoW L"{8715D03E-39E4-4260-BB83-C63CA64D7660}" L"PackageCode" 0x403b0118 0x4069dc2c err:dc:DCE_FreeWindowDCE [0x10026] GetDC() without ReleaseDC()! fixme:msi:MsiEnableLogA 00007fdf "c:\\windows\\wssetup.log" 00000000 fixme:msi:MsiInstallProductW L"Z:\\home\\alexander\\.wine\\drive_c\\AppsPatches\\netsetup\\Client.msi" L"SETUPEXEDIR=Z:\\home\\alexander\\.wine\\drive_c\\AppsPatches\\netsetup" err:msi:HANDLE_CustomType1 Unable to load library fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"AppSearch" fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"ValidateWorkstationSetupOSVersion") fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"FindRelatedProducts" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"ValidateProductID" err:msi:load_file Unfound Component L"MSXML.35210702_493B_42CA_BA13_865C5A8BDAC1" [.. above line x5] fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"IsolateComponents" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"ResolveSource" fixme:msi:ACTION_CostFinalize Version comparison.. [.. above line x10] fixme:msi:ACTION_CostFinalize cost should be diff in size fixme:msi:ACTION_CostFinalize Version comparison.. [.. above lines x3] alexander(a)reservations:~$ fixme:msi:ACTION_CostFinalize Version comparison.. fixme:msi:ACTION_CostFinalize Version comparison.. [.. above line x30] fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"ValidateIE5") fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"ValidateDCOM98") fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"GetWorkstationSetupInfo") fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"SetWorkstationSetupInstallPaths") fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"CacheWorkstationSetupSettings") fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"SetODBCFolders" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"MigrateFeatureStates" fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"SetWorkstationSetupFeatureStates") fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveExistingProducts" fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"RemoveReports") fixme:msi:ACTION_CustomAction UNHANDLED ACTION TYPE 5 (L"JScript" L"RemoveOldWorkstationSetupShortcuts") fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"AllocateRegistrySpace" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnpublishComponents" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"MsiUnpublishAssemblies" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnpublishFeatures" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterComPlus" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"SelfUnregModules" err:msi:HANDLE_CustomType1 Unable to load library fixme:msi:store_binary_to_temp File Name in temp tracking collision err:msi:HANDLE_CustomType1 Unable to load library fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterTypeLibraries" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveODBC" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterFonts" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveRegistryValues" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterClassInfo" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterExtensionInfo" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterProgIdInfo" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"UnregisterMIMEInfo" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveIniValues" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveShortcuts" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveEnvironmentStrings" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveDuplicateFiles" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveFiles" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"RemoveFolders" fixme:msi:ACTION_PerformAction UNHANDLED MSI ACTION L"MoveFiles" err:msi:extract_cabinet_file FDICopy failed err:msi:ACTION_InstallFiles Unable to ready media err:msi:ACTION_ProcessExecSequence Execution halted due to error (1627) Installation of Z:\home\alexander\.wine\drive_c\AppsPatches\netsetup\Client.msi (SETUPEXEDIR=Z:\home\alexander\.wine\drive_c\AppsPatches\netsetup) failed. so I figured that rather than getting the installer to run, I'd copy the files into wine and run it this way. I was able to copy from one PC to another with success, as long as the following libraries were present and registered: MSVBVM60.DLL TVW32.dll Tvlib.dll mfc71.dll msvcp71.dll msvcr71.dll ssinput1.ocx It is possible to regsvr32 files MSVBVM60.DLL, TVW32.dll, Tvlib.dll, ssinput1.ocx. It is not possible to regsvr32 files mfc71.dll, msvcp71.dll, msvcr71.dll. Files mfc71.dll, msvcp71.dll don't even appear in the registry. msvcr71.dll does, under .NET framework. Added the following to config: ;"MSVBVM60.DLL" = "builtin, native" ;"TVW32.dll" = "builtin, native" ;"Tvlib.dll" = "builtin, native" ;"mfc71.dll" = "native, builtin" ;"msvcp71.dll" = "native, builtin" ;"msvcr71.dll" = "native, builtin" ;"ssinput1.ocx" = "builtin, native" (tried different combos of commented, non-commented, builtin, native, with absolutely no effect) Upon doing this and attempting to run TeleVantage, I get these messages, and a black screen that appears on the first output message and dissapears on the last: alexander(a)reservations:~$ wine c:\\Program\ Files\\TeleVantage\\Client\\TVClient.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:GetRecordInfoFromGuids (0x425e80,1,1,1033,0x42626c,0x506274),stub! fixme:ole:CoRegisterMessageFilter stub I got this blank-in-blank-out problem when I did the PC to PC copy procedure as well. TeleVantage client just likes to quit with no errors if something is wrong. Per the registry entries mentioned above, I figured that installing .NET into wine would solve the problem. I just learned the hard way for the first time what this would entail. Installing windows version of mono into wine didn't solve the problem, and the msvcr71.dll didn't appear. Do you have any suggestions to help me install TeleVantage client on wine? Thanks --Alexander

2 1

Re: No RichEdit20A window class
by Michael Ost Nov. 19, 2004

Nov. 19, 2004

I'm re'ing my own post, but I think there's a combination of (1) a wine bug and (2) user error at work here. (1) The wine bug (I think) is that riched32.dll is registering the wrong window class name. Here's a suggested patch: [root(a)ihop dlls]# diff -Naur richedit/richedit.c richedit.MUSE/richedit.c --- richedit/richedit.c 2004-11-18 12:28:53.000000000 -0800 +++ richedit.MUSE/richedit.c 2004-11-18 17:03:33.000000000 -0800 @@ -792,7 +792,11 @@ wndClass.cbWndExtra = RTFInfoOffset + sizeof(RTFControl_Info*); wndClass.hCursor = LoadCursorA(0, (LPSTR)IDC_ARROW); wndClass.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1); +#if (_RICHEDIT_VER >= 0x0200 ) + wndClass.lpszClassName = RICHEDIT_CLASS20A; /* WC_RICHED32A; */ +#else wndClass.lpszClassName = RICHEDIT_CLASS10A; /* WC_RICHED32A; */ +#endif RegisterClassA (&wndClass); } Can any wise ones comment on this? (2) My user error is that Windows requires that RICHED32.DLL be manually loaded before use, it seems. At least that's what MFC requires, via its AfxInitRichEdit2() function. I called LoadLibrary("RICHED32.DLL") and, with my above patch, CreateWindow(RICHEDIT_CLASS,...) works fine. This isn't true for other DLLs... but, oh well, there it is. Cheers... mo

5 9

Re: Default System Colors
by William Poetra Yoga H Nov. 19, 2004

Nov. 19, 2004

--- Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > The colors of your gnome/kde desktop don't map that nicely to windows > colors. Because of this the end-result won't allways be very nice. In the > future we might want something like this. The best way to add something like > this is to finish our uxtheme dll and add support for theming to all > controls. Then WineLook=win95 (or winxp) will give you the "classic" colors > and lets say "uxtheme" will give everything the look and feel of lets say > gtk/qt. (this is how windows xp does its theming too) > > Roderick > Please reply below the original post. Yeah, agreed. Your idea is good, and we just have to wait for uxtheme.dll to finish. But in the meantime is it ok for us to change the default colors? Because the Win95 colors are just too... dull. And my "gradient colors for caption bar" patch will make WINE's windows look nice if Win2K/XP colors are applied... _IF_ my gradient-colors-patch will ever get accepted, because until now it's not been applied yet... (but that's for another thread :-P) __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

6 16

OK, this is off topic, but...
by William Poetra Yoga H Nov. 19, 2004

Nov. 19, 2004

I read WWN #249 and found my name is spelled correctly :) But the strange thing is, my (outgoing) name has been truncated in my emails since about a month ago. I wasn't trying to hide anything; rather, Yahoo! Mail has a maximum length of 32 characters for the outgoing name, and the last 'o' in my name gets truncated. It makes me feel itchy, so I decided truncating it would be better. But when I saw my name being spelled in full, I felt proud (I have always felt proud of my somewhat-long full name :P). So just out of curiosity, how did you guys know my real name? Anyway, now I have signature so you all should be able to read it. In full. Not restricted by Yahoo! Mail anymore. :) ===== William Poetra Yoga Hadisoeseno __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

1 0

Re: Thread-safe gethostbyname for WinInet
by Robert Shearman Nov. 19, 2004

Nov. 19, 2004

Robert Shearman wrote: > Hi, > > I have seen an issue that could be attributed to using the > non-thread-safe gethostbyname in wininet, so I have converted it as > best as I could to be thread-safe. > > Rob > > Changelog: > Use a thread-safe version of gethostbyname. Ignore this patch, it isn't actually any safer than the current version (actually, it's a lot less safer). I'll fix it up and resend soon. Rob

1 0

Re: Re: Kernel 2.6.9 - Issue Found
by Pouech Eric DMI AEI CAEN Nov. 19, 2004

Nov. 19, 2004

from what I read from Linus / Roland discussion on this topic (this night) on lkml, Linus only patched 1 out of 3 places which need to be patched (according to Roland). But I don't know yet if Linus will finish the job or not :-( IMO, what Linus proposes heads into the right direction (don't single step in signal handler if the process itself has set the TF flag, but do if the debugger has done it), however I cannot tell whether it's going to fix all issues. A+ > Message du 16/11/04 02:15 > De : "Jesse Allen" > A : wine-devel(a)winehq.org > Copie à : > Objet : Re: Kernel 2.6.9 - Issue Found > On Sun, Nov 14, 2004 at 08:45:00PM -0700, Jesse Allen wrote: > > On Sun, Nov 14, 2004 at 06:11:33PM -0800, Dan Kegel wrote: > > > I couldn't find the patch at either of the two > > > links Jesse posted, but I did see something similar here: > > > http://marc.theaimsgroup.com/?l=bk-commits-head&m=110048429304053&w=2 > > > > That's a brand new patch today. > > > > "x86: only single-step into signal handlers if the tracer asked for it." > > > > Looks like Linus may have been alerted by the problem and made this patch just > > in time for 2.6.10-rc2. Is this the "switch-off" we need? > > > > I'll be testing it shortly. > > > > It doesn't seem to fix the copy protection problem. So I'm wondering a few > things. Does wine need to be patched? This new patch seems to be related to > a chunk of code added in patch #2 mentioned in the original posting. I've > tried 2.6.10-rc2 with patch #1 reversed and patch 1+3 reversed. No difference > this time. > > Any idea will help. > > Jesse > >

3 2

Error while running wineprefixcreate
by ashok jani Nov. 19, 2004

Nov. 19, 2004

Dear Developer(s), While I am trying to run wineprefixcreae command on redhat 9.0 professional personal desktop installation following error is generated. # wineprefixcreate /usr/bin/wineserver: relocation error: /usr/bin/wineserver: symbol epoll_create, version GLIBC_2.3.2 not defined in file libc.so.6 with link time reference What is the solution? Ashok __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 1

replace a wrong fixme in dlls/winmm/playsound.c
by Rémi Assailly Nov. 19, 2004

Nov. 19, 2004

I tested a software ( a monopoly game ) and the error was that a sound was still playing so I think that is not a wine bug. Before submitting this patch to wine-patches I would like to know what do you think about it, what should be WARN, FIXME, if choosing ERR to all is correct or if some cases are useless.

3 3

wine - systray - gnome 2.8
by Grant Williamson Nov. 19, 2004

Nov. 19, 2004

Hi, I am seeing in Gnome-2.8 on the beta of RHEL4, the KDE status icons dock & are displayed correctly on the gnome systray. I am wondering if it anyone has considered using this technique to display wined based status icons now in gnome?< i.e. lotus notes new mail notification. Or am I simply barking mad?

3 3

CVS updates?
by Christian Britz Nov. 19, 2004

Nov. 19, 2004

Hi, sorry if this a stupid question, but I wonder why I get no new files anymore via cvs for about a week now (may be less or more). Are there really no updates or have I somehow misconfigured something? I'm used to get updates almost once a day... Thank you Christian

3 2

Win32 simulation
by Demoniak Nov. 19, 2004

Nov. 19, 2004

Hi ! Currently, I try to develop a stress tool for Windows. My main problem is to "simulate" multiple Windows system on one machine because of mouse and keyboard, and because only one Desktop or one Station can be active at a time. I discover Wine and I wonder if it is possible to use it on Windows platform to launch mutliple Windows-like OS ? - on http://sourceforge.net/project/showfiles.php?group_id=6241 there is a Win32 package. Is it dedicated to install Wine on Win XP ? How can I install it (five zip) ? - is it possible to launch multiple Wine on Windows ? (typically each one in a different Window, easily to monitor ?) - does Wine support Windows hooks mechanism ? I think it is a good beginning if I can have all this answers ;-))) Thanks Demoniak (not my real name) --------------------------------- Demoniak http://www.quisque.com --------------------------------- --------------------------------- Créez gratuitement votre Yahoo! Mail avec 100 Mo de stockage ! Créez votre Yahoo! Mail Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis.Téléchargez GRATUITEMENT ici !

2 1

Re: prevent peekmessage from crashing when msg == NULL
by Juan Lang Nov. 19, 2004

Nov. 19, 2004

Eric wrote: > Somewhere, for some reason, our client code was calling > PeekMessage(NULL, ...), basically asking windows to > discard a single message without returning it. From the > MSDN docs, this seems like an illegal use of the function, > but Windows does the right thing when we do it and wine > crashes. This sounds like a good place to write a test case. --Juan p.s. and I'll call that bluff: how _do_ you know what happens when you have more than 500 printers defined? ;) __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

3 4

Up-to-date instructions for relay trace
by Bill Medland Nov. 19, 2004

Nov. 19, 2004

Can someone please remind me; I can't find anything any longer in either the Wine User Guide or the Wine Developer's Guide I want to get a relay trace of all calls to functions in msvcrt.dll and in no other dlls. I thought all I'd have to do was set export WINEDEBUG=+relay and in the config file I set [Debug] "RelayFromInclude" = "msvcrt" ; everything else commented out However that also provides trace for a load of other stuff. Can I get just the msvcrt? (and, no I can't do it by getting everything and grepping the msvcrt; the program won't run with a full relay trace) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

No RichEdit20A window class
by Michael Ost Nov. 18, 2004

Nov. 18, 2004

Hi. My winelib application can't create a window of class RichEdit20A. It looks like the class is not being registered, because the DLL is not being loaded. Any clues why this might be? Turning on trace+richedit shows that dlls/richedit/richedit.c's RICHED32_Register and DllMain are not being called My test app tries to create a RICHEDIT_CLASS window and then it tries a TOOLTIP_CLASS window. Since both window classes are registered from their respective DLLInit I thought they would make a good comparison. The first fails; the other doesn't. Neither riched32.dll nor commctrl.dll show up in the exe.spec.c file, since winebuild finds none of their entry points in my code. But the commctrl DLL is loaded, while the riched32 one is not. Psuedo-code: #include <richedit.h> #include <tooltips.h> winmain(...) { CreateWindow(RICHEDIT_CLASS, ....) // Fails: I see err:win:CreateWindowExA bad class name "RichEdit20A" // on the console CreateWindow(TOOLTIP_CLASS, ...) // no complaint } Any help would be appreciated... mo =================================== Michael Ost, Software Architect Muse Research, Inc. most(a)museresearch.com

1 0

Fwd:providing app db entries
by Ivan Leo Puoti Nov. 18, 2004

Nov. 18, 2004

Not sure what to answer, so I'm forwarding to wine-devel Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

2 1

RE: profiling GTA4. question about polling
by Ann and Jason Edmeades Nov. 18, 2004

Nov. 18, 2004

Hi Brian, Firstly thanks for the profiling info - its something I have been waiting to try when I get through the d3d9 changes. We have always known that routine was bad (hence the name 'slow'!) but that confirms it. Re the splitting into wined3d - You asked "Is this a tedious task or does it require knowledge of the codebase?"... It's a bit of both. I am taking it slower because I am trying to ensure the patches get committed so I don't end up reworking things, and I only have limited time so I don't want to waste it. At the moment I am 'stuck' trying to get a particular patch in, which will dictate the future direction of lots of other patches, so it is important we get it right. Once that's done, I really hope to make a lot of progress relatively quickly, and once I get beyond a certain point, feel free to hack away. I hate the fact I am holding anyone back! Please do take Raphael's test patch and try again - I would be interested to know if it makes a significant difference (which I do believe it should). I would be very interested in any other profiling results, and if you feel like improving things in the code please go for it. One thing I always fancied doing was to profile the 3dMark2001SE utility, and see how close to windows performance we can get and identify the bottlenecks. Regards, Jason

1 0