wine-devel

wine-devel@winehq.org

3 participants
84472 discussions

Quick question on the Cygwin/Mingw port
by Steven Edwards 29 May '02

29 May '02

Hola, I'm on the road traveling till Monday so I sent the question here rather then cygwin support because I figured someone here has to have a little cygwin and mingw experience. I'm using cygwin to host my mingw WINE devel with --target=mingw --host-mingw --build=mingw -mno-cygwin and -fnative-struct and it is still linking to cygwin1.dll. I don't really understand whats going on because it doesn't seem to be using any of the exports from cygwin1.dll but if I try to test the dlls/programs/tools on another box it bitches about missing the dll. If anyone has any insight please let me know or just send this to /dev/null Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

3 3

Use of wine RPC implementation for TAPI 2 client ?
by Yann Dirson 29 May '02

29 May '02

We're investigating the implementation of a TAPI 2 client lib on Linux. Wine looks like one of the projects with an implementation of DCE/MS-RPC. What's the status of this RPC implementation, in terms of specs coverage, and stability ? Do you have an MIDL compiler ? Regards, -- Yann Dirson <Yann.Dirson(a)fr.alcove.com> http://www.alcove.com/ Technical support manager Responsable de l'assistance technique Senior Free-Software Consultant Consultant senior en Logiciels Libres Debian developer (dirson(a)debian.org) Développeur Debian

2 1

More regression errors ...
by Paul Millar 29 May '02

29 May '02

Hi, I've noticed that amongst last night's slew of patches, Mehmet's regression tests were applied without his patches that correct wine's behaviour. Wine now fails regression tests on all platforms. If his patches are delayed for some reason, could/should we use todo_wine to acknowledge that these failures are known? If so, I've attached a trivial patch to do this for the tests that failed for me ... ChangeLog: Mark failing regression tests as todo Cheers, ---- Paul Millar

2 1

Re: [Bug 722] Changed - GDI.EXE
by Andriy Palamarchuk 29 May '02

29 May '02

--- Johan Gill <johane(a)lysator.liu.se> wrote: > On Tue, 28 May 2002 wine-bugs(a)winehq.com wrote: > > > Some rights wouldn't hurt btw. > > + > > + > > + ------- Additional Comments From > Speeddymon(a)yahoo.com 2002-05-28 15:14 ------- > > + Send an email to wine-bugs(a)winehq.com asking > someone to give you additional > > + BugZilla priveleges so that you may work on bug > 722 > > So here's an offical request for privileges. Done. Official congratulations with new privileges :-) Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Main window size difference
by Guy L. Albertelli 29 May '02

29 May '02

Has anyone else noticed that the size of main windows under Windows is much different than under Wine. As an example, using the Tab control test program (from the ControlSpy series). Under Windows the overall size appears to be about 819x564. Under Wine it is about 505x268. (I may be off by 1 or 2 pixels, but not 30% to 40%.) And yes my screen resolution under both systems is 1024x768. This obviously makes doing pixel matching, or even item layout matching difficult. Guy Albertelli <<galberte(a)neo.lrun.com>>

2 1

Re: Idea for people with priveleges
by Andriy Palamarchuk 29 May '02

29 May '02

--- Dustin Navea <speeddymon(a)yahoo.com> wrote: > Anyone that can modify the layout of the BugZilla > site > should take this into consideration: > > People with priveleges as you know can pretty much > do > what they need to with a bug, i.e. if it is resolved > and the person working on it forgot to set it as > resolved, anyone with preveleges can do that. But, > what about if we havent heard from the reporter in a > while and we need to knock the bug out, our only > option is to ask the reporter if it has been > resolved, > tell them to try it with a recent wine build and to > try some of the things mentioned in the comments, > and > then mark it as resolved and them after that mark it > as closed, so it is shown as closed and not resolved > on the bug list... > > why not give people with priveleges the ability to > close it without resolving it, so that they only > have > to make 1 post instead of 2? Plus that way we have > bugs that are actually resolved marked so, and ones > that we are unsure of marked as closed but can > always > be reopened... Why do you want to close such bug in the first place? IMHO it is Ok to put the bug in the RESOLVED state and wait some time if the original reporter provides feedback or more information will become available. Keeping the bug in RESOLVED state will insure that somebody will look at the bug one more time. Is this too many steps? >From Bugzilla docs: "QA looks at resolved bugs and to make sure the appropriate action has been taken. If they agree, the bug is marked VERIFIED. Bugs remain in this state until the product ships, at which time the bug is marked CLOSED." Currently we do not have one more "verification layer" for bugs. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

1 0

Something's wrong with hypermail
by Johan Gill 29 May '02

29 May '02

I've noticed that selecting 'Next message' in the web interface to the mailinglists sometimes skips messages. For example, take a look at my latest messages to wine-patches. Standing at the second 'PATCH: DirectSound', the next message is said to be 'Re: RESUBMIT: PATCH: DirectSound'. Hang on...this is the case for my mmioAdvance patch also! Ok, so my patches seem to confuse the interface :/ /Johan Gill, johane(a)lysator.liu.se

1 0

Re: some other playsound fixes
by Alexandre Julliard 29 May '02

29 May '02

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > typedef struct tagWINE_PLAYSOUND { > - HANDLE hThread; > - HANDLE hReadyEvent; > - BOOL bStop; > - LPCWSTR pszSound; > - HMODULE hMod; > - DWORD fdwSound; > - BOOL bLoop; > - BOOL bAlloc; > + volatile BOOL bLoop : 1, > + bAlloc : 1; > + LPCWSTR pszSound; > + HMODULE hMod; > + DWORD fdwSound; > + struct tagWINE_PLAYSOUND* lpNext; > } WINE_PLAYSOUND, *LPWINE_PLAYSOUND; If you need to make variables volatile, something is wrong with the synchronization, and volatile is the wrong fix (especially on a bit field where updates can't be atomic). What is this supposed to fix? -- Alexandre Julliard julliard(a)winehq.com

2 1

Second current CVS compile failure
by Guy L. Albertelli 29 May '02

29 May '02

After bypassing previous error, got this one: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fPIC -D__WINE_ _ -D_REENTRANT -I/usr/X11R6/include -o information.o information.c ld -r comcat_main.o factory.o manager.o register.o information.o -o comcat.dll.tmp.o strip --strip-unneeded comcat.dll.tmp.o LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -D__WINE__ -sym comcat.dll.tmp.o -o comcat.spec.c -spec ./comcat.spec -L../../dlls -lole32 -ladvapi32 -lkernel32 gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fPIC -D__WINE_ _ -D_REENTRANT -I/usr/X11R6/include -o comcat.spec.o comcat.spec.c LD_LIBRARY_PATH="../../library:../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -D__WINE__ -o comcat.dll.dbg.c -debug -C. comcat_main.c factory.c manager.c register.c information.c gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fPIC -D__WINE_ _ -D_REENTRANT -I/usr/X11R6/include -o comcat.dll.dbg.o comcat.dll.dbg.c gcc -shared -Wl,-Bsymbolic comcat.spec.o comcat_main.o factory.o manager.o register.o information.o comcat.dll.dbg.o -o omcat.dll.so -L../../dlls -L../../library -lwine -L../../ole -lwine_uuid -l m information.o: In function `COMCAT_GetCategoryDesc': /home/albertel/t1/wine/dlls/comcat/information.c:392: undefined reference to `swprintf' collect2: ld returned 1 exit status make[2]: *** [comcat.dll.so] Error 1 Guy Albertelli <<galberte(a)neo.lrun.com>>

2 1

RFC - patch for psapi and missing imports on Mingw target
by Steven Edwards 29 May '02

29 May '02

This kind of a dirty hack but just a idea and it shouldn't have a effect on cygwin as it will use the win32api package also. Mabey a better name then MINGW_IMPORTS can be used. This patch allows psapi.dll to be (almost) built. Mingws libkernel32.a doesn't contain the import information for the toolhelp APIs. Instead it models Visual Studio 6 and implents them in libth32.a. Does anyone know if this has changed in Visual Studio .NET? If so then I will submit a patch to mingw for the Win32api. If not, then I belive using libth32.a is the most proper way. Would a better solution be for me to make the make implib rule and just use wines libkernel32.a? I havent really looked at doing it because NTDLL, MSVCRT,GDI,USER and KERNEL32 are not targets of my port and may contain exports lacking on a Windows host. The only bug after this patch is - psapi_main.o(.text+0x1248):psapi_main.c: undefined reference to `wine_server_cal l' Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson cvs diff -u Makedll.rules.in Index: Makedll.rules.in =================================================================== RCS file: /home/wine/wine/dlls/Makedll.rules.in,v retrieving revision 1.27 diff -u -r1.27 Makedll.rules.in --- Makedll.rules.in 22 May 2002 21:32:49 -0000 1.27 +++ Makedll.rules.in 29 May 2002 05:32:10 -0000 @@ -35,7 +35,7 @@ # Rules for .dll files $(MODULE): $(OBJS) $(MODULE).dbg.o $(SPEC_DEF) Makefile.in - $(DLLWRAP) $(DLLWRAPFLAGS) --def $(SPEC_DEF) --implib $(MODULE:.dll=.a) -o $@ $(OBJS) $(MODULE).dbg.o -L$(DLLDIR) $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) $(ALL_LIBS) + $(DLLWRAP) $(DLLWRAPFLAGS) --def $(SPEC_DEF) --implib $(MODULE:.dll=.a) -o $@ $(OBJS) $(MODULE).dbg.o -L$(DLLDIR) $(DELAYIMPORTS:%=-l%) $(IMPORTS:%=-l%) $(MINGW_IMPORTS) $(ALL_LIBS) $(SPEC_DEF): $(WINEBUILD) cvs diff -u Makefile.in Index: Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/psapi/Makefile.in,v retrieving revision 1.11 diff -u -r1.11 Makefile.in --- Makefile.in 11 May 2002 23:06:34 -0000 1.11 +++ Makefile.in 29 May 2002 05:33:48 -0000 @@ -4,6 +4,7 @@ VPATH = @srcdir@ MODULE = psapi.dll IMPORTS = kernel32 ntdll +MINGW_IMPORTS = -lth32 LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel