wine-devel December 2002

132 participants
377 discussions

by John K. Hohm

Alexandre Julliard <julliard(a)winehq.com> wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Appended program uses CxxFrameHandler and crashes in wine with builtin > > msvcrt, but not with native. Compile as Release version and include the > MFC > > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do > > you need something complete? > > That's a start, yes, thanks. I'll need a more complete example with > nested try blocks, destructors all over the place, typed exceptions, > etc. to make sure I understand all the compiler internal structures; > but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?

21 years, 1 month

DirectSound and i810 soundcards

by Francois Gouget

There is a problem with Directsound and i810 soundcards. The test I just sent to wine-patches illustrates it very well. Basically sounds are being played too fast. Here's my understanding of the problem (if my memory and understanding of the logs is correct): When DSound initializes it create a primary sound buffer and invokes winmm to actually get access to a sound device. The default format of the primary buffer is 22050x16x2 (i.e. 22050Hz, 16 bit sound, stereo). This means the device it's going to get will be handled by msacm.drv which will be responsible for performing the conversions on the fly. However during the primary buffer creation DSDB_MapPrimary gets invoked in wineoss and does an mmap of the hardware sound buffer. So when we then play sound in a secondary sound buffer, this sound gets mixed into the primary buffer, but because of the mmap this then goes straight to the sound card with no further conversion. So you end up with a chipmunk sound effect since you play a 22050x16x2 sound at 48000x16x2. I will try to make more tests to confirm this but does it seem to make sense? Should I look in some other direction? Any suggestion about a fix? If you have an i810 soundcard you can reproduce by doing the following: * apply "Add WINETEST_INTERACTIVE" from wine-patches * apply "Add 'audiophile' DirectSound tests" from wine-patches * cd dlls/dsound/tests * make * WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c (you can also set WINETEST_DEBUG=2 to get more debug info about the test's buffer management, though this is probably not relevant here) Alternately, you can download the latest Windows test binaries from my site (http://fgouget.free.fr/wine/winetests.zip) and run them using Wine, or on Windows: set WINETEST_INTERACTIVE=1 dsound_test dsound Actually I would be interested in the results of this test on Windows: * the test tone is usually played three times. Are all three, and especially the first one, at the right pitch? * what is the output of the test? I'm interested in reported capabilities as stated by Windows and Wine for instance (to determine whether the primary buffer is emulated for instance). * what is the primary buffer's default format? 22050x16x2? (that's not supported by the sound card!) * does the winmm test work? set WINETEST_INTERACTIVE=1 winmm_test wave * in particular, what happens when the test tone is played with WAVE_FORMAT_DIRECT on Windows? (except Win9x platforms which don't support that flag) -- Francois Gouget fgouget(a)codeweavers.com

21 years, 4 months

Re: Registering DLL's

by John K. Hohm

Alexandre said: > Part of it should be done with DllRegisterServer, the rest can be > handled by the .inf script. And I think it's OK to add the necessary > DllRegisterServer entry points even if the native dll doesn't have > them. I'm glad you feel that way. I created bug 1117, "Make all Wine OLE DLLs self-registerable", and have been working on an implementation. For some reason I can't accept the bug; though I've tried several times, it stays at UNCONFIRMED. What to do about DLLs like ole32.dll that have a native DllRegisterServer but no corresponding DllUnregisterServer? I'm inclined to include it for completeness, though it's unlikely that anyone would ever want to unregister such a basic system DLL. I posted my idea for representing the registration data, accidentally from "jhohm(a)happyhappy.dyndns.org" rather than my usual "jhohm(a)acm.org" (see http://www.winehq.com/hypermail/wine-devel/2002/11/1409.html), but I haven't gotten any responses, not even "looks fine" or "you are a moron". I guess I'll just start submitting patches, then.

21 years, 4 months

Re: tchar fixes: _tcs{dup,icmp}

by Francois Gouget

On Mon, 23 Dec 2002, Dimitrie O. Paun wrote: > That's what I have to do on my system. > > Francois, does this seem OK to you? If the fix is right, > what about the other _str* symbols? According to the latest sdk I have (2000), _tcsdup is supposed to map to _strdup and _tcsicmp to _stricmp. I think the catch is you are supposed to link with the msvcrt library since these symbols are only exported there. Now, pointing _tcsdup to strdup should not make any difference. However I am not sure that _stricmp really behaves exactly like strcasecmp: you would need to check how each of these handles accentuated characters and locale. Then the question is whether tchar.h should be considered to be a pure msvcrt thing, i.e. don't use it if you don't link to msvcrt, or whether we want to make is usable in Ansi mode with a regular C library. Currently we set the macros based on _MBCS and _UNICODE. Maybe we need to add a WINE_LIBC flag and add mappings to the native C library routines? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.

21 years, 4 months

Debugger / wineconsole problem

by Lionel Ulmer

Hi all, I have a little annoying problem with the wineconsole / winedbg : as soon as I switch to another window and come back to the debugger, I loose keyboard input. Mouse input still works fine. I have also often graphical glitches (ie I have only garbage when scrolling due to a newline being displayed). The scollbar seems also to be non-functionnal. Lionel -- Lionel Ulmer - http://www.bbrox.org/

21 years, 4 months

__WINE__ vs. __WINESRC__

by Dimitrie O. Paun

Hi folks, Here is another problem: we are currently defining the __WINE__ symbol to signal the headers that we are compiling Wine. This is fine. The problem that I'm facing is that there are apps (such as wxWindows) that want to know that they are _compiled_ (not run) under Wine. All platforms (and Wine is a platform, even if a virtual one) define standard symbols by default: __WIN32__, __MINGW32__, you name it. There are valid reasons for a program to be able to test that is being compiled under Wine, and not under MinGW for example. Thus, we need to define a standard symbol, and __WINE__ seems to be the most appropriate. I think it's better to expose the prettier name, and use a longer/uglier one internally. So, my proposal is: let's rename the __WINE__ symbol (as it's currently used) to something else (__WINESRC__, or whatever, suggestions welcome), once that's done, define __WINE__ when __WINESRC__ is not defined (the symbols would be mutually exclusive). I can send in a patch if people don't object... -- Dimi.

21 years, 4 months

Re: Make RECT === RECTL, fix compile warnings, use uniform format

by Dimitrie O. Paun

On December 28, 2002 04:10 pm, Dan Kegel wrote: > Decided to leave debugrect for later, too much of a pain for now. > This patch just uses a uniform format for RECTs where possible. > It reorders three or so TRACEs that had the coordinates in > nonstandard order, too. Patch against current CVS attached. > Should compile fine, but I haven't tested it (so do look it over :-) Cool stuff. Can you please turn this thing: Index: dlls/comctl32/datetime.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/datetime.c,v retrieving revision 1.34 diff -d -u -r1.34 datetime.c --- dlls/comctl32/datetime.c 2 Dec 2002 18:11:00 -0000 1.34 +++ dlls/comctl32/datetime.c 28 Dec 2002 20:43:22 -0000 @@ -1098,7 +1098,7 @@ infoPtr->rcClient.bottom = HIWORD(lParam); infoPtr->rcClient.right = LOWORD(lParam); - TRACE("Height=%d, Width=%d\n", infoPtr->rcClient.bottom, infoPtr->rcClient.right); + TRACE("Height=%ld, Width=%ld\n", infoPtr->rcClient.bottom, infoPtr->rcClient.right); /* use DrawEdge to adjust the size of rcEdge to get rcDraw */ memcpy((&infoPtr->rcDraw), (&infoPtr->rcClient), sizeof(infoPtr->rcDraw)); Into a standard [(%ld,%ld)-(%ld,%ld)]? As for debugrect(), it seems like half of the printed rectangles are in commctrl, so what we can do is use debugrect() in there without having to introduce any infrastructure changes. We can do that after Alexandre commits this change, so we don't cram too much stuff into one patch. -- Dimi.

21 years, 5 months

RE: Fixing include quotes (was: Re: conformance test for ShellExecute)

by Patrik Stridvall

> On December 30, 2002 03:41 pm, Patrik Stridvall wrote: > > I'm already on it by improving winapi_cleanup. > > Very well, I've put you up for it instead. But make sure > you don't over do it :) Well, for the future I have planned grouping and automatic addition of #ifdef HAVE_ and that sort of things. That is overdoing a little perhaps but it will look nicer. :-) > It seems to me the algo is simple > (if the include can not be accessed relative to the dir in > which the .c file is, change it to <>), This is that it already does I think. Please try it out yourself. > and the operation > is really one time. It depends what you mean by one time. People make mistakes. winapi_cleanup does C++ comment to C comment conversion and this is "one time" as well... > So if you have something that works, > let's just get the patch (and here I'm referring to the one > that does the actual "" to <> change) in, and check this off. I think it is better than Alexandre runs winapi_cleanup --include-quotes himself if he thinks it does the correct things. If not please inform me what the problem is. In my tree, the patch is over 800k.

21 years, 5 months

Visual-MinGW: Winelib patch

by Dimitrie O. Paun

Hi Manu, I got around getting Visual-MinGW to compile under Winelib. This patch touches only your makefile, and I hope the changes are not controversial: -- Use forward slash instead of backslash -- Explicitly list the DLLs you link against (shell32, comdlg32, advapi32) -- It make sense to specify -mno-cygwin For some reason, the code seems to require it. Please check that it works under Windows as well. If it does, if makes sense to have it as Visual-MinGW should not have a dependency on Cygwin, as far as I can tell. -- Do not use -pedantic, the code does not compile with gcc 3.2 on Linux with that flag. -- Do not use -fvtable-thunks, it is deprecated in gcc 3.2 Please apply this patch with 'patch -p1 < winelib.diff'. Note that I still need to get some changes integrated into the official Wine tree before you can actually compile Visual-MinGW under Winelib. The changes are not controversial, and I hope to get them in real soon. I will let you know when that happens. Regardless, I think the changes I'm proposing are logical in and of themselves, so I figured they can be integrated regardless. Enjoy! --- Visual-MinGW.orig/Projects/vmingw/src/makefile 2002-06-08 06:07:10.000000000 -0400 +++ Visual-MinGW/Projects/vmingw/src/makefile 2002-12-31 01:43:29.000000000 -0500 @@ -1,25 +1,25 @@ # Generated automatically by Visual-MinGW. # http://visual-mingw.sourceforge.net/ -CC = g++ +CXX = g++ WRES = windres DLLWRAP = dllwrap CPPFLAGS = -D_WIN32_IE=0x0400 -LDBASEFLAGS = -mwindows -lcomctl32 -lole32 +LDBASEFLAGS = -mwindows -mno-cygwin -lcomctl32 -lole32 -lshell32 -lcomdlg32 -ladvapi32 INCDIRS = -I ../include OPTIMIZ = -O2 STRIP = -s ifeq ($(MAKECMDGOALS),debug) -CXXFLAGS = -W -Wall -pedantic $(INCDIRS) -g -fvtable-thunks -fno-rtti +CXXFLAGS = -W -Wall $(INCDIRS) -g -mno-cygwin -fno-rtti LDFLAGS = $(LDBASEFLAGS) else -CXXFLAGS = -W -Wall -pedantic $(INCDIRS) $(OPTIMIZ) -fvtable-thunks -fno-rtti +CXXFLAGS = -W -Wall $(INCDIRS) $(OPTIMIZ) -mno-cygwin -fno-rtti LDFLAGS = $(STRIP) $(LDBASEFLAGS) endif -SRCDIR = .\src -BINDIR = ..\bin +SRCDIR = ./src +BINDIR = ../bin LIBDIRS = %.o : %.rc @@ -51,7 +51,7 @@ # Dependency rules $(TARGET): $(OBJS) - $(CXX) -o $(BINDIR)\visual-mingw.exe $(OBJS) $(INCDIRS) $(LIBDIRS) $(LDFLAGS) + $(CXX) -o $(BINDIR)/visual-mingw.exe $(OBJS) $(INCDIRS) $(LIBDIRS) $(LDFLAGS) rsrc.o: rsrc.rc -- Dimi.

21 years, 5 months

Alexandre?

by Jeff Smith

I've seen no activity on wine-cvs for a week (Dec 23). What's up? Holiday vacation? Either way, Happy (if belated) Holidays to everyone who celebrates a holiday. :-) -- Jeff S _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 3 months FREE*. http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&… http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_virusprote…

21 years, 5 months

Jump to page:

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