- Wine-Devel - list.winehq.org

Re: test-and-dereference: a common problem?
by Alexandre Julliard May 16, 2005

May 16, 2005

Paul Millar <paul(a)astro.gla.ac.uk> writes: > Anyway, I noticed that the dlls/advapi32/crypt.c tests were bombing out > for me. This turned out to be due to dlls/advapi32/crypt.c:1649 > > > if (!key || !pbData || !key->pProvider || key->pProvider->dwMagic != MAGIC_CRYPTPROV) > > CRYPT_ReturnLastError(ERROR_INVALID_PARAMETER); > > [...] > So, this makes sense. Its that old chestnut of compiler being free to > evaluate if clauses in any order it chooses (for optimisation). The && and || operators in C are short-circuit operators, meaning they are always evaluated left to right, and further tests are not executed if the first ones fail. I'm afraid you wasted your time with that patch, there's nothing to fix here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Make winelib resource data writeable
by Dmitry Timoshkov May 16, 2005

May 16, 2005

"Felix Nawothnig" <felix.nawothnig(a)t-online.de> wrote: > For PE files there is a hack in kernel/except.c which does COW for > resource data - but winelib apps crash when they try to write to it. > (If this is a design-decision please tell me) As it's clearly indicated in the error message in kernel/except.c only broken apps try to write to the resources. What your application is trying to do? -- Dmitry.

3 2

Re: PATCH: hglobalstream static
by Dmitry Timoshkov May 16, 2005

May 16, 2005

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > /*** > + * This implements the IUnknown method AddRef for this > + * class > + */ > +static ULONG WINAPI HGLOBALStreamImpl_AddRef( > + IStream* iface) > +{ > + HGLOBALStreamImpl* const This=(HGLOBALStreamImpl*)iface; > + return InterlockedIncrement(&This->ref); > +} I understand that this is an existing code, but calling InterlockedIncrement for a 'const' pointer looks very suspicious. Same for HGLOBALStreamImpl_Release, HGLOBALStreamImpl_Read and other interfaces which actually change the pointed data. -- Dmitry.

2 1

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards May 16, 2005

May 16, 2005

Hi Michael, --- Michael Lin <mlin(a)corvu.com.au> wrote: > If your target platform is windows, don't define the WINE_UNIX_PATHS > flag when you compile and it will all behave > the same as before. It's only when you define WINE_UNIX_PATHS flag that > GetOpenFileNameW() will be mapped > to UnixFSGetOpenFileNameW() for example. Else it will call the same > function as before and shouldn't break on Windows. > WINE_UNIX_PATHS is currently not defined anywhere in WINE, so no one > should see any difference. To see the change, > you have to define that flag in your winelib application's makefile. But your defining UnixFSGetOpenFileNameW in the spec file so the import library will still have that function listed so if I link a dll to that import library its going to fail on Windows even if I am not calling that function. The Windows Linker/Loader is not forgiving like the Unix loader if the symbol is not found in the import table. It seems like Winebuild will need some magic as well if you don't want these function exported all the time. Thanks Steven Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html

4 3

Game sound problem with wine 20050310 (Debian testing)
by J. Grant May 15, 2005

May 15, 2005

Hello, I have been trying to get audio working in sync with the game I am playing (Activision Call of Duty) I get this error: err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error) err:wave:DSDB_MapBuffer Use: "HardwareAcceleration" = "Emulation" in the [dsound] section of your config If I use the suggestion i get 1sec lag on in-game sounds. Someone #winehq gave me some tips. I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please? [dsound] ;"Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv" ; for KDE "Drivers" = "winealsa.drv" ; for ALSA users ;; HEL only: Number of waveOut fragments ahead to mix in new buffers. "HELmargin" = "5" ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;"HELqueue" = "5" ;; Max number of fragments to prebuffer ;"SndQueueMax" = "28" ;; Min number of fragments to prebuffer ;"SndQueueMin" = "12" ;; Forces emulation mode (using wave api) "HardwareAcceleration" = "Emulation" ;; Sets default playback device (0 - number of devices - 1) ;"DefaultPlayback" = "0" ; use first device (/dev/dsp) ;"DefaultPlayback" = "1" ; use second device (/dev/dsp1) ;"DefaultPlayback" = "2" ; use third device (/dev/dsp2) ;; Sets default capture device (0 - number of devices - 1) ;"DefaultCapture" = "0" ; use first device (/dev/dsp) ;"DefaultCapture" = "1" ; use second device (/dev/dsp1) ;"DefaultCapture" = "2" ; use third device (/dev/dsp2) Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh "Emulation" bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise) I wonder if this is a known problem (bug)? Is there a work around? Or a fix please? I am not on this list, so please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

4 8

Re: dlls/msvcrt/time.c build breakage
by Juan Lang May 15, 2005

May 15, 2005

Oops, I mistakenly assumed daylight and timezone were available in FreeBSD too. I'll take a look this week when I get a crack at my FreeBSD box. --Juan --- Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> wrote: > The following change to dlls/msvcrt/time.c > > revision 1.22 > date: 2005/05/14 11:07:10; author: julliard; state: Exp; lines: +31 > -4 > Juan Lang <juan_lang(a)yahoo.com> > - move _timezone to time.c, and correct its type > - implement _tzset, and initialize _daylight, _timezone, and _tzname > from libc values > > breaks the build on FreeBSD 4.10: > > time.c: In function `MSVCRT__tzset': > time.c:351: error: `daylight' undeclared (first use in this function) > time.c:351: error: (Each undeclared identifier is reported only once > time.c:351: error: for each function it appears in.) > time.c:352: warning: assignment makes integer from pointer without a > cast > > Would you mind fixing this? > > Gerald > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

1 0

dlls/msvcrt/time.c build breakage
by Gerald Pfeifer May 15, 2005

May 15, 2005

The following change to dlls/msvcrt/time.c revision 1.22 date: 2005/05/14 11:07:10; author: julliard; state: Exp; lines: +31 -4 Juan Lang <juan_lang(a)yahoo.com> - move _timezone to time.c, and correct its type - implement _tzset, and initialize _daylight, _timezone, and _tzname from libc values breaks the build on FreeBSD 4.10: time.c: In function `MSVCRT__tzset': time.c:351: error: `daylight' undeclared (first use in this function) time.c:351: error: (Each undeclared identifier is reported only once time.c:351: error: for each function it appears in.) time.c:352: warning: assignment makes integer from pointer without a cast Would you mind fixing this? Gerald

1 0

Debugging remotely from Visual studio
by David Hemmo May 15, 2005

May 15, 2005

Hello, After reading a mail exchanges about ptrace on Linux, I decided to switch to a newer Linux kernel to see how it modified my problem. Things got worse. Restarting a program from Visual studio stopped working. Is there anyone that can explain me how things are supposed to work ? I think I know the basics. To start, the debugger set the bit 0x100 in EFlags ot the current context, then wine test this bit to check what parameter to send to ptrace to restart the process. It gets blurry after that ... What happens after the traced instruction executes ? At least three parts are involved: - Linux that handle the first part of the exception - Wineserver - msvcmon. It is the visual C++ remote debugging program, but I think it could be any debugger. There may be a 4th player with the exception handling part of the debugged application but I am not sure. Thanks David

2 5

Re: comctl32: Move TrackMouse handling to MouseMove
by Dimi Paun May 15, 2005

May 15, 2005

On Sat, 2005-05-14 at 11:12 -0500, James Hawkins wrote: > + LVHITTESTINFO lvHitTestInfo; > + INT nItem; > + > + if (infoPtr->bLButtonDown) { > + lvHitTestInfo.pt = infoPtr->ptClickPos; > + nItem = LISTVIEW_HitTest(infoPtr, &lvHitTestInfo, TRUE, TRUE); > + > + if (LISTVIEW_TrackMouse(infoPtr, infoPtr->ptClickPos)) { > + NMLISTVIEW nmlv; > + > + ZeroMemory(&nmlv, sizeof(nmlv)); > + nmlv.iItem = nItem; > + nmlv.ptAction.x = infoPtr->ptClickPos.x; > + nmlv.ptAction.y = infoPtr->ptClickPos.y; > + > + notify_listview(infoPtr, LVN_BEGINDRAG, &nmlv); > + > + return 0; > + } Please use 4-space indentation for new code. Currently listview is a mixture of 2/4 space indentation, but we should be moving towards 4 spaces if it's not a problem. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

Re: Video Capturing under Wine
by Maarten Lankhorst May 14, 2005

May 14, 2005

> Basically applications have two obvious ways to use video capture > services in Windows. One is avicap32.dll which is basically the Video > for Windows way of doing this and the other one is > ActiveMovie/DirectShow, soon to be obsoleted by Microsoft as well, as it > seems. > Avicap32 implements two functions, one is for the enumeration of the VfW > devices registered in the system. For this it does enumerate all entries in > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvideo > and for compatibilty reasons with 16bit Windows also in the Drivers32 > section in system.ini. I have an untested version of this code already. > The enumeration function does not try to detect any devices other than > what it finds in above mentioned places. I assume that a webcam driver > installation would have to do that. > The second function in Avicap32.dll creates a (hidden) window which > handles the actual interaction with the video device as well as being an > optional user interface for the video data. The communication with the > video device is always by so called installable drivers, like wineoss, > etc. is used for audio devices. The interface to these installable video > drivers is for the video device specific parts declared in a header file > msviddrv.h which is really part of the DDK. (How would we add that to > the Wine headers?) > In modern Windows systems there is one MS provided installable driver > vfwwdm32.dll, which is basically a translation layer between the > installable interface and modern WDM stream based video drivers. We are not windows, using HKLM/SYSTEM/.../msvideo would not be an option imho, because when should we write it? And what if you just connected your webcam and modprobe'd the drivers for it, it would make things too difficult. I think the best way is to use winmm like dsound/etc uses, and add a configure option in ~/.wine/config so you can select what video driver you want to use. Since I don't exactly know how winmm works, some insight in how (for example) the sound drivers in winmm are called/used would be more then welcome, since, unlike the rest of the stuff I worked upon until now was well documented, but I doubt winmm is... Maarten Lankhorst

2 2