wine-devel November 2004

wine-devel@winehq.org

141 participants
248 discussions

dinput - fix detection under Windows
by Steven Edwards 24 Nov '04

24 Nov '04

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 24 Nov '04

24 Nov '04

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@.c core + *.flc *.spec.c *.spec.def *.dbg.c *.pedll.c *.tab.c *.tab.h @LEX_OUTPUT_ROOT@.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 24 Nov '04

24 Nov '04

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 24 Nov '04

24 Nov '04

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 24 Nov '04

24 Nov '04

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 24 Nov '04

24 Nov '04

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 24 Nov '04

24 Nov '04

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 24 Nov '04

24 Nov '04

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 24 Nov '04

24 Nov '04

"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 23 Nov '04

23 Nov '04

> 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

← Newer
1
2
3
4
5
6
7
8
9
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2004