wine-devel May 2005

wine-devel@winehq.org

145 participants
348 discussions

Re: A better Beep
by Marcelo Duarte 17 May '05

17 May '05

Whats happens if a program calls bepp with invalid values for dwFreq and dwDur on a linux console? (the programmer thinks that dwFreq and dwDur are ignored by Win95). David Lee Lambert escreveu: >Changelog: > Support beeping with the PC speaker when running from the Linux console > > > >------------------------------------------------------------------------ > >--- dlls/kernel/console.c.v1_39 Fri May 13 15:38:16 2005 >+++ dlls/kernel/console.c Fri May 13 21:02:19 2005 >@@ -193,9 +193,19 @@ > */ > BOOL WINAPI Beep( DWORD dwFreq, DWORD dwDur ) > { >- static const char beep = '\a'; >- /* dwFreq and dwDur are ignored by Win95 */ >- if (isatty(2)) write( 2, &beep, 1 ); >+ if (strcmp(getenv("TERM"),"linux")==0 && isatty(2)) { >+ /* the Linux console supports setting frequency and duration */ >+ char szBeep[50]; >+ snprintf(szBeep,50,"\x1B[10;%d]\x1B[11;%d]\a",(int)dwFreq,(int)dwDur); >+ write( 2, szBeep, strlen(szBeep) ); >+ usleep(dwDur*1000); >+ } else if (isatty(2)) { >+ /* dwFreq and dwDur are ignored by Win95 */ >+ static const char beep = '\a'; >+ write( 2, &beep, 1 ); >+ } else { >+ /* TODO: we could play a .wav file instead... */ >+ } > return TRUE; > } > > >

1 0

exeCryptor
by Kenneth Porter 17 May '05

17 May '05

<http://www.strongbit.com/execryptor.asp> Anyone have experience with this on WINE? Another developer pointed this out to me for use with a Windows binary, and is not releasing Linux betas because there's no native Linux equivalent. (The app works fine native in Linux, but the dev want's to prevent unauthorized use until GA.)

3 4

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink 17 May '05

17 May '05

The user interface is what the user has to do to use the program. This is not supported in Wine. You will find links from winehq to several lists of things that run under Wine. When you attempt to use these lists you will find that many if not most of the programs do not run as is. The user outside the Wine world sees a totally false picture of Wine. He loads Wine and finds there are NO current instructions on how to use it so he presumes Wine to be worthless and goes away. Even if he persists there is still the problem of figuring out exactly how to make many if not most of the programs in the will run database work. The public simply won't put up with this. You can't have Wine so that a user must be a priest to load a special dll or to find out what special dll is necessary. Currently, there needs to be a short document written and KEPT up to date. To install and use Wine do ....... This document needs to point to somewhere where the user can get more help. There needs to be a WIKI where postings can be made specifically concerning what is necessary to make a program work on Wine. How do you currently make Office or Acrobat work on Wine? To my knowledge there are currently no large or complicated programs that you just load and run under Wine. You must set them all up first. It doesn't make any difference to the user if a program fails because of a sound driver. Waiting for all this to be fixed perfectly means a wait forever and serves no purpose without at least simple instructions on how to use Wine now.

4 4

DirectX and Games
by Ivan Gyurdiev 16 May '05

16 May '05

Out of curiosity, why hasn't Oliver's swapchains and stateblocks patch been merged? I saw that in wine-patches about 10 days ago, but it hasn't been merged, and there's no comments at all. ===== On an unrelated note, what is causing this bug: http://bugs.winehq.org/show_bug.cgi?id=2082 As I understand, this is a regression, since Diablo used to work a long time ago, and then some patch broke it. The bug was opened sometime in March... -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

3 3

Re: edit: no not use LOCAL_*() functions
by Alexandre Julliard 16 May '05

16 May '05

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > @@ -426,19 +425,21 @@ static LRESULT WINAPI EditWndProc_common > { > EDITSTATE *es = (EDITSTATE *)GetWindowLongW( hwnd, 0 ); > LRESULT result = 0; > + STACK16FRAME *stack16; > + HANDLE16 oldDS; > > TRACE("hwnd=%p msg=%x (%s) wparam=%x lparam=%lx\n", hwnd, msg, SPY_GetMsgName(msg, hwnd), wParam, lParam); > > if (!es && msg != WM_NCCREATE) > return DefWindowProcT(hwnd, msg, wParam, lParam, unicode); > - else if (msg == WM_NCCREATE) > - return EDIT_WM_NCCreate(hwnd, (LPCREATESTRUCTW)lParam, unicode); > - else if (msg == WM_DESTROY) > - return EDIT_WM_Destroy(es); > > + if (es && (msg != WM_DESTROY)) EDIT_LockBuffer(es); > + > + /* Make sure DS points to hInstance for 16-bit apps */ > + stack16 = (STACK16FRAME*)MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); > + oldDS = stack16->ds; > + stack16->ds = GetWindowLongPtrW( hwnd, GWLP_HINSTANCE ); It seems dangerous to set DS for the whole window procedure, it will be calling a lot of other functions that may end up depending on DS. It's especially dangerous here since the window instance won't be a valid DS for 32-bit windows. I think you really want to set it only around the Local* calls and restore it as soon as possible. -- Alexandre Julliard julliard(a)winehq.org

2 1

Unknown stab type in crashes
by James Hawkins 16 May '05

16 May '05

Hey, Whenever wine crashes, I get a long stream of err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e Does everyone else get that too? Does anyone have info on this? It's understandable to output an unknown type, but it does make the backtrace pretty much useless. After a couple parts of the bt, the error message files a couple hundred lines, then another couple lines of the bt, so I can't see the whole bt at once. Sometimes parts of the bt are scrolled up past my history limit. I don't mean to complain, but it is hampering debugging a bit. -- James Hawkins

4 6

Re: comctl32: Move TrackMouse handling to MouseMove
by Alexandre Julliard 16 May '05

16 May '05

James Hawkins <truiken(a)gmail.com> writes: > This patch also fixes the WM_LBUTTONUP bug, and the new behavior with > listview is even better. The logic behind this is that we only want > to track the mouse by calling TrackMouse when the mouse moves. What you really want is to only start tracking if it moves by more than a certain amount, which is what LISTVIEW_TrackMouse already tries to do in a very inefficient way. So you should probably move all the logic from LISTVIEW_TrackMouse to the MouseMove handler. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: test-and-dereference: a common problem?
by Alexandre Julliard 16 May '05

16 May '05

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 16 May '05

16 May '05

"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 16 May '05

16 May '05

"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

← Newer
1
...
13
14
15
16
17
18
19
...
35
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 May 2005